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

紹介

ファイアウォールを使用することは、構文を学ぶことと同じくらい、賢明なポリシーの決定を行うことです。iptablesなどのファイアウォールは、管理者が設定したルールを解釈してポリシーを強制するように設計されています。しかし、管理者としては、インフラストラクチャに適切な種類のルールを知る必要があります。

他のガイドでは、起動と実行に必要なコマンドに焦点を当てていますが、このガイドでは、ファイアウォールを実装する際に行う決定について議論します。これらの選択肢は、ファイアウォールの動作方法、サーバーのロックダウンの程度、および発生するさまざまな状況への応答方法に影響を与えます。特定の例としてiptablesを使用しますが、ほとんどの概念は広く適用可能です。

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

ファイアウォールを構築する際に、最も重要な決定の一つはデフォルトポリシーです。これは、トラフィックが他のルールに一致しない場合の動作を決定します。デフォルトでは、ファイアウォールは以前のルールに一致しないトラフィックをACCEPTまたはそのトラフィックをDROPすることができます。

デフォルトドロップ対デフォルトアクセプト

A default policy of ACCEPT means that any unmatched traffic is allowed to enter the server. This is generally not recommended, because it means that you would need to work backwards from there, blocking all unwanted traffic. Blocklist-type approaches are difficult to manage, because you’d need to anticipate and block every type of unwanted traffic. This can lead to maintenance headaches and is generally prone to mistakes, misconfigurations, and unanticipated holes in the established policy.

別の選択肢は、デフォルトポリシーをDROPにすることです。これは、明示的なルールで一致しないトラフィックは許可されず、すべてのサービスが明示的に許可される必要があることを意味します。これは最初の設定がかなり多く必要になるかもしれませんが、この方法では、ポリシーがセキュリティに向かい、サーバーでトラフィックを受信することが許可されるものが正確にわかります。また、ほとんどの事前構成済みポリシーがこのアプローチに従うため、既存のデフォルトを基に構築できます。

デフォルトドロップポリシー対最終ドロップルール

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

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

ファイアウォールの組み込みポリシー機能がDROPに設定されている場合、およびファイアウォールのルールがフラッシュされたり、特定の一致するルールが削除されたりすると、サービスは即座にリモートからアクセスできなくなります。これは、非クリティカルなサービスのポリシーを設定する際に良い考えです。ルールが削除された場合、サーバーが悪意のあるトラフィックにさらされないようにします。

このアプローチのデメリットは、クライアントが完全にサービスを利用できなくなることです。パーミッシブルールを再確立するまで、サーバーにロックアウトされる可能性さえあります。ローカルまたはウェブベースのリモートアクセスがない場合は、特に注意が必要です。

組み込みポリシー機能を使用してドロップポリシーを設定する代わりに、ファイアウォールのデフォルトポリシーをACCEPTに設定し、通常のルールでDROPポリシーを実装することができます。チェーンの最後に、残っているすべての一致しないトラフィックを一致させて拒否する通常のファイアウォールルールを追加できます。

この場合、ファイアウォールのルールがフラッシュされた場合、サービスはアクセス可能ですが保護されません。ローカルまたは代替アクセスのオプションに応じて、ルールがフラッシュされた場合にサーバーに再入ることができるかもしれません。このオプションを使用する場合は、キャッチオールルールが常にルールセットの最後のルールになるように確認してください。

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

パケットを目的の宛先に到達させないためにはいくつかの異なる方法があります。これらの選択によって、クライアントが接続試行をどのように認識し、リクエストが処理されないことをどれくらい速く判断できるかに影響します。

最初の方法は、DROPを使用することです。ドロップはデフォルトポリシーとしても、マッチルールのターゲットとしても使用できます。パケットがドロップされると、iptablesは単にそれを破棄します。クライアントが接続しようとしていることを示す応答を送信せず、問題のパケットを受信したことさえ示しません。つまり、クライアント（正当または不正なもの）は、パケットの受信の確認を受け取りません。

TCP接続試行（ウェブブラウザによって行われる接続など）では、接続がタイムアウト制限に達するまで接続が停止します。UDPクライアントに対する応答が不明確です。実際、UDPパケットを受信しないことは、そのパケットが受け入れられたことを示すことがしばしばあります。UDPクライアントがパケットの受信に関心がある場合、それらを再送して受け入れられたか、輸送中に失われたか、ドロップされたかを判断する必要があります。これにより、悪意のあるアクターがサーバーポートの状態に関する情報を取得するために費やす時間が増える可能性がありますが、正当なトラフィックにも問題が発生する可能性があります。

トラフィックをドロップする代わりに、許可されていないパケットを明示的に拒否することもあります。ICMP、またはInternet Control Message Protocolは、TCPやUDPのような従来の通信プロトコルに依存しない、アウトオブバンドチャネルとしてインターネット全体で使用されるメタプロトコルです。 DROP ターゲットの代わりに REJECT ターゲットを使用すると、トラフィックが拒否され、送信元にはICMPパケットが返されて、トラフィックが受信されたことを通知しますが受け入れられないことが伝えられます。理由を提供するためのステータスメッセージも含めることができます。

これにはいくつかの影響があります。ICMPトラフィックがクライアントに到達することが許可されていると仮定すると、彼らはすぐにトラフィックがブロックされていることを知らされます。正当なクライアントの場合、これは管理者に連絡したり、接続オプションを確認して正しいポートに到達していることを確認できることを意味します。悪意のあるユーザーの場合、これは彼らが短い時間内にオープン、クローズド、およびフィルタリングされたポートをスキャンしてマップを作成できることを意味します。

トラフィックをドロップするか拒否するかを決定する際に考慮すべき点が多数あります。重要な考慮事項の1つは、ほとんどの悪意のあるトラフィックが実際には自動化されたスクリプトによって行われるということです。これらのスクリプトは通常監視されていないため、不正なトラフィックをドロップしてもそれらを有意義に妨げることはありませんし、正当なユーザーには否定的な影響があります。このトピックに関する詳細は、Peter Benie’s websiteで見つけることができます。

ドロップ対拒否応答テーブル

以下の表は、ファイアウォールによって保護されたサーバーが、宛先ポートに適用されるポリシーに応じて異なるリクエストにどのように反応するかを示しています。

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

ICMPポリシー

拒否されたトラフィックをドロップするか拒否するかを決定すると同様に、サーバーに宛てられたICMPパケットを受け入れるか拒否するオプションがあります。

ICMPは、多くのことに使用されるプロトコルです。前述のように、他のプロトコルを使用したリクエストの状態情報を返すためによく送信されます。最も一般的な機能の1つは、リモートホストへの接続可能性を確認するためにネットワークピングを送信および応答することです。ICMPの他にも広く知られていないが便利な用途が多数あります。

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

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

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

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

これは、ローカルネットワークを信頼し、初期構成中にルーティングテーブルの非効率性を検出したい場合に役立ちます。信頼できないネットワークでは、悪意のあるユーザーがホスト上のルーティングテーブルを操作するためにICMPリダイレクトを送信する可能性があります。

一部のネットワークで有用であり、他のネットワークでは潜在的に有害である他のICMPタイプには、ICMPルーター広告（タイプ9）およびルーター要求（タイプ10）パケットがあります。ルーター広告および要求パケットは、IRDP（ICMP Internet Router Discovery Protocol）の一部として使用され、ホストが起動時またはネットワークに参加した際に利用可能なルーターを動的に検出するシステムです。

ほとんどの場合、ホストが使用するゲートウェイの静的ルートが構成されている方が良いでしょう。これらのパケットは、ICMPリダイレクトパケットと同じ状況で受け入れるべきです。実際、ホストは任意の検出されたルートのトラフィックのための優先ルートを知らないため、リダイレクトメッセージは通常、直接検出後に必要です。ルーター要求パケットを送信するサービスや広告パケットに基づいてルートを変更するサービス（rdiscなど）を実行していない場合は、これらのパケットを安全にブロックできます。

通常安全な許可されるタイプ

通常、許可されるICMPタイプは次のとおりですが、より慎重である場合はこれらを無効にすることができます。

• タイプ8 – エコーリクエスト：これらはサーバーに向けられたpingリクエストです。通常、これらを許可しても安全です（これらのパケットを拒否してもサーバーを隠すことはできません。ユーザーは他の方法でホストの状態を確認することができます）。ただし、必要に応じてこれらをブロックするか、応答するソースアドレスの範囲を制限することもできます。
• タイプ13 – タイムスタンプリクエスト：これらのパケットは、クライアントがレイテンシ情報を収集するために使用できます。一部のOS指紋認識技術で使用されることもあるため、これらをブロックするか、応答するアドレスの範囲を制限することができます。

以下のタイプは、ファイアウォールを設定して、リクエストに対する応答を許可するようにすることで、明示的なルールなしに通常許可できます（conntrackモジュールを使用してESTABLISHEDおよびRELATEDトラフィックを許可する）。

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

すべての受信 ICMP トラフィックをブロックすることは、まだ一部のセキュリティ専門家によって推奨されていますが、多くの人々は現在、インテリジェントな ICMP 受入ポリシーを奨励しています。これら2つの Stackexchange スレッドには、詳細な情報があります。

接続制限とレート制限

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

接続制限

接続制限は、connlimit のような拡張機能を使用して、クライアントがオープンしているアクティブな接続の数を確認することで実装することができます。これにより、一度に許可される接続の数を制限することができます。接続制限を課す場合、以下の決定をする必要があります：

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

接続はホストごとに制限することもできますし、ネットワークセグメントごとに制限することもできます（たとえば、組織全体のIPアドレス範囲などを指定することができます）。また、サービスまたはマシン全体の最大接続数も設定することができます。これらを組み合わせてより複雑なポリシーを作成して、接続数を制御することも可能です。

レート制限

レート制限では、サーバーでトラフィックが受け入れられる速度や頻度を制御するルールを作成することができます。レート制限には、limit、hashlimit、recentなどのさまざまなファイアウォール拡張が使用されます。使用する拡張機能の選択は、トラフィックをどのように制限したいかに大きく依存します。

limit拡張機能は、そのルールが一致する限り、制限が達成されるまで一致し続けます。その後、さらにパケットはドロップされます。 5/secのような制限では、1秒間に5つのパケットが一致し、その後はルールが一致しなくなります。これはサービスのグローバルなレート制限を設定するのに適しています。また、Fail2banのような追加のサービスを展開して、繰り返しの接続試行をブロックすることもできます。

hashlimit拡張機能はより柔軟であり、iptablesが一致を評価するためにハッシュ化する値の一部を指定することができます。例えば、ソースアドレス、ソースポート、宛先アドレス、宛先ポート、またはこれら四つの値の組み合わせを見て、各エントリを評価することができます。パケットまたは受信バイトで制限することができます。これにより、クライアントごとのまたはサービスごとの柔軟なレート制限が可能です。

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

総合管理とチェインベースの管理

すべてのiptablesおよびnftablesファイアウォールポリシーは、基本的には組み込みチェインの拡張に根ざしています。まず、これは通常、既存のチェインのデフォルトポリシーを変更し、ルールを追加することを意味します。より複雑なファイアウォールの場合、追加のチェインを作成して管理フレームワークを拡張することがしばしば良いアイデアです。

ユーザー作成のチェーンは、二次的に呼び出され、それらが発生した「呼び出しチェーン」と本質的に結び付いています。ユーザー作成のチェーンにはデフォルトのポリシーがないため、パケットがユーザー作成のチェーンを通過した場合、呼び出しチェーンに戻り、評価が継続されます。その観点から、ユーザー作成のチェーンは、主に組織的な目的のために役立ちます。ルールの一致条件をより保守可能にし、一致条件を分割することで読みやすさを向上させるためです。

特定の一致基準を多くのルールで繰り返す場合は、共有の一致基準を持つジャンプルールを新しいチェーンに作成することが価値があるかもしれません。新しいチェーン内では、冗長な一致基準を省略してそのルールセットを追加することができます。

組み込みのチェーンのいずれかにすべてのルールをまとめるか、追加のチェーンを作成して利用するかどうかは、ルールセットがどのように複雑かに依存します。

結論

サーバーのファイアウォールポリシーを設計する際に行う必要がある決定について、より良い理解ができるはずです。通常、ファイアウォールにかかる時間投資は、初期のセットアップに大きく偏っています。自分のニーズに最も適したポリシーを作成するには、時間と実験が必要かもしれませんが、それによりサーバーのセキュリティをよりコントロールできるようになります。

ファイアウォールや iptables についてさらに詳しく知りたい場合は、以下の記事をご覧ください。

• Iptablesファイアウォールの動作方法
• A Deep Dive into Iptables and Netfilter Architecture

以下のガイドは、ポリシーを実装するのに役立ちます。ファイアウォールに合わせたガイドを選択して、開始してください：

• Ubuntu 22.04でNftablesを使用したファイアウォールの設定方法
• Ubuntu 22.04でUFWを使用したファイアウォールの設定方法
• Rocky Linux 9でFirewallDを使用したファイアウォールの設定方法