[linux] FC5 + iptables + nmap = DOS

[Michael Hornung]

You could also try testing for the problem by manually setting nmap's 
--max-parallelism to something low, like 100.  It will take long(er) to 
scan, but should eliminate a burst of packets that nmap will often send 
while it's trying to calculate an efficient packet rate.  That initially 
bursty traffic would be evidenced by the latency you see, then the 
following increasing RTT is due to nmap normalizing on a slower packet 
rate.

-Mike

On Tue, 22 Aug 2006 at 13:42, Michael Hornung wrote:

|It is possible if not likely that the scan is filling the state table with 
|SYN-received entries.  I know this happens.  Test this theory by doing a 
|FIN scan, or by using "-T 2" to slow down your scan and see if the 
|firewall is no longer impacted.
|
|You may be able to (but probably can't) tune your kernel to avoid this 
|problem, else you can enable rate limiting of connections (using, for 
|example, the iptables 'limit' feature) from outside hosts to protect your 
|state table.
|
|You could throw more CPU at the problem, but doing so merely raises the 
|bar and the problem still exists.  Thus rate limiting connections and 
|connection attempts (thereby limiting state table entries and state table 
|processing) is a solution that should prevent the problem from recurring.
|
|In the first paragraph above I am not condoning the use of FIN scans as a 
|permanent solution, rather just for testing the source of your problems.  
|But if you like doing FIN scans, that's your business.
|
|-Mike
|
|On Tue, 22 Aug 2006 at 13:24, Jonathan Nicol wrote:
|
||I've got a strange networking problem, I'm hoping someone can point me in the
||right direction.
||
||I've got a subnet of servers behind a bridging firewall running Fedora Core 5
||and iptables 1.3.5. When I run nmap (SYN scan) against a host behind the
||firewall, it causes packet delay/loss for all traffic to the subnet (including
||the firewall itself). Even stranger, it seems to be sporadic. Here's an example
||ping while nmap is running:
||
||64 bytes from 192.168.168.123: icmp_seq=557 ttl=64 time=0.770 ms
||64 bytes from 192.168.168.123: icmp_seq=558 ttl=64 time=0.677 ms
||64 bytes from 192.168.168.123: icmp_seq=559 ttl=64 time=0.677 ms
||64 bytes from 192.168.168.123: icmp_seq=560 ttl=64 time=0.726 ms
||64 bytes from 192.168.168.123: icmp_seq=561 ttl=64 time=10573.792 ms
||64 bytes from 192.168.168.123: icmp_seq=562 ttl=64 time=9574.044 ms
||64 bytes from 192.168.168.123: icmp_seq=563 ttl=64 time=9835.796 ms
||64 bytes from 192.168.168.123: icmp_seq=564 ttl=64 time=8835.790 ms
||64 bytes from 192.168.168.123: icmp_seq=565 ttl=64 time=7813.559 ms
||64 bytes from 192.168.168.123: icmp_seq=566 ttl=64 time=6813.680 ms
||64 bytes from 192.168.168.123: icmp_seq=567 ttl=64 time=5813.758 ms
||64 bytes from 192.168.168.123: icmp_seq=568 ttl=64 time=4813.821 ms
||64 bytes from 192.168.168.123: icmp_seq=569 ttl=64 time=3813.842 ms
||64 bytes from 192.168.168.123: icmp_seq=570 ttl=64 time=2813.864 ms
||64 bytes from 192.168.168.123: icmp_seq=571 ttl=64 time=1814.021 ms
||64 bytes from 192.168.168.123: icmp_seq=572 ttl=64 time=813.886 ms
||64 bytes from 192.168.168.123: icmp_seq=573 ttl=64 time=0.742 ms
||64 bytes from 192.168.168.123: icmp_seq=574 ttl=64 time=0.734 ms
||64 bytes from 192.168.168.123: icmp_seq=575 ttl=64 time=0.648 ms
||64 bytes from 192.168.168.123: icmp_seq=576 ttl=64 time=0.668 ms
||
||... and then it (usually) continues working as normal, even as the scan keeps
||running. It's not a big problem in a lab/office enviornment, but this is
||destined for the wild, wild Internet.
||It seems pretty strange that the offendingly high pings decrease by almost
||exactly 1000 ms every time. There's nothing I would call unusual about the
||firewall, there are no rate limits etc, the only STATE rules are allowing
||Established and Related packets. The problem doesn't seem to occur at all with
||the firewall disabled, but I can't say for sure, as it is seemingly random
||already.
|
|