☰

這個出站 iptables 防火牆有什麼問題？

tag-icon • tag-icon firewall iptables tcpip
這個出站 iptables 防火牆有什麼問題？

我有一個郵件伺服器，我想透過僅允許其使用的各個連接埠上的出站連接來確保其安全。入站規則運作正常 - 它們由 VM 主機處理。

我對此了解不多，雖然下面的腳本幾乎可以工作，但它正在丟棄資料包，例如這裡的連接埠 993：

Mar 25 16:08:11 lorina kernel: [200590.714226] IPTables-Dropped: IN= OUT=ens18 SRC=[local IP here] DST=[remote IP here] LEN=148 TOS=0x00 PREC=0x00 TTL=64 ID=37253 DF PROTO=TCP SPT=993 DPT=14826 WINDOW=243 RES=0x00 ACK PSH FIN URGP=0

這是腳本。請注意，ens19 是 LAN 介面（我希望保持開啟），ens18 是 WAN。

iptables -A OUTPUT -o lo -p all -j ACCEPT
iptables -A OUTPUT -o ens19 -p all -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp -m owner --uid-owner systemd-timesync -j ACCEPT

ip6tables -A OUTPUT -o lo -p all -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 -j ACCEPT
ip6tables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A OUTPUT -p tcp --dport 53 -j ACCEPT
ip6tables -A OUTPUT -p udp --dport 53 -j ACCEPT
ip6tables -A OUTPUT -p udp -m owner --uid-owner systemd-timesync -j ACCEPT

while read h; do
        ip6tables -A OUTPUT -m conntrack --ctstate NEW -d $h -j ACCEPT &> /dev/null
        iptables -A OUTPUT -m conntrack --ctstate NEW -d $h -j ACCEPT
done < /usr/local/etc/hosts-to-allow.list

while read p; do
        ip6tables -A OUTPUT -m conntrack --ctstate NEW -p tcp --dport $p -j ACCEPT
        iptables -A OUTPUT -m conntrack --ctstate NEW -p tcp --dport $p -j ACCEPT
done < /usr/local/etc/ports-to-allow.list

ip6tables -A OUTPUT -o ens18 -j LOGGING
ip6tables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A OUTPUT -o ens18 -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4

iptables -A OUTPUT -o ens18 -j REJECT
ip6tables -A OUTPUT -o ens18 -j REJECT

有趣的註腳

這些規則中丟棄的資料包可能是正常的，我仍然偶爾會看到它們。 Ubuntu 支援論壇上的使用者 Doug S 對此提供了解釋：

您的日誌行範例適用於非「新」資料包。您可以從該行末尾的 TCP 標誌看出。

我最好的猜測是，這是來自已關閉且被遺忘的 TCP 會話的揮之不去的資料包，否則它會遍歷 RELATED、ESTABLISHED 路徑。

這種情況在 iptables 中經常發生，具體取決於您的路由器和/或封包傳輸中的其他內容。為什麼？因為對於 TCP 連接，Linux 傾向於使用「半雙工」關閉序列，其中會話的任何一方都可以透過單一 2 路 FIN-ACK 握手（將連接置於 CLOSE_WAIT 狀態）來啟動連接終止，而不是透過完整的4 路FIN-ACK 握手。

始終觀察旗幟以確定發生了什麼。我覺得你還好

到目前為止，在今天的 /var/log/syslog 檔案中，我有 115 個以「RES=0x00 ACK FIN URGP=0」結尾的條目，其中 93 個來自我的 LAN。

答案1

我猜您的 ports-to-allow.list 包含連接埠 993，這就是為什麼您沒有想到您引用的日誌條目。但請注意，您似乎正在使用連接埠清單進行白名單目的地端口，而您的日誌顯示 993 作為來源被阻止資料包的連接埠。

相關內容