サーバーを安全に保護するため、効果的なファイアウォールポリシーを選択する方法を教えてください。

自己紹介

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

他のガイドが立ち上げに必要なコマンドに焦点を当てているのに対し、このガイドでは、ファイアウォールを実装する際に行う必要のあるいくつかの決定事項について説明します。これらの選択は、ファイアウォールの動作やサーバーのロックダウンの程度、およびさまざまな状況への応答方法に影響を及ぼします。具体的な例としてiptablesを使用しますが、ほとんどの概念は広く適用できます。

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

ファイアウォールを構築する際に最も重要な決定の一つは、デフォルトポリシーです。これは、トラフィックが他のルールにマッチしない場合に何が起こるかを決定します。デフォルトでは、ファイアウォールは以前のルールにマッチしないトラフィックを受け入れるか、そのトラフィックを拒否するかのいずれかを選択することができます。

デフォルトドロップ対デフォルト承諾

デフォルトのACCEPTポリシーは、一致しないトラフィックがサーバーに入ることを許可することを意味します。これは一般的には推奨されません。なぜなら、望ましくないトラフィックをすべてブロックするために逆算して作業する必要があるからです。ブロックリスト型のアプローチは管理が困難であり、望ましくないトラフィックのあらゆるタイプを予測してブロックする必要があります。これにより、保守上の問題や設定ミス、予期しないポリシーの穴が生じる可能性があります。

デフォルトポリシーは「ドロップ」という選択肢です。これは明示的なルールにマッチしないトラフィックは許可されないことを意味します。全てのサービスは明示的に許可する必要があり、最初の設定作業量はかなり大きくなるかもしれません。しかし、これによりセキュリティ志向のポリシーを持ち、サーバーに対して受信トラフィックが許可されるものを正確に把握できます。また、ほとんどの予め設定されたポリシーもこのアプローチに従っており、既存のデフォルト設定をベースに構築することができます。

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

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

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

もし、ファイアウォールの組み込みポリシー機能が「ドロップ」に設定されていて、ファイアウォールルールがリセットされたり、特定のマッチングルールが削除された場合、リモートからサービスにアクセスできなくなります。これは、ルールが削除された場合に悪意のあるトラフィックからサーバーが保護されるため、重要でないサービスのポリシーを設定する際に良いアイデアです。

このアプローチの欠点は、許可ルールを再確立するまで、お客様のサービスが完全に利用できなくなることです。さらに、ローカルまたはWebベースのリモートアクセスがない場合、サーバーに自分自身がロックアウトされる可能性もあります。

組み込まれたポリシー機能を使用してドロップポリシーを設定する代わりに、ファイアウォールのデフォルトポリシーを「ACCEPT」に設定し、その後通常のルールで「DROP」ポリシーを実装することができます。チェーンの最後に、マッチしなかったトラフィックをすべて阻止する通常のファイアウォールルールを追加することができます。

この場合、ファイアウォールのルールが削除されると、サービスにアクセスできますが保護されません。ローカルまたは代替アクセスのオプション次第では、ルールが削除された場合にサーバーに再入することを保証するために必要な悪になるかもしれません。このオプションを選択する場合は、キャッチオールルールが常にルールセットの最後に残るようにしてください。

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

パケットが予定した宛先に到達しないようにするためには、いくつかの異なる方法があります。これらの選択肢によって、クライアントが接続試行を認識する方法やリクエストが受けられないことを早く確認する速度に影響を及ぼします。

パケットが拒否される最初の方法は、DROPです。DROPはデフォルトポリシーとしても使用されるし、マッチルールの対象としても使用できます。パケットがドロップされると、iptablesはそれをただ捨ててしまいます。接続しようとするクライアントに応答を送らず、問題のパケットを受信したことすら示しません。つまり、クライアント（正規のものであってもそうでないものであっても）はパケットの到着の確認を受け取りません。

TCP接続試行（例えばウェブブラウザによる接続）では、接続はタイムアウト制限に達するまで中断されます。UDPクライアントの場合、レスポンスのないことはより曖昧です。実際、UDPパケットが返らないことは、そのパケットが受け入れられたことを示す場合がしばしばあります。もしUDPクライアントがパケットの受信を重要視する場合、受け入れられたか、通信中に失われたのか、破棄されたのかを判断するために、再送信が必要になります。このことは、悪意のある攻撃者がサーバーポートの状態に関する情報を得るために費やす時間を増やすことができますが、合法的なトラフィックにも問題を引き起こす可能性があります。

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

これにはいくつかの結果があります。ICMPトラフィックがクライアントに届けることが許可されていると仮定すると、彼らはすぐにトラフィックがブロックされていることを知らされます。正当なクライアントの場合、これは管理者に連絡を取るか、接続オプションを確認して正しいポートにアクセスしようとすることを意味します。悪意のあるユーザーの場合、これは彼らが短時間でスキャンを完了し、開いているポート、閉じているポート、フィルタリングされたポートを把握することができるということを意味します。

トラフィックを破棄するか拒否するかを決める際には、考慮すべき点がたくさんあります。重要な考慮事項の一つは、ほとんどの悪意のあるトラフィックが自動化されたスクリプトによって行われるということです。これらのスクリプトは通常、監督されていないため、不正なトラフィックを破棄しても意味のある抑止効果はなく、正当なユーザーにネガティブな影響を及ぼします。このテーマについては、Peter Benieのウェブサイトで詳細を確認できます。

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

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

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

ICMPポリシー

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

ICMPは多くのことに使用されるプロトコルです。先述のように、他のプロトコルを使用した要求の状態情報を返すためによく送信されます。その中でも最も一般的な機能の一つは、ネットワークのピングを送信し、遠隔ホストへの接続可能性を確認するための応答を行うことです。知名度は低いですが、ICMPには他にも多くの有用な用途があります。

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

ネットワーク構成によってブロックするタイプの種類

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

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

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

一部のネットワークでは有用であり、他のネットワークでは潜在的に有害である他のICMP種類には、ICMPルータ告知（タイプ9）とルータ要求（タイプ10）パケットがあります。ルータ告知と要求パケットは、ICMPインターネットルーター発見プロトコル（IRDP）の一部として使用され、ホストが起動時やネットワークに参加した際に利用可能なルーターをダイナミックに発見することができます。

ほとんどの場合、ホストが使用するゲートウェイに対して静的なルートの設定がある方が良いです。これらのパケットはICMPリダイレクトパケットと同じ状況で受け入れるべきです。実際に、ホストは発見されたルートのトラフィックの優先ルートを知らないため、リダイレクトメッセージは発見直後にしばしば必要です。もしもルーターソリシテーションパケットを送信したり、広告パケットに基づいてルートを変更するサービス（例えばrdisc）を実行していない場合は、これらのパケットを安全にブロックすることができます。

よく許可しても安全なタイプ

通常安全な許可ICMPタイプは以下の通りですが、より慎重にしたい場合は無効にすることもあります。

• Type 8 — Echo request: These are ping requests directed at your server. It is usually safe to allow these (denying these packets doesn’t hide your server, since there are plenty of other ways for users to find out if your host is up), but you can block them or limit the source addresses you respond to if you’d like.
• Type 13 — Timestamp request: These packets can be used by clients to collect latency information. They can be used in some OS fingerprinting techniques, so you can block them or limit the range of addresses that you respond to.

以下のタイプは、通常、ファイアウォールを設定して自分自身が行ったリクエストへの応答を許可することで、明示的なルールなしに許可されることがあります（conntrackモジュールを使用してESTABLISHEDおよびRELATEDトラフィックを許可することで）。

• Type 0 — Echo replies: These are responses to echo requests (pings).
• Type 3 — Destination Unreachable: Legitimate destination unreachable packets are responses to requests created by your server indicating that the packet could not be delivered.
• Type 11 — Time exceeded: This is a diagnostic error returned if a packet generated by your server died before reaching the destination because of exceeding its TTL value.
• Type 12 — Parameter problem: This means that an outgoing packet from your server was malformed.
• Type 14 — Timestamp responses: These are the responses for timestamp queries generated by your server.

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

接続制限とレート制限

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

接続制限

接続制限は、クライアントがオープンしているアクティブな接続の数をチェックするために、connlimitなどの拡張機能を使用して実装することができます。これを使用すると、同時に許可される接続の数を制限することが可能です。接続制限を課すことを決定した場合、いくつかの決定をする必要があります。

• Do you limit on a per-address, per-network, or global basis?
• Do you match and restrict traffic for a specific service or to the server as a whole?

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

レート制限

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

制限の延長により、そのルールは制限に達するまで一致し続け、その後にはさらなるパケットは破棄されます。例えば、5/秒という制限では、1秒あたり5つのパケットが一致し、その後はルールが一致しなくなります。これは、サービスのグローバルなレート制限を設定するのに役立ちます。また、Fail2banのような追加のサービスを展開して、繰り返しの接続試行をブロックすることもできます。

ハッシュリミット拡張機能は柔軟性があり、iptablesがマッチを評価するためにハッシュ化する値をいくつか指定することができます。例えば、ソースアドレス、ソースポート、宛先アドレス、宛先ポートのいずれか、またはこれら４つの値の組み合わせを各エントリーの評価に使用することができます。パケット数または受信バイト数で制限することができます。これにより、柔軟なクライアント毎またはサービス毎のレート制限が行えます。

最近の拡張機能では、ルールが一致した場合にクライアントのIPアドレスをリストに動的に追加するか、既存のリストと照合します。これにより、複雑なパターンに対して限定ロジックを複数の異なるルールに広げることができます。他の制限機能と同様に、ヒット数と時間範囲を指定できるだけでなく、追加のトラフィックが確認された場合に時間範囲をリセットすることもできます。これにより、制限がかかっている場合、クライアントはすべてのトラフィックを停止することが求められます。

単一体管理 vs チェーンベースの管理

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

ユーザーが作成したチェーンは、セカンダリと呼ばれ、元々の「呼び出しチェーン」と密接に関連しています。ユーザーが作成したチェーンにはデフォルトのポリシーがありませんので、パケットがユーザーが作成したチェーンを通過した場合、呼び出し元のチェーンに戻り、評価を続けます。このような観点から、ユーザーが作成したチェーンは主に組織的な目的で有用であり、ルールのマッチング条件を管理しやすくするために、また、マッチング条件を分割することで可読性を向上させるために利用されます。

もし特定のマッチ条件を多くのルールで繰り返している場合は、共有のマッチ条件を持つ新しいチェインにジャンプルールを作成することは、価値があるかもしれません。新しいチェイン内では、重複するマッチ条件を省いたルールセットを追加することができます。

ルールセットがどれほど複雑かによって、組み込みのチェーンにすべてのルールを統合するか、あるいは追加のチェーンを作成して利用するかの決定が下されます。

結論

サーバーのファイアウォールポリシーの設計時に必要な意思決定の理解がより深まったことでしょう。通常、ファイアウォールに関連する時間的な投資は初期設定に大きく偏ります。ニーズに最も適したポリシーを見つけるには、時間と実験が必要かもしれませんが、それを行うことでサーバーのセキュリティに対するより多くの制御が得られます。

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

• How the Iptables Firewall Works
• A Deep Dive into Iptables and Netfilter Architecture

次のガイドは、方針の実施をサポートします。始めるために、ファイアウォールに合わせたガイドを選んでください。

• How To Set Up a Firewall Using Nftables on Ubuntu 22.04
• How To Set Up a Firewall with UFW on Ubuntu 22.04
• How To Set Up a Firewall Using FirewallD on Rocky Linux 9