Messages in this thread |  | | Date | Fri, 8 Sep 2000 21:44:47 +0300 (EEST) | From | George Athanassopoulos <> | Subject | Re: linux kernel TCP, network connections and iptables |
| |
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/
|  |