关注ip_conntrack的内容

概要

• 服务器操作系统：Debian Squeeze
• Web服务器：Apache2
• IP表'脚本'：arno-iptables-firewall

服务器上的/proc/net/ip_conntrack有170个条目。 目前，其中134个涉及到一个IP地址parsing为cl59.justhost.com（我build议你不要浏览它，以防万一）。 我不明白conntrack条目，我担心他们可能表明安全漏洞。

详情

/proc/net/ip_conntrack的134个条目全部是这样的（我的服务器IPreplace为192.168.0.1），

• 不能在apache上安装ssl证书
• .htaccess中的相对pathvariables
• 同步多台服务器上的文件（rsync？）
• 有可能在Apache中部署asp.net文件
• apache2：以非www数据用户启动进程

 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 

我在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:* 

该服务器运行Apache2，PHP5，并有一些WordPress的博客和一个单一的phpBB3论坛（以及随机的其他一点点在这里和那里）。

任何人都可以对这些连接的一个可能的来源做一些阐述。 他们是从69.175.58.106连接到我的服务器失败/停滞，所以没有太大的担心，或者他们连接从我的服务器出站到69.175.58.106这可能表明一些邪恶的事情？

如果他们自己不在乎，那么他们有没有离开的原因呢？

更新：

因此，做了更多的挖掘工作，入场的第三个领域就是入场时间。 所以出于某种原因，所有这些条目都有很长的寿命。 这就解释了为什么他们没有消失，但还不是他们最初的原因，而现在，他们是如何创造如此巨大的时间。

更新2：

所以更多挖掘build议我的条目应该被读为，我的服务器（192.168.0.1）发送一个数据包到69.175.58.106，迄今为止没有响应。 这导致我怀疑69.175.58.106最初从服务器请求的数据，然后断开连接，并且iptables已经决定保持相当一段时间的条目。

我仍然有兴趣知道这个评估是否正确，或者是否有其他的事情发生。