サーバーを保護するための効果的なファイアウォールポリシーを選択する方法

getdocs

4年前

序章

ファイアウォールを使用することは、構文を学ぶことであると同時に、インテリジェントなポリシー決定を行うことでもあります。ファイアウォールのような iptables 管理者によって設定されたルールを解釈することにより、ポリシーを適用できます。ただし、管理者は、インフラストラクチャに適したルールの種類を知っておく必要があります。

その他のガイドは、起動して実行するために必要なコマンドに焦点を当てていますが、このガイドでは、ファイアウォールを実装するときに行う必要のあるいくつかの決定について説明します。これらの選択は、ファイアウォールの動作、サーバーのロックダウンの方法、およびサーバーが時々発生する可能性のあるさまざまな条件にどのように対応するかに影響します。使用します iptables 詳細を説明する例として、実際の決定のほとんどは、使用するツールに関係なく関連します。

デフォルトポリシーの決定

ファイアウォールを構築するとき、あなたがしなければならない基本的な決定の1つは、デフォルトのポリシーです。これにより、トラフィックが他のルールと一致しない場合に何が起こるかが決まります。デフォルトでは、ファイアウォールは、以前のルールと一致しないトラフィックを受け入れるか、そのトラフィックを拒否することができます。

デフォルトのドロップとデフォルトの受け入れ

「accept」のデフォルトポリシーは、一致しないトラフィックがサーバーに入ることが許可されることを意味します。これは、事実上、ブラックリストを維持することを意味するため、通常はお勧めできません。ブラックリストは、すべてのタイプの不要なトラフィックを明示的に予測してブロックする必要があるため、管理が困難です。これはメンテナンスの問題につながる可能性があり、一般に、確立されたポリシーに誤り、構成の誤り、予期しない穴が発生する傾向があります。

別の方法は、「ドロップ」のデフォルトポリシーです。これは、明示的なルールに一致しないトラフィックは許可されないことを意味します。これは、ホワイトリストACLに似ています。すべてのサービスを明示的に許可する必要があります。これは、最初はかなりの量の調査と作業のように見えるかもしれません。ただし、これは、ポリシーがセキュリティを重視する傾向があり、サーバーでトラフィックを受信するために何が許可されているかを正確に把握していることを意味します。

基本的に、選択は、デフォルトのセキュリティまたはすぐに使用できる到達可能なサービスへの傾向に帰着します。サービスの可用性に傾いたファイアウォールを実装したくなるかもしれませんが、明示的に許可されていない限り、ほとんどの場合、トラフィックをブロックすることをお勧めします。

デフォルトのドロップポリシーと最終的なドロップルール

デフォルトのドロップポリシーの上記の選択は、別の微妙な決定につながります。と iptables および他の同様のファイアウォールの場合、デフォルトのポリシーは、ファイアウォールの組み込みポリシー機能を使用して設定するか、ルールのリストの最後にキャッチオールドロップルールを追加することで実装できます。

これら2つの方法の違いは、ファイアウォールルールがフラッシュされた場合に何が起こるかにあります。

ファイアウォールの組み込みポリシー機能が「ドロップ」に設定されていて、ファイアウォールルールがフラッシュ（リセット）された場合、または特定の一致するルールが削除された場合、サービスは即座にリモートでアクセスできなくなります。これは、重要でないサービスのポリシーを設定するときに、ルールが削除された場合にサーバーが悪意のあるトラフィックにさらされないようにするためによく使用されます。

このアプローチの欠点は、許容ルールを再確立するまで、クライアントがサービスを完全に利用できないことです。問題を回避するためのローカルまたは帯域外アクセスがない場合は、サーバーから自分自身をロックアウトする可能性もあります（DigitalOceanサーバーは、[アクセス]にある[コンソールアクセス]ボタンを使用して、ネットワーク設定に関係なくアクセスできますコントロールパネルのDropletのページの一部）。ファイアウォールのフラッシュが意図的なものである場合は、ルールをリセットする直前にデフォルトのポリシーを「受け入れる」に切り替えるだけでこれを回避できます。

組み込みのポリシー機能を使用してドロップポリシーを設定する代わりに、ファイアウォールのデフォルトポリシーを「受け入れる」に設定してから、通常のルールで「ドロップ」ポリシーを実装することもできます。チェーンの最後に、残りの一致しないトラフィックをすべて一致および拒否する通常のファイアウォールルールを追加できます。

この場合、ファイアウォールルールがフラッシュされると、サービスにアクセスできますが、保護されません。ローカルアクセスまたは代替アクセスのオプションによっては、ルールがフラッシュされた場合にサーバーに再入できるようにするために、これが必要な悪である可能性があります。このオプションを使用する場合は、キャッチオールルールが常にルールセットのlastルールのままであることを確認する必要があります。

トラフィックのドロップと拒否

意図した宛先へのパケット通過を拒否する方法はいくつかあります。これらのどちらを選択するかは、クライアントが接続の試行をどのように認識するか、および要求が処理されないとクライアントがどれだけ迅速に判断できるかに影響します。

パケットを拒否できる最初の方法は、「ドロップ」を使用することです。ドロップは、デフォルトのポリシーとして、または一致ルールのターゲットとして使用できます。パケットがドロップされると、 iptables 基本的にそれを捨てるだけです。接続しようとしているクライアントに応答を返送せず、問題のパケットを受信したことさえあることを示すものもありません。これは、クライアント（正当かどうかに関係なく）がパケットの受信の確認を受け取らないことを意味します。

TCP接続の試行の場合、タイムアウト制限に達するまで接続は停止します。 UDPはコネクションレス型プロトコルであるため、クライアントの応答の欠如はさらにあいまいです。実際、この場合にパケットを受信しないことは、多くの場合、パケットが受け入れられたことを示しています。 UDPクライアントがパケットの受信を気にする場合は、パケットを再送信して、パケットが受け入れられたか、転送中に失われたか、またはドロップされたかを判断する必要があります。これにより、悪意のある攻撃者がサーバーポートの状態に関する適切な情報を取得するために費やす時間が長くなる可能性がありますが、正当なトラフィックに問題が発生する可能性もあります。

トラフィックをドロップする代わりに、許可しないパケットを明示的に拒否することもできます。 ICMP（インターネット制御メッセージプロトコル）は、インターネット全体で使用されるメタプロトコルであり、TCPやUDPなどの従来の通信プロトコルに依存しない帯域外チャネルとしてホスト間でステータス、診断、およびエラーメッセージを送信します。「拒否」ターゲットを使用すると、トラフィックは拒否され、ICMPパケットが送信者に返され、トラフィックは受信されたが受け入れられないことが通知されます。ステータスメッセージは、理由を示唆することができます。

これには多くの結果があります。 ICMPトラフィックがクライアントに流出することが許可されていると仮定すると、トラフィックがブロックされていることがすぐに通知されます。正当なクライアントの場合、これは、管理者に連絡するか、接続オプションをチェックして、正しいポートに接続していることを確認できることを意味します。悪意のあるユーザーの場合、これは、スキャンを完了し、開いているポート、閉じているポート、およびフィルター処理されたポートを短時間でマップできることを意味します。

トラフィックをドロップするか拒否するかを決定する際には、考慮すべきことがたくさんあります。重要な考慮事項の1つは、ほとんどの悪意のあるトラフィックが実際には自動化されたスクリプトによって実行されることです。スクリプトは通常、時間に敏感ではないため、不正なトラフィックをドロップしても、正当なユーザーに悪影響を与える一方で、意図的な阻害要因にはなりません。このテーマの詳細については、こちらをご覧ください。

ドロップvsリジェクト応答テーブル

次の表は、ファイアウォールで保護されているサーバーが、宛先ポートに適用されているポリシーに応じて、さまざまな要求にどのように反応するかを示しています。

クライアントパケットタイプ	NMapコマンド	ポートポリシー	応答	推定ポート状態
TCP	nmap [-sT \| -sS] -Pn	承認	TCP SYN / ACK	開ける
TCP	nmap [-sT \| -sS] -Pn	落とす	（無し）	フィルタリング
TCP	nmap [-sT \| -sS] -Pn	拒絶	TCPリセット	閉まっている
UDP	nmap -sU -Pn	承認	（無し）	開くまたはフィルタリング
UDP	nmap -sU -Pn	落とす	（無し）	開くまたはフィルタリング
UDP	nmap -sU -Pn	拒絶	ICMPポートに到達できません	閉まっている

最初の列は、クライアントによって送信されたパケットタイプを示します。 2番目の列には、 nmap 各シナリオのテストに使用できるコマンド。 3番目の列は、ポートに適用されているポートポリシーを示しています。 4番目の列はサーバーが送り返す応答であり、5番目の列はクライアントが受信した応答に基づいてポートについて推測できるものです。

ICMPポリシー

拒否されたトラフィックをドロップするか拒否するかに関する質問と同様に、サーバー宛てのICMPパケットを受け入れるかどうかについてはさまざまな意見があります。

ICMPは、多くのことに使用されるプロトコルです。上で見たように、他のプロトコルを使用したリクエストに関するステータス情報を提供するために、しばしば返送されます。おそらく、リモートホストへの接続性を確認するためにネットワークpingを送信および応答する最もよく知られている機能です。 ICMPには他にも多くの用途がありますが、あまり知られていませんが、それでも有用です。

ICMPパケットは、「タイプ」ごとに編成され、さらに「コード」ごとに編成されます。タイプは、メッセージの一般的な意味を指定します。たとえば、タイプ3は、宛先に到達できなかったことを意味します。コードは、タイプに関する詳細情報を提供するためによく使用されます。たとえば、ICMPタイプ3コード3は宛先ポートが使用できないことを意味し、ICMPタイプ3コード0は宛先ネットワークに到達できなかったことを意味します。

常にブロックできるタイプ

一部のICMPタイプは非推奨であるため、無条件にブロックする必要があります。これらの中には、ICMPソースクエンチ（タイプ4コード0）と代替ホスト（タイプ6）があります。タイプ1、2、7、およびタイプ15以上はすべて非推奨であり、将来の使用のために予約されているか、実験的です。

ネットワーク構成に応じてブロックするタイプ

一部のICMPタイプは、特定のネットワーク構成で役立ちますが、他の構成ではブロックする必要があります。

たとえば、ICMPリダイレクトメッセージ（タイプ5）は、不適切なネットワーク設計を明らかにするのに役立ちます。より適切なルートがクライアントに直接利用できる場合、ICMPリダイレクトが送信されます。したがって、ルーターが同じネットワーク上の別のホストにルーティングする必要のあるパケットを受信すると、ICMPリダイレクトメッセージを送信して、将来的に他のホストを介してパケットを送信するようにクライアントに通知します。

これは、ローカルネットワークを信頼していて、初期構成中にルーティングテーブルの非効率性を見つけたい場合に役立ちます（ルートを修正する方が長期的な解決策として優れています）。ただし、信頼できないネットワークでは、悪意のあるユーザーがICMPリダイレクトを送信して、ホスト上のルーティングテーブルを操作する可能性があります。

一部のネットワークで有用であり、他のネットワークで潜在的に有害である他のICMPタイプは、ICMPルーターアドバタイズメント（タイプ9）およびルーター要請（タイプ10）パケットです。ルーターのアドバタイズメントパケットと送信請求パケットは、IRDP（ICMPインターネットルーター検出プロトコル）の一部として使用されます。これは、ホストがネットワークの起動時または参加時に、使用可能なルーターを動的に検出できるようにするシステムです。

ほとんどの場合、ホストは、使用するゲートウェイ用に静的ルートを構成することをお勧めします。これらのパケットは、ICMPリダイレクトパケットと同じ状況で受け入れられる必要があります。実際、ホストは検出されたルートのトラフィックの優先ルートを認識しないため、多くの場合、検出直後にリダイレクトメッセージが必要になります。ルーター要請パケットを送信したり、アドバタイズメントパケットに基づいてルートを変更したりするサービスを実行していない場合（ rdisc）、これらのパケットを安全にブロックできます。

多くの場合安全に許可されるタイプ

通常は安全に許可できるICMPタイプを以下に示しますが、特に注意が必要な場合は、無効にすることをお勧めします。

タイプ8—エコー要求：これらは、サーバーに向けられたping要求です。通常、これらを許可するのが安全です（これらのパケットを拒否しても、サーバーが隠されることはありません。ホストが稼働しているかどうかをユーザーが確認する方法は他にもたくさんありますが、必要に応じて、ユーザーをブロックしたり、応答する送信元アドレスを制限したりできます。
タイプ13—タイムスタンプ要求：これらのパケットは、クライアントが遅延情報を収集するために使用できます。これらは一部のOSフィンガープリント技術で使用できるため、必要に応じてブロックするか、応答するアドレスの範囲を制限してください。

以下のタイプは通常、ファイアウォールが行った要求への応答を許可するようにファイアウォールを構成することにより、明示的なルールなしで許可できます（ conntrack 許可するモジュール ESTABLISHED と RELATED トラフィック）。

タイプ0—エコー応答：これらはエコー要求（ping）への応答です。
タイプ3—宛先到達不能：正当な宛先到達不能パケットは、パケットを配信できなかったことを示す、サーバーによって作成された要求への応答です。
タイプ11—時間を超えました：これは、サーバーによって生成されたパケットがTTL値を超えたために宛先に到達する前に停止した場合に返される診断エラーです。
タイプ12—パラメータの問題：これは、サーバーからの発信パケットの形式が正しくないことを意味します。
タイプ14—タイムスタンプ応答：これらは、サーバーによって生成されたタイムスタンプクエリに対する応答です。

一部のセキュリティ専門家は、すべての着信ICMPトラフィックをブロックすることを推奨していますが、多くの人がインテリジェントなICMP受け入れポリシーを推奨しています。リンクhereおよびhereに詳細があります。

接続制限とレート制限

一部のサービスとトラフィックパターンでは、クライアントがそのアクセスを悪用していない限り、アクセスを許可したい場合があります。リソースの使用を制限する2つの方法は、接続制限とレート制限です。

接続制限

接続制限は、次のような拡張機能を使用して実装できます connlimit クライアントが開いているアクティブな接続の数を確認します。これは、一度に許可される接続の数を制限するために使用できます。接続制限を課すことを決定した場合、それがどのように適用されるかに関して行うべきいくつかの決定があります。決定の一般的な内訳は次のとおりです。

アドレスごと、ネットワークごと、またはグローバルベースで制限しますか？
特定のサービスまたはサーバー全体のトラフィックを一致させて制限しますか？

接続はホストごとに制限することも、ネットワークプレフィックスを指定してネットワークセグメントに制限を設定することもできます。サービスまたはマシン全体の接続のグローバル最大数を設定することもできます。これらを組み合わせて、接続番号を制御するためのより複雑なポリシーを作成することが可能であることに注意してください。

レート制限

レート制限を使用すると、サーバーがトラフィックを受け入れるレートまたは頻度を管理するルールを作成できます。レート制限に使用できるさまざまな拡張機能があります。 limit, hashlimit、と recent. 使用する拡張機能の選択は、トラフィックを制限するwayに大きく依存します。

The limit 拡張により、制限に達するまで問題のルールが一致し、その後、さらにパケットがドロップされます。「5/秒」のような制限を設定すると、ルールは1秒あたり5パケットの一致を許可し、その後、ルールは一致しなくなります。これは、サービスのグローバルレート制限を設定するのに適しています。

The hashlimit 拡張機能はより柔軟で、いくつかの値を指定できます iptables 一致を評価するためにハッシュします。たとえば、送信元アドレス、送信元ポート、宛先アドレス、宛先ポート、またはこれら4つの値の任意の組み合わせを調べて、各エントリをハッシュできます。受信したパケットまたはバイトによって制限できます。基本的に、これにより、クライアントごとまたはサービスごとの柔軟なレート制限が提供されます。

The recent 拡張機能は、クライアントIPアドレスをリストに動的に追加するか、ルールが一致したときに既存のリストと照合します。これにより、複雑なパターンのさまざまなルール間で制限ロジックを分散させることができます。他のリミッターと同様にヒット数と時間範囲を指定する機能がありますが、追加のトラフィックが見られる場合は時間範囲をリセットすることもでき、制限されている場合はクライアントにすべてのトラフィックを効果的に停止させることができます。

使用するレート制限拡張機能の選択は、適用する正確なポリシーによって異なります。

モノリシックvsチェーンベースの管理

全て iptables ファイアウォールポリシーは、組み込みチェーンの拡張に基づいています。単純なファイアウォールの場合、これは多くの場合、チェーンのデフォルトポリシーを変更し、ルールを追加するという形をとります。より複雑なファイアウォールの場合、追加のチェーンを作成して管理フレームワークを拡張することをお勧めします。

ユーザーが作成したチェーンは、本質的に呼び出しチェーンに関連付けられています。ユーザーが作成したチェーンにはデフォルトのポリシーがないため、パケットがユーザーが作成したチェーンを通過した場合、パケットは呼び出し元のチェーンに戻り、評価を続行します。このことを念頭に置いて、ユーザーが作成したチェーンは、主に組織的な目的、ルールの一致条件をよりドライにし、一致条件を分割することで読みやすさを向上させるのに役立ちます。

かなりの数のルールに対して特定の一致基準を繰り返すことに気付いた場合は、代わりに、共有一致基準を使用して新しいチェーンへのジャンプルールを作成することをお勧めします。新しいチェーン内で、共有一致基準を削除したルールのセットを追加できます。

単純な編成を超えて、これはいくつかの有益な副作用をもたらす可能性があります。たとえば、非常によく似たルールのセットにチェーンをインテリジェントに使用することは、正しい場所にルールを追加する方が簡単で、エラーが発生しにくいことを意味します。また、チェーンで制限することにより、気になるポリシーの部分を表示して理解するのも簡単になります。

すべてのルールを組み込みチェーンの1つにまとめるかどうか、または追加のチェーンを作成して利用するかどうかの決定は、ルールセットの管理がどれほど複雑で簡単かによって大きく異なります。

結論

これで、サーバーのファイアウォールポリシーを設計するときに行う必要のある決定のいくつかについて、かなり良いアイデアが得られるはずです。通常、ファイアウォールに関連する時間の投資は初期設定に大きく依存し、管理はかなり単純になります。ニーズに最適なポリシーを考案するには、時間、思考、実験が必要になる場合がありますが、そうすることで、サーバーのセキュリティをより細かく制御できるようになります。

ファイアウォールと iptables 具体的には、次の記事を確認してください。

次のガイドは、ポリシーの実装に役立ちます。開始するには、ファイアウォールに一致するガイドを選択してください。