平成28年度 秋期 午後Ⅰ（旧試験）

本文の根拠

〔試験環境の構築〕

IPsec では，通信モードに a モードを使用し，ルータ間の通信を全て暗号化する。

〔試験環境の構築〕

片側のルータの IP アドレスが動的に変わる環境においては，IKEv1 の場合， b モードを使用する必要があるが，IKEv2 の場合は標準で対応している。

図1

インターネットには，ほかに VPNルータ（その上に監視端末がつながる）と Webブラウザがつながっている。

IPsec の通信モードには，トランスポートモードとトンネルモードの二つがある（RFC 4301）。トランスポートモードは元の IP ヘッダを残してペイロードだけを保護し，主に端末どうしの通信に使う。トンネルモードは元の IP パケット全体をカプセル化して新しい IP ヘッダを付けるので，ルータ（セキュリティゲートウェイ）どうしの間で，その配下の端末の通信をまとめて保護できる。本文は“ルータ間の通信を全て暗号化する”としており，図1 でも VPN ルータどうしが IPsec を張るので，a はトンネル（エ）である。

b は IKEv1 のフェーズ1 のモードである。IKEv1（RFC 2409）にはメインモードとアグレッシブモードがあり，事前共有鍵方式のメインモードでは，相手の ID を受け取る前に鍵を選ぶ必要があるため，事前共有鍵を相手の IP アドレスで識別することになる。片側の IP アドレスが動的に変わると，この識別ができないので，ID を最初のメッセージで送るアグレッシブモード（ア）を使う。IKEv2（RFC 7296）にはこのモードの区別が無く，本文のとおり標準で対応している。

トランスポート（ウ）はルータ間で配下の通信をまとめて暗号化する用途には合わない。アドホック，パッシブ，ブロックは IPsec や IKE のモードの名前ではない。a と b の二つの“モード”を取り違えないこと。a は IPsec の通信モード，b は IKEv1 の鍵交換のモードである。

本文の根拠

〔試験環境における情報セキュリティインシデントの発生〕

試験環境と無関係のグローバル IP アドレスとの接続が複数あること，及び c を送信元として SSH サービスにログインされていることが分かった。

表1

6行目：TCP／z1.z2.z3.z4:22／x1.x2.x3.x4:32489／ESTABLISHED／1547。7行目：TCP／z1.z2.z3.z4:45532／y1.y2.y3.y4:25／ESTABLISHED／1689。

表1

5行目：TCP／192.168.10.1:22／192.168.20.123:54433／ESTABLISHED／1545。

〔試験環境における情報セキュリティインシデントの発生〕

攻撃者が SSH のポートフォワード機能を使って， d を宛先として SMTP で電子メールを転送していることが分かった。

表1 は LTE ルータで netstat を実行した結果で，ローカルアドレスのポート 22 は LTE ルータの SSH サービスである。ポート 22 への ESTABLISHED の接続は 5行目と 6行目の二つある。5行目の 192.168.20.123 は IPsec の内側のプライベートアドレスで，E 君の監視端末からの接続と読める。6行目はグローバル IP アドレス z1.z2.z3.z4 のポート 22 に，グローバル IP アドレス x1.x2.x3.x4 から接続しているので，インターネットから直接ログインしている見覚えのない相手である。よって c は x1.x2.x3.x4。

7行目と 8行目は，LTE ルータから y1.y2.y3.y4 のポート 25（SMTP）への接続である。SSH のポートフォワードでは，SSH サーバ側（ここでは LTE ルータ）が転送先へ TCP 接続を張るので，LTE ルータを送信元とする SMTP の接続として現れる。よって d は y1.y2.y3.y4。

送信元と宛先の向きに注意する。c は“送信元”なので外部アドレス側，d は“宛先”なのでポート 25 の外部アドレスである。LTE ルータ自身のアドレス z1.z2.z3.z4 や，監視端末の 192.168.20.123 を書かないこと。

本文の根拠

〔試験環境における情報セキュリティインシデントの発生〕

LTE ルータのログには，SSH サービスがパスワードの辞書攻撃を受けた痕跡が残っていた。

〔試験環境における情報セキュリティインシデントの発生〕

不正にログインされないための暫定対策として，①SSH のログイン認証をパスワード強度に依存しない方式に設定変更した。

LTE ルータの SSH サービスはパスワードの辞書攻撃を受けていた。パスワード強度に依存しない方式とは，SSH の公開鍵認証である。SSH のユーザ認証には password 方式や publickey 方式などがあり（RFC 4252），公開鍵認証では利用者が秘密鍵を持っていることを署名で示すので，パスワードを推測されてもログインされない。

ただし，公開鍵認証を有効にしただけでは，パスワード認証も使える状態が残り，辞書攻撃は続けて成立し得る。そのため“パスワード認証を無効化する”ことと“公開鍵認証を使用する”ことの両方が要る。講評も，公開鍵認証を有効にすることに加えて，パスワード認証を無効化する設定が必要であるとしている。

字数は 30 字以内で，解答例は 24 字。“公開鍵認証にする”だけで終わらせず，パスワード認証の無効化を必ず入れる。

採点講評（IPA）

設問2(2)は，パスワード強度に依存しないSSHのログイン認証方式について問う問題である。正答率は低かった。辞書攻撃への対策には，公開鍵認証を有効にすることに加えて，パスワード認証を無効化する設定が必要であるということを理解してほしい。

本文の根拠

S 氏の発言

LTE ルータでは，監視端末を利用した場合にだけ，SSH サービスにアクセスできる仕様にすべきです。

S 氏の発言

TCP Wrapper を使って， e することで実現できます。

表1

5行目：TCP／192.168.10.1:22／192.168.20.123:54433／ESTABLISHED／1545。

TCP Wrapper は，サービスへの接続を受けたときに，接続元のホスト（IP アドレスなど）を見て接続を許可するか拒否するかを決める仕組みである。S 氏は“監視端末を利用した場合にだけ，SSH サービスにアクセスできる仕様”を求めているので，e には，SSH サービスへの接続の送信元 IP アドレスを監視端末の IP アドレスに限定する設定が入る。

監視端末は IPsec の内側から LTE ルータに接続しており，表1 の 5行目の 192.168.20.123 がその例である。送信元をこのアドレスに限れば，インターネットから直接 SSH サービスに接続してきた x1.x2.x3.x4 のような相手は拒否される。

字数は 30 字以内で，解答例は 24 字。“送信元 IP アドレス”と“監視端末”の二つを入れる。“アクセス制限する”だけでは，何を基準に制限するかが伝わらない。

本文の根拠

S 氏の発言

市販の幾つかの組込み機器について，②SSH のホスト鍵が同一モデルで全て同じになっているという脆弱性が，セキュリティ機関から注意喚起されています。

S 氏の発言

C 社でも，SSH のホスト鍵は，機器 1 台ごとに異なるものを使用するように設定してください。

SSH のホスト鍵は，クライアントが接続先のサーバが本物かどうかを確かめるための鍵である（RFC 4251）。クライアントはサーバのホスト鍵（公開鍵）を記録しておき，接続のたびにサーバがその秘密鍵を持っていることを確かめる。

同一モデルで全てのホスト鍵が同じだと，攻撃者は同じモデルの機器を手に入れてホスト鍵の秘密鍵を取り出せる。その秘密鍵を使えば，攻撃者のサーバが本物の機器になりすましても，クライアントは気付けない。こうして通信の間に入り込む中間者攻撃を行い，通信内容を盗聴できる。講評も，同一のホスト鍵が使われた場合，SSH サーバのなりすましに気付くことができないので，中間者攻撃による通信内容の盗聴や改ざんが行われてしまうと説明している。

字数は 20 字以内で，解答例は 15 字。“中間者攻撃”という攻撃の名前と，その結果（盗聴）を短く書く。“なりすまし”だけでも方向は合うが，何をされるかまで書くとよい。

採点講評（IPA）

設問3(2)は，SSHのホスト鍵が組込み機器の同一モデルで全て同じである場合に，同じホスト鍵を使ってどのような攻撃が行われるかについて問う問題である。ホスト鍵は，SSHサーバの真正性を担保するものであるが，その目的を理解していない解答が多く見受けられた。同一のホスト鍵が使われた場合，SSHサーバのなりすましに気付くことができないので，中間者攻撃による通信内容の盗聴や改ざんが行われてしまうということを理解してほしい。

本文の根拠

S 氏の発言

ファームウェアの更新機能において，イメージファイルが③改ざんされていないか検証できるようにする必要があります。

E 君の発言

インターネット又は外部記憶媒体経由で，ファームウェアの更新用イメージファイル（以下，イメージファイルという）を LTE ルータに読み込んで保存し，コマンドを使って更新するという機能を実装したいと考えています。

ディジタル署名では，署名する側が自分の秘密鍵で署名を作り，検証する側が対応する公開鍵で署名を確かめる。秘密鍵を持たない者は正しい署名を作れないので，イメージファイルが途中で書き換えられると検証に失敗する。

イメージファイルの作成時には，C 社が秘密鍵を使ってイメージファイルにディジタル署名を付与する。更新時には，LTE ルータが公開鍵を使ってイメージファイルのディジタル署名を検証し，検証に成功したものだけで更新する。イメージファイルはインターネット又は外部記憶媒体経由で読み込むので，経路の途中で改ざんされても，この検証で見つけられる。

字数はそれぞれ 35 字以内で，解答例はどちらも 30 字。設問は“使用する鍵の種類を明示”することを求めているので，作成時は“秘密鍵”，更新時は“公開鍵”を必ず書く。鍵を逆にしないこと。

本文の根拠

S 氏の発言

④しかし，イメージファイルを暗号化しても，攻撃者が復号のための鍵を入手して，イメージファイルを復号するという可能性を排除できません。

E 君の発言

インターネット又は外部記憶媒体経由で，ファームウェアの更新用イメージファイル（以下，イメージファイルという）を LTE ルータに読み込んで保存し，コマンドを使って更新するという機能を実装したいと考えています。

冒頭

監視端末から LTE ルータの設定変更ができるように，LTE ルータでは SSH サービスを稼働させる。

暗号化したイメージファイルで更新するには，LTE ルータ自身がそれを復号できなければならない。つまり復号のための鍵は LTE ルータの中に置かれている。攻撃者は LTE ルータを入手してログインし，ファイルシステムの中から鍵を見つければ，イメージファイルを復号できる。

本文の LTE ルータは Linux で動作し，SSH サービスでログインできる。試験環境でも辞書攻撃でログインされた。講評は，平文の状態の鍵を探すといった攻撃側の視点を踏まえて対策が立案できるようになることを期待している。だから S 氏は，暗号化に頼らず“解析されても問題がないように設計すること”が重要だと述べている。

字数は 35 字以内で，解答例は 30 字。“どこにある鍵をどうやって手に入れるか”を，ルータへのログインとファイルシステムからの探索の二つで書く。“鍵を盗む”だけでは具体的でない。

採点講評（IPA）

設問3(4)は，イメージファイルを復号するための鍵を，攻撃者がどのように入手するかについて問う問題である。平文の状態の鍵を探すといった攻撃側の視点を踏まえて対策が立案できるようになることを期待したい。

本文の根拠

〔脆弱性及びその悪用〕

ソフトウェアの脆弱性の情報を組織間で一意に特定し共有できる仕組みが運用されている。例えば，脆弱性が報告されると， a 識別子が付番され，

〔脆弱性及びその悪用〕

ただし，公表前に悪用されるものもあり， b 脆弱性と呼ばれる。 b 脆弱性は，特定の組織を狙う攻撃，つまり c 型攻撃でしばしば悪用される。

〔V 社の脆弱性対策〕

通常の利用では想定しないデータを入力し，その応答から脆弱性を探す d 検査を行うツールを利用したりして，

a は，脆弱性を組織間で一意に特定し共有するために付番される識別子なので，CVE（ア）である。CVE（Common Vulnerabilities and Exposures）は脆弱性ごとに“CVE-年-番号”の形の識別子を割り当てる仕組みで，MITRE が運営している。b は，公表前（修正プログラムの提供前）に悪用される脆弱性なので，ゼロデイ（イ）である。c は“特定の組織を狙う攻撃”なので，標的（ウ）型攻撃である。

d は，通常の利用では想定しないデータを大量に入力し，その応答（異常終了など）から脆弱性を探す検査なので，ファジング（エ）である。IPA も，ファジングを脆弱性の検出手法として紹介する手引きを公開している。

解答群は四つで，空欄も四つなので，一つずつ当てはめる。ゼロデイと標的型は“公表前に悪用”“特定の組織を狙う”という本文の言い換えをそのまま手掛かりにすればよい。

本文の根拠

〔脆弱性及びその悪用〕

ソフトウェアに BOF 脆弱性がある場合，当該ソフトウェアへの入力によって，①開発者が想定しないメモリ領域に書き込まれ，開発者の意図しない命令が実行されることがある。

C や C++ で関数を呼び出すと，スタックには，呼び出された関数の処理が終わったあとに戻る先，つまり呼出し元関数への戻りアドレスが積まれる。関数の局所変数（配列など）も同じスタック上に置かれるので，配列の範囲を超えて書き込むと，その先にある戻りアドレスが上書きされる。

攻撃者が戻りアドレスを自分の用意したコードの位置に書き換えておけば，関数から戻るときに処理がそこへ移り，下線①の“開発者の意図しない命令が実行される”状態になる。講評も，C / C++での関数呼出し時のスタックの状況に関する問題で，いわゆる攻撃ベクタの一つとしている。

字数は 20 字以内で，解答例は 14 字。“戻りアドレス”だけでなく，“呼出し元関数への”と，どこへ戻るためのアドレスかまで書く。“スタックポインタ”や“局所変数”と取り違えないこと。

採点講評（IPA）

設問2(1)は，C / C++での関数呼出し時のスタックの状況に関する問題である。正答率は低かった。いわゆる攻撃ベクタの一つなので，基本的な知識として確認をしてほしい。

本文の根拠

〔脆弱性及びその悪用〕

実行権限の属性に“s”が表示されているファイルは，ファイルの所有者権限で実行されることを示している。四つのファイルのうち ［ ア ］ は，一般利用者 suzuki によって起動された場合でも root 権限で動作する。

図1

6: -rwsrwxr-x 1 root root 7205 1月 18日 16:10 sample2

図1

8: -rwsrwxr-x 1 suzuki suzuki 7205 1月 18日 16:10 sample4

本文のとおり，実行権限の属性に“s”があるファイルは，起動した利用者ではなくファイルの所有者の権限で実行される。suzuki が起動しても root 権限で動作するのは，“s”があり，かつ所有者が root のファイルである。図1 では sample2（-rwsrwxr-x，所有者 root）だけが当てはまる。

sample4 も“s”を持つが，所有者は suzuki なので，suzuki の権限で動作するだけである。sample1 は所有者が root でも“s”が無いので，起動した suzuki の権限で動作する。sample3 はどちらにも当てはまらない。

“全て答えよ”とあるが，答えは sample2 の一つだけである。“s”が付いた sample4 を一緒に書かないよう，所有者の列も必ず見る。

本文の根拠

図2 20～23行目

20: uid = new char[UID_SIZE+1]; 21: pass = new char[PASS_SIZE+1]; 22: getPass(pass, argv[1]); 23: strcpy(uid, argv[1]);

図2 25行目

25: if (strlen(pass) == 0 || strcmp(argv[2], pass) != 0) {

〔ヒープベース BOF 脆弱性〕

“利用者 ID とパスワード”は，いずれも半角英数字，最小 6 文字最大 8 文字の文字列と仕様で定められている。

プログラム Y は，20・21 行目で uid と pass の領域（それぞれ 9 バイト）をヒープに続けて確保し，22 行目で登録済パスワードを pass に入れたあと，23 行目で第 1 引数を uid に strcpy でコピーする。strcpy は長さを確かめないので，第 1 引数が長いと uid の後ろにある pass の領域まで上書きする。上書きは getPass の後に起きるので，pass には登録済パスワードではなく第 1 引数の後ろの部分が入る。25 行目は pass が空でなく，第 2 引数と pass が一致すれば認証成功とするので，“第 1 引数のうち pass に重なる部分”と第 2 引数を同じにすれば，存在しない利用者 ID でも認証を回避できる。

各選択肢の“（繰返し）”は，pass の先頭に第 1 引数の末尾の 8 文字が重なるよう長さを調整する部分と読める。そうすると pass は第 1 引数の末尾 8 文字になる。ウは第 1 引数の末尾 8 文字が“11111101”で，第 2 引数の“11111101”と一致する。アとイは末尾 8 文字が“11111111”で第 2 引数“11111110”と合わず，エは“11111111”と“67891231”，オは“31231231”と“67891231”で合わない。

記号で答える設問。第 1 引数の“先頭”ではなく，pass の領域に重なる“末尾”を第 2 引数と比べるのが要点である。

本文の根拠

図2 20～23行目

20: uid = new char[UID_SIZE+1]; 21: pass = new char[PASS_SIZE+1]; 22: getPass(pass, argv[1]); 23: strcpy(uid, argv[1]);

実際にバッファがオーバフローするのは，第 1 引数を長さを確かめずに uid にコピーする 23 行目の strcpy(uid, argv[1]); である。uid の領域は UID_SIZE+1（9 バイト）しかないが，strcpy はコピー元の文字列の終わり（ヌル文字）までを全てコピーするので，9 バイトを超える第 1 引数は uid の後ろの領域にはみ出す。

22 行目の getPass も argv[1] を受け取るが，第 1 引数は登録済パスワードを探すための利用者 ID として使われるだけで，pass には登録済パスワード（又は長さ 0 の文字列）が入る。20・21 行目は領域の確保で，書き込みではない。

行番号で答える設問。“原因となる行”として 20 行目（領域が小さい）を挙げたくなるが，設問は“実際にバッファがオーバフローするコード”を問うている。

本文の根拠

図2 4行目

4: #define UID_SIZE 8 // 利用者 ID の文字列の上限値

図2 20行目

20: uid = new char[UID_SIZE+1];

〔ヒープベース BOF 脆弱性〕

“利用者 ID とパスワード”は，いずれも半角英数字，最小 6 文字最大 8 文字の文字列と仕様で定められている。

uid の領域は UID_SIZE+1（9 バイト）なので，コピーするバイト数をこの大きさまでに抑えれば，uid の外には書き込まれない。イの memcpy(uid, argv[1], UID_SIZE+1); とオの strncpy(uid, argv[1], UID_SIZE+1); は，どちらもコピーする量を 9 バイトまでに限るので，改修案として適切である。講評も，プログラムの引数は仕様でサイズの上限が定義されており，この上限を利用することによってオーバフローを防ぐとしている。

アとエは，コピーする量を strlen(argv[1])+1，つまり第 1 引数の長さに合わせているので，長い第 1 引数ではやはり uid の外に書き込む。ウは pass の領域を大きくするだけで，uid からのはみ出しは止まらない。なお，C 言語の strncpy は，コピー元が指定の長さ以上だと末尾にヌル文字を付けないので，実際の改修では終端の扱いにも気を付ける。

“全て選べ”の設問で，解答例は“イ，オ”の二つ。関数名（memcpy か strncpy か）ではなく，第 3 引数がバッファの大きさに抑えられているかで選ぶ。

採点講評（IPA）

設問3(3)は，ヒープベースBOF脆弱性を悪用する攻撃を引き起こすコードの改修に関する問題である。正答率は低かった。この問題では，プログラムの引数は仕様でサイズの上限が定義されており，この上限を利用することによってオーバフローを防ぐ。受験者には，この観点で正しい改修に気が付いてほしかった。

本文の根拠

〔ヒープベース BOF 脆弱性〕

ただし，K 氏によると，③このプログラム Y は引数が同じでも，実行環境によっては利用者認証を回避されないとのことだった。

図2 20～21行目

20: uid = new char[UID_SIZE+1]; 21: pass = new char[PASS_SIZE+1];

設問3(1)の攻撃は，uid の領域の先頭から pass の領域の先頭までの距離を前提に，第 1 引数の長さを調整している。この距離は，ヒープメモリをどのように確保するか（領域の並べ方，管理用の情報や詰め物の大きさなど）で決まり，それはメモリ確保のライブラリによって違う。実行環境が違えば距離も変わるので，同じ引数でも pass に第 1 引数の末尾 8 文字が重ならず，認証を回避できない。

講評も，今回のヒープベース BOF 脆弱性を悪用する攻撃は常に成功するものではなく，このケースでは OS に依存することを問うているとしている。設問は“攻撃のタイミングではなく実行環境の観点で”と断っているので，実行のたびに変わるといった時間の話ではなく，環境ごとの確保方法の違いを書く。

字数は 40 字以内で，解答例は 32 字。“ヒープメモリの確保方法”と“ライブラリによって違う”の二つを入れる。

採点講評（IPA）

設問4は，いずれも，BOF脆弱性を悪用する攻撃とその対策技術の有効範囲を問う問題である。正答率は低かった。今回のヒープベースBOF脆弱性を悪用する攻撃は，常に成功するものではなく，このケースではOSに依存することを問うている。データ実行防止機能は，スタックベースBOF脆弱性の対策技術であり，ヒープベースBOF脆弱性には効果がない。セキュリティ技術者としては，これらの知識は身に付けておいてほしい。

本文の根拠

〔V 社の脆弱性対策〕

例えば，Windows ではハードウェア DEP（Data Execution Prevention）のようなデータ実行防止機能を適用することで，一部の BOF 脆弱性を悪用する攻撃を抑制できる。しかし，④プログラム Y での利用者認証を回避する攻撃に対しては有効に機能しない。

図2 25行目

25: if (strlen(pass) == 0 || strcmp(argv[2], pass) != 0) {

データ実行防止機能は，データを置くためのメモリ領域に書き込まれた内容を命令として実行させないことで，攻撃コードの実行を防ぐ仕組みである。名前のとおり，防ぐのは“実行”であって，メモリへの書き込みそのものではない。

プログラム Y への攻撃は，ヒープ上の pass の領域を第 1 引数で書き換え，25 行目の比較を成り立たせるだけで，攻撃コードを実行させてはいない。ヒープ領域を書き換える行為そのものは防止できないので，データ実行防止機能は有効に機能しない。講評は，データ実行防止機能はスタックベース BOF 脆弱性の対策技術であり，ヒープベース BOF 脆弱性には効果がないと説明している。

字数は 30 字以内で，解答例は 22 字。“ヒープ領域を書き換える行為”を防げない，という点を書く。“コードを実行しないから”と書く場合も，書き換えで認証を回避している点が伝わるようにする。

採点講評（IPA）

設問4は，いずれも，BOF脆弱性を悪用する攻撃とその対策技術の有効範囲を問う問題である。正答率は低かった。今回のヒープベースBOF脆弱性を悪用する攻撃は，常に成功するものではなく，このケースではOSに依存することを問うている。データ実行防止機能は，スタックベースBOF脆弱性の対策技術であり，ヒープベースBOF脆弱性には効果がない。セキュリティ技術者としては，これらの知識は身に付けておいてほしい。

本文の根拠

表1

a 機能（注 1)）：・インターネットから Web サーバへの通信を中継する。

インターネット側から来た通信を受けて，内側の Web サーバへ中継するプロキシは，リバースプロキシ（エ）である。Web サーバの手前に置いて，負荷分散や Web サーバの保護に使う。

反対に，社員 PC などの内側の利用者からインターネットの Web サイトへの通信を中継するのがフォワードプロキシで，Q 社がプロキシ 1・2 で使っている機能はこちらに当たる。表1 の a は向きが逆の“インターネットから Web サーバへ”なので，フォワードプロキシ（イ）ではない。DMZ（ア）はネットワークの区画の名前で機能ではなく，プロキシ ARP（ウ）は他のホストに代わって ARP 要求に応答する機能で，Web の中継とは別物である。

記号で答える設問。中継の向き（内から外か，外から内か）で見分ける。

本文の根拠

〔情報セキュリティインシデントの発生と対応〕

マルウェア Z は，文書ファイルのマクロとして実装されていた。

〔情報セキュリティインシデントの発生と対応〕

攻撃用プログラムは，OS の管理用のコマンドを U さんの社員 PC 上に複数ダウンロードして起動させ，サーバ情報を窃取した。

冒頭

サーバ管理者は各種設定などのサーバ管理業務を行う場合だけ，1 台の管理 PC に自分の管理者 ID でログオンし，OS の管理用のコマンドなどを使用する。

冒頭

社員 PC には OS の管理用のコマンドはインストールされていない。

冒頭

プログラム起動禁止設定には，プログラム名が一致した場合にプログラムの起動を禁止にする方式と，プログラムの実行ファイルのハッシュ値が一致した場合に禁止する方式があり，

プログラム起動禁止設定は，プログラム名や実行ファイルのハッシュ値でプログラムの起動を止める仕組みである。マルウェア Z は文書ファイルのマクロとして実装されており，文書閲覧ソフトの中で動くので，プログラムとして起動を禁止する対象にならない。したがって b にも c にも（ⅲ）は入らない。

社員 PC には OS の管理用のコマンドがもともとインストールされておらず，業務で使わない。攻撃用プログラムは OS の管理用のコマンドをダウンロードして起動させたので，社員 PC では（ⅰ）と（ⅱ）の両方を禁止すればよく，b はイ。一方，管理 PC ではサーバ管理者が OS の管理用のコマンドを使ってサーバ管理業務を行うので，これを禁止すると業務ができなくなる。管理 PC で禁止できるのは攻撃用プログラム（ⅱ）だけで，c はオである。

記号で答える設問。“攻撃に使われたものは全部禁止”と考えると，管理 PC で OS の管理用のコマンドまで止めてしまう。それぞれの PC で業務に必要かどうかを確かめる。

本文の根拠

冒頭

プログラム起動禁止設定には，プログラム名が一致した場合にプログラムの起動を禁止にする方式と，プログラムの実行ファイルのハッシュ値が一致した場合に禁止する方式があり，両方の方式を組み合わせた設定もできる。

プログラム名による禁止は，名前が一致したときだけ働くので，名前を変えれば逃れられる。ハッシュ値による禁止は，実行ファイルの内容が一致したときだけ働くので，内容を少しでも変えればハッシュ値が変わり，逃れられる。

両方を組み合わせても，どちらか一方に一致すれば止まるだけなので，攻撃用プログラムの内容を変え，かつプログラム名も変えた場合は，どちらの条件にも一致せず起動を防ぎきれない。攻撃者は C&C サーバから攻撃用プログラムをダウンロードさせているので，配るプログラムの内容と名前を変えるのは容易である。

字数は 30 字以内で，解答例は 27 字。“内容を変える”と“名前を変える”の両方を“かつ”でつなぐ。片方だけでは，もう一方の方式で止められてしまう。

本文の根拠

〔プロキシ更新〕

フェーズ 1 では，プロキシ 1 と社員 PC との通信方法を変えずに，DMZ にプロキシ 2 を導入し，プロキシ 1 とインターネット間の通信を，全てプロキシ 2 経由とする。

冒頭

プロキシ 1 では，日時，接続先 URL，送信元 IP アドレス，ステータスコード，応答のサイズなどのログを取得している。

〔プロキシ更新〕

ログについては，プロキシ 2 で，プロキシ 1 と同じ項目のログを取得するよう設定する。

フェーズ 1 では，社員 PC は今までどおりプロキシ 1 に接続し，プロキシ 1 がプロキシ 2 を経由してインターネットへ中継する。プロキシ 2 から見ると，接続してくる相手は常にプロキシ 1 である。

プロキシ 2 はプロキシ 1 と同じ項目（送信元 IP アドレスなど）をログに取るが，その送信元 IP アドレスはどの通信でもプロキシ 1 の IP アドレスになる。そのため，プロキシ 2 のログだけでは，どの社員 PC からの通信だったかが分からない。講評も，ログから送信元 PC を特定できない理由について，他者に誤解なく伝わるように必要な情報を正確に記述してほしかったとしている。

字数は 30 字以内で，解答例は 27 字。“送信元 IP アドレス”が“プロキシ 1 の IP アドレス”になる，と何が何になるのかを具体的に書く。“プロキシ 1 を経由するから”だけでは，ログのどの項目が問題なのかが伝わらない。

採点講評（IPA）

設問3(1)は，プロキシサーバのログに関する問題である。正答率は低かった。ログから送信元PCを特定できない理由について，他者に誤解なく伝わるように，必要な情報を正確に記述してほしかった。

本文の根拠

〔プロキシサーバにおける追加設定〕

そこで，プロキシ 1 では，HTTP ヘッダとして d ヘッダフィールドを追加するように設定し，プロキシ 2 では， d ヘッダフィールドをログに出力するように設定した。

プロキシが中継するときに，元のクライアントの IP アドレスを HTTP ヘッダに書いて次へ渡すのが X-Forwarded-For（オ）である。プロキシ 1 がこのヘッダに社員 PC の IP アドレスを入れ，プロキシ 2 がそれをログに出力すれば，プロキシ 2 のログから送信元 PC を特定できる。RFC 7239 は，X-Forwarded-For を，広く使われている非標準のヘッダフィールドとして挙げ，標準の Forwarded ヘッダフィールドを定めている。

Max-Forwards（ア）は TRACE や OPTIONS で中継できる回数を制限するヘッダ，Proxy-Authorization（イ）はクライアントがプロキシに認証情報を渡すヘッダ，Referer（ウ）は直前に閲覧していたページの URI，User-Agent（エ）はクライアントのソフトウェアの情報を伝えるヘッダで，どれも送信元の IP アドレスは運ばない。

記号で答える設問。講評は，広く使われている HTTP プロトコルについての知識を深めてほしいとしている。名前の似た Max-Forwards と取り違えないこと。

採点講評（IPA）

設問3(2)は，プロキシサーバが処理するHTTPヘッダに関する問題である。正答率は低かった。広く使われているHTTPプロトコルについての知識を深めてほしい。

本文の根拠

〔フェーズ 2 の開始〕

フェーズ 2 において，情シ部は，まず，②プロキシ認証に対応したマルウェアも多いとの調査報告を踏まえ，効果が完全ではないことを認識しながらも，プロキシ 2 のプロキシ認証機能を有効にした。

表1 プロキシ認証機能

PC からインターネットの Web サイトへの接続時に利用者 ID とパスワードによる利用者認証を行い，認証結果をログに記録する。

プロキシ認証は，利用者 ID とパスワードで利用者を認証してからインターネットへの接続を許す仕組みで，人が操作しない通信（マルウェアの C&C 通信など）を止める効果が期待される。しかし，マルウェアは感染した PC 上で動いているので，その PC の Web ブラウザがプロキシサーバへ送る通信を盗聴して認証情報（利用者 ID とパスワード）を取得できる。取得した認証情報を自分の通信に付けてプロキシサーバに送信すれば，認証は成功する。

HTTP のプロキシ認証では，クライアントは Proxy-Authorization ヘッダで認証情報を送る（RFC 7235）。Basic 認証の場合，認証情報は利用者 ID とパスワードを Base64 で符号化しただけのものである（RFC 7617）。情シ部が“効果が完全ではない”と認識していたのはこのためである。講評も，認証機能を通過する仕組みについて，他者に誤解なく伝わるように必要な情報を正確に記述してほしかったとしている。

字数は 50 字以内で，解答例は 47 字。“どこから認証情報を得るか（Web ブラウザからプロキシサーバへの通信の盗聴）”と“それをどう使うか（プロキシサーバに送信）”の二つを入れる。

採点講評（IPA）

設問4(1)は，プロキシサーバの認証機能を通過する最新のマルウェアに関する問題である。正答率は低かった。認証機能を通過する仕組みについて，他者に誤解なく伝わるように，必要な情報を正確に記述してほしかった。

本文の根拠

〔フェーズ 2 の開始〕

そこで，業務に不要と思われるカテゴリを“検知”に設定し，1 か月間運用した後，③業務に必要かつ安全であることを確認した URL は許可し，それ以外の URL は遮断することにした。

表1 URL フィルタリング機能

・ホワイトリストに設定した URL を許可する。・ブラックリストに設定した URL を遮断する。

表1 カテゴリ単位フィルタリング機能

“遮断”：カテゴリごとに定義された URL を遮断し，ログに記録する。

表1 の後

URL フィルタリングとカテゴリ単位フィルタリングで同じ URL が設定された場合は，URL フィルタリングによる設定が優先される。

下線③は，“検知”で 1 か月間記録したログを基に，業務に必要かつ安全と確認できた URL だけを許可し，それ以外を遮断するという方針である。カテゴリ単位フィルタリング機能では，業務に不要であるカテゴリを“遮断”に設定する。そのうえで URL フィルタリング機能のホワイトリストに，業務に必要かつ安全であることを確認した URL を設定する。

本文のとおり，URL フィルタリングとカテゴリ単位フィルタリングで同じ URL が設定された場合は URL フィルタリングの設定が優先される。そのため，遮断したカテゴリに含まれる URL でも，ホワイトリストに入れたものは許可される。最初に“遮断”にしたときに業務の Web サイトが使えなくなった問題も，この組合せで解消できる。

字数はそれぞれ 40 字以内で，解答例は URL フィルタリング機能が 36 字，カテゴリ単位フィルタリング機能が 18 字。URL フィルタリング機能は“ホワイトリスト”に設定することを，カテゴリ単位フィルタリング機能は“遮断”に設定することを明記する。ブラックリストを使うと書くと，確認していない URL が許可されたままになる。