We have structured our Iptables by saying, at the front of the filter/INPUT chain,
Chain INPUT (policy ACCEPT) num target prot opt source destination 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 2 drop-rules-INPUT all -- 0.0.0.0/0 0.0.0.0/0 3 firewall-filter-INPUT all -- 0.0.0.0/0 0.0.0.0/0 The drop-rules-INPUT chain is where we institute our fail2ban checks, and any others that would DROP or REJECT incoming packets. The firewall-filter-INPUT is more of a test for OK stuff, and accept, or reach the end of the chain and log, and DROP. Somewhere along the line, fail2ban would enter bans, but the conntracking stuff would allow those sites, giving them ESTABLISHED or RELATED state. We scratched our heads, and for every ban, we add a rule to raw/PREROUTING wherein the banned IP is marked NOTRACK: Chain PREROUTING (policy ACCEPT) num target prot opt source destination 1 NOTRACK all -- 139.99.119.241 0.0.0.0/0 2 NOTRACK all -- 119.2.4.36 0.0.0.0/0 With these NOTRACK rules in place, it all works like a charm. The Question is: is there a better test than iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT that will give us better results, and make the raw / PREROUTING rules unnecessary? I don't think we want our thousands of tests (we are using ipset a lot) to be run thru on every packet, what a waste of cpu cycles! murf -- Steve Murphy ParseTree Corporation
_______________________________________________ Fail2ban-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fail2ban-users
