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@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
