応用情報技術者 2011年 春期 午後 問05

解答の論理構成

1. サーバ証明書の設置先
   引用: “第三者機関から取得したサーバ証明書は a にインストールする。”
   直前の記述で “リバースプロキシサーバだけを DMZ に配置し…ゲートウェイとリバースプロキシサーバの通信ではSSLを用いた通信を行い” とあります。SSLを終端する機器に証明書を置くのが原則なので、a は “リバースプロキシサーバ” となります。
2. FW1 で許可すべきポート番号
   引用: “ゲートウェイとリバースプロキシサーバの通信ではSSLを用いた通信を行い”
   SSL (HTTPS) は “HTTPで用いるポート番号は80、HTTPSで用いるポート番号は443” と定義済み。したがって、インターネット側（FW1）で許可するのは “443” です。
   よって b＝443。
3. FW2 で許可すべきポート番号
   引用: “リバースプロキシサーバと各Webサーバ…の通信では、SSLは用いない。”
   SSL を用いない＝平文 HTTP なので、c には HTTP の既定ポート “80” を設定します。
4. 転送先 URL のスキーム
   表2では “d://192.168.5.201/” などと記載されています。前項で確認したとおり内部通信は非SSLですから、スキームは “http”。
   よって d＝http。

誤りやすいポイント

• “SSL を用いた通信” と聞いて、DMZ 内部もすべて HTTPS と決めつけてしまい c まで “443” にしてしまう。
• 証明書は Webサーバに載せるものという思い込みから a を “各Webサーバ” と誤記する。
• 表2の “d://” の空欄を URL の先頭に来る “https” と思い込む（内部通信は平文という条件を見落とし）。

FAQ

解答の論理構成

1. 外部アクセス時のプロトコル
   • 【問題文】「ゲートウェイとリバースプロキシサーバの通信ではSSLを用いた通信を行い」とあるため、外部（携帯電話端末→リバースプロキシサーバ）では HTTPS（https）を利用します。
   • よって e は https です。
2. 外部アクセス時のホスト名＋パス
   • インターネット側から見える FQDN は【問題文】「“www.example.com”は、FW1のインターネット側IPアドレスに割り付けられたドメイン名である。」と明示されています。
   • インターネット工事管理システムは【問題文】「表2　リバースプロキシサーバの設定」で /srv2/ が転送対象。ログインページは【問題文】「ログインページのURLパスは、どの工事管理システムも共通で login.html とする。」とあります。
   • 以上より外部 URL は www.example.com/srv2/login.html。したがって f は www.example.com/srv2/login.html です。
3. 内部転送時のプロトコル
   • 【問題文】「リバースプロキシサーバと各Webサーバ（192.168.5.201、192.168.5.202及び192.168.5.203）の通信では、SSLは用いない。」とあるので平文 HTTP（http）となります。
   • したがって g は http です。
4. 内部転送時のホスト名＋パス
   • インターネット工事管理システム用 Web サーバは【問題文】図2 に示すとおり 192.168.5.202。
   • リバースプロキシは /srv2/ を http://192.168.5.202/ に転送する設定になっているので、ログインページは http://192.168.5.202/login.html。
   • よって h は 192.168.5.202/login.html です。

• e：https
• f：www.example.com/srv2/login.html
• g：http
• h：192.168.5.202/login.html

誤りやすいポイント

• 「リバースプロキシサーバと各Webサーバの通信では、SSLは用いない」を読み落として g を https にしてしまう。
• 表2の「/srv2/」設定を見落とし、/srv1/ や /srv3/ と取り違えて f を誤記。
• 外部 URL に内部 IP アドレス 192.168.5.202 を書いてしまうなど、DMZ／社内 LAN の区別を混同する。

FAQ

解答の論理構成

• 【問題文】には、リバースプロキシサーバが “DMZ” に置かれ、IP アドレスが “192.168.3.90” であると記されています。
  引用：「リバースプロキシサーバ…右上にIPアドレス “192.168.3.90” の表記」
• 同じく【問題文】には、携帯電話端末かどうかの判定を「送信元 IP アドレスを参照」して行うと書かれています。
  引用：「携帯電話端末以外からのアクセスか否かの判定は、Webサーバに通知される送信元 IP アドレスを参照することで行われる。」
• 変更後は、外部からの通信が必ずリバースプロキシサーバを経由して社内 LAN の各 Web サーバ（ “192.168.5.201” “192.168.5.202” “192.168.5.203” ）に届けられます。
  引用：「リバースプロキシサーバは、インターネットからのアクセスを受け付け…通信を中継する」
• この中継で元の送信元 IP はプロキシの IP に書き換えられるため、各 Web サーバが受け取るパケットの送信元は常に “192.168.3.90” となります。
  結果として、元々 Web サーバで行っていた「送信元 IP によるアクセス制御」が機能しなくなります。
• 以上から、解答は「送信元のIPアドレスが、すべて192.168.3.90になるから」となります。

誤りやすいポイント

• 「X-Forwarded-For ヘッダを見れば良い」と考えてしまう
  → 出題は OSI 第3層のパケットフィルタ条件について問うており、アプリ層ヘッダは対象外です。
• 「192.168.5.201 など社内側で何らかの NAT を行えば区別できる」と誤解する
  → 区別したいのは送信元、つまり外部利用者の IP。NAT は宛先アドレスの変換であり解決策になりません。
• 「UA（User-Agent）が携帯ブラウザなら判定可能では？」
  → 問題文に「送信元 IP アドレスを参照」と明示されているため、他の情報は前提として使えません。

FAQ

解答の論理構成

1. 追加するパケットフィルタの目的
   下線②では、
   “ファイアウォールのパケットフィルタに、携帯電話端末からのアクセス時に使用されるIPアドレスの範囲以外からの通信を禁止する設定を追加する”
   と記載されています。したがって設定は「携帯電話端末の送信元 IP アドレス」を識別できる場所に施す必要があります。
2. 送信元 IP アドレスを識別できるポイント
   変更後の構成（図2）を見ると、
   ・インターネット → “FW1” → DMZ（“リバースプロキシサーバ”）
   ・DMZ → “FW2” → 社内LAN（各Webサーバ）
   の順でパケットが流れます。
   アクセスは一度リバースプロキシサーバで終端されるため、リバースプロキシサーバより後ろ（すなわち “FW2” 側）では送信元 IP が “192.168.3.90” に変わります。外部クライアントの実 IP は保持されません。
3. どちらにフィルタを置くべきか
   “FW2” に設定してしまうと、すべての通信の送信元 IP はリバースプロキシサーバの “192.168.3.90” であり、携帯電話端末の IP 範囲か否かを判定できません。
   一方、“FW1” はインターネットに直接面しており、携帯電話端末が持つグローバル IP 範囲をそのまま確認できます。したがって下線②の要件を満たせるのは “FW1” です。
4. 結論
   追加設定を行うファイアウォールは “FW1” となります。

誤りやすいポイント

• 「リバースプロキシサーバがあるから送信元 IP が後段でも分かる」と早合点する。実際にはリバースプロキシで TCP セッションが分断されるため、FW2 からは外部 IP を確認できません。
• 「DMZ 内で制御すれば十分」と考えて FW2 を選ぶ。外部不正アクセスを DMZ 内に入れないこと自体がセキュリティ強化の主旨です。
• “静的アドレス変換” と “逆引きプロキシ” を混同し、どの段階で IP が書き換わるかを取り違える。

FAQ