web-dev-qa-db-ja.com

iptables:ポリシーを変更するか、キャッチオールルールを使用しますか?

Iptablesを設定するときはどうしますか:デフォルトのポリシーを変更します(iptables -P INPUT DROPなど)またはルールセットの最後にキャッチオールルールを追加します(iptables -A INPUT DROP)?特に1つを好む場合、あなたの好みの背後にある理由は何ですか?

これはこのフォーラムにとって主観的すぎる質問かもしれませんが、おそらく私が気付いていないものを選択するいくつかの難しい理由があります。

私が持っているポリシーの方法に反して、過度に楽観的であるため、サーバーから自分自身をロックアウトする方がおそらく簡単ですiptables -F。そのため、キャッチオールルールを気付かずに削除する方がおそらく簡単で、サーバーを完全に開いたままにしておくことができます(これは過去に発生したことがあります)。

インターネットからの唯一の保護としてファイアウォールに頼るべきではないのは事実ですが(たとえば、ほとんどの場合、内部ネットワークサービスをローカルホストまたは内部ネットワークにのみバインドできます)、半ば公開することを余儀なくされることもあります。特定のソースネットワークへの公共サービスなど。

個人的には、ルールセットを最初から作成する場合は最初のものを好む傾向がありますが、既存のルールセットを更新する場合は、すでに設定されているものに固執します。

5
Eduardo Ivanec

私はそのように筋金入りなので、ポリシーを設定し、最終的なドロップルールの両方を使用します。

呼び出して更新するスクリプトでルールを定義しています。たまにルール/統計をリストするために、iptablesを直接呼び出すことはありません。私は、一方が他方よりも優れている理由を実際に見たことがありません。

4
Zoredache

トレードオフの観点から、私はマシンを持っているよりも、偶然に(ルールをフラッシュして忘れた場合などに-P ALLOWを持っているリスクです)、ファイアウォールのないマシンを一定期間持っていることを好みます誤ってネットワークをドロップオフします(これは、ポリシーがDROPの場合のフラッシュの結果です)。私の考えでは、ファイアウォールはサーバーを保護する唯一の方法ではないため、ファイアウォールの誤動作は大惨事ではなくエラーです。ほとんどの場合、ユーザーがサービスを利用できないis大惨事。

2
jmtd

キャッチオールルールを使用する方がよい理由は2つあります。

  1. デフォルトのポリシーには制限されたオプションがあります。パケットを通過させたくない場合は、DROP(パケットが床にぶつかる)という選択肢があります。キャッチオールルールでは、ICMP応答を送信できるREJECTを使用できます。
  2. Iptables -Lの出力を解析するスクリプトがある場合、キャッチオールルールは他のすべてのルールと同じ形式で表示されるため、解析が簡単になります。
2
Mark Wagner

私が今気づいたこと:DROPポリシーでは、事後にiptables -Aを使用してルールセットにルールを追加できます。これは、ルールセットを簡単に順序付けておくことができるので便利であり、ルールセットをオンザフライで作成するときに特に便利です(後でiptables-saveなどで保存します)。

1
Eduardo Ivanec