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

This question already has an answer here:

I am seeing a huge number of connections from a single IP.

# netstat -alpn | grep :80 | grep 92.98.64.103

tcp        0      0 my.ip.address.x:80            92.98.64.103:45629          TIME_WAIT   -                   
tcp        0      0 my.ip.address.x:80            92.98.64.103:44288          TIME_WAIT   -                   
tcp        0      0 my.ip.address.x:80            92.98.64.103:48783          TIME_WAIT   -                   
tcp        0      0 my.ip.address.x:80            92.98.64.103:40531          TIME_WAIT   -                   
tcp        0      0 my.ip.address.x:80            92.98.64.103:54094          TIME_WAIT   -                   
tcp        0      0 my.ip.address.x:80            92.98.64.103:47394          TIME_WAIT   -                   
tcp        0      0 my.ip.address.x:80            92.98.64.103:43495          TIME_WAIT   -                   
tcp        0      0 my.ip.address.x:80            92.98.64.103:55429          TIME_WAIT   -                   
tcp        0      0 my.ip.address.x:80            92.98.64.103:42993          TIME_WAIT   -                   
tcp        0      0 my.ip.address.x:80            92.98.64.103:49542          TIME_WAIT   -                   
tcp        0      0 my.ip.address.x:80            92.98.64.103:54812          TIME_WAIT   - 

There are 419 such lines. But I see only 1 request from 92.98.64.103 in my access log. Is this DoS attack?

UPDATE - 419 Connections are from a single IP. There are several such IPs with over 100 connections.

The normal RAM usage of my server is around 2-3 GB. But at that time it was using 15GB RAM.

root@mars [~]# netstat -alpn | grep ':80 .*TIME_WAIT' | wc -l
6728

UPDATE 2 - TIME_WAIT increased to over 10000 in a few seconds

root@mars [~]# netstat -nat | awk '{print $6}' | sort | uniq -c | sort -n
      1 established)
      1 Foreign
      4 CLOSE_WAIT
      9 FIN_WAIT2
     34 LAST_ACK
     39 SYN_RECV
     44 LISTEN
     45 CLOSING
     68 FIN_WAIT1
    128 ESTABLISHED
  10261 TIME_WAIT

But the web server is loading fine without any problem.

share|improve this question

marked as duplicate by Jacob, MDMarra, Tim Brigham, Stefan Lasiewski, Dave M Jul 3 '13 at 17:41

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
Connections in a "TIME_WAIT" state are simply waiting to end the connection. See the details as to why here: en.wikipedia.org/wiki/… –  Stefan Lasiewski Jul 3 '13 at 17:36

1 Answer 1

419 measly connections is not a DoS.

On one particular medium-usage webserver at the moment I have:

$ netstat -alpn | grep ':80 .*TIME_WAIT' | wc -l
384

384 connections in this state.

How many per IP?

$ netstat -alpn | awk 'BEGIN {FS="[ :]+";} /:80 .*TIME_WAIT/ {print $6}' | sort | uniq -c | sort -g | tail -n5
      6 xx.xxx.xx.xx
      6 xx.xxx.xx.xx
      9 xxx.xxx.xx.xx
     13 xxx.xx.xx.xx
     48 xxx.xxx.xxx.xx

It's unusual to have so many from one IP - my guess is a PMTU problem resulting in terminated connections without requests being made.

If you're concerned, dump the traffic.

I'd recommend dropping down the number of seconds the socket stays in TIME_WAIT. Add the following to /etc/sysctl.conf:

net.netfilter.nf_conntrack_tcp_timeout_time_wait=15

and run:

sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=15
share|improve this answer
    
Upvoting for the smart answer and the elegance of the commands provided. –  mimipc Jul 3 '13 at 17:18
1  
TIME_WAIT spam tends to freak people out, which is why I went for the duplicate flag. –  Andrew B Jul 3 '13 at 17:28
    
419 Connections are from a single IP. There are several such IPs with over 100 connections. –  Joyce Babu Jul 4 '13 at 6:18
    
So possibly a netwok issue? that still is a low number for a ddos. –  TomTom Jul 4 '13 at 6:26
    
I would not be concerned about this number at all. Added a recommendation for dropping TIME_WAIT timeout. –  MikeyB Jul 4 '13 at 13:52

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