☰

この送信 iptables ファイアウォールの何が問題なのでしょうか?

tag-icon • tag-icon firewall iptables tcpip
この送信 iptables ファイアウォールの何が問題なのでしょうか?

メール サーバーを所有しており、そのサーバーが使用するさまざまなポートで OUTBOUND 接続のみを許可することで、そのサーバーを保護したいと考えています。受信ルールは正常に機能しており、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 によって説明されています。

ログ ラインの例は、「NEW」ではないパケットのものです。行末の TCP フラグから判断できます。

私の推測では、これはすでに終了して忘れ去られた TCP セッションからの残留パケットであり、そうでなければ RELATED、ESTABLISHED パスを通過したはずです。

これは、ルーターやパケットが移動する他の要素に応じて、iptables でよく発生します。なぜでしょうか? TCP 接続の場合、Linux は、完全な 4 ウェイ FIN-ACK ハンドシェイクではなく、セッションのどちらの側でも単一の 2 ウェイ FIN-ACK ハンドシェイク (接続を CLOSE_WAIT 状態にする) を介して接続の終了を開始できる「半二重」のクローズ シーケンスを使用する傾向があるためです。

何が起こっているかを確実に知るために、常に旗を観察してください。大丈夫だと思います

今日の /var/log/syslog ファイルには、今のところ「RES=0x00 ACK FIN URGP=0」で終わるエントリが 115 個あり、そのうち 93 個は LAN からのものです。

答え1

ports-to-allow.list にポート 993 が含まれているため、引用したログ エントリは想定外だったと思われます。ただし、ポート リストをホワイトリストに使用しているようです。行き先ログには993と表示されていますが、ソースブロックされたパケットのポート。

関連情報