netfilter / iptables:生のテーブルを使用しないのはなぜですか?


22

Linuxでは、通常、「filter」テーブルを使用して一般的なフィルタリングを行います。

iptables --table filter --append INPUT --source 1.2.3.4 --jump DROP
iptables --table filter --append INPUT --in-interface lo --jump ACCEPT

以下のnetfilterのフローチャートによると、パケットは最初に「生の」テーブルを通過します。

ここに画像の説明を入力してください

だから私たちは書くことができます:

iptables --table raw --append PREROUTING --source 1.2.3.4 --jump DROP
iptables --table raw --append PREROUTING --in-interface lo --jump ACCEPT
  • パケットはconntrack + mangle + nat + routingを経由する必要なく、より早く処理されます。使用されるCPU /メモリがわずかに少ない(そしてiptable_rawモジュールをロードしなければならないという事実によってわずかに補正される)
  • フィルター/転送に同じルールを追加する必要がないため、ボックスがルーターでもある場合のルールは1つだけです(すべてのルールで問題ないことは明らかです)

私は迅速なテストのみを行いましたが、これは完璧に機能します。
私が見つけたドキュメントでは、厳密な場合に使用される生のテーブルについて常に説明しています。しかし、最小の正当化さえも与えません。

質問:独断的なものとは別に、生のテーブルを使用しない理由はありますか?


特定のIPアドレスからのすべてのトラフィックを単にドロップする場合は、生のテーブルで問題ありません。ただし、多くの場合、ファイアウォールはそれよりも少しきめが細かいので、生のルールとフィルターのルールが必要になります。これにより、メンテナンスが頭痛の種になり、数サイクルのCPUサイクルの価値があります。
ウルテル

1
それが単なる頭痛の問題であれば、生のテーブルについて話すいくつかの例を見つけるべきだと思います。これは事実ではないので、頭痛の理論はおそらく主要因ではありません。
グレゴリームサット

1
ipsetの作成者は、ipset iptablesルールの未加工テーブルを使用することをお勧めしますipset.netfilter.org/tips.html
スチュアートカードオール

回答:


17

man iptablesから:

raw: This table is used mainly for configuring exemptions from connection
     tracking in combination with the NOTRACK target. It registers at the
     netfilter hooks with higher priority and is thus called before
     ip_conntrack, or any other IP tables.
     It  provides the following built-in chains:

     - PREROUTING (for packets arriving via any network interface)
     - OUTPUT (for packets generated by local processes)

分析

したがって、RAWテーブルはconntrackの前にあり、netfilterで追跡したくないパケットにNOTRACKマークを設定するために使用する目的で設計されました。

-jターゲットはNOTRACKのみに制限されていないため、はい、未加工テーブル内のパケットをフィルター処理し、CPU /メモリー消費量を削減します。

ほとんどの場合、サーバーはすべての接続を追跡する必要はありません。以前に確立された接続に基づいてiptablesでパケットをフィルタリングする必要がある場合にのみ、追跡が必要です。ポート80(およびおそらく21)のみが開いているような単純な目的にのみ役立つサーバーでは、その必要はありません。これらのインスタンスでは、接続追跡を無効にできます。

ただし、NATルーターを実行しようとしている場合は、少し複雑になります。何かをNAT変換するには、これらの接続を追跡して、外部ネットワークから内部ネットワークにパケットを配信できるようにする必要があります。

接続全体がNOTRACKで設定されている場合、関連する接続も追跡できません。conntrackとnatヘルパーは、追跡されていない接続では機能せず、関連するICMPエラーも機能しません。つまり、これらを手動で開く必要があります。FTPやSCTPなどの複雑なプロトコルに関しては、管理が非常に難しい場合があります。

ユースケース

1つの例は、ルーティングされたトラフィックではなく、着信トラフィックと発信トラフィックをファイアウォールで保護する、トラフィックの多いルーターがある場合です。次に、転送されたトラフィックを無視するようにNOTRACKマークを設定して、処理能力を節約できます。

NOTRACKを使用できるもう1つの例は、トラフィックの多いWebサーバーがある場合、すべてのローカルに所有されているIPアドレス、または実際にWebトラフィックを処理しているIPアドレスでポート80の追跡を有効にするルールを設定できます。その後、すでに過負荷状態のシステムで処理能力をいくらか節約できるWebトラフィックを除き、他のすべてのサービスでステートフルトラッキングを楽しむことができます。

例-> running-a-semi-stateless-linux-router-for-private-network

結論:生のテーブルを使用しない強力な理由はありませんが、生のテーブルでNOTRACKターゲットを使用する際に注意するいくつかの理由があります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.