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.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
