Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
auth_update crash
Dec 23, 2017, 10:15 pm
By Remcon
check_tumble
Dec 18, 2017, 7:21 pm
By Remcon
parse description bug
Dec 15, 2017, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Users Online
CommonCrawl, Yandex, DotBot, Yahoo!

Members: 0
Guests: 7
Stats
Files
Topics
Posts
Members
Newest Member
478
3,708
19,242
612
Jacki72H
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » General » General Discussions » Is there a problem with mudby...
Forum Rules | Mark all | Recent Posts

Is there a problem with mudbytes?
< Newer Topic :: Older Topic >

Pages:<< prev 1, 2 next >>
Post is unread #21 Jun 10, 2009, 6:58 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

I see -- since we were talking about forums and spammers there, or even spammers at a given MUD, I was trying to figure out what the functional difference between blocking their connection at the service level or firewall level (there isn't any, unless you're talking about a DOS). Of course, if one wants to block them for all services, the firewall is the way to go.

But this whole conversation got started because of ranged IP bans being too aggressive, and AFAICT none of this talk speaks to fixing that. In particular, requiring registered users at the firewall is (w.r.t. one service) functionally no different from requiring registered users at the service itself.
       
Post is unread #22 Jun 11, 2009, 9:09 pm
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

Given how long the current tcp/ip has been established and it's present wide-spread usage, add to that the advent of IPv6, I'm not really sure that there is a reasonable way to actually fix it. This conversation was really more of a "it's too bad that we don't have a better way to handle this" than a "let's come up with a better way to handle this" sort of thread. Though if you have something in mind that could be done to eliminate the need to use broad IP range bans to block individuals which sometimes also means inadvertantly blocking individuals we hadn't intended to, I'm sur we'd love to hear your ideas. As far as blocking someone at the firewall versus at the service via IP, yes, you're right, the only functional difference is which log their hit gets added to and whether they can still access other things on the network/machine in question.
       
Post is unread #23 Jun 11, 2009, 10:07 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

I guess what I'm saying is that I'm not convinced that there really is a better way with IPv4 or IPv6. The main functional difference between stopping somebody at the firewall vs. the application -- no matter how you accomplish that, be it via IP blocks or authentication -- is that it's cheaper to stop connections before they're fully established, and perhaps more secure in case the application has vulnerabilities.

That said, the DOS problem is a very real one and is recognized by security people, because the process of starting up a TCP/IP session, even if you throw it away shortly thereafter, is actually somewhat expensive on the server end, when you're doing it hundreds of times a second.

Basically I think the security problem here is intrinsic in the requirements:
- Broad IP range bans are bad because you lose people, so you avoid broad IP range bans.
- Single IP range bans, and in fact almost anything based on IP, don't work, because people can easily change IPs (e.g., via proxies).
- Username bans don't work, because a new username can be quickly created at the application.
- For various reasons, we want the username creation process to be open.

I think that from the above, it becomes clear that we have conflicting goals: not wanting to block too many people vs. blocking the right person; blocking username creation to avoid spammers vs. not blocking legitimate new users, ...

What you would really need is some way to guarantee that a connection is coming from a very specific person. Perhaps this could be accomplished with some kind of message signing, such that a packet says who it's from, and the contents are signed with that person's private key. You would only be able to read the message if you were able to access the person's public key. The key point (no pun intended) is that such keys would have to be uniquely identifiable with a single person, as opposed to some generic password mechanism, and that such keys would have to be relatively difficult to acquire. Of course this idea has tons of problems with it, and would require a much more considerable rethinking of how the internet works than merely moving to IPv6.


All of the above said, yes, it really is too bad that it's so hard to uniquely identify people. :sigh: I guess that's just life, though, when you have a protocol that is basically anonymous and where things can come from anywhere, with unlimited levels of indirection via proxies etc.
       
Post is unread #24 Jun 11, 2009, 11:20 pm
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

Hmm, I think I said basically the same thing with significantly more brevity. :tongue:
       
Pages:<< prev 1, 2 next >>