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.


  • Server OS: Debian Squeeze
  • Web Server: Apache2
  • IP Tables 'script': arno-iptables-firewall

There are 170 entries in /proc/net/ip_conntrack on the server. At present, 134 of those relate to an IP address which resolves as cl59.justhost.com (I suggest you don't browse to it, just in case). I don't understand the conntrack entries, and I'm concerned they might indicate a security breach.


The 134 entries in /proc/net/ip_conntrack all look like this (my server IP replaced with,

tcp      6 282883 ESTABLISHED src= dst= sport=80 dport=33053 packets=2 bytes=3000 [UNREPLIED] src= dst= sport=33053 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2
tcp      6 282877 ESTABLISHED src= dst= sport=80 dport=33064 packets=2 bytes=3000 [UNREPLIED] src= dst= sport=33064 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2
tcp      6 284392 ESTABLISHED src= dst= sport=80 dport=60963 packets=1 bytes=1500 [UNREPLIED] src= dst= sport=60963 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2
tcp      6 284392 ESTABLISHED src= dst= sport=80 dport=60950 packets=1 bytes=1500 [UNREPLIED] src= dst= sport=60950 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2
tcp      6 283131 ESTABLISHED src= dst= sport=80 dport=33221 packets=11 bytes=17948 [UNREPLIED] src= dst= sport=33221 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2
tcp      6 283080 ESTABLISHED src= dst= sport=80 dport=33253 packets=11 bytes=17948 [UNREPLIED] src= dst= sport=33253 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2
tcp      6 282879 ESTABLISHED src= dst= sport=80 dport=33208 packets=2 bytes=3000 [UNREPLIED] src= dst= sport=33208 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2

I'm not seeing any active connections in netstat,

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0    *               LISTEN
tcp        0      0   *               LISTEN
tcp        0      0*               LISTEN
tcp        0      0  *               LISTEN
tcp        0      0    *               LISTEN
tcp        0      0          xx.xx.xx.xx:54586       ESTABLISHED
tcp6       0      0 :::25                   :::*                    LISTEN
tcp6       0      0 :::443                  :::*                    LISTEN
tcp6       0      0 :::80                   :::*                    LISTEN
tcp6       0      0 :::22                   :::*                    LISTEN
tcp6       0      0          xxx.xx.196.80:30010     TIME_WAIT
tcp6       0      0          xx.xx.13.54:60767       TIME_WAIT
tcp6       0      0          xxx.xx.196.11:33402     TIME_WAIT
tcp6       0      0          xx.xxx.142.192:58280    TIME_WAIT
tcp6       0      0          xx.xxx.142.192:58281    TIME_WAIT
tcp6       0      0          xx.xx.13.54:62025       TIME_WAIT
udp        0      0*
udp        0      0 *
udp        0      0   *

The server runs Apache2, PHP5 and has a number of wordpress blogs and a single phpBB3 forum (as well as random other little bits here and there).

Can anyone shed some light on a possible source for those connections. Are they failed/stalled connections to my server from and so not much to worry about, or are they connections outbound from my server to which might indicate something sinister going on?

If they're not in and of themselves a concern, is there a reason why they don't appear to be going away?


So, did some more digging, and the third field in the entry is the time the entry will remain live. So for some reason, all of these entries have very large lifespans. That explains why they haven't gone away, but not yet their original cause, and now, how they were created with such huge durations.

Update 2:

So more digging suggests to me that the entries should be read as, my server ( sent a packet to, which has so far failed to respond. This leads me to suspect originally requested data from the server, and then disconnected, and iptables has decided to keep the entry around for quite some time.

I'd still be interested to know if this assessment is correct, or if there's something else going on.

share|improve this question
btw, you might want to install netstat-nat, or conntrack. It outputs the same data, but it is more clear. –  Zoredache Sep 1 '11 at 18:37

1 Answer 1

up vote 3 down vote accepted

Right, so further digging and I have my answer.

  1. the long TTL's on the connections are the default for the kernel and Debian Squeeze that I have, are around 5 days for Established connections, and are set in /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established

  2. Reading the conntrack entries, I now interpret them to mean, connected to the web server on port 80, and the web server responded with some data, but before the connection could be closed, it was simply dropped by either something between my server and, or by itself. Closed connections have a much shorter TTL.

  3. It's not possible to say if connected lots of times and then simply stopped communicating, or whether there was a network issue between my server and, but judging by the fact that the IP address points to another server and not a user connection, I'm inclined to think something odd was going on, but that it ultimately didn't cause any issues at my end.

  4. iptstate appears to be a nice curses based tool for looking at the conntrack data.

share|improve this answer

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.