☰

关注ip_conntrack的内容

tag-icon • tag-icon debian iptables apache-2.2 tcpip
关注ip_conntrack的内容

概括

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

服务器上有 170 个条目/proc/net/ip_conntrack。目前，其中 134 个与解析为 cl59.justhost.com 的 IP 地址相关（我建议您不要浏览它，以防万一）。我不理解 conntrack 条目，我担心它们可能表明存在安全漏洞。

细节

总共134 个条目/proc/net/ip_conntrack如下所示（我的服务器 IP 已替换为 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

我没有看到任何活动连接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：

经过进一步挖掘，我发现这些条目应该被理解为：我的服务器 (192.168.0.1) 向 69.175.58.106 发送了一个数据包，但到目前为止还没有响应。这让我怀疑 69.175.58.106 最初向服务器请求数据，然后断开连接，而 iptables 决定将该条目保留一段时间。

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

答案1

好的，进一步挖掘后我得到了答案。

  1. 连接的长 TTL 是内核和 Debian Squeeze 的默认设置，对于已建立的连接，大约为 5 天，并设置在/proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established

  2. 读取 conntrack 条目后，我现在将其解释为：69.175.58.106 连接到端口 80 上的 Web 服务器，并且 Web 服务器响应了一些数据，但在关闭连接之前，它被我的服务器和 69.175.58.106 之间的某个东西或 69.175.58.106 本身丢弃。已关闭的连接具有更短的 TTL。

  3. 无法判断 69.175.58.106 是否连接了很多次然后就停止了通信，或者我的服务器和 69.175.58.106 之间是否存在网络问题，但根据 69.175.58.106 IP 地址指向另一台服务器而不是用户连接的事实来判断，我倾向于认为发生了一些奇怪的事情，但最终并没有给我带来任何问题。

  4. ipt状态似乎是一个很好的基于 curses 的工具，用于查看 conntrack 数据。

相关内容