[1046] in linux-security and linux-alert archive
Re: [linux-security] inetd and denial-of-service
daemon@ATHENA.MIT.EDU (Racer X)
Thu Aug 22 05:30:03 1996
Date: Wed, 21 Aug 1996 23:19:14 -0400 (EDT)
From: Racer X <shagboy@wspice.com>
Reply-To: shagboy@bluesky.net
To: Joel Maslak <j@pobox.com>
cc: Linux Security Mailing List <linux-security@tarsier.cv.nrao.edu>
In-Reply-To: <Pine.LNX.3.95.960819184623.22341H-100000@blackhole.mordor>
On Mon, 19 Aug 1996, Joel Maslak wrote:
> evil.com writes a program which, all at once, sends out 40 connection
> requests to good.edu's telnet port. Good.edu's inetd, thinking that
> something is broke stops allowing incoming telnets.
>
> Ideas for solution:
>
> 1. Add a number after nowait for TCP services in /etc/inetd.conf. This
> number represents the max number of requests per minute. Set it to 32000
> or something. Note that this requires a recent version of inetd. (I run
> 1.1)
This sounds pretty good, but what do you do when you pass the limit
(whatever it is)? Would you shut down the service, or just start
ignoring connects?
[REW: my inetd closes the socket causing "connection refused" errors]
> 2. Block access to all ports except from "trusted sites". This assumes a
> open environment where the network medium is generally trusted. Note that
> IP spoofing attacks can occur if the network is not trusted.
This can be done with TCP wrappers.
[REW: Not quite. If inetd drops the port, tcpd won't get started.
Another problem is that a tcpd is started for every connection. This
means that state would have to be passed by files, creating locking
problems etc etc. -> Not trivial. Inetd seems fine to me.]
I started thinking about this a couple of days ago (right after I read
the source for the SYN-flooder in the latest 2600). I thought of a way
to at least try to avoid total denial-of-service.
>From the sources I have seen for SYN-flooders, they generally forge the
source address. One style is to generate random source addresses, the
other is to take a user-specified address. A way around the first style
is this:
If the max number of connects per unit time is passed, stop the server
for (say) 1 or 2 minutes. Then try to reverse DNS all those connects on
that port. Any that can't be reversed should be immediately dropped.
Once you're back under the limit, restart the server.
You could get around the second style by specifying a max number of
connects to accept from any one site at a time. However, passing this
limit would not shut down the server, it would just deny that site until
it was back under limit.
[REW: We use this to limit "misuse" of our NNTP server. Just sleep for
a second after each request before servicing the next one.... This
would not "break" the script but severely limit the performance for
the guy who started this thread....]
The more I think about this though, the more it seems this would be
better implemented in TCP wrappers (tcpd). It doesn't seem TOO difficult
to do, although I'm not sure if you would have to do anything in kernel
space too. For instance, if you have a connect that is in state
SYN_RECV, can you just arbitrarily drop it, or do you have to wait for
something to timeout in the TCP code?
[REW: You could fiddle with the firewall rules to lock out certain
hosts/ports....]
shag
Judd Bourgeois | When we are planning for posterity,
shagboy@bluesky.net | we ought to remember that virtue is
Finger for PGP key | not hereditary. Thomas Paine
