Take the 2-minute tour ×

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 OUTPUT -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
add comment

3 Answers

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:


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
add comment

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
add comment

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
add comment

Your Answer


