On Fri, 8 Sep 2000, Andi Kleen wrote:
:The source address does not matter.
Well from the attacker's point of view I believe it does. For many reasons
starting from the fact that the more ip addresses, the more difficult to
block (per ip-blocking firewall basis) and, if there is a chance for the
linux ipv4 code of handling some kind of floods per host basis (eg buffering
"bad" hostips for some time for doing some special communication with those),
then it is even worse. Btw the same can happen with userspace code doing
buffering.
:Define netdead exactly. The machine is very unresponsive to any local input,
:correct ?
During the attack and while the machine is replying RST's, seems like the
NIC cannot get a chance to send a single packet to machines connected to
the same switch. If, I disable replying of RST's (with ipfw - that is
allow only incoming and outgoing packets at specific ports), even when during
the attack is going on, the linux machine can happily communicate with others.
: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.
During the attack the linux does not have any special load and internaly,
processes and everything are doing great (either when replying RSTs or when
I have disabled them). But if it is replying RSTs, I can only sit at the
console and see it is doing great because it is unreachable (meaning it takes
about 15 minutes to get an established an ssh connection to it) from everywhere
else. In other words, apart from its network connectivity, all else is
doing great.
:I don't know why you're blocking non ACK packets, it does not make much sense.
If you live in an ideal networld, it doesn't. I don't.
:It seems your firewall can take packet floods better than your IRC server.
:Not suprising.
Actually it is not a masquerading firewall. It is only an ip-blocking
firewall. It does not take any flood. It justs forwards packets as it's
been told to and that includes all incoming TCP packets with ACK bit set at
defined port ranges.
: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)
The fact is that I am doing fine with all the other ways except for this one
from the script kiddies and that's because they make my 100mbps NIC
sing back lots of RSTs flooding itself (and the rest on the network path
that packets follow) off.
-- George Athanassopoulos http://www.real.macedonia.gr http://www.egnatia.ee.auth.gr- 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:11 EST