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
私は迅速なテストのみを行いましたが、これは完璧に機能します。
私が見つけたドキュメンテーションは常に、厳密なケースで使用される生のテーブルを説明しています。しかし、最小の正当化すらしません。
質問:独断的なものを除いて、生のテーブルを使用しない理由はありますか?
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/メモリの消費が少ないという利点でrawテーブルのパケットをフィルタリングします。
ほとんどの場合、サーバーはすべての接続を追跡する必要はありません。以前に確立された接続に基づいて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
結論:rawテーブルを使用しない強い理由はありませんが、NOTRACKターゲットを生のテーブル。