今回は、平成 26 年度（2014 年度）秋期の「応用情報技術者試験」の過去問（午後 問1 情報セキュリティ）を解いていきます。
この問題では、FW、IDS、IPS、WAF について、基本的な理解が問われています。設問 1 に関しては、出題の仕方が工夫されており、単に用語を知っているだけでは解きにくくなっています。つぶしがいのある問題ですね。
さっそくいきましょう。
・ IPA の情報処理技術者試験 過去問題のページから、問題冊子をダウンロードしておいてください
・ 二重カッコ『 』は、問題文や解答からの引用を表します
・ このエントリでは、設問 1 のみ解説します。設問 2, 3, 4 については、別のエントリで解説します
整理
解説に入る前に、ネットワークに関する基本的な知識を、簡単に確認させてください。押さえてほしいことは、これだけです。
- TCP/IP は、4 つの層からできている
- パケットは、原則、ヘッダ部分と、データ部分に分かれている。下位層では、上位層のパケット全体を、データ部分に、まるっと突っ込んでいる（カプセル化）
- 各層では、自分の層に対応するヘッダ部分を見て処理をする。データ部分は、原則、見ない
簡単に、解説していきます。
プロトコルスタック
コンピュータ同士の通信を実現するためのプロトコルは、実装や改修をより容易にするため、階層構造になっています。
TCP/IP のプロトコルスタック（階層構造）は、次の図↓の真ん中の絵のように 4 つの層（レイヤ）で実装されています。TCP/IP は、OSI 基本参照モデルとは全く異なるモデルなのですが、レイヤ分けが似ていることから、対比して説明されることがあります。このため、TCP/IP のプロトコルスタックも、2 層、3 層、4 層、7 層と呼ばれることがあります。
以下、2 層が「イーサネット」であるとします。
パケットのレイアウト
このような階層構造にあわせ、パケットのレイアウトは、次↓のようになっています。パケットは、基本的に「ヘッダ」部分と「データ」部分（「ペイロード」と呼びます）に分かれており、下位層では、上位層のパケット全体を、データ部分にカプセル化します。
なお、青字で「ヘッダ部」と「データ部」と書かれた箇所を、あわせて「イーサフレーム」と呼びます。
具体的な通信の流れ
これらを踏まえて、本問における『社内の PC から社外 Web サイトへの HTTP 通信』を例に、どのように通信が実現されているのか、見ていきます。
次の図↓は、PC から、DMZ に配置されたプロキシサーバ（以下、プロキシ）までの HTTP による通信を表しています。
次↓のように処理されるため、各層は、自分の層のことだけを気にしておけばよいとなります。
- PC で作られたパケットは、まずは L2SW を通ります。L2SW は、イーサフレーム中の宛先 MAC アドレスを見て、該当する機器がある口（ポート）へ、パケットをフォワード（転送）します。このとき、3 層以上のデータ（イーサフレームのデータ部分）は、原則、見ません
- L3SW では、イーサフレームから IP のパケット（イーサフレームのデータ部）を取り出し、IP ヘッダ中の宛先 IP アドレスを見て、ルーティング（中継）します。このとき、4 層以上のデータ（IP データ）の内容は、原則、見ません
- 同様に、今回の FW では、7 層のデータ（今回は HTTP のメッセージ）は、原則、見ません
という感じです。
通信の様子を、もう少し細かく知りたい方は、このエントリの最後の「【4】付録」をご覧ください。
解説
前置きが長くなりました。問題を解き進めましょう。
設問 1
① FW による IP アドレスやポート番号を用いたパケットフィルタリングだけでは、外部からの攻撃を十分に防ぐことができない
FW の『IP アドレスやポート番号を用いたパケットフィルタリング』では、どの PC（送信元 IP アドレス）から、どのサーバ（宛先 IP アドレス）の、どのサービス（宛先ポート番号）にアクセスするのか、これしか制御できません。
次↓の表は、内部セグメントにある IP アドレス 192.168.0.3 の PC が、社外の Web サイトにアクセスできるようにするための FW のルールです。
| 方向 | 送信元 IP | 宛先 IP | 送信元ポート | 宛先ポート | 処理 |
| 内部 → DMZ | 192.168.0.3 | 192.168.0.1 | 任意 | 80 / TCP | 許可 |
| DMZ → 外部 | 200.a.b.1 | 任意 | 任意 | 任意 | 許可 |
※1. このルールは、ステートフルインスペクション（個々の通信の状態を保持し、それをもとにフィルタリングできる）機能がある場合をイメージしています。この場合は、応答の通信については、ルールを記載しなくても OK です
※2. プロキシサーバについて、内側の IP アドレスを 192.168.0.1 に、外側の IP アドレスを 200.a.b.1 としました
※3. TCP のポート 80 番は、HTTP です。ちなみに 443 番は、HTTPS です
ここまでわかれば、答えは出たようなものです。それぞれの選択肢を見ていきます。
| 記号 | 防御 | 解答群 | 解説 |
| ア | 不可 | DNS サーバを狙った、外部からの不正アクセス攻撃 | ・ DMZ 上に配置し、外部から直接アクセスできるよう、FW を設定 ・ FW では、DNS のペイロードは見ない |
| イ | 不可 | Web サーバの Web アプリケーションプログラムの脆弱性を悪用した攻撃 | ・ DMZ 上に配置し、外部から直接アクセスできるよう、FW を設定 ・ FW では、HTTP/HTTPS のペイロードは見ない |
| ウ | 可 | 内部 Web サーバを狙った、外部からの不正アクセス攻撃 | ・ 内部セグメントには、外部から直接アクセスできないよう、FW を設定 |
| エ | 可 | ファイルサーバを狙った、外部からの不正アクセス攻撃 | ・ 内部セグメントには、外部から直接アクセスできないよう、FW を設定 |
| オ | 可 | プロキシサーバを狙った、外部からのポートスキャンを悪用した攻撃 | ・ DMZ 上に配置しているが、外部から直接アクセスできないよう、FW を設定（内部セグメントからのみ、アクセスできるように設定） |
ということで、答えは、 ア と イ になります。
ポートスキャンとは、ポートがオープンなのか、クローズなのかを確認する手法です。対象のポートに対し、TCP や UDP のパケットを送信し、そのレスポンスの内容から、そのポートがオープンなのか、クローズなのか（サービスが起動しているのか、起動していないのか）判定します。
※ ポートスキャンには複数の手法があります。典型的な手法では、TCP の SYN パケットを送信し、コネクションが確立したらオープン、RST/ACK が応答されたらクローズと判定します
復習
それでは、本エントリで学んだことを、簡単に復習しておきましょう。
- TCP/IP のプロトコルスタックは、2 層、3 層、4 層、7 層の 4 つのレイヤからなる
TCP/IP では、ネットワークを流れるパケットは、基本的に「ヘッダ」部分と「データ」部分に分かれている。下位層では、上位層のパケット全体を、データ部分にカプセル化している - L2SW は、3 層以上のデータ（イーサフレームのデータ部分）の内容は、原則、見ない
L3SW は、4 層以上のデータ（IP データ）の内容は、原則、見ない
FW では、7 層のデータ（HTTP/HTTPS や DNS の内容）は、原則、見ない - ポートスキャンとは、オープン/クローズを確認したいポートに対し TCP や UDP のパケットを送信し、そのレスポンスの内容からサービスが有効かどうか判定する手法である
付録
PC から外部の Web サイトにたどり着く様子を、もう少し細かく知りたい方向けに、通信の流れをざっと、書いてみました（細かい用語は説明しませんので、あしからず）。
まず、プロキシの動きを説明します。プロキシまでうまく到達すれば、あとはプロキシがよしなにやってくれることを理解してください。
- ブラウザの URL 欄に http://example.com/foo を打って、Enter キーをべこっと押すと、ブラウザに設定されているプロキシを目がけて、リクエストが飛びます
- プロキシまで届けば、後はプロキシが PC を代理して、example.com に HTTP リクエストを投げてくれます
- プロキシは、まず example.com を名前解決して、外部 Web サイトの IP アドレスをゲットします。これで、外部の Web サイトに到達できるようになります。そこで、Web サイトの TCP ポート 80 番とコネクションを張り、そのコネクション上で、GET /foo HTTP/1.0 のようなテキストを送信してくれます
では、PC からプロキシまで、どのようにデータが到着するか、順にみていきましょう（なぜか、物語調）。
- 昔々、とある内部セグメントにいる PC が、自身が作成したパケットの内容を、プロキシに伝えようとしていました。このプロキシは、かつて情報システム部門から指示され、ブラウザに設定したものです。
PC が、プロキシの IP アドレスを確認したところ、どうやら、自分とは別のネットワークにいることがわかりました。残念ながら、直接届けることができません。
- 困った PC は、ふと、情報システム部門（以下、情シ）から指示され、PC に「デフォルトゲートウェイ（以下、デフォゲ）」として、L3SW を設定したことを思い出しました。そして、情シの方が、「直接届かない場合には、デフォゲにお願いするのですよ」、と言っていたことも思い出しました。
そこで、デフォゲまでパケットを届け、デフォゲに、プロキシのいるネットワークに、ルーティング（中継）してもらうことにしました。 - デフォゲは、PC と同じネットワークにいるので、PC から、直接パケットを届けることができます。つまり、デフォゲまでは、CSMA/CD の方式に従って、ケーブルに電気信号流すことで、パケットの内容を伝えられるのです。
しかし、そのためには、デフォゲの MAC アドレスが必要です。PC は、すぐに自分の ARP テーブル（ARP キャッシュ）を見てみましたが、デフォゲのレコード（IP アドレスと MAC アドレスの組）がありません。そこで、同じネットワークにいる全員に、この IP アドレスを持っているのは誰なのか、聞くことにしました。つまり、デフォゲの IP アドレスについて、ARP リクエストを、ブロードキャストしました。すると、デフォゲが応えてくれました。ARP リプライで、デフォゲの MAC アドレスを教えてくれたのです。 - すかさず、デフォゲの MAC アドレス宛に、CSMA/CD の方式に従って、ケーブルに電気信号を流しました。コリジョンは検出されなかったため、再送せずに済みました。これで、ようやくデフォゲにたどり着きました。
- デフォゲである L3SW では、パケットの送信先 IP アドレスのネットワークを確認してくれました。そして、L3SW のルーティングテーブルに従い、送信先のネットワークにルーティング（中継）してくれました。
- ようやく、パケットが、プロキシと同じネットワークにたどり着きました。あとは、L3SW に、プロキシの MAC アドレスをゲットしてもらい、電気信号を流してもらうだけです。
たまたま、L3SW の ARP テーブルに、プロキシのレコードがあったため、そこから MAC アドレスをひきました。CSMA/CD の方式で、ケーブルに電気信号流して、PC が作成したパケットの内容は、無事、プロキシまで伝わりました。
めでたしめでたし。
[…] 前回は、主にネットワークの話をしました。今回は、IDS/IPS、WAF の話をしていきます。さっそくいきましょう。 […]