情報処理安全確保支援士 2018年 春期 午後1 問02

解答の論理構成

1. SPFレコードの役割確認
   • 【問題文】図2に「t‐sha.co.jp. IN TXT ”v=spf1 +ip4:a -all”」とある。
   • “v=spf1 … -all” は、送信元アドレスがT社ドメイン名の場合に、どのIPアドレスからの送信を正当とみなすかを示す仕組みである。
2. インターネットへ実際にメールを送信するサーバの特定
   • 表2「外部メールサーバ」の行
     • サーバ名：「外部メールサーバ」
     • IPアドレス：「x1.y1.z1.4」
     • 機能の概要：「転送されてきたメールをインターネットにSMTPで転送する機能がある。」
   • 他にインターネットへ直接SMTP送信するサーバは、表2・表1を通読しても存在しない。
3. SPFレコードに登録すべきIPの決定
   • 送信ドメイン認証として公開DNSに登録するのは、「インターネットにSMTPで転送する」サーバのグローバルIPである。
   • したがって a には 「x1.y1.z1.4」 が入る。

誤りやすいポイント

• 迷惑メール対策サーバ（x1.y1.z1.2）がインターネットからメールを受信するため、「送信側」と誤解してしまう。実際に外部へSMTP送信するのは外部メールサーバである。
• 内部システムLAN上の「Webメールサーバ (192.168.1.11)」はSMTP転送機能を持つが、FWの設定とDMZ構成からインターネットへ直接出るわけではないのでSPF登録対象外である。
• SPFで登録するのはサーバ名ではなくグローバルIPアドレスである点を忘れ、ホスト名を記入してしまう。

FAQ

解答の論理構成

1. インターネットから最初にSMTPで受信するサーバ
   • 表2に「迷惑メール対策サーバ」について
     「『インターネットからのメールの受信』において、…メールを転送する機能がある。」と記載されています。
   • したがって、表3 ①「送信元：インターネット → 宛先：b」はインターネット側から直接到達するメールゲートウェイである「迷惑メール対策サーバ」です。
2. 迷惑メール対策サーバから次にSMTP転送されるサーバ
   • 表2「迷惑メール対策サーバ」には「『受信したメールをWebメールサーバにSMTPで転送する機能がある。』」と明示されています。
   • よって、表3 ②「送信元：b → 宛先：c」の宛先は「Webメールサーバ」です。
3. 社内で作成した送信メールが外部へ出る前に経由するサーバ
   • 表1「Webメールサーバ」には「『外部メールサーバに、SMTPでメールを転送するメール転送機能がある。』」という仕様があります。
   • 従って、表3 ③「送信元：c → 宛先：d」の宛先は「外部メールサーバ」です。
4. 外部メールサーバはインターネットへ最終転送
   • 表2「外部メールサーバ」には「『転送されてきたメールをインターネットにSMTPで転送する機能がある。』」と説明されています。
   • これにより、表3 ④「送信元：d → 宛先：インターネット」に整合します。

誤りやすいポイント

• 「Webメールサーバが直接インターネットとSMTPでやり取りしている」と早合点してしまい、b と c を逆にする。
• 「外部メールサーバ」をDMZ内の名称だと知りながら、転送方向（社内→外部）を意識せず b に入れてしまう。
• ステートフルパケットインスペクション型FWのため戻りパケットは自動許可される点を忘れ、サーバ間の順序関係を混同する。

FAQ

解答の論理構成

1. 問題文の該当箇所
   • DMZ上の「DNSサーバ」の機能として、 「インターネット上のドメイン名の名前解決を行う機能がある。」
     と明記されています。
2. チェックリストの確認事項
   • 表4では「DNSサーバ」が「オープンリゾルバ防止機能」を対象に、 「DNSサーバがeを許可するのは、DMZ上の他のサーバからだけであること」
     と記載されています。
3. オープンリゾルバ防止の趣旨
   • オープンリゾルバを放置すると外部から不特定多数の再帰問い合わせを受け、 DNS増幅攻撃などの踏み台にされる恐れがあります。
   • そこで「インターネット上のドメイン名の名前解決」は
     DMZ内の特定ホストだけに限定すべき通信になります。
4. 以上より、e には
   「インターネット上のドメイン名についての名前解決」
   が入ることが導かれます。

誤りやすいポイント

• 「T社ドメイン名の管理」と混同しやすい
  権威応答（自社ドメイン）ではなく再帰的な外部ドメイン解決を制限する趣旨です。
• 「DNS問い合わせ」だけでは曖昧
  内部・外部どちらの問い合わせかを明確にしないと部分点も失います。
• オープンリゾルバ＝外部からの問い合わせ全拒否と早合点
  DMZ内部サーバからの再帰問い合わせは許可する設計である点を見落としがちです。

FAQ

解答の導き方

1. プロキシでのトンネル確立が可能であること
   本文のプロキシ説明に「HTTPS通信の中継には、CONNECTメソッドを利用する」とあり、さらに図3に「CONNECT x1.y1.z1.4:25 HTTP/1.1」と示されています。これらから、PCがプロキシに対して外部のx1.y1.z1.4の25番ポートへTCPトンネルを要求し、実際にトンネルを確立できることが読み取れます。加えてプロキシの「ポート制限機能」は「現在は、1023以下の宛先ポート番号だけを許可している」とあるので、SMTPの25番ポートは許可範囲に入ります。
2. トンネル化によりWebメールサーバのアプリケーション制御が適用されないこと
   Webメールサーバには「インターネットメール送信制限機能がある」「送信者メールアドレスをメールアカウントに対応付ける送信者メールアドレス詐称防止機能がある」「SMTP通信及びHTTP通信のマルウェアスキャンを行うマルウェアスキャン機能がある」と記載されています。通常はユーザがWebメール経由や迷惑メール対策サーバ経由で送信するとこれらの機能により外部送信の可否判定や差出人照合、マルウェア検査が行われます。しかし、CONNECTによるトンネルで外部の外部メールサーバ（x1.y1.z1.4:25）へ直接SMTPセッションを張ると、Webメールサーバを経由しないためこれらのアプリケーション層の検査・制御を回避できます。重要なのは、問題の本質はWebメールサーバの「アプリケーション層制御の回避」であり、ファイアウォールの振る舞いは経路や検査機能に依存するため、ここではアプリケーション制御の回避に着目する点です。

誤りやすいポイント

• CONNECTは必ずファイアウォールを回避すると考える誤り
  → ファイアウォールの挙動は経路やプロトコル検査機能に依存します。本問で問題となるのは主にWebメールサーバ側のアプリケーション制御が効かなくなる点です。
• SPFが送信側の詐称を自動的に防ぐと誤解すること
  → 迷惑メール対策サーバは受信時に「SPF（Sender Policy Framework）を用いてメールの転送を許可又は拒否する」機能を持ちますが、これが外向きの送信時の詐称防止を直接保証するわけではありません。
• プロキシのポート制限設定を見落とすこと
  → 本文は「現在は、1023以下の宛先ポート番号だけを許可している」と明示しており、25番は許可されている点を見落とすと誤答します。
• Webメール経由と直接SMTPの経路を混同すること
  → Webブラウザ経由の送信（HTTP経由でWebメールサーバが送信する場合）と、プロキシ経由で直接外部SMTPに接続する場合で適用される制御が異なります。

FAQ

解答の論理構成

• 【問題文】にはWebメールサーバの設定として
  「IPアドレス単位に、HTTPによる接続を拒否することができるHTTP接続拒否機能がある。その機能を用いて、内部システムLAN上の他のサーバからの接続を拒否している。」
  とあります。現状は “内部システムLAN上の他のサーバ” だけが対象です。
• 一方、運用方法の見直しで
  「運用PCでは、メールの送受信及びインターネットのWeb閲覧を技術的に制限する。」
  と明記され、さらに下線②として
  「WebメールサーバのHTTP接続機能の設定」
  を変更対象に挙げています。
• 運用PCは新設する「運用PC-LAN」に接続され、運用担当者はサーバに特権IDでログインします。したがって運用PCからWebメール（HTTP）を使えてしまうと、攻撃面が残るため遮断が必要です。
• 以上より、HTTP接続拒否機能の拒否対象に “運用PC-LAN（運用PCのIPアドレス）” を追加し、「運用PCからの接続も拒否するように変更する」ことが適切となります。

誤りやすいポイント

• 「Webメールを禁止＝全PCを拒否」と早合点し、営業・業務PCまで遮断してしまう。要件は運用PCのみ。
• HTTP接続拒否機能ではなくFWやL3SWに設定すると勘違いする。設問はあくまで “WebメールサーバのHTTP接続機能”。
• 「許可リストに運用PCを追加しない」と表現してしまう。実装は拒否リスト追加であるため逆の意味になる。

FAQ

解答の論理構成

• 【問題文】ではプロキシサーバの「アクセス制限機能」について「送信元IPアドレスごとに接続可能なURLを制限する」ことができ、「現在は、全てのURLへの接続を許可している。」と明記されています。
• さらに運用PCに関しては「運用PCでは、メールの送受信及びインターネットのWeb閲覧を技術的に制限する。」という運用方針が示されています。
• しかし運用PCも「T社標準ソフト」の自動更新を行う必要があるため、これらのサイトへの通信は残さなければなりません。
• したがって下線③の設定変更は、「運用PCの送信元IPアドレスに対してだけURLフィルタを強く掛け、T社標準ソフトのベンダサイト以外へのHTTP／HTTPSトラフィックを拒否する」ことになります。
• これにより (1)Web閲覧経由のマルウェア感染リスクを低減しつつ、(2)業務に不可欠な更新系通信だけを許可するという要件を同時に満たせます。

誤りやすいポイント

• 運用PCでもアップデート通信が必要であることを見落とし、「全ての外部URLを遮断」と書いてしまう。
• プロキシサーバの「接続元制限機能」と混同し、「IPアドレスで制限する」と記述してしまう。
• 「Web閲覧禁止」とだけ説明し、URL単位で許可を残すという具体性が不足する。

FAQ