On Fri, Sep 08, 2000 at 05:49:35PM +0300, George Athanassopoulos wrote:
> On Fri, 8 Sep 2000, Andi Kleen wrote:
>
> :The only way to fix that with TCP is to pull the plug. You probably didn't
> :understand it, but the RST is only *one* way where TCP replies, but there
> :are lots of other ways too (like ACKs)
>
> I think I know how TCP works but seems like you analyze the subject
> without having tested in practise.
>
> In case you want to test it yourself and see:
> Well on 4 machines located on different LANs (C class netblocks),
> run a program as root which constructs TCP ACK packets (win 65535 as shown
> in my previous tcpdump piece), and sends them coming from different
> ip addresses (of the same class c netblock though) hitting the same
The source address does not matter.
> target ip address on random target ports (try random source ports as well).
> While the attack is going on, your machine is netdead.
Define netdead exactly. The machine is very unresponsive to any local input,
correct ?
> If not, add 2 more class c netblocks on the attack and it is for sure. And
> that's because your machine send so many RST's back.
Not quite. The reason is that it processes so many interrupts that it cannot
do any other work. The NIC interrupts feeds packet much faster than the
network bottom half can process them. The NIC interrupt and the NETBH
are running near continuously, not leaving any CPU time for anything else.
It is a well known weakness. Get two machines connected via fast ethernet.
Send a stream of 64byte UDP packets from one to the other without any rate
limit. The other is nearly dead (and it doesn't send any RSTs at all). It
helps a bit to have a NIC that does proper interrupt mitigation in this
case and does flow control with your NIC [e.g. there are some hacked tulip
drivers that handle it better, most gigabit ethernet chips also handle it
better because it is a bigger problem on gigabit ethernet]
I think your analysis of that the replied RSTs are the main problem is not
quite correct.
> If you think this is only a "bandwidth" issue with 4 machines against one,
> try with source attacker machines located on less bandwidth than the target
> or even the "sum" of their bandwidth less (but not much less) than the
> target's.
> The attackers have studied really carefully TCp protocol and
> why they have choosen ACK bit set for the offending packets (well another
> reason is because I block non-ACK incoming packets before they enter
> my netblock with a firewall). Else, sending just TCP packets with no bits
They did it because that hit a well known bug in BSD stacks (making the
stack do much more work than for a simple RST). On Linux it doesn't matter
much.
I don't know why you're blocking non ACK packets, it does not make much sense.
> Afterall, I have an end-user solution about it in case you
> are interested: I take FTP service off to another machine and I firewall
> (ip-block) all packets except for those coming in listening ports and it is
> over.
It seems your firewall can take packet floods better than your IRC server.
Not suprising.
>
> Since I believe we are wasting reader's time, I made my point and
> let the ones who handle linux's kernel ipv4 decide wether or not somethng
> should be done at kernel level. For me this email thread is over unless
> something else about it comes up as "solution"/better-way-of-handling it.
> Better than nothing, is for sure that delay of sending RSTs that Alan
> suggested IMHO.
It'll probably help against clueless script kiddies that only run a single
attack script, but be warned that there are other ways to make TCP bounce
packets as well (given an established connection)
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:10 EST