Of late I have a former player/staff member who is using tintin to connect to the mud, but not anything else. Now, you are probably thinking, "Big freaking deal! So what?" Well, when it's done over 140,000 times and it overloads the descriptor flow, it's a big deal.

This is what's happening. he connects, gets the color prompt, and then (I'm assuming) starts another session up with a trigger to start it all over again.

The user is using two accounts, one is a DSL through Qwest (who is a pain in the ass to talk to), and the other is a mud server, Tamarisk in Canada. I've sent emails to Qwest to their abuse email, and got diddly squat in response. We have also sent logs and emails to Tamarisk, but since our "mud logs" aren't "server logs" they apparently arent' reliable enough.

This is causing our descriptors to not be available when people try to legitimately log in, and is making some HUGE log files which is filling up our space.

Our host (Betterbox) has banned the first two sockets from connecting to the shell at all on any ports, but now this morning there's a new IP (big shock right?) on another class B that Qwest owns. Sure, we could ban all the Qwest ranges, there's only 6 Class B ranges, so around 500,000 users would be banned, but that's insane.

I've left messages with the FBI's office that handles DOS attacks, but not heard anything back, and I've filed incident reports with them as well, but let's be honest, we're a game running 60 players, not a website with a million users, so are they really going to do squat?

Any ideas from ANYONE out there what we might be able to do?

Thanks,

Terloch

I'm not sure if I should bother posting this, because I'm sure you've thought of it already, but just do a host check (leave it reasonible though), maybe have a max of ten descriptors available to any given IP, and if they already have 10 don't accept the connection. This might be a cpu-consuming task if you have a lot of players to check hosts on each time someone connects, but it should work until the kiddy finds another poor mud to attack.

We actually did do that, so now he connects 10 times, drops all of the connections and starts over...here's a bit of log so you can see...

Tue Jan 28 05:47:57 2003 :: Sock.sinaddr:  63.230.45.111
Tue Jan 28 05:47:58 2003 :: Sock.sinaddr:  63.230.45.111
Tue Jan 28 05:47:58 2003 :: Sock.sinaddr:  63.230.45.111
Tue Jan 28 05:47:58 2003 :: Sock.sinaddr:  63.230.45.111
Tue Jan 28 05:47:58 2003 :: Sock.sinaddr:  63.230.45.111
Tue Jan 28 05:47:59 2003 :: Sock.sinaddr:  63.230.45.111
Tue Jan 28 05:47:59 2003 :: Sock.sinaddr:  63.230.45.111
Tue Jan 28 05:47:59 2003 :: Sock.sinaddr:  63.230.45.111
Tue Jan 28 05:47:59 2003 :: Sock.sinaddr:  63.230.45.111
Tue Jan 28 05:48:00 2003 :: Sock.sinaddr:  63.230.45.111
Tue Jan 28 05:48:00 2003 :: EOF encountered on read.
Tue Jan 28 05:48:00 2003 :: EOF encountered on read.
Tue Jan 28 05:48:00 2003 :: EOF encountered on read.
Tue Jan 28 05:48:00 2003 :: EOF encountered on read.
Tue Jan 28 05:48:00 2003 :: EOF encountered on read.
Tue Jan 28 05:48:00 2003 :: EOF encountered on read.
Tue Jan 28 05:48:00 2003 :: EOF encountered on read.
Tue Jan 28 05:48:00 2003 :: EOF encountered on read.
Tue Jan 28 05:48:01 2003 :: EOF encountered on read.
Tue Jan 28 05:48:01 2003 :: EOF encountered on read.

Then 10-20 seconds later, 10 more connections, 10 more drops, and so on...

I second Koryon's idea. You can also automatically ban this IP when it reaches a certain threshold, so it wouldn't be bothered by him changing hosts. Another problem is that some codebases limit the amount of incoming connections per pulse. This is actually a good idea in general because it limits the effectiveness of distributed DoS attacks, but in your case it would harm legitimate users due to their experiencing severe lag when trying to connect, even when the attacker has his IP banned. So I'd recommend attempting to accept a new connection when the connection you've accepted is banned, so you can kill all of his connections each time around. Depending on how you do this, it could hammer your CPU and disk resources, so you might want to optimize it with an in-memory ban table.

You might also want to get your administrator to write you a little script so that your mud can execute an IP ban on your own port using the system's internal firewall. This would probably be the optimal solution.

Well, you said he uses tintin, tintin usually means a UNIX os, so... when your mud detects him doing this to you, have you mud port scan him and start DoS'ing him... this is probably a bad idea, very illegal, but hey, it'd tick him off, might make him go away..

(Seriously here...) It might also be more effecient when determing if it's this guy, to hash all the connect hosts (the corresponding value would be number of connections), this will save searching through your descriptor list anyway. But Yui has probably got it right, get the mud to auto-add him to a firewall if you can.

A Mud summarily trying a Dos...now I've heard it all.

Seriously, if you're worried about too many open descriptors, launching a DOS would be pretty retarded, unless I'm missing something fundamental.

-Xanes -=- Lone Coder WinterMUTE