情報処理安全確保支援士 2011年 春期 午前2 問12
問題文
自社の中継用メールサーバのログのうち、外部ネットワークからの第三者中継と判断できるものはどれか。ここで、AAA.168.1.5とAAA.168.1.10は自社のグローバルIPアドレスとし、BBB.45.67.89とBBB.45.67.90は社外のグローバルIPアドレスとする。a.b.cは自社のドメイン名とし、a.b.dとa.b.eは他社のドメイン名とする。また、IPアドレスとドメイン名は詐称されていないものとする。

選択肢
ア:
イ:
ウ:(正解)
エ:
🔒 解説は解答すると表示されます
第三者中継判定【午前2解説】
正解の理由
外部ネットワークのIPアドレスから自社の中継用メールサーバへ接続し、宛先が自社ドメイン以外(外部ドメイン)になっている場合は、自社サーバを経由して外部同士のメールを中継している、すなわち第三者中継であると判断します。表のうち、接続元が外部IPであり送信先も外部ドメインになっている行が該当します。該当するのは ウ(接続元:BBB.45.67.89、送信者:a.b.d、受信者:a.b.e)で、外部(BBB)が自社サーバを経由して他社ドメインへ送信しているため第三者中継と判定できます。
解法ステップ
- 接続元IPを確認する
- 自社グローバルIP(AAA.*)なら自社側からの接続(内部送信/正当な利用の可能性が高い)。
- 社外グローバルIP(BBB.*)なら外部からの接続であり、無断で中継されている可能性を考慮する。
- 受信者ドメインを確認する
- 受信者が自社ドメイン(a.b.c)であれば「外部→自社」着信であり、中継ではない(通常の受信)。
- 受信者が自社以外(他社ドメイン)であれば、自社サーバを経由して外部へ中継している可能性が高い。
- 両者を組み合わせて判定する
- 接続元が外部かつ受信者が外部 → 第三者中継(不正中継)の典型ケース(今回の正解)。
- 接続元が外部だが受信者が自社 → 単なる外部からの着信で中継とはしない。
- 接続元が自社 → 自社利用(第三者中継とはしないが内部感染など別観点で確認が必要)。
選択肢別の誤答解説
- ア(接続元:AAA.168.1.5、送信者:a.b.c、受信者:a.b.d)
接続元が自社IP(AAA)であるため、自社内からの送信と解釈するのが自然です。自社利用による外部宛送信であり、「外部が自社サーバを経由して第三者として中継している」状況ではないため第三者中継とは言えません。 - イ(接続元:AAA.168.1.10、送信者:a.b.c、受信者:a.b.c)
送信者・受信者とも自社ドメインで、接続元も自社IPです。これは内部のドメイン内配送(ローカル配送)であり、中継とは無関係です。 - ウ(接続元:BBB.45.67.89、送信者:a.b.d、受信者:a.b.e)
接続元が社外IPで、宛先が自社ドメインでないため、外部が自社サーバを経由して他社へ送信している状況に一致します。よって第三者中継と判定します。 - エ(接続元:BBB.45.67.90、送信者:a.b.d、受信者:a.b.c)
接続元は外部IPですが、受信者が自社ドメインです。これは外部から自社への着信(外部→自社)であり、自社サーバを使って外部間を中継しているわけではないため、第三者中継とは判断しません。
よくある誤解
- 外部IPが関与していればすべて第三者中継だと思う誤解
→ 接続元が外部でも受信者が自社であれば単なる着信で、中継ではありません。 - 送信者ドメインが自社でなければ必ず第三者中継とする誤解
→ 送信者ドメインだけで中継を断定できません。接続元IPと受信者ドメインの組合せで判断します(問題ではドメイン詐称はないと明示されている点に注意)。 - ログの「接続元IP」と「送信者アドレス(MAIL FROM)」を混同する誤解
→ 接続元IPは実際に接続したホスト(SMTPコネクション元)を示します。NATやプロキシの存在、または詐称の有無により解釈が変わるため、ログ項目を正確に読み取ることが重要です。
補足コラム
実運用で第三者中継(オープンリレー)を検出する際は、単一ログの表だけでなく次を確認します。
- SMTPセッションのAUTHの有無(認証なしで外部宛へリレーしていないか)
- MAIL FROM / RCPT TO の時刻と接続元IPの一致(短時間に大量の外部宛を中継していないか)
- HELO/EHLOやReceivedヘッダの経路(外部が経由箇所を偽装していないか)
- 具体的なログ例(Postfixの一行例):
Jul 29 12:34:56 mail postfix/smtpd[12345]: connect from mail.example.net[45.67.89.1]
Jul 29 12:34:57 mail postfix/smtpd[12345]: NOQUEUE: reject: RCPT from mail.example.net[45.67.89.1]: 554 5.7.1 Relay denied;
適切な対策:認証必須化、IP/ポリシベースの中継制限、ログ監視の自動化(スコアリング)など。
FAQ
Q1. 送信者ドメインが自社でも接続元が外部だったら?
A1. ドメインが自社でも接続元が外部であれば、詐称(なりすまし)の可能性や自社の端末が外部から接続されている可能性があります。問題文で「詐称されていない」とあるかどうかで判断基準が変わります。
A1. ドメインが自社でも接続元が外部であれば、詐称(なりすまし)の可能性や自社の端末が外部から接続されている可能性があります。問題文で「詐称されていない」とあるかどうかで判断基準が変わります。
Q2. NAT越しのログではどう判定する?
A2. 接続元IPがプロバイダや境界機器のIPになる場合があります。可能ならSMTPのReceivedヘッダや境界機器のログと突合して発信源を特定してください。
A2. 接続元IPがプロバイダや境界機器のIPになる場合があります。可能ならSMTPのReceivedヘッダや境界機器のログと突合して発信源を特定してください。
Q3. 内部から大量外部宛があればそれも問題か?
A3. 内部端末が踏み台になって外部へ大量送信するケースはあるが、それは「内部不正利用」であり第三者中継(外部が自社サーバを経由して他社へ中継する)とは概念が異なります。どちらも検出・対処が必要です。
A3. 内部端末が踏み台になって外部へ大量送信するケースはあるが、それは「内部不正利用」であり第三者中継(外部が自社サーバを経由して他社へ中継する)とは概念が異なります。どちらも検出・対処が必要です。
関連キーワード: SMTPログ解析、オープンリレー対策、受信者ドメイン判定、接続元IP、メールサーバ監視

\ せっかくなら /
情報処理安全確保支援士を
クイズ形式で学習しませんか?
クイズ画面へ遷移する→
すぐに利用可能!

