On Sat, 20 Feb 1999, Mark Boolootian wrote: > The Process Table Attack is a [relatively] new kind of denial-of-service > attack that can be waged against numerous network services on a variety of > different UNIX systems. The attack is launched against network services Although not without quirks, I recommend that anyone interested in defending against this attack take a look at xinetd. It solves these problems and others, and has been available for a number of years (I started using it in 1993): (xinetd README) ] Q. Why should I use it ? ] A. Because it is a lot better (IMHO) than inetd. Here are the reasons: ] ] 4) It can prevent denial-of-access attacks by ] a. placing limits on the number of servers for each service ] (avoids process table overflows) ] b. placing an upper bound on the number of processes it will fork ] c. placing limits on the size of log files it creates > 2. Alternatively, if there are more than a preset number of network daemons > for the service running, incoming requests should be queued rather than > serviced. This is the approach that xinetd takes: (xinetd.conf manpage) ] instances determines the number of servers that can ] be simultaneously active for a service (the ] default is no limit). The value of this ] attribute can be either a number or UNLIM- ] ITED which means that there is no limit. > 3. Network services (such as finger) should implement timeouts. For > example, the statement alarm(30) could be inserted into the finger > daemon source code so that the program would stop running after 30 > seconds of execution. Or, better yet, a timeout option should be implemented in the inetd daemon. I have added this to my local copy of xinetd 2.2.1 with the following syntax: timeout = 30 # 30-second timeout timeoutsig = SIGINT # signal to send when timeout is hit Modifications are fairly trivial, does anyone know if Jan Wedekind and Chuck Murcko are still maintaining it? > [Simson informed me over a year ago that he had discovered this attack > and had notified many relevant operating system vendors. To the best of > my knowledge, no one has addressed the problem in the intervening year. Again, check out xinetd. It's not new and flashy (and it doesn't work with TLI services) but is does the job well. I have found it to be rock-solid. -James -- James D. Lockwood The (former) Getty Information Institute System Administrator 1200 Getty Center Drive, Suite 300 jamesat_private Los Angeles, CA 90049-1680
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:37:22 PDT