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

Summary

  • 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.

Detail

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

tcp      6 282883 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=33053 packets=2 bytes=3000 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=33053 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2
tcp      6 282877 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=33064 packets=2 bytes=3000 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=33064 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2
tcp      6 284392 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=60963 packets=1 bytes=1500 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=60963 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2
tcp      6 284392 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=60950 packets=1 bytes=1500 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=60950 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2
tcp      6 283131 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=33221 packets=11 bytes=17948 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=33221 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2
tcp      6 283080 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=33253 packets=11 bytes=17948 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=33253 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2
tcp      6 282879 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=33208 packets=2 bytes=3000 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 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 0.0.0.0:25              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:842             0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:4949            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 192.168.0.1:22          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 192.168.0.1:80          xxx.xx.196.80:30010     TIME_WAIT
tcp6       0      0 192.168.0.1:80          xx.xx.13.54:60767       TIME_WAIT
tcp6       0      0 192.168.0.1:80          xxx.xx.196.11:33402     TIME_WAIT
tcp6       0      0 192.168.0.1:80          xx.xxx.142.192:58280    TIME_WAIT
tcp6       0      0 192.168.0.1:80          xx.xxx.142.192:58281    TIME_WAIT
tcp6       0      0 192.168.0.1:80          xx.xx.13.54:62025       TIME_WAIT
udp        0      0 192.168.0.1:123         0.0.0.0:*
udp        0      0 127.0.0.1:123           0.0.0.0:*
udp        0      0 0.0.0.0:123             0.0.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 69.175.58.106 and so not much to worry about, or are they connections outbound from my server to 69.175.58.106 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?

Update:

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 (192.168.0.1) sent a packet to 69.175.58.106, which has so far failed to respond. This leads me to suspect 69.175.58.106 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
1  
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
add comment

1 Answer

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, 69.175.58.106 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 69.175.58.106, or by 69.175.58.106 itself. Closed connections have a much shorter TTL.

  3. It's not possible to say if 69.175.58.106 connected lots of times and then simply stopped communicating, or whether there was a network issue between my server and 69.175.58.106, but judging by the fact that the 69.175.58.106 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
add comment

Your Answer

 
discard

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.