web-dev-qa-db-ja.com

iptablesで接続追跡を無効にしても安全ですか？

IptablesのNOTRACKテーブルのrawターゲットについて読んでいるときに、特定のトラフィックに対して接続追跡を無効にできる（またはすべきである）ことを示唆する記事に遭遇しました。 2つの例は、（1）ルーティングされたすべての種類のパケット、および（2）リソースを消費するWebサーバーまたはその他のサービスがある場合は、そのようなサービスの接続追跡も無効にする必要があります。 Webサーバーはありませんが、p2pクライアントはいくつかあります。接続追跡の標準ルールは次のとおりです。

iptables -t filter -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -t filter -A INPUT -p udp -m conntrack --ctstate NEW -j udp
iptables -t filter -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j tcp

udpおよびtcpチェーンで、次を使用してトレントクライアントのポートを開きます。

iptables -t filter -A udp -p udp --dport 33333 -m conntrack --ctstate NEW -j ACCEPT
iptables -t filter -A tcp -p tcp --dport 33333 -m conntrack --ctstate NEW -j ACCEPT

Conntrackエントリを確認すると：

# cat /proc/net/nf_conntrack | wc -l
3569

次に、この種類のトラフィックに対してNOTRACKテーブルにrawを設定するオプションがあります。次に例を示します。

iptables -t raw -A notrack_in -p udp --dport 33333 -j NOTRACK
iptables -t raw -A notrack_in -p udp --dport 33333 -j ACCEPT
iptables -t raw -A notrack_in -p tcp --dport 33333 -j NOTRACK
iptables -t raw -A notrack_in -p tcp --dport 33333 -j ACCEPT

フィルターテーブルには2つのルールも必要です。

iptables -t filter -A INPUT -p udp --dport 33333 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 33333 -j ACCEPT

この操作の後、/proc/net/nf_conntrackのエントリ数は150〜200に減少し、ポート33333の行はありません。

私の質問はこれです：接続追跡を無効にしても安全ですか？そのためには、iptablesにルールを追加する必要がありますか？このソリューションの長所と短所は何ですか？

linuxfirewallsiptables
12
Mikhail Morfikov

短い答え

通常は、アウトバウンド接続の接続追跡のみが必要です。ローカルデバイスがインターネットに接続している場合、ファイアウォールはこの特定のIPとポートが他のIPとポートに接続しようとしたことを記録します。

したがって、インターネットからの応答が到着すると、ファイアウォールはそれを通過させることを知っています。これは、前に発信パケットを見たことがあるためです。接続追跡が行われていない場合、パケットがどこからどこへ、またはどこへ移動するかについて、明示的なルールを配置する必要があります（たとえば、google.comポート80からのすべてのパケットを許可します）。これにより、ファイアウォールルールが非常に複雑になることは簡単です。

長い答え

インバウンド接続に使用する場合、2つのソリューションにはわずかな違いがあります。 1つの違いは、パケットをチェックするCPU負荷がどのシステムで発生するかです。専用のコンピューター/ルーター/ファイアウォール（以降、ファイアウォールと呼びます）を使用していて、接続追跡が有効になっている場合、このデバイスは少なくとも妥当性をチェックしますパケットの。これにより、アプリケーションサーバー（パケットを取得するサーバー）が解放されます。

妥当性は、UDPの場合、パケットが予期されるホストと予期されるポートから送信され、さらに、 TCP。

通常、validationは、アプリケーション自体のプロトコルに基づいてのみ有効性を保証できるため、アプリケーション層内でのみ発生します。

これらの仮定から3つの結果があります。

  • 状態追跡の場合、CPUとネットワークの負荷はネットワークの「エッジ」に向かって移動します。つまり、ネットワーク上の（通常）最初のデバイスは、ローカルネットワークに転送する前に、パケットのsome基本検査を実行して、内部を維持します。クリーンなネットワークとファイアウォールの負荷。
  • アプリケーションサーバーは、パケットが有効かどうか、つまり、パケット内のデータが予期されたプロトコルに準拠しているかどうかについてのみ心配する必要があります。
  • これにより、プロトコルによっては、UDP接続を追い越す可能性が生まれます。アプリケーションにパケットの送信者を認証する方法がない（または信頼できない）場合、アプリケーションは任意のIPアドレスからの正しいペイロードを受け入れます。たとえば、データ送信では、UDPパケットが検証に合格すると、ゴミを受信者に送信することができます。

それにもかかわらず、一般的な方法（高度なセキュリティ環境でない限り）では、すべてのインターネットサーバーがローカルネットワークからの要求に応答することを明示的に許可する必要がないため、（一般）接続追跡を発信接続のみに使用します。着信接続の場合、通常は本当に（定義された）ポートに到達可能にするだけです（-A INPUT -p tcp --dport 80 -j ACCEPT）。これは新しい接続に適用されますが、既存の接続にも適用され、オーバーヘッドを回避して、接続を追跡します。同様に、特定の宛先ポートへのパケットのみをローカルネットワーク内のアプリケーションサーバーに転送します。

アプリケーション固有の接続追跡

私がまだ言及しなかった1つのケースがあり、それはアプリケーション固有の接続追跡です。いくつかのプロトコル（ftp、irc、tftp、amanda、sipおよびその他のプロトコルについては、 http://www.iptables.info/en/connection-state.html#COMPLEXPROTOCOLS などを参照）がある場合があります。接続の高度な追跡を可能にする特別なiptablesモジュールである。たとえばFTPでは、クライアントからサーバーへの接続をポート21で開きます。これは制御接続と呼ばれ、ファイアウォールで通常の方法で開く必要があります。このチャネル内で、クライアントとサーバーは、生のファイルデータが送信される2番目の接続を定義します。通常、この接続はサーバーからクライアントへ（ACTIVEモードで）確立されます。このローカルポートとリモートポートはランダムに見えるため、静的ファイアウォール構成ファイルで定義することはできません。クライアントのネットワークにiptablesを備えたファイアウォールがあった場合、以前の関連付けがないため、この接続は拒否されます。アプリケーション固有の接続追跡を使用すると、モジュールはパケットの内容を「調べて」、そのような合意が行われたかどうかを確認し、ファイアウォールは、以前に接続がなかった場合でも、合意されたポートでの新しい着信接続を許可します。

13
Spacy