Iptables ignoring a rule in the config file

Question

I see lot of established connections to my apache server from the ip 188.241.114.22 which eventually causes apache to hang . After I restart the service everything works fine. I tried adding a rule in iptables

-A INPUT -s 188.241.114.22 -j DROP

but despite that I keep seeing connections from that IP. I'm using centOS and i'm adding the rule like thie:

iptables -A INPUT -s 188.241.114.22 -j DROP

Right afther that I save it using: service iptables save
Here is the output of iptables -L -v

    Chain INPUT (policy ACCEPT 120K packets, 16M bytes)

     pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  any    any     lg01.mia02.pccwbtn.net  anywhere
    0     0 DROP       all  --  any    any     c-98-210-5-174.hsd1.ca.comcast.net  anywhere
    0     0 DROP       all  --  any    any     c-98-201-5-174.hsd1.tx.comcast.net  anywhere
    0     0 DROP       all  --  any    any     lg01.mia02.pccwbtn.net  anywhere
    0     0 DROP       all  --  any    any     www.dabacus2.com     anywhere
    0     0 DROP       all  --  any    any     116.255.163.100      anywhere
    0     0 DROP       all  --  any    any     94.23.119.11         anywhere
    0     0 DROP       all  --  any    any     164.bajanet.mx       anywhere
    0     0 DROP       all  --  any    any     173-203-71-136.static.cloud-ips.com  anywhere
    0     0 DROP       all  --  any    any     v1.oxygen.ro         anywhere
    0     0 DROP       all  --  any    any     74.122.177.12        anywhere
    0     0 DROP       all  --  any    any     58.83.227.150        anywhere
    0     0 DROP       all  --  any    any     v1.oxygen.ro         anywhere
    0     0 DROP       all  --  any    any     v1.oxygen.ro         anywhere

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 186K packets, 224M bytes)
 pkts bytes target     prot opt in     out     source               destination

Answer 1

The command iptables -A INPUT adds a new rule at the end of the INPUT chain. Iptables works on the 1st match principle so it is likely that you have rule that is allowing access on port 80 earlier in the chain.

Save the state of your iptables with a

service iptables save
then edit the /etc/sysconfig/iptables file and move the -A INPUT -s 188.241.114.22 -j DROP above the line that allows port 80. Save the file and run

service iptables restart

Answer 2

Like most firewall access-lists (ACLs) entries are read from top to bottom. People who are new to stateful firewalls (both host based and network based) often make an entry checking the access-list that is applied for similar rules that would match the same criteria BEFORE the rule that is entered. This is often done when a firewall administrator places a permit rule after a deny rule and curious to why they still cannot get a connection from a host.

My advice is check your access-list and see if anything matches your statement before the statement you are trying. Your deny rule should probably be at the top of the list since its a high priority for you to block that traffic. Just be specific as to what host you want to block.

Answer 3

According to the info you provided the rule that blocks this IP seems to be there, and nothing seems to be accepting traffic in a more general sense before that (unless you copied just a part of it).

Try also blocking OUTPUT to this IP:

 iptables -I OUTPUT -d <dst-ip> -j DROP

Answer 4

Give us your iptables -L -v. I bet you have a rule that is accepting with a wildcard before your new rule.

EDIT: Possible thoughts include that these connections are generating from a compromise on your machine, or that multiple hosts reverse map to that same domain name and you're not noticing because (just double-check).

Answer 5

Well, since it's rather a dark matter with your netfilter (at least in your explanation), you can use ip route to drop that host: sudo ip route add unreachable 188.241.114.22. This also will be more CPU-friendly, since route table uses either Hash, or Tree to store lots of routes (not a list of to proceed when packet comes in).