今週は、ネットワークセキュリティの「地図」とも言えるOSI参照モデルから始まり、インターネットの根幹を支えるDNS、そしてビジネスの生命線であるメールシステムのセキュリティについて集中的に学習を進めてきました。これらは単独で機能しているわけではなく、相互に依存し合いながら通信を行っています。しかし、その「つながり」の中にこそ、攻撃者が狙う隙、すなわち脆弱性が潜んでいます。
情報処理安全確保支援士試験、特に午後の記述式試験では、「プロトコルの仕様上、なぜその攻撃が成立するのか」という根本的な理解が問われます。単なる用語の暗記ではなく、通信の流れ（シーケンス）の中で脆弱性を特定し、適切な対策を選定できる能力が必要です。「なぜここでこの対策が必要なのか？」を論理的に説明できる力が、合格への鍵となります。
本記事では、第1週で学んだ各要素を「脆弱性と対策」という軸で横断的に整理し直します。知識の点と点をつなぎ合わせ、試験本番で戦える強固な知識体系へと昇華させていきましょう。
ネットワークの階層構造と潜む脅威：見えない場所での攻防
私たちが普段何気なく利用しているインターネット通信は、厳密なルールの積み重ねによって成り立っています。OSI参照モデルやTCP/IPの階層構造は、ネットワークエンジニアだけのものではなく、セキュリティを学ぶ者にとって必須の概念図です。ここでは、階層構造における「セキュリティの死角」を再確認し、攻撃者がどこを狙ってくるのかを深掘りします。
カプセル化とデータの隠蔽性が生むリスク
データが送信される際、アプリケーション層から物理層へと向かって、各層で制御情報（ヘッダ）が付与されていく「カプセル化」が行われます。逆に受信側では、物理層から順にヘッダを外していく「非カプセル化」が行われ、最終的に元のデータが取り出されます。
この仕組みは効率的な通信を実現するために不可欠ですが、セキュリティの観点では「各階層は自分の担当するヘッダしか見ない」という原則が悪用されるケースがあります。
例えば、一般的なルータはネットワーク層（レイヤ3）のデバイスであり、IPヘッダを見てパケットの転送先を決定します。ルータにとって重要なのは「宛先IPアドレス」だけであり、そのパケットの中身（ペイロード）に何が含まれているかは関知しません。たとえペイロード部分に悪意のあるSQLインジェクションのコードや、既知のマルウェアが含まれていたとしても、IPヘッダが正しければルータは素直にパケットを通します。
これが、ファイアウォール（FW）やWAF（Web Application Firewall）、IDS/IPS（侵入検知・防御システム）といった専用の防御装置が必要となる理由です。
各セキュリティ機器の検査範囲は以下の通りです：
- ファイアウォール（FW）: 主に送信元/宛先のIPアドレスとポート番号（レイヤ3, 4）を見て制御します。
- IDS/IPS: パケットの中身（シグネチャ）を検査しますが、暗号化された通信の中身までは見られない場合があります。
- WAF: HTTP/HTTPS通信のアプリケーション層（レイヤ7）の中身まで復号・検査（ディープパケットインスペクション）を行います。
試験では、どの機器がどのレイヤまでを検査できるかを問われることが多々あります。「ルータでウイルスは防げない」「L4ファイアウォールでSQLインジェクションは防げない」という基本原則を、カプセル化の仕組みから視覚的に理解しておくことが重要です。
コネクションレス型通信の悪用とIPスプーフィング
インターネット通信の主要なプロトコルには、TCPとUDPがあります。TCPは「3ウェイハンドシェイク」によって送信元と宛先の間で仮想的な通信路（コネクション）を確立し、信頼性の高い通信を実現します。一方、UDPやIP自体は「コネクションレス」であり、相手の都合はお構いなしにデータを送りつける「送りっぱなし」のプロトコルです。
攻撃者はこの性質を悪用します。代表的な手口が「IPスプーフィング」です。これは、送信元IPアドレスを偽装してパケットを送りつける攻撃です。
TCPの場合、偽装したIPアドレスで通信を開始しようとしても、サーバからの応答（SYN/ACKパケット）が偽装された（本来の）所有者に届いてしまい、そこで通信の不整合が発覚してコネクションが確立されません。そのため、TCPを使った単純なスプーフィングによる接続は成立しにくい側面があります。
しかし、UDPは違います。DNSへの問い合わせなど、UDPを使った通信では、送信元IPアドレスを偽装してリクエストを送ると、サーバはその偽装されたIPアドレスに対して即座に応答（レスポンス）を返します。これを悪用したのが「DNSアンプ攻撃（リフレクション攻撃）」です。
攻撃者は被害者のIPアドレスを送信元に偽装し、オープンリゾルバ（外部からの問い合わせを無制限に受け付けるDNSサーバ）に大量の問い合わせ（ANYレコードなど応答サイズが大きくなるもの）を行います。すると、DNSサーバからの大きな応答パケットが、身に覚えのない被害者の元へ集中砲火のように降り注ぎます。
この対策として、インターネットサービスプロバイダ（ISP）レベルでの「Ingressフィルタリング」が重要視されています。これは、ISPのネットワークの入り口で、そのISPに割り当てられたIPアドレス範囲以外を送信元とするパケットが、顧客側から入ってくるのを遮断する仕組みです。また、企業ネットワークの入り口（受信側）では、インターネット側から来るパケットの送信元が、プライベートIPアドレス（本来インターネット上に存在しないはずのアドレス）であった場合、それをファイアウォールでブロックする設定が必須となります。
ステートフルインスペクションとステートレスの違い
ファイアウォールの動作モードにも、プロトコルの理解が関わってきます。従来の「パケットフィルタリング」は、パケット単位でヘッダを見て通過・遮断を判断する「ステートレス」な方式でした。しかし、これでは「内部から外部への通信に対する戻りのパケット（応答）」を通すために、ハイポート（1024番以降）を広範囲に開放する必要があり、セキュリティ強度が下がります。
これに対し、現在の主流である「ステートフルインスペクション（動的パケットフィルタリング）」は、TCPのコネクション状態（ステート）をファイアウォールが記憶します。内部から外部へ接続要求（SYN）があった場合、そのセッション情報をテーブルに保持し、その通信に対する正当な応答パケット（SYN/ACK、ACK）のみを自動的に通過させます。通信が終了（FIN/ACK）すれば、テーブルから削除され、ポートは再び閉じられます。
これにより、外部から突然送りつけられる不要なパケットを効果的に遮断できます。試験では、ファイアウォールのルール設定において「戻りパケットの明示的な許可が必要か否か」という形で問われることがあります。ステートフルであれば「明示的な許可は不要（自動許可）」となります。
アドレスとポート：通信の「玄関」を守る重要性
ネットワーク上の住所であるIPアドレス、物理的な識別子であるMACアドレス、そしてサービスの窓口であるポート番号。これらは通信を成立させるための基本要素ですが、同時に攻撃者にとっては、ターゲットを特定し、侵入経路を探るための最初の手掛かりとなります。レイヤ2およびレイヤ4における脅威を見ていきましょう。
ARPスプーフィングと中間者攻撃のメカニズム
LAN内（レイヤ2・データリンク層）の世界では、IPアドレスではなくMACアドレスを使って直接通信相手を特定します。「このIPアドレスを持つ端末のMACアドレスは何か？」を問い合わせるプロトコルがARP（Address Resolution Protocol）です。
ARPの動作は非常にシンプルです：
- ARP Request: 「IP: 192.168.1.1 のMACアドレスを教えて！」（ブロードキャスト）
- ARP Reply: 「192.168.1.1 は私です。MACアドレスは AA:BB:CC... です」（ユニキャスト）
ARPは非常にシンプルなプロトコルであり、セキュリティ機能、特に「認証」の仕組みを持っていません。「誰が応答したか」を検証する術がないのです。ここに脆弱性があります。
攻撃者が、同一LAN内で「私はデフォルトゲートウェイ（ルータ）です、私のMACアドレスはこれです」という偽のARP応答（ARPポイズニング）を送信すると、被害者のPCはその情報を疑わずに受け入れ、ARPテーブルを書き換えてしまいます。
その結果、被害者のPCがインターネットへ向けて送信する全てのパケットは、本物のルータではなく、攻撃者の端末へと送られることになります。攻撃者は受け取ったパケットを盗聴・改ざんした上で、本物のルータへ転送すれば、被害者は通信異常に気づきにくくなります。これが「中間者攻撃（MITM：Man-in-the-Middle）」の典型的な手口です。暗号化されていない通信（HTTPやTelnetなど）であれば、IDやパスワードは丸見えになります。
対策としては、スイッチ側で「ダイナミックARPインスペクション（DAI）」などの機能を有効にし、DHCPスヌーピングバインディングデータベースと照合して正規のARPパケット以外を破棄する方法があります。また、サーバなどの重要な機器では、ARPテーブルを動的に学習させず、静的（Static）に設定して書き換えを防ぐという古典的ですが確実な手法も、試験の選択肢として登場します。
ポートスキャンと不要サービスの停止
ポート番号は、サーバという建物にある「ドア」のようなものです。0番から65535番まで存在し、それぞれが特定のアプリケーションやサービスに紐付いています。攻撃者は攻撃の前段階として必ず「ポートスキャン」を行い、どのドアが開いているか（Listen状態か）を確認します。
代表的なスキャン手法に「SYNスキャン（ハーフオープンスキャン）」があります。これはTCPの接続要求（SYN）だけを送り、相手から応答（SYN/ACK）があれば「ポートが開いている」と判断し、直後にRST（リセット）パケットを送って接続を中断するものです。ログに接続完了の記録が残りにくいため、かつてはステルススキャンと呼ばれましたが、現代のIDS/IPSやファイアウォールでは容易に検知されます。
特に注意すべきは「ウェルノウンポート（0-1023番）」の中でも、レガシーなプロトコルです。Telnet（23番）やFTP（20, 21番）は通信経路が暗号化されないため、現代のセキュリティ基準では「原則使用禁止」です。これらが開いていること自体が重大な脆弱性と見なされます。SSH（22番）やSFTP、FTPSといった暗号化対応のプロトコルへの移行が必須です。
SC試験の記述問題において、「セキュリティ対策を答えよ」という問いに対し、「不要なサービスを停止する」「不要なポートをファイアウォールで閉じる」という解答は定石中の定石です。これは「攻撃対象領域（アタックサーフェス）」を最小化するための基本動作です。また、「必要なポートのみを許可する（ホワイトリスト方式）」という考え方も極めて重要です。ブラックリスト方式（悪いものだけ拒否）では、未知の脅威や設定漏れに対応しきれないからです。
DNS：インターネットの電話帳に対する信頼の揺らぎ
今週の学習の中で、試験での重要度が極めて高いのがDNS（Domain Name System）です。ドメイン名とIPアドレスを変換するこのシステムは、インターネットの根幹ですが、その仕組みは複雑であり、信頼関係の隙を突いた攻撃は非常に巧妙です。
DNSキャッシュポイズニングの脅威
私たちがWebサイトを閲覧する際、PCはまず組織内のキャッシュDNSサーバ（フルサービスリゾルバ）に問い合わせを行います。キャッシュサーバは答えを持っていなければ、ルートDNSサーバから順に権威DNSサーバへと問い合わせを繰り返します（反復問い合わせ）。
「DNSキャッシュポイズニング」は、このキャッシュサーバが権威サーバに問い合わせを行っている「待ち時間」を狙った攻撃です。攻撃者は、権威サーバになりすまして、キャッシュサーバに対して偽の応答（ポイズンパケット）を送り込みます。
この攻撃は一種の「早押しクイズ」のようなものです。もし、本物の権威サーバからの応答より早く偽の応答が届き、かつ条件が合致して受け入れられてしまうと、キャッシュサーバには「www.example.com = 攻撃者のIP」という偽の情報が保存（キャッシュ）されます。その結果、その組織内の正規の利用者が正しいURLを入力しても、キャッシュサーバが偽の情報を返すため、自動的にフィッシングサイトやマルウェア配布サイトへ誘導されてしまいます。
この攻撃が成立するためには、以下の要素がキャッシュサーバの期待するものと一致する必要があります：
- トランザクションID: 問い合わせ時に発行される16ビットの識別子
- 宛先ポート番号: 問い合わせに使用した送信元ポート（通常はランダム）
かつては送信元ポート番号が固定されていたり、ランダム性が低かったりしたため、攻撃者はトランザクションID（約65,000通り）を推測するだけで攻撃が可能でした。現在は「ソースポートランダマイゼーション」により、ポート番号もランダム化することで攻撃の難易度を上げていますが、総当たり的な攻撃（カミンスキー攻撃など）により、依然として脅威は去っていません。
DNSSECによる信頼の鎖（Chain of Trust）
キャッシュポイズニングへの根本的な対策として導入が進んでいるのが「DNSSEC（DNS Security Extensions）」です。これはDNSの応答に「デジタル署名」を付加することで、応答の正当性を保証する技術です。通信の暗号化ではなく、あくまで「真正性の証明」である点に注意してください。
DNSSECの仕組みは、公開鍵暗号基盤（PKI）と似ています。権威DNSサーバは、自身が管理するレコード情報（リソースレコードセット）に対して、秘密鍵を使ってデジタル署名（RRSIGレコード）を生成し、応答と一緒に送ります。キャッシュサーバは、権威サーバの公開鍵（DNSKEYレコード）を使って署名を検証します。これにより、「データが改ざんされていないこと」と「正しい権威サーバからの応答であること」を確認できます。
しかし、「その公開鍵が本物であるか」をどうやって保証するかが問題になります。ここで登場するのが「信頼の連鎖（Chain of Trust）」です。下位のゾーン（例：example.co.jp）の公開鍵のハッシュ値（DSレコード）を、上位のゾーン（例：jpドメインのDNS）が署名することで信頼を保証します。これをルートゾーンまで遡ることで、最終的にルートゾーンの信頼（トラストアンカー）に基づき、全てのドメインの信頼性を確認できるのです。
試験では、DNSSECの導入によるメリットだけでなく、デメリットについても問われます：
- 応答パケットサイズが増大するため、DNSアンプ攻撃の踏み台にされた際の被害が大きくなる
- IPフラグメンテーション（パケット分割）が発生しやすくなり、一部のファイアウォールで遮断される可能性がある
- 運用管理（鍵の更新など）が複雑になる
これらを理解した上で、導入の是非を判断する視点が必要です。
DNS関連の攻撃手法とその対策
DNSキャッシュポイズニング以外にも、DNSを標的とした攻撃は多数存在します。それぞれの攻撃手法と対策を整理しておきましょう。
DNSアンプ攻撃（リフレクション攻撃）は、前述のIPスプーフィングと組み合わせた攻撃です。攻撃者は送信元IPアドレスを被害者のものに偽装し、オープンリゾルバに対して応答サイズの大きいクエリ（ANYレコードなど）を送信します。その結果、被害者には大量の応答パケットが集中し、DDoS攻撃となります。
この対策として、DNSサーバ側では以下の設定が有効です：
- 外部からの再帰的な問い合わせを制限する（オープンリゾルバ化を防ぐ）
- レートリミット機能を有効にし、同一送信元からの大量クエリを制限する
- ANYクエリに対する応答を制限する
ランダムサブドメイン攻撃は、存在しないランダムなサブドメイン名を大量に生成してキャッシュサーバに問い合わせる攻撃です。キャッシュにヒットしないため、権威サーバへの問い合わせが大量に発生し、両方のサーバに負荷がかかります。対策としては、同一ドメインへの大量の問い合わせを検知するIDS/IPSの導入や、レートリミット機能の活用が挙げられます。
DNSトンネリングは、DNSの問い合わせと応答を使ってデータを不正に外部送信する手法です。多くのファイアウォールがDNS通信（UDP 53番ポート）を通すことを利用し、マルウェアがC&Cサーバと通信するために使われます。対策としては、DNSトラフィックの異常を検知するセキュリティ製品の導入や、信頼できるDNSサーバ以外への通信をブロックすることが効果的です。
メールセキュリティ：なりすましを防ぐ「3つの盾」
メールシステムは、インターネットの黎明期に設計されたものであり、当初は「性善説」に基づいて作られていました。そのため、送信元の詐称が非常に容易であるという構造的な欠陥を持っています。これを補うために開発されたのが、SPF、DKIM、DMARCという3つの送信ドメイン認証技術です。これらは現在、Google（Gmail）などがガイドラインで対応を強く求めていることもあり、実務・試験ともに必須の知識です。
SPF（Sender Policy Framework）：IPアドレスによる検証
SPFは、DNSのTXTレコードを利用して、「このドメインのメールを送ってもよい正規のIPアドレス」を宣言する仕組みです。
送信側は、自ドメインのDNSに「v=spf1 ip4:192.0.2.1 include:_spf.google.com -all」のように、メール送信を許可するIPアドレスリストを登録します。受信側は、メールを受信した際、その通信の送信元IPアドレスと、メールの封筒上の送信元（Envelope-From）ドメインのSPFレコードを照合します。リストに含まれていれば認証成功（Pass）です。
SPFの弱点は、メーリングリストや転送サービスを経由する場合にあります。送信元IPアドレスが転送サーバのものに変わってしまうため、本来は正規のメールであっても、SPF認証に失敗（Fail）してしまう可能性があります。この問題は、次に説明するDKIMと組み合わせることで解決できます。
DKIM（DomainKeys Identified Mail）：電子署名による検証
DKIMは、メール自体に電子署名を付与することで、「送信元の正当性」と「メール本文が改ざんされていないこと」を証明します。
送信側は、メールヘッダや本文のハッシュ値を計算し、秘密鍵で暗号化（署名作成）します。この署名を「DKIM-Signature」ヘッダとしてメールに付与します。受信側は、メールヘッダに含まれる「セレクタ」という情報を元に、送信元ドメインのDNSから公開鍵を取得します。その公開鍵で署名を検証できれば、メールが途中で改ざんされていないことが証明されます。
DKIMのメリットは、メールデータ自体に署名が付いているため、途中で転送サーバを経由してIPアドレスが変わったとしても、署名自体が壊れなければ認証は成功する点です。これにより、SPFの弱点を補完することができます。
DMARC：ポリシーとレポートによる統制
SPFやDKIMだけでは、認証に失敗したメールを「受信側がどう扱えばいいか」までは指示できません。また、メールソフトで表示される送信元（Header-From）と、認証に使ったドメイン（Envelope-From）が異なる「なりすまし」を防げないケースもあります。これらを解決するのがDMARCです。
DMARCでは、送信側が認証失敗時の扱いをDNSで宣言します：
- p=none: 何もしない（監視モード）。まずはここから始めて、届くはずのメールが認証失敗していないかレポートを確認します
- p=quarantine: 迷惑メールフォルダへ隔離するなど、疑わしい扱いをします
- p=reject: 受信を拒否します。最も強力な設定です
DMARCのもう一つの重要な機能が「アライメント確認」です。SPFやDKIMで認証されたドメインと、メールヘッダ上の送信者（Header-From）のドメインが一致しているか（作成者署名であるか）を確認します。これにより、第三者が勝手に取得したドメインでSPFをパスさせて、Header-Fromだけ有名企業に見せかけるといった高度ななりすましを排除できます。
試験では、「SPFとDKIMを導入済みだが、それでもフィッシングメール被害が減らない理由」として、このアライメント（一致）の欠如や、DMARCポリシーの設定不備が問われることがあります。
メールセキュリティにおけるその他の重要技術
送信ドメイン認証以外にも、メールセキュリティには重要な技術が存在します。
S/MIME（Secure/Multipurpose Internet Mail Extensions）は、メール本文そのものを暗号化し、さらにデジタル署名を付与する技術です。SPF/DKIM/DMARCが「送信経路の認証」であるのに対し、S/MIMEは「メール内容の暗号化と署名」という違いがあります。PKI（公開鍵基盤）を利用するため、事前に証明書の交換が必要であり、導入のハードルは高いものの、機密性の高い情報をやり取りする際には不可欠です。
PGP（Pretty Good Privacy）も、S/MIMEと同様にメール暗号化技術ですが、より個人向けで分散型の信頼モデル（Web of Trust）を採用しています。企業での利用はS/MIMEが主流ですが、技術者コミュニティではPGPも広く使われています。
オープンリレー対策も重要です。かつてのメールサーバは、誰からでもメールの転送（リレー）を受け付ける設定になっていることがあり、これがスパムメールの大量配信に悪用されました。現在では、認証（SMTP-AUTH）を必須とし、正規ユーザー以外からのリレーを拒否する設定が標準となっています。試験では、「オープンリレーの危険性」と「SMTP-AUTHによる対策」がセットで問われることがあります。
メール関連のポート番号とプロトコル
メールに関連する主要なポート番号とプロトコルを整理しておきましょう。これらは試験で頻出です：
- SMTP（Simple Mail Transfer Protocol）: メール送信用プロトコル。ポート25番（非暗号化）、ポート587番（STARTTLS対応）
- POP3（Post Office Protocol version 3）: メール受信用プロトコル。ポート110番（非暗号化）、ポート995番（SSL/TLS対応）
- IMAP4（Internet Message Access Protocol version 4）: メール受信用プロトコル。ポート143番（非暗号化）、ポート993番（SSL/TLS対応）
現代では、非暗号化のポート（25, 110, 143）は原則使用すべきではなく、暗号化対応のポートまたはSTARTTLS（平文で接続開始後に暗号化へ移行）を使用することが推奨されます。特にポート25番は、ISPによってブロックされるケースが増えており、代わりにサブミッションポート（587番）の使用が標準となっています。
TCP/IPの深層：プロトコルの隙間を突く攻撃
ネットワーク通信の基盤であるTCP/IPプロトコル自体にも、設計上の脆弱性が存在します。これらは「プロトコルの仕様」に起因するため、個別のソフトウェアやハードウェアの問題ではなく、根本的な理解と対策が必要です。
TCPシーケンス番号予測攻撃
TCPの3ウェイハンドシェイクでは、初期シーケンス番号（ISN）を使って通信の順序を管理します。この番号が予測可能であった場合、攻撃者は正規のクライアントになりすまして通信を乗っ取ることができます。
かつては、シーケンス番号が単純な規則（タイムスタンプベースなど）で生成されていたため、攻撃者が次の番号を予測し、正規ユーザーのセッションを乗っ取る「TCPセッションハイジャック」が可能でした。現在では、ランダムなISNを生成する実装が標準となり、攻撃の難易度は大幅に上がっています。
しかし、試験では「古い実装のシステムにおける脆弱性」として、この攻撃が問われることがあります。対策としては、システムやライブラリを最新に保つこと、またアプリケーション層での認証を併用することが重要です。
SYNフラッド攻撃とその対策
SYNフラッド攻撃は、TCPの3ウェイハンドシェイクの仕組みを悪用したDoS攻撃です。攻撃者は大量のSYNパケットを送りつけますが、最後のACKパケットを送らずに接続を放置します。サーバ側は「半開き（Half-Open）」状態のコネクションを大量に抱え込み、リソースが枯渇してしまいます。
対策としては、以下のような技術が実装されています：
- SYN Cookies: 半開き状態のコネクション情報をメモリに保持せず、応答パケット内に暗号化して埋め込む技術。これにより、メモリ消費を抑制できます
- 接続タイムアウトの短縮: 半開き状態のコネクションを早期に破棄することで、リソース枯渇を防ぎます
- ファイアウォールやIPS/IDSでの検知: 同一送信元からの大量のSYNパケットを検知し、遮断します
試験では、「SYN Cookiesの仕組み」や「なぜ従来の方法ではメモリが枯渇するのか」といった原理の理解が問われます。
ICMPリダイレクト攻撃
ICMP（Internet Control Message Protocol）は、ネットワークの診断や制御に使われるプロトコルです。pingコマンドで使われることで有名ですが、その機能の一つに「ICMPリダイレクト」があります。これは、ルータが「もっと効率的な経路があるよ」と端末に教えるメッセージです。
攻撃者がこのICMPリダイレクトメッセージを偽造して送ると、被害者の端末のルーティングテーブルが書き換えられ、通信が攻撃者の用意したルータを経由するようになります。これにより、中間者攻撃や通信の傍受が可能になります。
対策としては、不要なICMPリダイレクトメッセージを無視する設定（OSレベルの設定やファイアウォールでの遮断）が有効です。また、重要なシステムでは、静的ルーティングテーブルを使用し、動的な変更を受け付けないようにすることも検討されます。
防御の多層化：Defense in Depth戦略
ここまで見てきた通り、ネットワーク上の脅威は単一のレイヤや単一のプロトコルに限定されません。攻撃者は複数の脆弱性を組み合わせて攻撃を仕掛けてきます。そのため、防御側も単一の対策に頼るのではなく、「多層防御（Defense in Depth）」の考え方が重要です。
レイヤごとの防御策
各レイヤにおける代表的な防御策を整理しておきましょう：
レイヤ2（データリンク層）
- VLANによるネットワーク分割
- ポートセキュリティ機能の有効化（許可されたMACアドレスのみ接続可能）
- ダイナミックARPインスペクション（DAI）
- DHCPスヌーピング
レイヤ3（ネットワーク層）
- ファイアウォールによるIPアドレスフィルタリング
- Ingressフィルタリング/Egressフィルタリング
- アンチスプーフィング設定
- IPsec VPNによる暗号化
レイヤ4（トランスポート層）
- ステートフルファイアウォールによるポートフィルタリング
- SYN Cookie等のDoS対策
- 不要なサービス・ポートの停止
レイヤ7（アプリケーション層）
- WAFによるWebアプリケーション保護
- IDS/IPSによるシグネチャ検知
- アンチウイルスソフトウェア
- アプリケーション層での認証・認可
ネットワークセグメンテーション
ネットワークを論理的または物理的に分割し、異なるセキュリティレベルのゾーンを設けることも重要です。代表的なセグメント構成は以下の通りです：
インターネットゾーン
最も信頼度の低いゾーン。ここからの通信は厳しく制限されます。
DMZ（DeMilitarized Zone：非武装地帯）
公開サーバ（Webサーバ、メールサーバ、DNSサーバなど）を配置するゾーン。インターネットと内部ネットワークの中間に位置し、両方向からファイアウォールで保護されます。DMZのサーバが侵害されても、内部ネットワークへの影響を最小限に抑える設計です。
内部ネットワーク（イントラネット）
業務用端末やファイルサーバなど、組織内部のリソースが配置されるゾーン。最も保護されるべき領域です。
管理ネットワーク
サーバやネットワーク機器の管理用インターフェースを配置する専用ネットワーク。通常の業務ネットワークから物理的または論理的に分離し、限られた管理者のみがアクセスできるようにします。
試験では、ネットワーク構成図を見て「このサーバはどのゾーンに配置すべきか」「ファイアウォールのルールはどう設定すべきか」といった実践的な問題が出題されます。各ゾーンの役割と、ゾーン間の通信制御ポリシーを理解しておくことが重要です。
ログ分析とインシデント検知
セキュリティ対策を実装するだけでなく、「異常を検知する」能力も試験では問われます。各種ログの読み方と、そこから攻撃の兆候を見つけ出すスキルを身につけましょう。
ファイアウォールログの読み方
ファイアウォールのログには、通過を許可したパケット（Accept/Allow）と、遮断したパケット（Deny/Drop/Reject）の記録が残ります。試験でよく出題されるのは「Denyログ」の分析です。
典型的なファイアウォールログには、以下の情報が含まれます：
- タイムスタンプ（日時）
- アクション（Accept/Deny）
- 送信元IPアドレスとポート番号
- 宛先IPアドレスとポート番号
- プロトコル（TCP/UDP/ICMP）
- パケット数やバイト数
ログ分析のポイントは、「パターンの発見」です。例えば、同一送信元から連続する異なるポート番号への接続試行があれば、それは「ポートスキャン」の痕跡です。また、プライベートIPアドレスが送信元として外部から届いていれば、それは明らかに「IPスプーフィング」です。
DNSログの異常検知
DNSサーバのログからは、以下のような攻撃の兆候を検知できます：
- 大量の同一ドメインへの問い合わせ: DDoS攻撃の準備段階
- 存在しないランダムなサブドメインへの大量問い合わせ: ランダムサブドメイン攻撃
- 異常に長いドメイン名や、奇妙な文字列を含むドメイン: DNSトンネリングの可能性
- 短時間での大量のANYクエリ: DNSアンプ攻撃の踏み台として利用されている可能性
試験では、実際のログの抜粋が示され、「この現象は何という攻撃か」「どのような対策が有効か」といった問題が出題されます。
メールサーバログとSPF/DKIM/DMARC認証結果
メールサーバのログには、送信ドメイン認証の結果が記録されます。以下のような情報に注目しましょう：
- SPF結果: Pass/Fail/SoftFail/Neutral/None
- DKIM結果: Pass/Fail/None
- DMARC結果: Pass/Fail
- アライメント状況: Header-FromとEnvelope-From（またはDKIM署名ドメイン)の一致
認証が全て失敗しているメールは、明らかに偽装メールである可能性が高く、隔離または拒否の対象となります。ただし、正規のメールでも設定不備や転送の影響で認証に失敗することがあるため、DMARCの「p=none」モードで監視期間を設け、レポートを確認してから厳格なポリシー（quarantine/reject）に移行することが実務では推奨されます。
まとめ：プロトコルの理解がセキュリティの基礎
今週は、ネットワークの基礎となるプロトコルとその脆弱性について、かなり深い部分まで掘り下げて復習しました。
TCP/IPとOSI参照モデルでは、カプセル化による「見えない」リスクと、レイヤごとの防御策の必要性を学びました。各セキュリティ機器がどのレイヤまで検査できるかを理解することが、適切な防御設計の第一歩です。
アドレス管理においては、ARPスプーフィングによる盗聴リスクと、スイッチ側での対策（DAI、ポートセキュリティ）の重要性を確認しました。レイヤ2の脅威は見落とされがちですが、内部ネットワークでの攻撃に直結する重大な問題です。
DNSでは、キャッシュポイズニングの原理と、DNSSECによる信頼の連鎖（Chain of Trust）を詳しく見てきました。DNSは名前解決という重要な役割を担っているだけに、その信頼性が損なわれた場合の影響は甚大です。DNSアンプ攻撃やランダムサブドメイン攻撃など、DNS特有の攻撃手法も押さえておきましょう。
メールセキュリティでは、SPF/DKIM/DMARCの3点セットによる、なりすましメールの排除とドメイン認証の完全性を学びました。それぞれの技術が持つ強みと弱点を理解し、組み合わせて使うことで初めて効果を発揮することを忘れないでください。
TCP/IPの深層では、シーケンス番号予測攻撃やSYNフラッド攻撃など、プロトコルの仕様に起因する脆弱性を見てきました。これらは「仕様上の問題」であるため、根本的な対策が難しく、複数の防御策を組み合わせる必要があります。
そして最も重要なのは、「多層防御（Defense in Depth）」の考え方です。単一の防御策に頼るのではなく、各レイヤで適切な対策を重ね、万が一一つの防御が突破されても、次の層で防御できる体制を構築することが、現代のセキュリティの基本です。
これらの技術は、単独で存在する知識ではなく、セキュリティインシデント（事故）が発生した際の「原因究明」や「対策立案」の土台となるものです。セキュリティ製品の設定一つをとっても、「なぜこの設定が必要なのか」という理由は、すべてこれらのプロトコルの仕様に起因しています。
試験勉強を進める中で、もし解説を読んでも理解できない部分が出てきたら、必ずこの「プロトコルの仕組み」に立ち返ってください。「どうやって通信しているか」が分かれば、必然的に「どこが弱点か（脆弱性）」が見え、そこから「どう守るべきか（対策）」も論理的に導き出せるようになります。
来週は、いよいよこれらのプロトコルを守るための具体的な「防御技術」に入ります。ファイアウォールの詳細なフィルタリングルール、IDS/IPSによる検知の仕組み、そしてWebアプリケーションを守るWAFなど、より実践的なセキュリティ技術を学んでいきます。今週学んだ「攻撃者の視点」を持っている皆さんなら、防御側の理屈もスムーズに理解できるはずです。基礎固めは順調です。この調子で、合格へ向けて一歩ずつ着実に進んでいきましょう。