On Mon, 13 Sep 1999, Alan Cox wrote:
> > It's easy to make an inetd service unusable on Redhat Linux, by simple
> > flooding the port with connections.
>
> Its easy to set it up in inetd.conf to change the time limits if you wish
>
> > You should add a feature in inetd which limits the number of connections per
> > minute based on the source IP addr.
> > With this addition we can easily block the attacker, while keeping the services
> > enabled for regular users.
>
> You can't do that. Then you have a denial of service attack. I can force you
> to remember 2^32 IP addresses who tried to connect. That takes, oh 16Gb
> of memory. Whoops bang.
>
> If you do it by class C then you only need 64Mb for the table worst case
> but you now have another problem. A single host can take out a whole class
> C so typically one problem on a local network takes out everything on that
> network.
Agreed,
but what about having a sort of cache to store the offenders-IP,
let's say give a upperbound of 256k-1MB ?
What do think the inetd maintainers about this ?
I think it's not easy to spoof IPaddrs remotely during TCP sessions,
therefore your case 2^32 IP-addrs doesn't apply in real-world.
I think Redhat should provide out-of-the-box a secure and robust
server platform,
and inetd is one crucial part of a server.
I can easily shut down all inetd services of a Redhat Linux (other
distros too since they use the same inetd) installation,
by using a one-line script using little bandwidth.
>
> There are some alternative schemes. They require tracking the current
> number of sessions and maintaining a connections/period limit as well. The
> best you can do is increase the bandwidth an attacker needs which also
> conveniently reduces the potential dead time.
Increasing bandwidth is not the definitive solution,
since not everyone does have "fat pipes".
>
> Take a look at xinetd. It handles some of this better than inetd
>
> Alan
>
I know xinetd but I am for the "secure and robust out of the box",
than means if the user instally RH and selects server install,
the system should be configured for maximum security and robustness.
Just for curiousity: How do the inetd's or other UNIXES manage the attacker
problem (DOS) ?
regards,
Benno.
--
To unsubscribe:
mail -s unsubscribe [EMAIL PROTECTED] < /dev/null