The spammer or a DoS attack ? Doesn't really matter.

Body

So, I'm still a hardcore GNU/Linux administrator after all ?!

Apache "The webserver" is down. Looks like the master process gets killed by the kernel. That's weird.

Now what's interesting is the dmesg output:

TCP: Treason uncloaked! Peer 62.68.70.130:62537/80 shrinks window 1681427947:1681430707. Repaired.
TCP: Treason uncloaked! Peer 62.68.79.66:61105/80 shrinks window 288684489:288684490. Repaired.
TCP: Treason uncloaked! Peer 62.68.79.66:61107/80 shrinks window 285018062:285018063. Repaired.
TCP: Treason uncloaked! Peer 62.68.79.66:61137/80 shrinks window 282542156:282542157. Repaired.
TCP: Treason uncloaked! Peer 62.68.79.66:61161/80 shrinks window 305746809:305746810. Repaired.
TCP: Treason uncloaked! Peer 62.68.79.66:61185/80 shrinks window 341351133:341351134. Repaired.
TCP: Treason uncloaked! Peer 62.68.79.66:61213/80 shrinks window 356410419:356410420. Repaired.

Looks like the peer is playing bad games with my TCP/IP stack. Decreasing the window size. I guess that's why apache was holding too many connections. Something like 119 connections.

netstat output was interesting:

     88 CLOSE_WAIT
     21 SYN_RECV

I wouldn't know but I guessed that the high number of SYN requests is due gto the high number of half closed sockets.

The problem is that after I've decreased the CLOSE_WAIT time via:

echo 2 >  /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait

The number of TIME_WAIT started to increase.

echo 10 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait

Of course all the above might be incorrect or even nonsense. Let's see.

Add new comment

The content of this field is kept private and will not be shown publicly.