web-dev-qa-db-ja.com

iptablesをステートレスにしようとすると、予期しないフィルタリングが発生します

TCP接続の状態を追跡しないようにiptablesを調整することで、サーバーのパフォーマンスを向上させようとしています。このガイドを見ています： http：// cotdp。 com/2011/07/nginix-on-a-256mb-vm-slice-24000-tps /

ただし、次のいずれかを実行すると、すべての発信接続が切断されているように見えます。

このルールを削除します：INPUT -m state --state ESTABLISHED,RELATED -j ACCEPTこれらを追加する：

 iptables -t raw -I OUTPUT -j NOTRACK 
 iptables -t raw -I PREROUTING -j NOTRACK

いずれかの変更を行った直後に、「ping google.com」は「google.com」を見つけることができないというエラーを返します（つまり、DNSは解決を停止します）。

起動時にロードされるルールは次のとおりですが、他のルールはfail2banによって追加されます。

 * filter 
-入力-ilo -j ACCEPT 
-入力！ -i lo -d 127.0.0.0/8 -j REJECT 
-AINPUT -m state --state ESTABLISHED、RELATED -j ACCEPT 
-AOUTPUT -j ACCEPT 
- A INPUT -p icmp -j ACCEPT 
-AINPUT -p tcp --dport ssh -j ACCEPT 
-AINPUT -p tcp --dport http -j ACCEPT 
- A INPUT -p tcp --dport https -j ACCEPT 
-AINPUT -p tcp --dport smtp -j ACCEPT 
-AINPUT -p tcp --dport ssmtp -j ACCEPT 
-AINPUT -j REJECT 
-AFORWARD -j REJECT 
 COMMIT

Iptables--listの出力は次のとおりです。

 Chain INPUT（policy ACCEPT）
 target prot opt source destination 
 fail2ban-ssh tcp --where where multiport dports ssh 
 fail2ban-ssh-ddos tcp-どこでもどこでもmultiportdports ssh 
 fail2ban-pam-generic tcp--どこでもどこでも
 ACCEPTall--どこでもどこでも
 REJECTall--どこでもloopback/8 require-with icmp-port -到達不能
 ACCEPT all--どこでもどこでも状態RELATED、ESTABLISHED 
 ACCEPTicmp--どこでもどこでも
 ACCEPTtcp--どこでもどこでもtcpdpt：ssh 
 ACCEPT tcp -どこでもどこでもtcpdpt：www 
 ACCEPTtcp--どこでもどこでもtcpdpt：https 
 ACCEPTtcp--どこでもどこでもtcpdpt：smtp 
 ACCEPTtcp-どこでもどこでもtcpdpt：ssmtp 
どこでも拒否すべて-どこでも拒否-icmp-port-unreachable 
 
チェーンFORWARD（ポリシーACCEPT）
 target prot opt source destination 
 REJECT all --where where where react-with icmp-port-unreachable 
 
 Chain OUTPUT（policy ACCEPT） 
 target prot opt source destination 
 ACCEPT all --where where where 
 
 Chain fail2ban-pam-generic（1 reference）
 target prot opt source destination 
 RETURN all --where where where 
 
 Chain fail2ban-ssh（1 reference）
 target prot opt source destination 
 RETURN all --whereどこでも
 
 Chain fail2ban-ssh-ddos（1参照）
 target prot opt source destination 
 RETURN all--where where where
linuxiptablesfirewalltcp
5
Tim Tisdall

すべての着信トラフィックをブロックするルールがあります。

-A INPUT -j REJECT

また、接続の追跡を停止すると、確立された接続のパケットを受け入れるルールが機能しなくなります。

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

したがって、DNSパケットは送信され、追跡されず、最初のルールによって拒否されます。

2番目のルールが機能するように追跡を有効にするか、「適切な」ソースからの着信トラフィックを許可するルールを追加する必要があります。

3
mulaz

Linux接続追跡は、TCP接続を追跡するだけでなく、UDP疑似接続やその他のさまざまなものも追跡します。

Notrackルールがないと、何が起こるかです。

  • システムがDNS要求を送信します。これにより、接続追跡エントリが作成されます。
  • DNSサーバーが応答を生成します
  • 返信は、「確立された関連するものを受け入れる」ルールに一致します。

Notrackルールで何が起こるか

  • システムはDNS要求を送信しますが、接続追跡エントリは作成しません。
  • DNSサーバーが応答を生成します
  • 返信は、「確立された関連するものを受け入れる」ルールと一致しません。
  • 返信は失敗し、キャッチオール拒否ルールにヒットします。

では、これを修正する方法は？状態の追跡に依存せずに応答トラフィックを明示的に許可するか、notrackルールをより選択的にする必要があります。

DNSの場合、応答トラフィックを明示的に許可することはおそらく合理的です。あなたはあなたのDNSサーバーが何であるかを知っていて、おそらくそれを信頼しています。

サーバーが一般にインターネット上のリソースにアクセスする必要がある場合、接続追跡なしで完全に実行することは、はるかに効果の低いファイアウォールを使用することを意味します。

Webサーバーとの間のトラフィックにnotrackを適用するだけで、はるかに少ない苦痛でパフォーマンス上の利点の多くを得ることができると思います。例えば.

iptables -t raw -I OUTPUT -p tcp --sport http -j NOTRACK
iptables -t raw -I PREROUTING -p tcp --dport http -j NOTRACK
4
Peter Green