Home / server / Questions / 708474
Accepted
Frank Barcenas
Asked: 2015-07-26 07:23:50 +0800 CST

IPTABLES not working, fail2ban still notifying me of instrusions from those ips

  • 772

I added 200 hundred iptable rules like these:

iptables -A INPUT -s 108.62.150.0/24 -j DROP
iptables -A INPUT -s 109.108.64.0/19 -j DROP
iptables -A INPUT -s 109.110.32.0/19 -j DROP

to block russian and eastern europe ips from my server.

However, my fail2ban is still going off for many of the ips which fall within those ranges.

The begining of my rule set looks like so:

Chain INPUT (policy DROP)
target     prot opt source               destination         
DROP       tcp  --  0.0.0.0/0            127.0.0.0/8         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
DROP       all  --  224.0.0.0/4          0.0.0.0/0           
PUB_IN     all  --  0.0.0.0/0            0.0.0.0/0           
PUB_IN     all  --  0.0.0.0/0            0.0.0.0/0           
PUB_IN     all  --  0.0.0.0/0            0.0.0.0/0           
PUB_IN     all  --  0.0.0.0/0            0.0.0.0/0           
PUB_IN     all  --  0.0.0.0/0            0.0.0.0/0           
DROP       all  --  0.0.0.0/0            0.0.0.0/0           
DROP       all  --  108.62.150.0/24      0.0.0.0/0           
DROP       all  --  109.108.64.0/19      0.0.0.0/0           
DROP       all  --  109.110.32.0/19      0.0.0.0/0           
DROP       all  --  109.110.64.0/19      0.0.0.0/0           
DROP       all  --  109.111.176.0/20     0.0.0.0/0

Why are they still getting through?

Is it the PUB_IN statements?? Should my block(DROP) rules appear before the PUB_IN rules?

iptables

1 Answers

  1. Best Answer

    The order of rules in Netfilter tables are important. You should move PUB_IN and ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 rules after your DROP rules. The rule with state RELATED,ESTABLISHED should remain in place.

    If the rules are matching complementary traffic, you should order them with bigger prefixes on top (e.g. /4 should be on top /32 on bottom). If they overlap (they could match same packet), reordering them will change the semantic, but if they are complementary, it is safe to reorder them.

    • 5