とことこロゴス
メニュー

ファイアウォール

読み：ふぁいあうぉーる　／　英語表記：Firewall

信頼度の異なるネットワークや端末の間で、あらかじめ定めたセキュリティポリシーに従って通信を許可・拒否する機能または装置である。IPアドレスやポート番号による選別に加え、通信状態やアプリケーションの情報を使う方式もある。

イマシルちゃんの解説

会社のネットワークでは、外部に公開するWebサーバと社員だけが使うサーバを区別して守る必要があるんだ。
ファイアウォールは、通信を通すか止めるかを決める機能や装置だよ。
例えば、外部から公開Webサーバへの接続は認めても、社内のファイルサーバへの接続は止めるように設定できるの。
その判断には、接続先のIPアドレスや使うサービスのポート番号などを使うよ。
接続の経過を覚えて、許可した通信への返事かどうかを確かめる方式もあるんだ。
必要な通信を使いながら、守るべき場所への接続を絞れるのが大切なんだよ。

より深い解説

どこで通信を制限するのか

ファイアウォールは「どの通信を認めるか」という組織の方針を実際の通信経路で実施する。インターネットとの境界だけでなく、部署間やサーバ間の境界にも配置する。外部からの侵入を防ぐことに加え、侵害された端末から別のシステムへ被害が広がる範囲を抑えるためである。

ネットワークを通過する通信をまとめて制御する装置と、PCやサーバ自身で動くホスト型の機能では、制御できる場所が異なる。ある経路に装置を置いても、その装置を通らない通信にはルールを適用できない。例えば同じVLANの端末同士がスイッチだけを経由する場合、別の場所にある境界装置では制御できない。

基本的な役割と配置の考え方は、NIST SP 800-41 Rev.1で整理されている。

何を見て判断するのか

方式によって確認する情報が異なる。単に「ファイアウォールがある」と書かれていても、アプリケーションの内容まで検査するとは限らない。

方式主に確認する情報判断できる範囲
パケットフィルタリングIPアドレス、プロトコル、ポート番号など指定した通信相手やサービスへの接続を制限する
ステートフルパケットインスペクションヘッダーと記録済みの接続の状態新規の接続か、許可した接続に対応するパケットかを判断する
アプリケーションプロキシ中継するアプリケーションの要求や応答対応するプロトコルの内容を確認して中継する

IPアドレスはOSI基本参照モデルのネットワーク層、TCPやUDPのポート番号はトランスポート層の情報である。HTTPの要求などを解釈する検査はアプリケーション層の情報を扱う。

次世代ファイアウォール（NGFW）は、接続の追跡に加えてアプリケーション識別やIPSなどを統合する製品群である。利用者単位の制御や暗号化通信の検査に対応するものもあるが、実際に使える機能と検査条件は製品ごとに確認する。Ciscoの方式別解説では、これらの検査範囲が比較されている。

許可ルールを組み立てる

ルールを作る前に「誰が、誰へ、何のサービスを使って接続を始めるか」を決める。通常は送信元・宛先のIPアドレス、プロトコル、ポート番号などを条件にし、許可・拒否とログ出力を指定する。ゾーンというネットワークの管理区分を条件に使う製品もある。

必要な通信だけを許可し、それ以外を拒否する考え方をデフォルト拒否という。次は、状態を追跡する装置で新規接続の許可を考えるための独自例である。NATによるアドレス変換はないものとする。

送信元宛先プロトコル・宛先ポート接続の目的
インターネットの利用者公開WebサーバTCP・443HTTPSでWebサイトを利用する
管理端末管理対象サーバTCP・22SSHで管理する
社内PC社内DNSサーバUDP/TCP・53名前解決に使う
任意任意任意上の許可に一致しない通信を拒否する

この例の宛先ポートは、接続を受け付ける側のサービスを表す。送信元ポートまで443にそろえるわけではない。DNSはUDPだけでなくTCPも利用するため、TCPを必要とする通信まで止めないか確認する。

アドレス条件に用いるanyは、その欄で相手を特定のアドレスに限定しない指定である。例えばプロキシサーバが不特定の外部Webサーバへ接続する場合、送信元をプロキシ、宛先をany、サービスを必要なTCPの80番・443番に限定する構成がある。宛先を任意にしても、送信元、方向、サービスなどの残りの条件は適用される。すべての通信を無条件に許可する意味ではない。

上から順に照合する製品では最初に一致したルールが適用される。広すぎる許可ルールを先に置くと、後に書いた拒否ルールまで評価が進まないことがある。ただし全製品が同じ評価方法を採るわけではない。Junos OSのポリシー仕様のように、使用する機器の処理順を確かめる必要がある。

要求と応答で入れ替わる情報

PCが一時的な送信元ポート53,100を使い、WebサーバのTCPポート443へ接続したとする。往復のIPアドレスとポートは次の関係になる。

向き送信元宛先
要求PCのIPアドレス・53,100WebサーバのIPアドレス・443
応答WebサーバのIPアドレス・443PCのIPアドレス・53,100

静的なパケットフィルタリングでは、逆向きの通信もルールで許可する必要がある。対してステートフル方式では、記録した接続に対応する応答を認識できる。単に送信元ポートが443だから信用することと、実際の接続記録に合うことを確認することは異なる。

UDPにはTCPのような接続確立手順がない。それでも、アドレスやポートの組と経過時間を使って応答の扱いを管理できる。タイムアウトを過ぎた通信の扱いは設定と実装に依存する。詳しい仕組みはステートフルパケットインスペクションの記事で扱う。

クラウドにもこの違いがある。AWSではセキュリティグループが接続を追跡し、ネットワークACLは各方向を個別に評価する。名前が似ていても戻り通信の扱いは同じではない。

中継装置とアドレス変換を見落とさない

端末からWebサイトまでの間に明示的なプロキシサーバがある場合、通信は「端末からプロキシ」と「プロキシからWebサイト」に分かれる。後半のTCP接続を新しく開始するのはプロキシである。追加の送信元変換がなければ、後半の経路で許可すべき送信元はプロキシサーバのIPアドレスになる。

HTTPヘッダーに元の利用者の情報を付けても、IPヘッダーの送信元が自動的にその利用者へ戻るわけではない。どの区間のパケットを装置が見ているかを先に特定することが大切である。

NAT・NAPTを併用する構成では、変換前と変換後のどちらのアドレスをルールに指定するかも確認する。例えばJunos OSでは宛先変換や経路検索とポリシー検索の処理順が定められている。ほかの製品へそのまま当てはめてはならない。NATの処理順の資料を読み、通信制御とアドレス変換を別の仕事として整理する。

公開サーバと内部ネットワークを分ける

外部へ公開するWebサーバなどは、内部ネットワークと分離したDMZへ配置することがある。公開されるサービスに攻撃が届くことを前提に、侵害時にも内部へ自由に接続できない構成にするためである。

ただし「DMZだから内部へ一切接続できない」とは限らない。公開Webサーバから内部のデータベースへ接続する必要があるなら、そのサーバから対象DBの必要なポートだけを許可する。DMZ全体から内部全体への許可に広げる必要はない。区画の名前よりも、許可した経路とサービスの範囲が実際の防御を決める。配置の詳細はDMZの記事を参照する。

暗号化された通信と防御の限界

HTTPSではHTTPの内容がTLSで暗号化される。宛先IPアドレスやポートを確認できても、暗号化された本文をそのまま読めるわけではない。内容検査には、TLSを終端する場所や復号できる条件を設計する必要がある。検査用の証明書配布やプライバシーへの配慮も別途必要になる。

許可した443番への通信には、通常のWeb利用と脆弱性を悪用する要求の両方が含まれ得る。Webへの攻撃はWAF、侵入の兆候はIDS・IPS、端末上の活動はEDRなども使って対処する。これらは役割を補い合うための機能であり、一つを導入すれば残りが不要になるわけではない。

クラウド型WAFがWebサーバへ接続する構成では、公開サーバへのHTTPSの許可をWAFの送信元IPアドレスに限定する方法がある。利用者がWAFを経由せず元のWebサーバへ直接接続する経路を閉じ、内容検査を迂回させないためである。DNSなどの別サービスの許可条件は独立に判断する。Cloudflareのオリジンサーバ保護の資料にも、指定した中継元以外を遮断する構成が示されている。

WAF障害時に任意の送信元からのHTTPSを許可する運用へ変更すると、到達性は回復できてもWAFを通さない経路が開く。障害時の代替経路でも、元の保護条件をどう保つかを設計する。ポートを開けるパケットフィルタリングと、HTTPの内容を検査するWAFの役割を区別する。

また、入口の回線自体を大量通信で埋められれば、その先でパケットを捨てても回線の混雑は解消しない。防御する場所を決めるときはDDoS対策や上流側の制御も考える必要がある。

IPv6の通信を壊さずに制限する

IPv4のルールだけを設定しても、IPv6の通信まで同じ方針で制御できるとは限らない。両方を利用するネットワークでは、各アドレス体系で到達可能なサービスを点検する。

ICMPv6はエラー通知だけでなく近隣探索などにも使われるため、一律に遮断すると必要な通信まで壊れる。特に経路途中のMTUを知らせるPacket Too Bigを止めると、小さいパケットは通るのに大きいデータを送れない原因になり得る。近隣探索のような同一リンク内の処理と、経路を越えて届くエラー通知を区別して許可を考える。RFC 4890はこのフィルタリング方針を扱っている。

障害時も接続を維持するための設計

行きと帰りで異なる経路を通ることを非対称ルーティングという。戻りのパケットが接続記録を持たない別のファイアウォールへ届くと、通信が拒否される場合がある。単なる経路の到達性だけでなく、往復をどの装置が観測できるか確認する。非対称経路の確認例では、TCPの接続開始を観測できない場合が示されている。

冗長化でも設定ファイルの複製だけでは十分でない。既存の接続を引き継ぐには、接続記録などの状態同期が関わる。同期できない情報や、切替後に再接続が必要な通信もあるため、機器ごとの仕様と実際の切替試験を確認する。HA同期の仕様例も、すべての処理が同じように引き継がれるわけではないことを示している。

ログから原因を切り分ける

「通信できない」という症状だけで許可範囲を広げてはいけない。通信を始める機器と経路を特定し、ログ・経路表・接続記録を照合する。次は切り分けのための独自例である。

観測した状態確認すること
拒否ログに記録がある送信元・宛先・方向と、一致したルールを確認する
許可ログはあるが応答がない接続先の待受け、後段の制御、戻り経路を確認する
該当するログがないログ設定を確認したうえで、そもそも装置へ到達しているか調べる
しばらく放置した接続だけ切れる接続記録のタイムアウトとアプリケーション側の維持方法を確認する
切替時や負荷が高いときだけ失敗する往復経路、同期状況、処理能力と接続記録の上限を確認する

性能を考える場合も通信量だけでは足りない。大量の短い接続では新規接続の処理能力、長く残る接続では同時セッション数が問題になる。暗号化通信の検査などを有効にした条件で必要な性能を満たすか評価する。

ルールには業務上の目的と管理者を記録し、不要になった許可を残さない。変更前後で必要な接続と拒否すべき接続の両方を確かめることが、通信障害と意図しない公開を防ぐ基本になる。

実際の試験ではここに出る！全3問

ネットワークスペシャリスト

午後Ⅰ
午後Ⅱ

この用語が出てくる記事

↑