このアウトバウンド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サポートフォーラムでユーザーDougSによって説明されました。

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

これは、すでに閉じられて忘れられているTCPセッションからの長引くパケットであると私は推測します。そうでない場合は、RELATED、ESTABLISHEDパスを通過することになります。

これは、ルーターやパケット内の他のものに応じて、iptablesで多く発生します。どうして？TCP接続の場合、Linuxは「半二重」クローズシーケンスを使用する傾向があるため、セッションのいずれかの側が、単一の2ウェイFIN-ACKハンドシェイク（接続をCLOSE_WAIT状態にする）を介して接続終了を開始できます。フル4ウェイFIN-ACKハンドシェイク。

常にフラグを観察して、何が起こっているかを確認してください。大丈夫だと思います

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