Conntrack および動的 ipset/iptables ルール

Conntrack および動的 ipset/iptables ルール

conntrackモジュールのいくつかの基本概念を理解していません。

modinfoまず、私のシステム(Ubuntu 18.04)で有効になっていること、nf_conntrackに関する情報が表示され、/proc/modulesnf_conntrackに表示されているファイルが「live」であることを確認しました。

次に、次のテスト設定があります。

マシンA(192.168.1.2)<------>ルーターマシン(192.168.1.1&192.168.2.1)<---->マシンB(192.168.2.2)

ルータシステムには、次の iptables ルールがあります。
iptables -t filter -A FORWARD -m set --match-set BlackListPort dst -j DROP

BlackListPortはipsetテーブルです。
これで、マシンA(1.2)からマシンB(2.2)へのSSH接続が確立されました。動作していることを確認した後、BlackListPortテーブルにポート22(SSHデフォルト)を追加しました。

対応するipsetテーブルからポート22を削除するまで、SSH接続は停止/中断されます。

今問題は:私のシステムにconntrackがあり、SSHブロックが成功したのはなぜですか? SSH接続はポート22がipsetに追加される前に確立されているため、conntrackはすべてのパケットをスキップしてSSHが機能するようにする必要があります。

答え1

SSH接続はポート22がipsetに追加される前に確立されているため、conntrackはすべてのパケットをスキップしてSSHが機能するようにする必要があります。

これは正確ではありません。

すべてのパケットは、追跡された接続に属しているかどうかにかかわらず、フィルタリングルールによって処理されます。

関連ルールチェーンの先頭(FORWARDあなたの例では)の近くにこのようなものを配置することは、iptablesルールの非常に一般的な最適化です。

iptables -t filter -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

以前のディストリビューションでは、次のバージョンが表示されます。

iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

conntrack(最近ではmatchよりもmatchが人気があることがわかっていますstate

これにより、接続追跡情報がある場合は、既存の接続に属するパケットが通過する可能性があります。しかし、ポイントは、あなた制御可能正確にどこにこのルールを作成しましたか、それとも使用しましたか?これにより、ファイアウォールルールで接続状態を好きなだけ気にすることができます。

関連情報