Re: [Admin] [SERIOUS PROBLEM] Vicious attacks on MUD?

From: Sammy (samedi@DHC.NET)
Date: 09/01/97

On Sun, 31 Aug 1997, Chris Jacobson wrote:

> It appears my MUD may be the victim of some odd occurrence...
> It appears that at times, there will be attempts to connect from odd IPs,
> including and  Suddenly massive lag will
> ensue the MUD (but not the server... I'm on the shell or the 'builder'
> version of the MUD and nothing happens).  Doing a reboot or copyover
> (usually) solves the lag problem, but it can be SO severe that thge lag
> can be up to several minutes.

I've seen the same thing.  I never did find a good explanation for it, but
I think it's probably not a malicious hacker.

> Today it happened again while I was on. tried to
> connect, and suddenly major lag.  So I went and tried to DNS it from my
> own machine, and it didn't, so I pinged it, no response.
> So what might fix this odd problem?  Basically, it appears that fake
> connects are attempted, and it causes major lag on the program, including
> causing the CPU resource time to shoot way up (after 24 hours of running,
> the MUD uses less than 1 minute of CPU time at most.  When the fake
> connects are attempted, it uses practically 80% of the CPU time!  Within
> 2 minutes the CPU time is well over a minute and a half).

There's a very easy way to fix this.  Look in new_descriptor() in comm.c.
I added a check right before the part that creates the new descriptor
WHat I did was to try to write to the socket, and if it failed, return a 0
from new_descriptor to flag it as a bad socket.

/* code that checks to see if the mud is already full */

if((write_to_descriptor(desc, "Validating socket...\r\n")) < 0) {
  return 0;

/* create a new descriptor */

The mud I did this on had an ansi color prompt, so I put that in place of
"Validating socket".  This will eliminate the lag caused by these
connections and get rid of them a lot sooner than stock circlemud would.


     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | |

This archive was generated by hypermail 2b30 : 12/08/00 PST