工場のログはRFC 5424に従って転送する。事務所のプロキシは、Basic認証ではなく、MD5やSHA-256でハッシュ化する方式を使用する。HTTPSの中継では、HTTPメソッドによってトンネルを作り、宛先ポート443に限定する。

問題

解説：Syslogはイベント通知の転送に使う。ダイジェスト認証と、単にBase64で表現するBasic認証を区別する。CONNECTはHTTPプロキシ経由のトンネルを要求するメソッドである。

社外と通信する外部メールサーバとプロキシサーバを、FWで分離したDMZへ置く。利用者PCなどはOAセグメントへ置く。

問題

解説：公開サーバ自体の侵害を完全に防ぐという説明ではない。侵害後に別の内部機器へ到達する範囲を、境界の分離によって制限する。

本社UTMと支社UTMのペアには、IPsec VPNのために同じ秘密の鍵情報をあらかじめ設定する。

問題

解説：通信相手同士が事前に同じ値を持つ方式を問う。原問の「鍵」は証明書や公開鍵を選ばせるものではない。

本社と各支社のUTMはペアごとに事前共有鍵を設定する。全てのペアで同じ値にする案と、ペアごとに異なる値にする案を比較する。

問題

解説：一つのペアの鍵が知られても、その値を別ペアの認証にそのまま使えない。管理上の利点は漏えい時の影響を接続単位で分離できることである。

元のIPパケットをIP-in-IPでカプセル化すると、「IP-in-IP用のIPヘッダー＋元のIPパケット」となる。現行のIPsecトランスポートモードでは、元のIPパケットとESPトレーラーを暗号化する。これをIPsecトンネルモードへ変更する。

問題

解説：IPsecへ渡す時点で、IP-in-IPのIPヘッダーは既に付加されている。トンネルモードでは、そのIPヘッダーも含めて保護する。インターネット転送用にさらに付く最外側のIPヘッダーまで暗号化するわけではない。

ISPのルータAと社内ルータBの間、およびルータBとFWの間では、LLAのみを設定する。これらのインタフェースにはGUAを割り当てない。

問題

解説：LLAによる隣接通信や次ホップ指定と、インターネットから機器自身への到達性を分離する設計である。これは該当インタフェースへのGUA割当てを避ける狙いであり、FWによる通過通信の制御が不要になるという意味ではない。

SaaSは送信元IPでアクセスを制限する。導入するSGWは複数企業へ提供され、利用者の通信を固定のグローバルIPへNAPTする。自社だけを許可するため、この出口IPをSaaSへ登録する予定である。

問題

解説：他社と同じ出口IPを共有すると、IPアドレスだけでは自社通信を区別できない。固定であることに加えて、専用割当であることが必要になる。

営業所のPCはIPsec VPNで本社へ接続し、本社のL3SW、FWを経てSaaSへアクセスする。FWの外部IPはa.b.c.d、本社IPsecルータの外部IPはs.t.u.vである。FWがインターネット向け通信をNAPTする。

問題

解説：SaaSが見るのは、最終的なインターネット出口で変換した後のアドレスである。IPsecの外側で使うルータのアドレスとは異なる。

一部のSaaSは送信元IPアドレスで利用を制限している。既存の出口FW10と新しい出口FW40は、それぞれ別のグローバルIPアドレスへNAPTする。

問題

解説：アプリケーションや利用者が同じでも、外部から見えるアドレスが変わる。旧アドレスだけが許可されているSaaSでは、アクセスが拒否される。

移行期間中は旧プロキシAを使えば旧グローバルIPアドレスでSaaSへ接続できる。移行完了後は旧プロキシAを廃止し、FW40を出口にする。

問題

解説：旧出口を残すのは一時的な回避策である。新しいNAPT後のアドレスを許可することで、旧プロキシを使わずにアクセスできる。

店舗のWi-Fi APはルーティングポート側に置く。在庫管理端末はブリッジポート側に置く。両ポート間の通信は禁止される。

本社との接続はブリッジポート間のL2トンネルだけである。インターネットから本社のルーティングポート配下へ着信することもできない。

問題

解説：Wi-Fiはルーティングポート側に分離されている。本社へ届くブリッジ側経路との間に通信経路がないことが理由である。

社内プロキシは、登録済みFQDN・IPアドレスへの通信をブロックする。アクセスログを保存する。利用者は認証サーバを用いて認証される。Webサイトへの通信はこのプロキシを経由する。

問題

解説：通信先の制限、履歴の取得、利用者の確認という三つの役割が本文に示されている。二つを答える問題なので、同じ目的を言い換えて重複させない。

社内にはsyslogサーバと認証サーバがある。DMZの機器はUDP/514でログを送信する。プロキシはRADIUSを使い、UDP/1812で利用者認証を行う。

問題

解説：ポート番号と、本文でその機能を担当する機器を対応付ける。送信元がプロキシだから宛先もWebサーバになるとは限らない。利用者認証のための通信は、業務データの中継とは別に発生する。

社内プロキシはTCP/10080でPCからの接続を待ち受ける。PCからK社SaaSへの通信はHTTPSを用い、プロキシを経由せず直接接続する。

問題

解説：プロキシの待受ポートは本文に指定された値を使う。HTTPSのWebサイトへ向かう通信と、PCが明示プロキシへ接続する通信は異なる区間である。

DMZには公開Webサーバ、プロキシサーバ、外部DNSサーバがある。外部DNSは公開ゾーンを管理し、社内DNSからの外部名の解決要求も受け付ける。

内部LANの社内DNSは外部名を外部DNSへ転送する。Webアクセスはプロキシからインターネットへ中継する。

問題

解説：公開サービスの受信、中継サーバの外向き通信、内部DNSからの転送要求を別々のルールとして整理する。原問のFWはステートフルであり、応答通信はその状態に基づいて扱う。

カメラ管理サーバはサーバ室にあり、カメラとは独自プロトコルで通信する。執務室のPCは、HTTPSでカメラ管理サーバのWebページにアクセスする。FWは、必要な通信だけを許可する。

問題

解説：管理サーバとカメラ間の通信と、PCから管理画面への通信を区別する。後者はHTTPSなので宛先TCPポート443を使用する。

CDNのBGPルータは、隣接ASのBGPルータとMD5認証用の共通パスワードを設定している。

問題

解説：この設定が確認するのはBGP接続の相手である。接続後に広告される経路の正しさまでを、この認証だけで保証するわけではない。

CDNではアドレスブロックやAS番号を偽った経路を受け取らないように、経路フィルタリングを実施する。フィルタリングせず不正な経路を採用した場合を考える。

問題

解説：経路表が誤った転送先を選ぶと、その宛先へ正常にデータを届けられない。問われているのはCDN全体の停止ではなく、不正な経路が示す宛先への影響である。

インターネットからBGPルータ、内部ルータ、FW、LBの順に通信が流れる。RTBHでは攻撃対象宛てのホスト経路をBGPルータへ広告し、ネクストホップを廃棄用インタフェースにする。比較対象は内部のFWでの遮断である。

問題

解説：BGPルータで破棄すれば、内部ルータやFWへ攻撃パケットを運ばずに済む。どちらも遮断できるという説明ではなく、遮断する位置の差を答える。

宛先アドレスベースのRTBHは、攻撃対象IPアドレス宛ての通信を破棄する。BGP FlowSpecでは、宛先IPアドレスに加えて送信元IPアドレスや宛先ポート番号などを組み合わせて条件を広告できる。

問題

解説：宛先が同じでも、条件の異なる通信を区別できる。遮断の単位が細かくなるため、原問ではBGP FlowSpecの方が有用と判断している。

新しいIPsec接続ではIKEv2とESPを使用する。元のIPパケットへESPトレーラを付けて保護し、外側の新しいヘッダを加えてVPNの接続先へ送る。Diffie-Hellmanグループでは、鍵生成に用いるアルゴリズムと長さを選ぶ。

問題

解説：外側のIPヘッダはトンネルの両端を示す。元の利用者パケットはESPで保護される。IKE SAによる交渉と、ESPデータ通信に用いるChild SAを区別する。

Gメーターから管理サーバまでの通信経路は、Y社向けの閉域網で構成する。途中のインターネット区間にはIPsec VPNを使用する。DTLSの利用は端末の処理量を増やす。

問題

解説：回答の根拠は原問が定めた通信範囲と保護経路である。「閉域網なら暗号化は一律不要」という一般則には拡張しない。

K社は個人PCからVDIを利用する。通信はSSL-VPNで保護する。必要なアプリケーションはRDPだけである。

原問ではSSL-VPNをリバースプロキシ、ポートフォワーディング、L2フォワーディングの方式に整理する。TLS 1.3を使用する。

問題

解説：RDPのTCP接続だけを中継するので、対象ポートを転送する方式を選ぶ。L2フレーム全体を運ぶ方式とは転送対象が異なる。

証明書は公開鍵とその主体を結び付ける。原問の「ポート」「公開」という空欄は、学習用に用語全体で解答する形式にした。

原問の通信シーケンスでは、TCPの接続確立後にClientHelloとServerHelloを交換し、その後にHTTPの要求・応答を送る。ALPNは、このTLSハンドシェイクの中で利用する。

問題

解説：クライアント側の提示とサーバ側の選択をハンドシェイク中に行う。ここでは原問に示されたシーケンスに対応するメッセージ名を答える。

増設したECサーバにはサーバ証明書をインストールしない。既存ECサーバの証明書を流用して、利用者側のTLSをLBで終端する。

問題

解説：証明書だけでは秘密鍵を使う処理を実行できない。証明書に対応する秘密鍵を組にして移行する必要がある。

TLS 1.3はAEADを利用する。AEADは通信内容を隠す処理と、メッセージの完全性を確認する処理を組み合わせる。

問題

解説：暗号化だけでは、受信データが変更されていないことを確認する機能を表せない。AEADではメッセージ認証も扱う。

SSL-VPN装置はX.509証明書を使用する。証明書には発行者の情報と、証明対象の主体の識別情報が含まれる。

問題

解説：発行したCAではなく、その証明書が誰の公開鍵を証明するかを問うている。対象主体を示すのがSubjectである。

利用者ごとに鍵ペアとクライアント証明書を発行する。対応する秘密鍵は本人だけが保有する。SSL-VPN装置は証明書によるクライアント認証を行う。

問題

解説：証明書自体は秘密情報ではない。認証の根拠は、公開鍵に対応する秘密鍵を持つことの確認にある。

K社は外部CAサービスからクライアント証明書を発行してもらう。SSL-VPN装置がその証明書を検証する。

問題

解説：利用者の公開鍵を含む証明書を受信するだけでは、その発行者を信頼できるか判断できない。CAのルート証明書を信頼の起点として用いる。

SSL-VPNクライアントは、接続先装置が提示するサーバ証明書を検証する。

問題

解説：クライアント認証とは確認する向きが逆である。ここでは利用者が接続先の装置を確かめる。

原問は、RSAなどの従来の鍵交換と、TLS 1.3で用いる一時的な鍵による鍵交換を比較している。通信は攻撃者に記録されているものとする。

問題

解説：漏えい後の通信だけでなく、記録済みの過去の通信に影響が及ぶ点が比較の焦点である。原問はこの範囲の違いを問うている。

利用者は自分の鍵ペアを生成する。公開鍵を含むCSRに署名してCAへ提出する。CAはCSRの署名を検証する。

問題

解説：CSRを作った利用者の鍵ペアを用いる。CAが証明書を発行するときのCA署名とは区別する。

CAは証明書失効リスト（CRL）を提供する。CRLには失効日時と、当該CAが発行した証明書を識別する情報が載る。

問題

解説：証明書の主体名だけでは、更新前後などの個々の証明書を区別できない。CRLは証明書のシリアル番号を用いる。

ECサーバの証明書は一つであり、複数ドメインには対応していない。公開用の接続名はecsv.example.jp、社内用の接続名はecsv.y-sha.example.lanである。社内名を使うとTLSハンドシェイク時にエラーになる。

問題

解説：接続対象を示す名前が証明書で保証されているかを確認する問題である。ここでは、原問の指定どおりコモン名との不一致を説明する。

利用者IDはクライアント証明書に含まれる。接続シーケンスは、サーバ側のCertificateRequestとCertificateの後、クライアントがCertificate、CertificateVerify、Finishedを送る。

SSL-VPN装置はユーザーテーブルを検索し、対応する仮想PCへのNATエントリを作成する。

問題

解説：利用者IDを含む証明書そのものはCertificateで届く。続くCertificateVerifyは秘密鍵の保有を確認する処理であり、IDの取得元とは異なる。

ゲーム端末はLBのグローバルIPアドレスのTCP443番へHTTPSで接続する。LBから配信サーバへはHTTPのTCP80番で接続する。

問題

解説：HTTPSを受け取り、バックエンドへHTTPで接続し直す装置がTLSの終端となる。原問の通信条件では、その装置は配信サーバではなくLBである。

原問のKerberos手順では、KDCがPCの鍵で保護した認証情報を返す。その後、PCはKDCへTGTを示してサービスチケットSTを要求する。STの払い出し情報も、PCの鍵で保護されている。

問題

解説：ネットワーク上で保護された応答を取得することと、本人の鍵で処理して使用可能なSTを得ることは異なる。サービスへは、必要なSTを取り出して提示する必要がある。

通信は、PCからKDCへの初回認証要求、KDCからのTGT払い出し、PCと業務Webサーバ間のHTTP要求・応答、PCからKDCへのST要求、KDCからのST払い出し、STを付けたHTTP要求の順に進む。

問題

解説：ポート88はKDCとの認証・チケット取得で使う。業務WebサーバへSTを提示する段階は、原問ではHTTPの通信に組み込まれる。

TGTとSTには有効期限がある。PCとサーバの時刻がずれていると、有効なSTでもサーバが使用不可と判断する可能性がある。

問題

解説：同じチケットについて期限内かを判断する基準時刻を揃える。チケットの保存や配布だけでは解決しない。

ECサイトはSAMLのSPとして動作する。会員企業はそれぞれ自社のIdPを使用する。SPはログイン要求に対し、該当するIdPへブラウザをリダイレクトする。

問題

解説：利用者ごとに認証を依頼すべき組織が異なる。所属企業を判断し、その企業のIdPへ認証要求を送る。

IdPはSAMLアサーションにデジタル署名を付ける。ECサーバであるSPは、事前に信頼したIdPの情報を登録して署名を検証する。

問題

解説：IdPが秘密鍵で作成した署名を、対応する公開鍵で検証する。SPへIdPの秘密鍵を配布する必要はない。

KDCはIdP向けのサービスチケットSTをIdPの鍵で暗号化する。さらに、そのSTとセッション鍵などをPCの鍵で包んでPCへ渡す。PCは外側を取り出してSTをIdPへ提示する。

問題

解説：PCが開ける外側の保護と、IdPだけが処理できるST本体の保護を区別する。PCはSTを運ぶが、その内部を正しく作り直すためのIdPの鍵は持たない。

IdPは利用者を認証し、署名付きSAMLアサーションをブラウザ経由でSPへ渡す。SPは、信頼関係を設定したIdPの公開鍵証明書を使って署名を検証する。

問題

解説：ブラウザを経由して届いても、署名によって生成元と内容の完全性を確認できる。アサーションの記述に基づく利用権限の判断は、その検証の後に行う。

管理セグメントとOAセグメントの間にファイル転送アプライアンスFTAを設ける。既存の内部メールサーバとプロキシは、利用者認証のためLDAPサーバを参照している。

問題

解説：すでに利用者情報を管理している認証情報源を使う。FTAだけに別の利用者情報を作る場合の重複管理を避けられる。

FTAの利用者はログイン後、ファイルをアップロードする。承認は指定された上長だけが行い、ダウンロードは指定された受信者だけが行える。

問題

解説：ログインできた利用者であっても、すべてのファイルを承認・取得できるわけではない。本人確認と、個々の操作の許可判断を分ける。

DKIMはメール本文と、メールの先頭にある管理情報を基に署名を作る。検証用の鍵はDNSで公開する。原問では拡張を使わない従来のUDPによるDNSメッセージ長を前提としている。

問題

解説：署名対象にはヘッダーと本文が含まれる。512バイトは原問の説明に対応する値であり、DNSの拡張方式を含むあらゆる通信の上限として扱わない。

DNSのDKIM TXTレコードには「v=DKIM1; k=rsa; p=…」が登録されている。pのデータはBase64で表現し、受信側が署名検証に利用する。

問題

解説：k=rsaからアルゴリズムを読み取る。誰でも取得できるDNSへ載せるのは検証用の公開鍵であり、署名生成に使う秘密鍵ではない。

正規の送信メールサーバは秘密鍵で署名する。受信側は送信ドメインのDNSから公開鍵を取得して、その署名を検証する。

問題

解説：署名用の鍵に対応する公開鍵で検証するため、送信ドメインが公開した鍵との対応を確認できる。原問がこの後で扱うとおり、同じ正規サーバを使う社内の別利用者まで識別する仕組みとは限らない。

Y社の正規の外向け中継サーバは二台であり、公開IPアドレスは200.a.b.1と200.a.b.2である。Y社ドメインのSPFは、二つのip4項目と、それ以外を許可しない-allで構成する。

問題

解説：受信者から見える送信元のグローバルIPアドレスを登録する。DMZ内部のプライベートIPアドレスを書いても、外部の受信サーバが実際に観測する送信元と一致しない。

サポートメールの送信者はsupport@y-sha.comである。受信側はメール転送プロトコルのエンベロープ送信者を基に、SPFを検索するドメインを取得する。

問題

解説：メール本文の見た目の差出人ではなく、SMTPのMAIL FROMで指定された送信者に着目する。メールアドレスから取り出すのは@より後ろのドメイン部分である。

受信サーバは接続してきたメールサーバの送信元IPアドレスを把握できる。MAIL FROMのドメインについて権威DNSからSPFレコードを取得した。

問題

解説：許可された送信元の一覧と、今回の通信相手のIPアドレスを照合する。SMTPで主張した名前だけを比較する処理ではない。

受信側が、送信元IPアドレスのPTRレコードで得たFQDNと送信者メールアドレスのドメインの一致だけで正当性を判断するとする。攻撃者は自分の送信サーバ用のPTRレコードを管理できる。

問題

解説：攻撃者自身が設定できる逆引き名を根拠にすると、その名前を正当性の証明として扱えない。送信元ドメインの管理者が公開した認証情報とは区別する。

Z社の担当者はsupport@y-sha.comを使い、Z社のメール中継サーバz-mail1から顧客へ送る。Y社ドメインの権威DNSは外部DNSサーバY（y-ns1）である。z-mail1の公開IPアドレスは222.c.d.1である。

問題

解説：認証対象の送信ドメインはY社のままである。そのドメインのDNSに、実際の送信元となるZ社の中継サーバを許可する情報を追加する。

Z社の中継サーバはY社の送信者アドレスのメールに署名する。受信側がY社の外部DNSに登録されたDKIM鍵で検証できるようにする。署名ヘッダーのdタグは署名ドメインを示す。

問題

解説：実際にメールを中継する会社名と、署名に使うドメインは必ずしも同じではない。どのDNSゾーンに検証用レコードを登録したかから判断する。

Y社はセレクターsel.yshaを使う。委託先Z社はsel.zshaという別のセレクターを使い、Y社とは異なる鍵で署名する。両方の公開鍵をY社のDNSに登録する。

問題

解説：一つのドメインでも、セレクターごとに鍵を管理できる。委託先の鍵を交換・失効させる場合も、自社用の鍵を同じ理由で交換する必要をなくせる。

Z社のサポート担当者以外の従業員が、送信者をsupport@y-sha.comにしてメールを送る。正規のサポートメールと同じZ社中継サーバを通り、そのサーバでDKIM署名される構成である。

問題

解説：実際の送信元IPアドレスも署名するサーバも正規メールと同じになる。ドメインの送信経路の認証と、その経路を使う個人の権限確認は区別する。

経路交換を行うインタフェースではOSPFのネイバー認証を使用する。許可していないOSPF機器を経路交換相手にしないことが目的である。

問題

解説：認証の対象は、OSPFの経路交換相手である。不正なルータとの隣接関係が成立すると、そのルータと経路情報を交換する可能性がある。利用者のログイン認証や、転送する業務データの暗号化を答える問題ではない。

UDP上のDTLSサーバがClientHelloに対して大きな応答を直ちに返すとする。攻撃者は応答を自分ではないホストに集中させたい。

問題

解説：サーバはパケットの送信元として示されたIPアドレスへ応答する。そこを攻撃対象に置き換えると、サーバからの応答が攻撃対象へ向かう。攻撃者がサーバの応答を利用する点が要点である。

DTLSサーバはClientHelloを受けるとcookieを含むHelloRetryRequestを返す。クライアントは受け取ったcookieを次のClientHelloに入れる。サーバはcookieを確認してからServerHelloを返す。

問題

解説：正しいcookieを返すには、宛先へ送られたHelloRetryRequestを受信できなければならない。大きな応答を返す前にこの確認を行う。cookieだけで利用者の本人認証まで完了するという意味ではない。

SWGはHTTPSのコンテンツを検査する。PCはエージェント経由でSWGに接続する。SWGを経由したHTTPS通信を信頼させるため、PCへ証明書を事前配布する。

問題

解説：PCがSWGによる検査用の証明書を信頼できるようにする設定である。接続先Webサイトごとの証明書をすべて事前登録するという話ではない。原問が求めるのは、SWGの信頼の起点となる証明書である。

SWGはファイルを隔離環境で実行し、挙動を観察してマルウェアを分析する。対象ファイルに、遠隔操作を受けるマルウェアが含まれていた。

問題

解説：遠隔操作の指示を受ける通信先を答える。隔離環境そのものの名称や、単なるWebサーバという一般名では、マルウェアの役割を表せない。

旧プロキシのフォワード機能を停止し、社外PCから社内サーバへのリバースプロキシとして利用する。既存FWには、①プロキシからインターネットへのTCP/80・443、②内部PCからプロキシへのTCP/10080、③ログ送信、④認証、⑤時刻同期などの許可がある。

問題

解説：不要になるのは、社内PCから外部Webサイトへ中継するための入口と出口である。機器自体はリバースプロキシとして残るので、ログや認証に必要な通信まで一律に削除しない。

社内PCのソフトEはローカルプロキシとして動き、HTTP・HTTPSの通信をSWGのTCP/443へ中継する。PCは内部セグメントに配置されている。

問題

解説：FWから見える接続相手は、最終的なWebサイトではなくSWGである。ソフトEからSWGへの中継通信の仕様を、そのまま通信許可に対応付ける。

K社SaaSはアクセス元をJ社のグローバルIPアドレスだけに制限している。移行後のPC・社外PCはSWGを経由する。SWGはJ社専用の固定グローバルIPアドレスSWG-GIPを送信元として使う。

問題

解説：中継点が変われば、SaaSから観測する送信元も変わる。端末のプライベートIPや社内FWのアドレスではなく、最終的にSaaSへ接続するSWGの送信元を許可する。

PCやブラウザのプロキシ自動検出が有効である。ネットワーク内に悪意のあるDHCPサーバやDNSサーバが存在し、不正なPACの場所を知らせることができる。

問題

解説：PACは通信に使うプロキシを指定する。検出先の情報を攻撃者が変えると、正規のプロキシではない経路へ通信を誘導できる。