応用情報技術者 試験情報＆徹底解説

https://www.ap-siken.com/kakomon/01_aki/pm01.html
表題の２問について、私の読解力と知識が未熟な故どうしても分からないので、お分かりになる方ご教示ください。

■設問1(1)
公式回答：社内の他の機器と通信させないため
私の回答：他の機器と不審な通信をさせないため

なぜ「社内の」という限定を付す方がより適切な回答となるのか、ご教示ください。

私が「社内の」という限定を付さなかったのは、
ＮＷからＰＣを切り離す目的として
①社内の他の機器に対して感染拡大や攻撃することを防ぐため
②外部のＣ＆Ｃサーバ等へ不正な通信を行うことを防ぐため
という目的があると思ったためです。

①の目的のみだと、極論は外部のＮＷやインターネットへの直接接続ができるということになってしまいます。
なお、実際に、本文中下線部１の直後に「インターネット上の特定のサーバと不審な通信を試みていた」と記載してあるため、本文中の根拠も踏まえたつもりでした。
本文のシナリオとしては、結果的にインターネット上の特定のサーバと不審な通信は失敗していたとはいえ、下線部１の時点ではそのことは判明していなかったため、目的としてはあり得るものだと読み取れました。

■設問2(2)c関連

本文空欄ｃ直後
「（ＳＰＦを）導入すれば，今回の不審メールは検知できたと思います。」
という文章が、どうしても理解できないのでご教示ください。

理解ができていない理由は、私が次のように考えてたからです。

本文中には、
＞情報システム担当のYさんが不審メールのヘッダを確認したところ，送信元メールアドレスのドメインはP社以外となっていた。
と記載があります。

私はこの文から、
不審メールのfromヘッダでは、送信元メールアドレスをなりすませていなかった（送信元メールアドレスが、Ｐ社のドメインと一致していないため）、
と読み取れました。

この場合、ＳＰＦを利用していたとしても、
  ・なりすませていないメールアドレス
  ・なりすませていないメールアドレスのドメインのＳＰＦレコード
の照合で「なりすまし無し」と判定されてしまうのでは？と思ってしまいました。

これが「なりすまし有り」判定になるのは
例えば
  ヘッダfrom：Ｐ社の実在のメールアドレス
  エンベロープfrom：攻撃者のメールアドレス
というメールなのではないか、と思いました。

したがって、本文空欄ｃ直後
「導入すれば，今回の不審メールは検知できたと思います。」
ということにはならないように思えました。



・・・恐らく、私の浅い読み込みと知識の無さによる誤った見解なのかとは思うのですが
複数の解説を読み、何時間も考えてもどうしても理解ができなかったので
どなたか分かりやすくご教示くださいますと、大変ありがたく存じます。

よろしくお願い申し上げます。

この投稿は投稿者により削除されました。(2023.09.10 22:50)

>なぜ「社内の」という限定を付す方がより適切な回答となるのか
まあ、社内の、はあろうがなかろうが影響しないとは思いますが、不審な、という制約修飾があるほうがまずいんじゃないですかね。汚染されたやつに通信そのものをされちゃかなわんわけで。

>不審メールのfromヘッダでは、送信元メールアドレスをなりすませていなかった（送信元メールアドレスが、Ｐ社のドメインと一致していないため）、
>と読み取れました。

まず、エンベロープfrom（封筒の宛名）とヘッダfrom（封筒の中のハガキの宛名）があって、メールアプリとかで日本語で表示されてるのがヘッダFromに記載されているアドレスなわけですけど、ヘッダFromは簡単にいじれちゃいます。最近、アマゾンとかを名乗ってメールが来たりするんだけど、そういうのです。キャリアのドメイン名乗って出○い系の連中が来たりはた迷惑なメールの類いは大半そういう姑息なごまかしをします。

実際はRecievedヘッダっていうのを見て、
Recieved:from 自称送信者 (確認済送信者 [送信者のIPアドレス]) by 受信者 (タイムゾーン)
の中の、自称送信者と確認済送信者の名前が一致しているか？をまず見ます。一致してなかったら、おかしいので。まあそれでも、あてになるのは受信者側のMTAが付けた情報しか実質ないので、この見分けも十全ではないからSPFだのなんだのの話に移っていくわけです。

このあたりは、
なりすましメールをメールソースから見破る方法 | SendGridブログ
2022年12月6日
吉田 健人
とかを参照してください

SPFの話に移りますけど、原理は
受け取ったメールサーバが、SPFレコード（送信元のメールサーバがMAIL FROMコマンドで書いたメールアドレスの、アットマーク以降の文字列のtxtレコードのこと）をDNSサーバに聞いて、そのSPFレコードに書いてあったIPアドレスと、送信元メールサーバのIPアドレスが合うか？を確認するわけです。

それで、
>・なりすませていないメールアドレス
>・なりすませていないメールアドレスのドメインのＳＰＦレコード
>の照合で「なりすまし無し」と判定されてしまうのでは？と思ってしまいました。
は、攻撃者のメールサーバのIPアドレスをQ社DNSのSPFレコードに持っていて、MAIL FROMに馬鹿正直に攻撃者の自前のメールアドレスを書いてきたパターンになるわけですけど、まあSPFレコードの時点であるわけないですね。むしろ、SPFは登録のし忘れとかでメールが届かないだなんだ、と始まるのが多いので、そんなやつのメールは届かなくて正解なんですね。

私もNo.3と同意見で，「社内の」が無くても採点に影響はしないだろうけれど，「不審な通信」という表現の方が問題視されると思います。

不審な通信の存在は Q社に調査を依頼した結果，判明したことであり，被疑PCをネットワークから切り離すことを決めた時点では，添付ファイルを実行したことしか分かっていません。

皆様色々回答されているようですので、私感ですが国語的な解答方法の観点からの内容を
掲載いたします。

IPAの午後の文章問題には暗黙のルールがあります。
それは、設問部分以前の文章の内容から解答するというものです。
逆を言えば、設問部分以降の文章の内容から解答することはないということです。

具体的には、設問は下線①「ネットワークから切り離し、」とあります。
この下線①以前の文章の内容から解答するというものです。

不審なプロセスとの通信に関する文章は下線①以降に「Q社で被疑PCを調査した結果、
不審なプロセスが稼働しており、」とあります。
これは下線①以降に判明した事象なので、解答のメインとして考えるのは
適していないと思われます。

それでは本設問で下線①より以前にあり、下線①の設問に対しての解答として
ヒントになる文章はなにかということになります。
それは問の先頭にある「標的型サイバー攻撃に関する次の記述を読んで，
設問1，2に答えよ。」という文章になります。

当たり前なことかもしれませんが問の最初の概要文は問の特徴を表しています。
本問は「標的型サイバー攻撃」の対応という観点で解答するようにということを
示唆しています。
そのためには「標的型サイバー攻撃」の特徴や対応を一般論として学習しておく
必要があります。
また、この部分が「DDoS攻撃」や「フィッシング攻撃」といった別の攻撃の種類の
場合、解答の根拠となる一般論を頭の中で切り替えてゆく必要があります。

長々と書いてしまいましたが、要約すると
・本問は「標的型サイバー攻撃」の対応について問うている
  故に「標的型サイバー攻撃」の対応としての一般論が解答になる場合がある
・下線①「ネットワークから切り離し、」は「標的型サイバー攻撃」に対して
  一般的な初動としての目的を解答するのが適切と考えられる。
・一般的な初動とは「社内への感染拡大の防止」であり、
  その対応が下線①「ネットワークから切り離し、」であり、
  その対応の目的が「社内の他の機器と通信させないため」とである。

といった論旨の展開になります。

補足します。
少し詩的な表現をするのであれば、
「IPAは国の機関であり、日本語の文章・表現は一字一句時間をかけて推敲されている。
  そのため、IPAの文章はさながら日本語の姿をしたプログラミング言語である。」
とも捉えられます。

IPAの文書をプログラミング言語と捉えるなら
・上から下に内容は流れている
・解答の際には、文書中で未定義な事象は解答ではない
・もし文章中に曖昧な表現・問題がある場合は、かならず訂正が入る
です。

ですのでIPAの文章を日本語としてとらえるのではなく、独自のプログラミング言語と
捉え、プログラム的に理解してゆく方が、意外とすんなり受け入れられるかも
しれません。

皆さま、ご指導ありがとうございます。

■設問1(1)  については、私の懸念点と別の部分に誤りがあったことを知ることができて、良かったです。
特に、pix様の
＞IPAの午後の文章問題には暗黙のルールがあります。
＞それは、設問部分以前の文章の内容から解答するというものです。
＞逆を言えば、設問部分以降の文章の内容から解答することはないということです。
については大変勉強になりました。
より文章に寄り添った読解が必要だったと、反省しています。それにしても、論述で点を取るのは本当に難しいですね・・・。解いた量で本当に点が上がるのか、不安になります。

■設問2(2)c関連  についてGinSana様から詳しい解説を頂きましたが、個人的に未だ消化しきれておらず、考え中です。

＞攻撃者のメールサーバのIPアドレスをQ社DNSのSPFレコードに持っていて、MAIL FROMに馬鹿正直に攻撃者の自前のメールアドレスを書いてきたパターンになるわけですけど、まあSPFレコードの時点であるわけないですね。むしろ、SPFは登録のし忘れとかでメールが届かないだなんだ、と始まるのが多いので、そんなやつのメールは届かなくて正解なんですね。

仰っていることを、
・今回の攻撃では「ヘッダfromのなりすましを暴くためにSPFを利用できたわけではない」が、
・ヘッダfromを書き換えるスキルがないような攻撃者が、事前にSPFレコードまで用意してなりすまそうとしていた訳がないだろう
と理解しましたが、合っていますでしょうか？読解力がなくてすみません。

この投稿は投稿者により削除されました。(2023.09.12 08:15)

この投稿は投稿者により削除されました。(2023.09.15 08:04)

GinSana様

丁寧なご解説、ありがとうございます。

理解が追いついていないので、もう少しお付き合い頂けますか。

＞SPFは自社側のDNSに受け取る相手のメールサーバのIPアドレスを書いとかないとならないこと

とのことですが、ここで用語の意味を再確認させてください。

「自社側」→本文でいう「メール送信者（攻撃者）」ではなく、「メール受信者（Ｐ社）」のことで間違いないでしょうか？
「受け取る相手」→本文でいう「メール受信者（Ｐ社）」ではなく、「メール送信者（攻撃者）」のことで間違いないでしょうか？
「ＤＮＳ」→「自ドメインの権威ＤＮＳサーバ」か、「インターネットにアクセス等するためのキャッシュＤＮＳサーバ」か、どちらでしょう？

上手く理解できておらず申し訳ございません。一度整理したかったので・・・すみません。

＞1. 自社側のDNSに攻撃者の用意したメールサーバのIPアドレスがSPFレコードとして書いてあって、その上で攻撃者の送信元メールアドレスのドメインが攻撃者の用意したメールサーバのドメインである場合

ここで仰っているのは、
「送信者（攻撃者）のドメインのＳＰＦの設定を行うには、メール受信者（Ｐ社）が、自社のＤＮＳサーバ（「自ドメインの権威ＤＮＳサーバ」or「インターネットにアクセス等するためのキャッシュＤＮＳサーバ」？）に、送信者（攻撃者）のドメインをあらかじめ登録しておく必要がある」
ということでしょうか・・・？（誤読ならすみません）



私が疑問に思っているのは、私のＳＰＦの理解が次のとおりだからです。

①送信者は、予め自ドメインの権威ＤＮＳサーバにＳＰＦレコードを登録しておく
②送信者は、受信者にメールを送る
③受信者のメールサーバは、送信者の権威ＤＮＳサーバに対して、
  「受信したメールの送信元＝送信者のドメイン」かどうか
  を確認する（＝ＳＰＦレコードの確認）。
  ↓
  ここで、送信者が例えばfromを偽装していると、送信者の権威ＤＮＳサーバは、fromと異なる別のドメインである（＝なりすましあり）ことを返す。
  逆に、送信者が例えばfromを偽装していなければ、送信者の権威ＤＮＳサーバは、fromと同じドメインである（＝なりすましなし）ことを返す。

→したがって、本文ではfromの偽装がないため、ＳＰＦの結果が「なりすましなし」と返ってくる、と考えました。



この理解に関して、誤っている部分や、実は不足している知識などご教示頂けますと幸いです。

なお、このように理解したのは
「送信ドメインを認証するためのSPFレコードに詳しくなろう  2022年12月20日 by SendGrid」
  →例えば、図では「sender」の領域にＤＮＳサーバがあり、そこに「receiver」が確認をしている

「【図解】SPFレコードとは？？spfレコードの仕組みを初心者にも分かりやすく解説します」
「SendGridからメール送信する場合のSPFとDKIMの認証の仕組み – 前編  2022年10月4日 by 有田繭子」
や、合格教本（p.485）などの参考書を確認した結果です。
私の誤読か知識不足による理解不足だとは思うのですが・・・。

この投稿は投稿者により削除されました。(2023.09.13 22:29)

この投稿は投稿者により削除されました。(2023.09.13 22:49)

>「自社側」→本文でいう「メール送信者（攻撃者）」ではなく、「メール受信者（Ｐ社）」のことで間違いないでしょうか？
>「受け取る相手」→本文でいう「メール受信者（Ｐ社）」ではなく、「メール送信者（攻撃者）」のことで間違いないでしょうか？

そうです。

>「ＤＮＳ」→「自ドメインの権威ＤＮＳサーバ」か、「インターネットにアクセス等するためのキャッシュＤＮＳサーバ」か、どちらでしょう？
プライマリ（権威）に指定して、セカンダリにゾーン転送します。

>ここで仰っているのは、
>「送信者（攻撃者）のドメインのＳＰＦの設定を行うには、メール受信者（Ｐ社）が、自社のＤＮＳサーバ（「自ドメインの権威ＤＮＳサーバ」or「インターネットにアクセス等するためのキャッシュＤＮＳサーバ」？）に、送信者（攻撃者）のドメインをあらかじめ登録しておく必要がある」
>ということでしょうか・・・？（誤読ならすみません）
理屈の上ではそうなります。
実際には、相手のドメインのことはわからないから、No.10で書いた「SPFの未設定ドメインのメールアドレスで送ってきた場合」として扱われることになります。

>ここで、送信者が例えばfromを偽装していると、送信者の権威ＤＮＳサーバは、fromと異なる別のドメインである（＝なりすましあり）ことを返す。
>逆に、送信者が例えばfromを偽装していなければ、送信者の権威ＤＮＳサーバは、fromと同じドメインである（＝なりすましなし）ことを返す。

たとえば、取引先のhogeというドメインがあって、IPアドレスがαとする。hogeのドメインで、IPアドレスをαとしてSPFレコードを受信側が用意したとする。

1.IPアドレスがαの取引先のメールサーバからメールアドレスのドメインがhogeのメールが届いたとする。これは、なりすましがない。
2.攻撃者が指定したメールアドレスのドメインがhogeで、攻撃者の用意したメールサーバのIPアドレスがβとする。これは、なりすましと判定されて叩き落とされる。
3.攻撃者が指定したメールアドレスのドメインがfugaで、攻撃者の用意したメールサーバのIPアドレスがβとする。これは、DNSに判定材料がないのでなりすましともいえない。一般的には、そのまま届く。

だいぶさっ引いた話もあるので、
迷惑メール対策（SPAM対策） - 情報処理安全確保支援士 - SE娘の剣 -
とかも参考にしてください

>本文ではfromの偽装がない
たしかに、いま読み直してみると、Fromにどう書いたのか？がわからないので、偽装したともないともわかりません。ヘッダをみたはいいがどこからどこまで見た上でいっているのかは本文からはわからないので、SPFの話を持ち出している前提で考えるなら、自社ドメインへの偽装はあったと言いたいところなんですが、そうだとも言い切れないですね。

仮に自社のドメインがp_sha.comだったとしたら、
のようなレコードを用意する。
@p_sha.comのメールはそもそも
1.1.x.101のIPアドレスからしか来ない
という意味になるので、自社のメールサーバのIPアドレスから来ないp_sha.comのドメインのはおかしいよね、という意味で弾かれるから、そういう偽装が発生したとするなら、
W氏は「導入すれば，今回の不審メールは検知できた」（と思う）といっているんだと解釈するんですが、あんまり突き詰めても不毛な気がします。

解説ありがとうございます！

すると、私が書き込みました、
＞①送信者は、予め自ドメインの権威ＤＮＳサーバにＳＰＦレコードを登録しておく
＞③受信者のメールサーバは、送信者の権威ＤＮＳサーバに対して、
＞ 「受信したメールの送信元＝送信者のドメイン」かどうか
＞ を確認する（＝ＳＰＦレコードの確認）。
は理解が誤っており

①【受信者】は、予め自ドメインの権威ＤＮＳサーバに【送信者の】ＳＰＦレコードを登録しておく
③受信者のメールサーバは、【受信者】の権威ＤＮＳサーバに対して、
 「受信したメールの送信元＝送信者のドメイン」かどうか
 を確認する（＝ＳＰＦレコードの確認）。

が正しい・・・ということでしょうか？

それとも、
＞①送信者は、予め自ドメインの権威ＤＮＳサーバにＳＰＦレコードを登録しておく
という行為と
＞①【受信者】は、予め自ドメインの権威ＤＮＳサーバに【送信者の】ＳＰＦレコードを登録しておく
という行為は、どちらも必要なものなのでしょうか。

参考書やネット上の記事を調べたのですが、
＞③受信者のメールサーバは、送信者の権威ＤＮＳサーバに対して、
＞ 「受信したメールの送信元＝送信者のドメイン」かどうか
＞ を確認する（＝ＳＰＦレコードの確認）。
という趣旨のものが多いように見受けられる一方、

＞①【受信者】は、予め自ドメインの権威ＤＮＳサーバに【送信者の】ＳＰＦレコードを登録しておく
＞③受信者のメールサーバは、【受信者】の権威ＤＮＳサーバに対して、
＞「受信したメールの送信元＝送信者のドメイン」かどうか
＞を確認する（＝ＳＰＦレコードの確認）。
という記述がなかなか見つからず、消化しきれずにおります・・・。

もし分かれば、参考記事などとともに、ご教示お願いします。

この投稿は投稿者により削除されました。(2023.09.15 07:59)

>①【受信者】は、予め自ドメインの権威ＤＮＳサーバに【送信者の】ＳＰＦレコードを登録しておく
>③受信者のメールサーバは、【受信者】の権威ＤＮＳサーバに対して、
> 「受信したメールの送信元＝送信者のドメイン」かどうか
> を確認する（＝ＳＰＦレコードの確認）。

迷惑メール対策（SPAM対策） - 情報処理安全確保支援士 - SE娘の剣 -
によれば
という設定が必要であり、
SPFによるドメイン検証の流れ
という項の図を見るとよくわかる（まず、参考のサイトを確認してください）が、

③受信者のメールサーバは、送信者のメールアドレスのドメインのDNSサーバに対してTXTレコードを問い合わせて、「TXTレコードに記されたIPアドレスが、届いたメールの送信元IPアドレスと一致するかどうか」を確認する。
が流れとして正しいです。どこかで受信側のDNSがどうのと書いてしまったのが間違いでした。

「受信したメールの送信元」と書くと、「送信元」の何？という言葉がないので、何を比較したいのかがわからない。あいまいなものを比較することはできない。

ap難しいさん


>もし分かれば、参考記事などとともに、ご教示お願いします。

迷惑メール対策委員会のSPFの説明サイトから有益な情報が得られると思います。
Google上で"迷惑メール対策委員会  SPF"で検索すれば1番目にヒットします。


>本文中には、
>"＞情報システム担当のYさんが不審メールのヘッダを確認したところ，送信元メールアドレスのドメインはP社以外となっていた。"
>と記載があります。

>私はこの文から、
>不審メールのfromヘッダでは、送信元メールアドレスをなりすませていなかった（送信元メールアドレスが、Ｐ社のドメインと一致していないため）、
>と読み取れました。
>
>この場合、ＳＰＦを利用していたとしても、
> ・なりすませていないメールアドレス
> ・なりすませていないメールアドレスのドメインのＳＰＦレコード
>の照合で「なりすまし無し」と判定されてしまうのでは？と思ってしまいました。
>
>これが「なりすまし有り」判定になるのは
>例えば
> ヘッダfrom：Ｐ社の実在のメールアドレス
> エンベロープfrom：攻撃者のメールアドレス
>というメールなのではないか、と思いました。

>したがって、本文空欄ｃ直後
>「導入すれば，今回の不審メールは検知できたと思います。」
>ということにはならないように思えました。


解説にあるとおり、P社以外のドメインについても
詐称されている可能性が高いのでSPFで検知できると判断しています。


解説より抜粋
===============================================
標的型メール攻撃では攻撃者の身元を隠ぺいするため、
送信元メールアドレスが詐称されている
（実在しないドメインを使用している）ことがほとんどです。
===============================================

SPF認証結果は、なりすまし有り・無しではなく、正確に把握する必要があります。
「None」、「Pass」、「Fail」の結果の理解は最低限必要です。
これらは冒頭で案内しましたサイトで確認できます。

そのうえで(c)の解説を熟読すれば、理解が深まると思います。

>すると、私が書き込みました、
>"＞①送信者は、予め自ドメインの権威ＤＮＳサーバにＳＰＦレコードを登録しておく"
>"＞③受信者のメールサーバは、送信者の権威ＤＮＳサーバに対して、"
>"＞ 「受信したメールの送信元＝送信者のドメイン」かどうか"
>"＞ を確認する（＝ＳＰＦレコードの確認）。"


こちらで正しいです。


SPF認証には、2つの考えがあります。

・メール受信者側の被害防止策

こちらは、③に該当します。
メールサーバにSPFの設定をすると受信メールサーバが③の動作をするようになります。
これにより成りすましの検知が可能となります。
問題文で取り扱われているのはこちらです。


・メール送信者側の加害疑惑防止対策

こちらは①に該当します。
問題文では、登場しませんので補足事項として捉えていただければと思います。
被害防止策の裏返しとなりますが、取引先など相手の受信メールサーバがSPFを導入している場合、
自社からのメールを取引先が受信すると取引先のメールサーバから自社のDNSサーバのSPFレコードを確認するようになります。
こちらの対策が未実施の場合、メールが正当でもNoneの判定が下り迷惑メールに認定される恐れがあります。
また、自社に成りすました攻撃者のメールが取引先で受信されると、検知はされるものの結果的に
先方に受信される恐れがあります。身に覚えのない取引先の被害を防止する上でも重要となります。

SPF認証の理解を確認するという意味で、平成元年秋 SC 午後Ⅰ問1の「表1 SPFへの対応状況と各攻撃に対する効果」は、ap難しいさんの疑問に沿った内容となっており、エッセンスが詰まっていると思います。ご興味があればご確認ください。

GinSana  様
陽射  様

お二人の解説で、やっと理解できました・・・！

＞「None」、「Pass」、「Fail」の結果の理解は最低限必要です。
仰るとおりでした。
Noneによる判定で引っ掛けていた、というところがポイントだったのですね。
普及率９割以上という解説も、読んだ気になっていて、その重要さが分かっていませんでした。

詳細にわたる解説、ありがとうございました。

セキスペの問題も解いてみまして、大変勉強になりました。

ＩＰＡの午後問題は、仕組みを理解させる上で良問が多いのですね。

お二人の貴重なお時間を無駄にしないよう、あと３週間全力で頑張っていこうと思います。