Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a problem with my Apache webserver where there's and IP than connecting to my server, using a lot of connection and wont die which eventually making my webserver timeout. The connection will stay as SYN_SENT state if I check using

netstat -netapu

I even flush my iptables and use the basic rules and it still doesn't work. The IP will get connected when I start my Apache

Basic rules that I use:

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT ! -i lo -d -j REJECT

iptables -A INPUT -s -j REJECT

iptables -A OUTPUT -s -j REJECT

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 21 -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
iptables -A INPUT -j REJECT
iptables -A FORWARD -j REJECT

The bold part is rule in question.

Not sure this is related but tcp_syncookies value is 1.

Can someone point out my mistake? Is there a way to block it for good.

share|improve this question
The OUTPUT rule with that IP address should say -d rather than -s. – Ladadadada Nov 27 '11 at 8:48
Ahh.. thank you for that. My copy paste skill failed me again. The IP is gone now. Cheers! – Sam W. Nov 27 '11 at 15:58

Can you show us the output of


? Maybe the order of the rules is not what you think. Then

iptables -A OUTPUT -s -j REJECT

should probably read:

iptables -A OUTPUT -**d** -j REJECT

By the way, why REJECT and not DROP ? Then if you are using the state module, you should write:

iptables -A INPUT  -m state --state NEW -p tcp --dport 80 -j ACCEPT

And note that if your server is behind a load-balancer in DSR mode the state module will not work correctly.

share|improve this answer
Forgot to mention that I've tried DROP before I change it to REJECT. Seems fine now. The typo on the rules cause it doesn't work. Thanks – Sam W. Nov 27 '11 at 15:59

Connections stuck in the SYN_SENT state are known as embryonic connections. These happen when you try to make a connection out to an IP address and for some reason that IP can't contact you back. This means that you are trying to connect to him, not the other way around.

I don't know what it looked like before you added those two rules but with the way they are now, you can send the first part of the three way handshake (the SYN) but you can't receive the second part (the SYN/ACK) and this will leave a connection in the SEN_SENT state for each attempt.

I suspect you copied/pasted the first rule to create the second and changed INPUT to OUTPUT but forgot to change -s to -d. I know because I've done it myself more than once.

share|improve this answer
Does this mean that there's a possibility a file in my server is infected by malware and been calling home? After I correct the rules typo it seems gone now. How can I investigate this further. Sorry for being such a noob. – Sam W. Nov 27 '11 at 16:03
This is a possibility. It could also be a legitimate piece of software checking for updates or an open proxy on your server or any one of lots of other things. The best idea is probably to temporarily remove the firewall rule and run a tcpdump until you find out what it's doing. – Ladadadada Nov 28 '11 at 11:40
Thank you for your help. Cheers! – Sam W. Nov 29 '11 at 3:22

you need to try "FAIL2BAN" linux utility, which blocks majority of such brute force attacks. Fail2Ban supports protection of brute force attack for ssh, apache and many other services. If for example an IP address is trying to make huge number of concurrent connections, then fail2ban will block it through automatically adding (and after some time, removing as well) that IP address by iptables.

share|improve this answer
thanks for the recommendation. I'll look into that. – Sam W. Nov 27 '11 at 16:00

Your Answer


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.