Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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
share|improve this question
add comment

5 Answers

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

share|improve this answer
    
this could also be done with 'iptables -I INPUT <N> ...' where <N> is the position in which this rule will be set. As an example, if N=1, the it will be the first rule. –  Torian Feb 7 '11 at 23:35
    
i looked in the /etc/sysconfig/iptables file and couldn't find any other rules except the drop rules I added –  Overdeath Feb 7 '11 at 23:55
add comment

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.

share|improve this answer
add comment

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
share|improve this answer
    
Thanks.. this solved my issue –  Overdeath Feb 9 '11 at 7:39
    
The thing is that something is sending traffic out from your server to this IP. My advice would be to run chkrootkit, rkhunter, etc. if this traffic is not to be expected. –  Torian Feb 9 '11 at 11:17
    
It seemed the problem wasn't there.. after a day of peace and relaxation the issue reappeared –  Overdeath Feb 10 '11 at 13:49
    
Gnarly things are going on in your machine. It is suspect, and should be wiped clean and rebuilt. –  Jeff Ferland Feb 10 '11 at 17:45
add comment

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).

share|improve this answer
    
i have updated the question an included your request –  Overdeath Feb 7 '11 at 23:24
    
When i reverse dns that ip i get "oxygen.ro", but in iptables -L i see v1.oxygen.ro. Can this be e problem? –  Overdeath Feb 10 '11 at 17:11
add comment

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).

share|improve this answer
    
Thanks for the info. Didn't try it because another advice worked using iptables but I will deffinately remember it. I really was wondering if there is another way of blocking an ip without using iptables. –  Overdeath Feb 9 '11 at 7:41
    
Well, actually blocking output isn't a correct answer, since blocking only the INPUT should be just enough, thus you should conclude something's terrible wrong with you firewall. –  poige Feb 9 '11 at 8:20
    
I know that but since i blocked output too i didn't see any requests from that IP. That's why I waited. From my point of view that is a correct answer since it solved my problem, eventhough there might be a bigger problem underneath. Maybe I'll ask another question for that. –  Overdeath Feb 9 '11 at 9:29
    
It seems you were right.. and it was only a temporary solution. I also tried your solution but that didn't work either. –  Overdeath Feb 10 '11 at 13:50
    
Unless you're running corresponding ip route commands on every boot they have only current session effect. Also, you can easily check whether it works at all -- add such a route, then ping the IP and see what would be the answer. –  poige Feb 10 '11 at 16:05
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.