ネットワーク・通信基盤のセキュリティ
この章の到達目標
システム構成図、通信要件、FWの設定表、DNSレコード、ログを読み取り、攻撃経路の特定と、正確な設定変更 を記述できるようにする。
ネットワークは補助的な分野ではなく、独立した大問として繰り返し出ている。
| 年度 | ネットワーク関連の論点 |
|---|---|
| 2023 | 無線LAN、EAP-TLS、RADIUS、ネットワーク分離 |
| 2024 | VPN、認証、DDoS、CDN/SPF、DKIM、DMARC、メールドメインの移行 |
| 2025 | DNSレコード、公開IT資産の管理/DNSSEC、DoH、VPN、接続元IPアドレスの制限 |
特に、VPN導入時の通信要件からFWの許可ルールを導くような問題では、用語の知識ではなく 通信経路・制御点・許可すべき通信を設計する力 が問われる。IPAの対象者像にも、ネットワーク・暗号・認証・フィルタリング・ロギングなどの要素技術を適用できることが明記されている。
1. 用語一覧
| 優先 | 用語・技術 | 科目Bで解けるようにすること |
|---|---|---|
| A | TCP/IP、TCP・UDP | ヘッダー、ポート、通信の成立条件 |
| A | IPアドレス、サブネット | 通信元・通信先と経路の特定 |
| A | ルーティング、NAT/NAPT | アドレス変換前後の通信経路 |
| A | ステートフルFW、ACL | 許可・拒否ルールの設計 |
| A | DNS、権威DNS、キャッシュDNS | 名前解決の経路とDNS設定 |
| A | DNSSEC、DoH、DoT | DNS応答の真正性と通信の暗号化 |
| A | DNSキャッシュポイズニング | 偽応答の成立条件と対策 |
| A | TLS 1.2 / 1.3 | ハンドシェイク、証明書、鍵交換 |
| A | IPsec、IKE、ESP | トランスポートモード・トンネルモード |
| A | VPN、ZTNA | リモートアクセスの認証・通信制御 |
| A | SPF、DKIM、DMARC | メール送信ドメイン認証の成立条件 |
| A | リバースプロキシ、WAF | 通信経路と検査・防御の位置 |
| B | VLAN、ネットワーク分離 | セグメント間の通信制限 |
| B | IEEE 802.1X、EAP-TLS | 端末認証、RADIUS、証明書(sc_3) |
| B | ARPスプーフィング | MACアドレスの偽装、中間者攻撃 |
| B | DHCPスプーフィング | 不正なネットワーク設定の配布 |
| B | IDS / IPS、NDR | ネットワーク上の異常検知 |
| B | DDoS、DRDoS | 攻撃経路、増幅攻撃、CDNによる緩和 |
| B | HTTP/2、HTTP/3、QUIC | 通信の違いとプロキシでの制御 |
| B | DNSリバインディング | ブラウザーを介した内部システムへのアクセス |
| B | プロキシ、SWG、SASE | 外向き通信の検査と統制 |
| B | SMTP、STARTTLS、SMTPS | メール配送・送信時の暗号化 |
| B | MTA-STS、DANE、S/MIME | メール通信とメッセージの保護 |
| B | パケットキャプチャ、NetFlow | 通信ログからの調査 |
| B | ルーティングの冗長化、VRRP | 障害時の切替えと可用性 |
| C | BGPハイジャック、RPKI | 経路広告の偽装と検証 |
| C | QUICの通信制御 | UDPベースの通信に対する監視・制限 |
2. 通信の基本と「誰から誰への通信か」
2.1 ポートとプロトコル(暗記必須)
| ポート | プロトコル | 用途 |
|---|---|---|
| 22/TCP | SSH | リモート管理 |
| 25/TCP | SMTP | MTA間のメール配送 |
| 53/UDP・TCP | DNS | 名前解決(大きな応答やゾーン転送はTCP) |
| 80/TCP | HTTP | |
| 123/UDP | NTP | 時刻同期 |
| 389 / 636/TCP | LDAP / LDAPS | ディレクトリ |
| 443/TCP、443/UDP | HTTPS、HTTP/3(QUIC) | |
| 445/TCP | SMB | ファイル共有(横展開でよく使われる) |
| 465/TCP | SMTPS | メール送信(暗号化) |
| 500・4500/UDP | IKE、NAT越えのIPsec | VPN |
| 587/TCP | Submission | メールクライアントからの送信 |
| 853/TCP | DoT | DNS over TLS |
| 1812・1813/UDP | RADIUS | 認証・アカウンティング |
| 3389/TCP | RDP | リモートデスクトップ |
2.2 NAT/NAPTと送信元の見え方
- NAPTの後ろにある端末からの通信は、外部からは NAT装置のグローバルIPアドレス に見える。接続元IPアドレスで制限するとき、どのアドレスを許可すればよいかを問う問題が多い。
- リバースプロキシやCDNを経由すると、Webサーバから見た送信元は プロキシのアドレス になる。本来の送信元は
X-Forwarded-Forなどのヘッダーで渡されるが、このヘッダーは偽装できるので、信頼できるプロキシが付けたものだけを使う。 - 接続元IPアドレスによる制限を、CDNを経由しない直接アクセス(オリジンサーバへの直接接続)で回避される問題にも注意する。
2.3 ステートフルFWのルール設計
ステートフルFWは、許可した通信の 戻りの通信 を自動で通す。したがって、ルールは 通信を開始する側から 書く。
例題:社外の利用者がVPN装置を経由して社内のファイルサーバを使う。VPN装置はDMZにある。
| No. | 送信元 | 宛先 | サービス | 動作 |
|---|---|---|---|---|
| 1 | any(インターネット) | VPN装置 | 443/TCP(SSL-VPN)または 500・4500/UDP(IPsec) | 許可 |
| 2 | VPNのアドレスプール | ファイルサーバ | 445/TCP | 許可 |
| 3 | VPN装置 | 認証サーバ(RADIUS) | 1812/UDP | 許可 |
| 4 | any | any | any | 拒否 |
答案のポイント:
- 「VPNの利用者に割り当てられるアドレス」と「VPN装置自身のアドレス」を区別する。
- 認証、DNS、NTP、ログ転送など、装置自身が行う通信 を見落とさない。
- 必要以上に広い許可(宛先がany、サービスがanyなど)がないかを確認する。
- ルールは上から順に評価される。拒否ルールより後ろの許可ルールは効かない。
3. DNS
3.1 名前解決の経路
端末 → キャッシュDNSサーバ(フルリゾルバー) → ルート → TLD → 権威DNSサーバ
| 種類 | 役割 | 設定上の注意 |
|---|---|---|
| キャッシュDNSサーバ | 端末の代わりに問い合わせ、結果をキャッシュする | 社内からの問合せだけに応答する(オープンリゾルバーにしない) |
| 権威DNSサーバ | 自ドメインの情報を回答する | 再帰問合せを受け付けない。ゾーン転送をセカンダリだけに限定する |
キャッシュと権威を 同じサーバで兼用しない ことが基本。
3.2 主なレコード
| レコード | 内容 |
|---|---|
| A / AAAA | IPv4 / IPv6アドレス |
| CNAME | 別名(参照先のホスト名) |
| MX | メールの受信サーバ |
| TXT | SPF、DMARC、ドメインの所有確認など |
| NS | 権威DNSサーバ |
| SOA | ゾーンの管理情報 |
| PTR | 逆引き |
| CAA | 証明書を発行してよいCA |
| DS / DNSKEY / RRSIG | DNSSEC |
3.3 公開IT資産とDNSの管理(2025年度関連)
- サブドメインテイクオーバー:CNAMEの参照先(クラウドのサービスなど)を解約した後もDNSレコードを残していると、第三者が同じ名前でサービスを作成し、自社のサブドメインでコンテンツを公開できる。サービスの廃止時にDNSレコードも削除する。
- 公開しているホスト名・IPアドレスの棚卸しを行い、管理されていない資産(シャドーIT、検証用サーバ)を見つける。攻撃者から見える範囲を把握する考え方をASM(Attack Surface Management)という。
- ドメイン名の有効期限切れ、レジストラアカウントの乗っ取りも、ドメインを失うリスクになる。
3.4 DNSキャッシュポイズニング
キャッシュDNSサーバに偽の応答を受け入れさせ、利用者を偽のサーバに誘導する。
成立条件:攻撃者が、正規の応答より先に、問合せと一致する偽の応答(送信元ポート番号、トランザクションIDが一致)を届けること。
| 対策 | 効果 |
|---|---|
| 送信元ポート番号のランダム化 | 推測が必要な組合せを増やす |
| オープンリゾルバーにしない | 攻撃者が任意のタイミングで問合せを発生させにくくする |
| DNSSEC | 応答の署名を検証し、偽の応答を検出する(根本対策) |
3.5 DNSSEC・DoH・DoT の違い
| 技術 | 守るもの | 守らないもの |
|---|---|---|
| DNSSEC | 応答の 真正性・完全性(権威DNSサーバのデータが改ざんされていない) | 通信の機密性(内容は平文) |
| DoT(853/TCP) | 端末とキャッシュDNSサーバ間の 機密性 | キャッシュDNSサーバより上流の真正性 |
| DoH(443/TCP) | 同上。HTTPSに紛れる | 同上 |
- DNSSECの検証は キャッシュDNSサーバ が行う。権威DNSサーバ側はゾーンに署名する。
- 信頼の連鎖:親ゾーンのDSレコードが、子ゾーンのDNSKEYのハッシュ値を持つ。鍵を更新するときは、親ゾーンのDSレコードも更新が必要(手順を誤ると名前解決ができなくなる)。
- DoHの組織への影響:ブラウザーがDoHで外部のDNSサービスを直接使うと、社内のキャッシュDNSサーバを経由しなくなり、DNSによるフィルタリングや監視、社内向けの名前解決が機能しなくなる。ブラウザーの設定(ポリシー)で無効にする、許可したDoHサーバ以外への通信を制限する、などの対応が問われる。
3.6 DNSリバインディング
攻撃者のドメインの名前解決の結果を、短いTTLで外部のアドレスから内部のアドレスに切り替える。ブラウザーは同じオリジンとみなすため、攻撃者のページのスクリプトから内部のサーバにアクセスできてしまう。対策は、内部サーバで Host ヘッダーを検証する、内部サービスにも認証を設ける、キャッシュDNSサーバで外部ドメインがプライベートアドレスを返す応答を破棄する、など。
4. TLS
4.1 TLS 1.3 のハンドシェイク(概要)
- ClientHello:対応する暗号スイート、鍵共有のパラメータ(ECDHE)、SNI
- ServerHello:選択した暗号スイート、鍵共有のパラメータ
- 以降は暗号化:サーバ証明書、CertificateVerify(サーバの秘密鍵による署名)、Finished
| 項目 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| ハンドシェイク | 2往復 | 1往復(再開時は0-RTTも可) |
| 鍵交換 | RSA鍵交換も可 | (EC)DHEのみ(前方秘匿性が必須) |
| 暗号 | CBCモードなども可 | AEAD(AES-GCM、ChaCha20-Poly1305)のみ |
| 証明書 | 平文で送信 | 暗号化して送信 |
前方秘匿性:通信のたびに使い捨ての鍵を交換するため、後でサーバの秘密鍵が漏えいしても、過去に記録された通信は復号できない。
0-RTT:再送(リプレイ)される可能性があるため、状態を変更するリクエストには使わない。
4.2 TLSインスペクション
プロキシが通信を一度復号して検査する。端末にプロキシのCA証明書をインストールする必要がある。証明書のピン留めをしているアプリは通信できなくなる、プロキシ自体が高価値の攻撃対象になる、などの考慮点がある。
5. VPNとZTNA
5.1 IPsec
| 要素 | 役割 |
|---|---|
| IKE(IKEv2) | 相互認証と鍵交換、SAの確立 |
| ESP | 暗号化と完全性の保護 |
| AH | 完全性の保護のみ(暗号化しない、NATと相性が悪い) |
| モード | 暗号化する範囲 | 用途 |
|---|---|---|
| トランスポートモード | IPのペイロードのみ | 端末間 |
| トンネルモード | 元のIPパケット全体を新しいIPヘッダーでカプセル化 | 拠点間VPN、リモートアクセス |
NATを越える場合は、ESPをUDP 4500でカプセル化する(NATトラバーサル)。
5.2 リモートアクセスVPNの論点
- VPN装置の脆弱性 は、ランサムウェアの初期侵入経路として非常に多い。インターネットに公開している装置は、脆弱性情報の収集と迅速なパッチ適用の最優先対象である。
- 認証:ID・パスワードだけにせず、MFAや端末証明書を組み合わせる。
- 接続後のアクセス範囲:VPNに接続すると社内ネットワーク全体に到達できる設計は、侵入後の横展開を容易にする。接続後に到達できる宛先をFWで制限する。
- スプリットトンネル:社内向けの通信だけVPNを通す。インターネット向けの通信は社内の監視・フィルタリングを通らなくなる。
- 接続元IPアドレスによる制限:委託先など、接続元が固定されている場合に有効。
5.3 ZTNA
ネットワークへの接続ではなく、アプリケーション単位 で、利用者と端末の状態を検証したうえで接続を許可する。VPNと違い、接続しても他のサーバは見えない。
6. メールのセキュリティ
6.1 送信ドメイン認証
| 技術 | 検証するもの | DNSに登録するもの |
|---|---|---|
| SPF | エンベロープFrom(MAIL FROM)のドメインに対して、送信元のIPアドレスが許可されているか | 送信を許可するIPアドレス(TXTレコード) |
| DKIM | 署名ドメイン(d=)の公開鍵で、ヘッダーと本文の署名を検証 | 公開鍵(セレクター._domainkey.ドメイン のTXTレコード) |
| DMARC | SPFまたはDKIMが成功し、そのドメインがヘッダーFromと 一致(アライメント) するか | ポリシー(_dmarc.ドメイン のTXTレコード) |
なぜDMARCが必要か:SPFとDKIMはヘッダーFrom(利用者がメールソフトで見る送信者)を検証しない。攻撃者が自分のドメインでSPFを成功させつつ、ヘッダーFromを詐称できる。DMARCはアライメントによってこれを防ぐ。
_dmarc.example.jp. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-report@example.jp"
p= | 認証失敗時の扱い |
|---|---|
none | 何もしない(監視のみ)。まずレポートで状況を把握する |
quarantine | 隔離(迷惑メールフォルダーなど) |
reject | 受信拒否 |
6.2 よく問われる設定上の問題
- メール配信サービスや外部のシステムからの送信:SPFにそのサービスを追加し、DKIMの署名を自社ドメインで行わないと、DMARCが失敗する。
- 転送:転送サーバのIPアドレスはSPFで許可されていないため、SPFが失敗する。DKIMは本文が変更されなければ維持されるので、DMARCを成功させるにはDKIMが重要。
- SPFのDNS参照回数:
includeなどによるDNSの参照は10回までに制限されている。超えるとエラー(permerror)になる。 - メールドメインの移行(2024年度関連):新旧のドメインのSPF・DKIM・DMARCを並行して設定する。旧ドメインを手放すと第三者に取得され、なりすましに使われる危険がある。
- メールを送信しないドメインにも、SPF(
v=spf1 -all)とDMARC(p=reject)を設定し、なりすましを防ぐ。
6.3 通信の暗号化
| 技術 | 内容 |
|---|---|
| STARTTLS | 平文で接続してからTLSに切り替える。切替えの指示を消されると平文のまま送られる(ダウングレード) |
| SMTPS(465) | 最初からTLSで接続する |
| MTA-STS | 受信側がHTTPSで「TLSが必須」というポリシーを公開し、ダウングレードを防ぐ |
| DANE | DNSSECで保護されたTLSAレコードで、受信サーバの証明書を指定する |
| S/MIME | メッセージそのものへの署名と暗号化(エンドツーエンド) |
6.4 BEC・標的型メール
- BEC(ビジネスメール詐欺):取引先や経営者になりすまし、振込先の変更などを指示する。類似ドメインや、乗っ取った正規のアカウントから送られると、送信ドメイン認証では防げない。
- 対策:振込先の変更などは、メール以外の方法(登録済みの電話番号など)で確認する手順を定める。
- メールヘッダーの分析:
Receivedヘッダーは下から上に辿ると経路の順になる。Authentication-Resultsで受信サーバによるSPF・DKIM・DMARCの判定結果を確認する。
7. LAN内の攻撃と分離
| 攻撃 | 仕組み | 対策 |
|---|---|---|
| ARPスプーフィング | 偽のARP応答で、通信先のMACアドレスを攻撃者の端末に書き換える | Dynamic ARP Inspection、静的ARP、暗号化通信 |
| DHCPスプーフィング | 偽のDHCPサーバが、偽のデフォルトゲートウェイやDNSサーバを配布する | DHCPスヌーピング(信頼するポート以外からのDHCP応答を遮断) |
| 不正な端末の接続 | 社内のLANポートや無線LANに接続する | 802.1X認証、未使用ポートの無効化 |
ネットワーク分離:VLANやFWでセグメントを分け、セグメント間の通信を必要なものだけに限定する。サーバ管理用、利用者端末、OT(工場の制御系)、来訪者用を分けるのが典型。分離しても、セグメント間で許可している通信(管理用のRDP、ファイル共有)が横展開の経路になることに注意する。
8. 境界での検査と可用性
8.1 検査の位置
| 機器 | 検査する通信 | 位置 |
|---|---|---|
| FW | IPアドレス・ポート・状態 | 境界、セグメント間 |
| IDS / IPS | 通信の内容(シグネチャ、異常) | IDSは監視(ミラーポート)、IPSは経路上(インライン) |
| WAF | HTTPの内容 | Webサーバの前 |
| リバースプロキシ | 外部から内部への通信の中継 | DMZ |
| フォワードプロキシ、SWG | 内部から外部への通信 | 利用者端末と外部の間 |
| NDR | ネットワーク全体の通信の振る舞い | 内部ネットワーク |
| SASE | SWG、CASB、ZTNA、FWをクラウドで統合 | クラウド |
暗号化された通信は、復号しなければ内容を検査できない。検査機器を TLSを終端する位置の後ろ に置くか、TLSインスペクションを行う必要がある。
HTTP/3(QUIC):UDP 443を使い、通信の大部分が暗号化される。TCPを前提にしたプロキシやFWの検査を迂回することがある。組織によってはUDP 443を遮断し、HTTP/2にフォールバックさせる。
8.2 DDoS
| 種類 | 内容 | 対策 |
|---|---|---|
| ボリューム型 | 帯域を埋め尽くす | ISPやクラウドのDDoS対策サービス、CDN |
| リフレクション・増幅型(DRDoS) | 送信元を被害者に偽装し、DNS・NTPなどの応答を被害者に送らせる | 自組織のサーバを踏み台にしない(オープンリゾルバーの禁止)、送信元を偽装したパケットの遮断(イングレスフィルタリング) |
| プロトコル型 | SYNフラッドなど | SYN Cookie |
| アプリケーション層 | HTTPリクエストの大量送信 | WAF、レート制限、CDNのキャッシュ |
CDNを使う場合は、オリジンサーバへの直接アクセスをCDNからの通信だけに制限しないと、CDNを迂回して攻撃される。
8.3 冗長化
- VRRP:複数のルーターで仮想IPアドレスを共有し、障害時に待機系へ切り替える。
- 冗長化は可用性を高めるが、待機系の設定(FWルールやパッチ)が本番と食い違っていると、切替え時にセキュリティが低下する。
9. ログによる調査
| ログ | 分かること |
|---|---|
| FWログ | 送信元・宛先・ポート・許可/拒否・時刻 |
| プロキシログ | アクセス先のURL、利用者、送受信量 |
| DNSクエリログ | 端末が名前解決したドメイン(C2の通信先の手掛かり) |
| VPNログ | 接続した利用者、接続元IPアドレス、割り当てたアドレス、時刻 |
| NetFlow | 通信の要約(誰が誰とどれだけ通信したか) |
| パケットキャプチャ | 通信の内容そのもの(暗号化されていなければ) |
調査の基本は、NATやVPNで変換されたアドレスを対応付けること と、機器間の時刻を揃えること(NTP)である。
10. 補強(C)
- BGPハイジャック:他組織のIPアドレスの経路を誤って、または意図的に広告し、通信を奪う。RPKIで、経路の広告元が正当であることを検証する(ROV)。
11. 構成図を読むときのチェックリスト
- 各サーバ・端末は どのセグメント にあるか
- 通信要件ごとに、誰が開始し、どの機器を通り、どこで終端するか
- NAT・プロキシ・VPNで アドレスがどう変わるか
- TLSは どこで終端 し、検査機器はどこにあるか
- 名前解決は どのDNSサーバ を使うか
- 装置自身の通信(認証、DNS、NTP、更新、ログ転送)は許可されているか
- 許可ルールに 必要以上の範囲 はないか
~Yu Tokunaga