Sections of the example /etc/init.d/filrewall contain lines like: #Flood protection $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \ ALL RST --dport ssh -j ACCEPT $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \ ALL FIN --dport ssh -j ACCEPT $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \ ALL SYN --dport ssh -j ACCEPT $IPTABLES -A allow-ssh-traffic-in -p tcp --dport ssh -j ACCEPT which are intended to limit SYN, FIN and RST floods. However, the final ACCEPT in the chain defeats the whole purpose. Reproducible: Always Steps to Reproduce: 1. Load the iptables rules in the example (/etc/init.d/firewall start) 2. hping --fast --syn (or --rst or --fin) --destport <port> <host> 3. Actual Results: All packets have been delivered Expected Results: Only 1/second should be allowed (mod bursting)
I'll take the security-guide bugs
Would substituting """ $IPTABLES -A allow-ssh-traffic-in -p tcp --dport ssh -j ACCEPT """ with """ $IPTABLES -A allow-ssh-traffic-in -m state --state RELATED,ESTABLISHED -p tcp --dport ssh -j ACCEPT """ suffice? SYN's aren't accepted since the connection isn't established yet; FIN's would, but once the connection is closed it doesn't do any more harm.
Proposed fix, part of #26705: @@ -2565,7 +2583,7 @@ ALL FIN --dport ssh -j ACCEPT $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \ ALL SYN --dport ssh -j ACCEPT - $IPTABLES -A allow-ssh-traffic-in -p tcp --dport ssh -j ACCEPT + $IPTABLES -A allow-ssh-traffic-in -p tcp --dport ssh -j DROP #outgoing traffic einfo "Creating outgoing ssh traffic chain"
wrt to Comment #2, I'm not sure what the potential harm of a "FIN Flood" would be on an already-closed connection. For that matter a "RST Flood" would probably fall into the same category. It wouldn't have the same damage of leaving state machines in long-term waiting states, like a SYN flood, but it would take som processing time (as would processing rules, so a wash?) The fix in Comment #3 seems broken, unless you also include the fix in Comment #2. Otherwise, you end up dropping all traffic to these ports, other than rate-limited SYN, FIN and RST packets. Perhaps if the allowed-connection chain was run earlier, that would also work...
okay, using the first fix instead of the second...
Committed
