Denial of service process table attacks

1999-02-23 Thread John Conover

On http://lwn.net/daily/ptable.html is a description of denial of
service process table attacks. Am I correct that tcpserver limits
fork() calls to a specified number, and therefore alleviates the
situation?

Thanks,

John

-- 

John Conover, 631 Lamont Ct., Campbell, CA., 95008, USA.
VOX 408.370.2688, FAX 408.379.9602
[EMAIL PROTECTED], http://www2.inow.com/~conover/john.html



Re: Denial of service process table attacks

1999-02-23 Thread Mark Delany

At 05:31 23/02/99 -, you wrote:
On http://lwn.net/daily/ptable.html is a description of denial of
service process table attacks. Am I correct that tcpserver limits
fork() calls to a specified number, and therefore alleviates the
situation?

Correct. As long as you run all of your services via tcpserver.

Whilst some inetd implementations have crude forms of DOS protection 
(initially created for other reasons) I'm not aware of too many that protect 
against concurrency - most do it by rate.


Regards.



Re: Denial of service process table attacks

1999-02-23 Thread Scott Lystig Fritchie

 "md" == Mark Delany [EMAIL PROTECTED] writes:

md Whilst some inetd implementations have crude forms of DOS
md protection (initially created for other reasons) I'm not aware of
md too many that protect against concurrency - most do it by rate.

Heh.  If I may take a slight detour to tell an inetd-related war
story, even if it isn't directly qmail-related

In a former life, I was the sysadmin for a cable-based ISP in the US.
One customer was in the middle of transitioning email services from
machines they ran to our machines.  Their boxes were using an older
Red Hat distribution and were using Sendmail + the Qualcomm POP
daemon.  I avoided working on those machines (they weren't really
mine), but the transition wasn't going fast enough ... so I had to
grease the squeaky wheel.

In the evenings, the POP service would become unavailable due to
inetd's rate-limiting.  Spending as little time as possible to "fix"
the problem, I had a cron job check the POP service every minute and
SIGHUP inetd every time it was unavailable.  But during the busy
evening times, the SIGHUPs were remarkably frequent.  Oh, 40-50
times/hour, with 5-minute load averages rising into the teens.

Trying another quick fix, I simply dropped qmail's tcpserver in place
of inetd for starting the POP server.  I set the session limit at 60.
This killed the machine performance-wise.  Thrash-O-Matic.  Unlike
before, when the machine started thrashing now, it was pretty obvious
that syslog was a huge problem.

I finally discovered that syslogd was the cause.  As syslog was
logging events from Sendmail and the POP daemon's login/logout events,
it used fsync() after each event.  The disk couldn't keep up during
busy times, so openlog() calls started blocking ... causing load
averages to rise, delays in SMTP and POP server initial greetings, POP
client retries making things worse.  Until the inetd throttle kicked
in.  Then enough syslog could finally catch up, the number of blocked
processes dropped, and life returned to (near) normal.  Then my cron
job would HUP inetd, and the cycle repeated.  When I started using
tcpserver, things went to hell because there was no emergency escape
valve (namely that !@#$! inetd) to keep syslog from getting too busy.

I recompiled syslogd without the fsync() call, and the system gently
purred through the busiest times thereafter.

A lot of people don't know about inetd's throttle mechanism.  I didn't
know there were any modern UNIXen which still used it.  Live and
learn.

-Scott
---
Scott Lystig Fritchie
5401 - 10th Ave S, Minneapolis, MN 55417 USA
Professional Governing: Is It Faked?



Re: Denial of service process table attacks

1999-02-23 Thread Justin M. Streiner

On Tue, 23 Feb 1999, Mark Delany wrote:

 At 05:31 23/02/99 -, you wrote:
 On http://lwn.net/daily/ptable.html is a description of denial of
 service process table attacks. Am I correct that tcpserver limits
 fork() calls to a specified number, and therefore alleviates the
 situation?
 
 Correct. As long as you run all of your services via tcpserver.

Too bad similar protection isn't currently available for udp and RPC
services :-)

jms