On 16/05/11 19:16, David Mehler wrote:

Hello, I'm using fail2ban to block bots in conjunction with existing iptables rules. Here's a few rules from my iptables configuration:

# # Set up a temporary pass rule so we don't lock ourselves out when #doing remote ssh iptables -P INPUT ACCEPT

# # flush the current rules iptables -F

# # Allow SSH connections on tcp port 22 iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# # Set default policies for INPUT, FORWARD and OUTPUT chains iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT

iptables -A INPUT -s 202.0.0.0/8 -j DROP

This morning the ssh fail2ban jail blocked this:

202.205.176.125

and the email sent gave me this ip range: inetnum: 202.205.176.0 - 202.205.191.255

That shouldn't have even been seen it should have been blocked by the 202/8 drop rule before fail2ban even saw it. Is that not so?

Suggestions welcome. Thanks. Dave.

Rules within a chain are evaluated in order, start to finish. In your INPUT chain you ACCEPT tcp connections on port 22 (SSH) *before* you DROP all traffic from 202.0.0.0/8. That is why fail2ban is seeing it.

If that is not the intention then reverse the (relative) order of the two rules within your script. Just be careful not to lock yourself out if working remotely.