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

前書き

ファイアウォールを使用することは、構文を学習することと同じくらいインテリジェントなポリシー決定を行うことです。 「+ iptables +」のようなhttps://www.digitalocean.com/community/tutorials/what-is-a-firewall-and-how-does-it-work[Firewalls]は、管理者。 ただし、管理者は、インフラストラクチャに適したルールの種類を知る必要があります。

https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-iptables-on-ubuntu-14-04 [その他のガイド]は、立ち上がるために必要なコマンドに焦点を当てていますこのガイドでは、ファイアウォールを実装するときに行う必要がある決定のいくつかについて説明します。 これらの選択は、ファイアウォールの動作、サーバーのロックダウン、および時々発生する可能性のあるさまざまな条件への応答方法に影響します。 詳細を説明する例として「+ iptables +」を使用しますが、実際の決定のほとんどは、使用するツールに関係なく関連します。

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

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

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

「受け入れ」のデフォルトポリシーは、一致しないトラフィックがサーバーに入ることを許可することを意味します。 これは一般的には推奨されません。これは、事実上、ブラックリストを維持することになるからです。 ブラックリストは、あらゆる種類の不要なトラフィックを明示的に予測およびブロックする必要があるため、管理が困難です。 これは、メンテナンスの頭痛につながる可能性があり、一般にミス、設定ミス、および確立されたポリシーの予期しないホールになりやすいです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

トラフィックをドロップするか拒否するかを決定する際に考慮すべき点がたくさんあります。 重要な考慮事項の1つは、ほとんどの悪意のあるトラフィックが実際に自動スクリプトによって実行されることです。 通常、スクリプトは時間に敏感ではないため、不正なトラフィックをドロップしても、正当なユーザーにマイナスの影響を与えることはありませんが、望ましいインセンティブを失うことはありません。 このテーマの詳細については、http://www.chiark.greenend.org.uk/%7Epeterb/network/drop-vs-reject [こちら]をご覧ください。

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

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

Client Packet Type NMap Command Port Policy Response Inferred Port State

TCP

nmap [-sT

-sS] -Pn <server>

Accept

TCP SYN/ACK

Open

TCP

nmap [-sT

-sS] -Pn <server>

Drop

(none)

Filtered

TCP

nmap [-sT

-sS] -Pn <server>

Reject

TCP RESET

Closed

UDP

nmap -sU -Pn <server>

Accept

(none)

Open or Filtered

UDP

nmap -sU -Pn <server>

Drop

(none)

Open or Filtered

UDP

nmap -sU -Pn <server>

最初の列は、クライアントが送信したパケットタイプを示します。 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インターネットルーター検出プロトコル)の一部として使用されます。IRDPは、ネットワークの起動時または参加時にホストが使用可能なルーターを動的に検出できるシステムです。

ほとんどの場合、ホストが使用するゲートウェイ用に構成された静的ルートを持つ方が適切です。 これらのパケットは、ICMPリダイレクトパケットと同じ状況で受け入れられる必要があります。 実際、ホストは検出されたルートのトラフィックの優先ルートを知らないため、多くの場合、リダイレクトメッセージは検出後に直接必要になります。 ルーター要請パケットを送信したり、広告パケット( `+ rdisc +`など)に基づいてルートを変更したりするサービスを実行していない場合、これらのパケットを安全にブロックできます。

しばしば安全に許可されるタイプ

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

  • タイプ8-エコー要求:これらはサーバーに向けられたping要求です。 通常、これらを許可しても安全です(これらのパケットを拒否してもサーバーが隠されることはありません。 ユーザーがホストが稼働しているかどうかを確認する方法は他にもたくさんありますが、必要に応じてそれらをブロックしたり、応答する送信元アドレスを制限したりできます。

  • タイプ13-タイムスタンプ要求:これらのパケットは、クライアントが待ち時間情報を収集するために使用できます。 一部のOSフィンガープリント手法で使用できるため、必要に応じてブロックするか、応答するアドレスの範囲を制限します。

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

  • タイプ0-エコー応答:これらはエコー要求(ping)への応答です。

  • タイプ3-宛先到達不能:正当な宛先到達不能パケットは、サーバーが作成したリクエストに対する応答であり、パケットを配信できなかったことを示します。

  • タイプ11-超過時間:これは、サーバーによって生成されたパケットが、TTL値を超えたために宛先に到達する前に停止した場合に返される診断エラーです。

  • タイプ12-パラメータの問題:これは、サーバーからの送信パケットの形式が正しくないことを意味します。

  • タイプ14-タイムスタンプ応答:これらは、サーバーによって生成されたタイムスタンプクエリの応答です。

一部のセキュリティ専門家は、着信ICMPトラフィックをすべてブロックすることを引き続き推奨していますが、現在では多くの人がインテリジェントなICMP受け入れポリシーを推奨しています。 リンクhttp://security.stackexchange.com/questions/22711/is-it-a-bad-idea-for-a-firewall-to-block-icmp/22713#22713[here]およびhttp:// serverfault .com / questions / 84963 / why-not-block-icmp / 84981#84981 [こちら]に詳細があります。

接続制限とレート制限

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

接続制限

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

  • アドレスごと、ネットワークごと、またはグローバルに制限しますか?

  • 特定のサービスまたはサーバー全体のトラフィックを一致させて制限しますか?

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

レート制限

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

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

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

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

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

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

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

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

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

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

すべてのルールを組み込みチェーンの1つにまとめるか、追加のチェーンを作成して利用するかについての決定は、ルールセットの複雑さと管理の容易さに大きく依存します。

結論

これまでに、サーバーのファイアウォールポリシーを設計する際に下す必要のある決定について、かなり良いアイデアを持っているはずです。 通常、ファイアウォールに関連する時間投資は初期セットアップに大きく依存し、管理はかなり簡単になります。 ニーズに最適なポリシーを考案するのには時間がかかるかもしれませんが、そうすることで、サーバーのセキュリティをより詳細に制御できるようになります。

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

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