Debian
關注ip_conntrack的內容
概括
- 伺服器作業系統：Debian Squeeze
- 網路伺服器：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 決定保留該條目相當長的一段時間。
我仍然很想知道這個評估是否正確，或者是否還有其他事情發生。
對，所以進一步探勘，我有我的答案。
- 連接上的長 TTL 是我擁有的核心和 Debian Squeeze 的預設值，已建立連接大約需要 5 天，並且設置為
/proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established- 閱讀 conntrack 條目，我現在將它們解釋為，69.175.58.106 連接到埠 80 上的 Web 伺服器，並且 Web 伺服器響應了一些數據，但在連接可以關閉之前，它只是被我之間的任何東西丟棄了伺服器和 69.175.58.106 或 69.175.58.106 本身。關閉的連接具有更短的 TTL。
- 不能說 69.175.58.106 是否連接了很多次然後就停止了通信，或者我的伺服器和 69.175.58.106 之間是否存在網路問題，但從 69.175.58.106 IP 地址指向另一台伺服器的事實來看而不是使用者連接，我傾向於認為發生了一些奇怪的事情，但它最終並沒有導致我的任何問題。
- iptstate似乎是一個很好的基於詛咒的工具，用於查看 conntrack 數據。