iptables, the Linux firewall engine, is capable of a lot more than I’d previously given it credit for. It seems like it has native support for things like OS fingerprinting and port-scan detection, plus analysis of low-level TCP headers that mere mortals like me probably shouldn’t touch. Tarpitting and ECN support, too.<\/p>\n
It also turns out that in addition to commands like \/etc\/init.d iptables {start, stop, restart...}<\/tt>, there’s a panic<\/tt> that will restart iptables with a policy of dropping all traffic. Kind of a neat thing for the back of your head — just don’t do it over ssh! \ud83d\ude42<\/p>\n
Of course, as with a lot of advanced firewall tools, things get complicated very quickly. I just tried allowing NTP traffic to my machine and it’s still being refused. If I disable iptables momentarily, traffic goes right through. I need to look more into it, but suspect it involves the “custom” chains that CentOS (probably derived from RHEL) includes.<\/p>\n
Edit: Ha. They want you to use the “RH-Firewall-1-INPUT” chain instead of just “INPUT,” and the rule I was adding was getting put at the bottom — right after the default deny rule. iptables -I RH-Firewall-1-INPUT 9 -p udp --dport 123 -j ACCEPT<\/tt> (don’t run without understanding: it refers to a specific position in your rules) put it right before<\/em> the deny; -I lets you specify the position (9th in the RH-Firewall-1-INPUT chain) to put the rule into, as opposed to -A (add to the bottom).<\/p>","protected":false},"excerpt":{"rendered":" iptables, the Linux firewall engine, is capable of a lot more than I’d previously given it credit for. It seems like it has native support for things like OS fingerprinting and port-scan detection, plus analysis of low-level TCP headers that … Continue reading