ネットワーク・通信基盤のセキュリティ

Aug 4, 202525 min

この章の到達目標

システム構成図、通信要件、FWの設定表、DNSレコード、ログを読み取り、攻撃経路の特定と、正確な設定変更 を記述できるようにする。

ネットワークは補助的な分野ではなく、独立した大問として繰り返し出ている。

年度ネットワーク関連の論点
2023無線LAN、EAP-TLS、RADIUS、ネットワーク分離
2024VPN、認証、DDoS、CDN/SPF、DKIM、DMARC、メールドメインの移行
2025DNSレコード、公開IT資産の管理/DNSSEC、DoH、VPN、接続元IPアドレスの制限

特に、VPN導入時の通信要件からFWの許可ルールを導くような問題では、用語の知識ではなく 通信経路・制御点・許可すべき通信を設計する力 が問われる。IPAの対象者像にも、ネットワーク・暗号・認証・フィルタリング・ロギングなどの要素技術を適用できることが明記されている。


1. 用語一覧

優先用語・技術科目Bで解けるようにすること
ATCP/IP、TCP・UDPヘッダー、ポート、通信の成立条件
AIPアドレス、サブネット通信元・通信先と経路の特定
Aルーティング、NAT/NAPTアドレス変換前後の通信経路
AステートフルFW、ACL許可・拒否ルールの設計
ADNS、権威DNS、キャッシュDNS名前解決の経路とDNS設定
ADNSSEC、DoH、DoTDNS応答の真正性と通信の暗号化
ADNSキャッシュポイズニング偽応答の成立条件と対策
ATLS 1.2 / 1.3ハンドシェイク、証明書、鍵交換
AIPsec、IKE、ESPトランスポートモード・トンネルモード
AVPN、ZTNAリモートアクセスの認証・通信制御
ASPF、DKIM、DMARCメール送信ドメイン認証の成立条件
Aリバースプロキシ、WAF通信経路と検査・防御の位置
BVLAN、ネットワーク分離セグメント間の通信制限
BIEEE 802.1X、EAP-TLS端末認証、RADIUS、証明書(sc_3)
BARPスプーフィングMACアドレスの偽装、中間者攻撃
BDHCPスプーフィング不正なネットワーク設定の配布
BIDS / IPS、NDRネットワーク上の異常検知
BDDoS、DRDoS攻撃経路、増幅攻撃、CDNによる緩和
BHTTP/2、HTTP/3、QUIC通信の違いとプロキシでの制御
BDNSリバインディングブラウザーを介した内部システムへのアクセス
Bプロキシ、SWG、SASE外向き通信の検査と統制
BSMTP、STARTTLS、SMTPSメール配送・送信時の暗号化
BMTA-STS、DANE、S/MIMEメール通信とメッセージの保護
Bパケットキャプチャ、NetFlow通信ログからの調査
Bルーティングの冗長化、VRRP障害時の切替えと可用性
CBGPハイジャック、RPKI経路広告の偽装と検証
CQUICの通信制御UDPベースの通信に対する監視・制限

2. 通信の基本と「誰から誰への通信か」

2.1 ポートとプロトコル(暗記必須)

ポートプロトコル用途
22/TCPSSHリモート管理
25/TCPSMTPMTA間のメール配送
53/UDP・TCPDNS名前解決(大きな応答やゾーン転送はTCP)
80/TCPHTTP
123/UDPNTP時刻同期
389 / 636/TCPLDAP / LDAPSディレクトリ
443/TCP、443/UDPHTTPS、HTTP/3(QUIC)
445/TCPSMBファイル共有(横展開でよく使われる)
465/TCPSMTPSメール送信(暗号化)
500・4500/UDPIKE、NAT越えのIPsecVPN
587/TCPSubmissionメールクライアントからの送信
853/TCPDoTDNS over TLS
1812・1813/UDPRADIUS認証・アカウンティング
3389/TCPRDPリモートデスクトップ

2.2 NAT/NAPTと送信元の見え方

  • NAPTの後ろにある端末からの通信は、外部からは NAT装置のグローバルIPアドレス に見える。接続元IPアドレスで制限するとき、どのアドレスを許可すればよいかを問う問題が多い。
  • リバースプロキシやCDNを経由すると、Webサーバから見た送信元は プロキシのアドレス になる。本来の送信元は X-Forwarded-For などのヘッダーで渡されるが、このヘッダーは偽装できるので、信頼できるプロキシが付けたものだけを使う。
  • 接続元IPアドレスによる制限を、CDNを経由しない直接アクセス(オリジンサーバへの直接接続)で回避される問題にも注意する。

2.3 ステートフルFWのルール設計

ステートフルFWは、許可した通信の 戻りの通信 を自動で通す。したがって、ルールは 通信を開始する側から 書く。

例題:社外の利用者がVPN装置を経由して社内のファイルサーバを使う。VPN装置はDMZにある。

No.送信元宛先サービス動作
1any(インターネット)VPN装置443/TCP(SSL-VPN)または 500・4500/UDP(IPsec)許可
2VPNのアドレスプールファイルサーバ445/TCP許可
3VPN装置認証サーバ(RADIUS)1812/UDP許可
4anyanyany拒否

答案のポイント:

  • 「VPNの利用者に割り当てられるアドレス」と「VPN装置自身のアドレス」を区別する。
  • 認証、DNS、NTP、ログ転送など、装置自身が行う通信 を見落とさない。
  • 必要以上に広い許可(宛先がany、サービスがanyなど)がないかを確認する。
  • ルールは上から順に評価される。拒否ルールより後ろの許可ルールは効かない。

3. DNS

3.1 名前解決の経路

端末 → キャッシュDNSサーバ(フルリゾルバー) → ルート → TLD → 権威DNSサーバ
種類役割設定上の注意
キャッシュDNSサーバ端末の代わりに問い合わせ、結果をキャッシュする社内からの問合せだけに応答する(オープンリゾルバーにしない)
権威DNSサーバ自ドメインの情報を回答する再帰問合せを受け付けない。ゾーン転送をセカンダリだけに限定する

キャッシュと権威を 同じサーバで兼用しない ことが基本。

3.2 主なレコード

レコード内容
A / AAAAIPv4 / IPv6アドレス
CNAME別名(参照先のホスト名)
MXメールの受信サーバ
TXTSPF、DMARC、ドメインの所有確認など
NS権威DNSサーバ
SOAゾーンの管理情報
PTR逆引き
CAA証明書を発行してよいCA
DS / DNSKEY / RRSIGDNSSEC

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 のハンドシェイク(概要)

  1. ClientHello:対応する暗号スイート、鍵共有のパラメータ(ECDHE)、SNI
  2. ServerHello:選択した暗号スイート、鍵共有のパラメータ
  3. 以降は暗号化:サーバ証明書、CertificateVerify(サーバの秘密鍵による署名)、Finished
項目TLS 1.2TLS 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レコード)
DMARCSPFまたは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が必須」というポリシーを公開し、ダウングレードを防ぐ
DANEDNSSECで保護された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 検査の位置

機器検査する通信位置
FWIPアドレス・ポート・状態境界、セグメント間
IDS / IPS通信の内容(シグネチャ、異常)IDSは監視(ミラーポート)、IPSは経路上(インライン)
WAFHTTPの内容Webサーバの前
リバースプロキシ外部から内部への通信の中継DMZ
フォワードプロキシ、SWG内部から外部への通信利用者端末と外部の間
NDRネットワーク全体の通信の振る舞い内部ネットワーク
SASESWG、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. 構成図を読むときのチェックリスト

  1. 各サーバ・端末は どのセグメント にあるか
  2. 通信要件ごとに、誰が開始し、どの機器を通り、どこで終端するか
  3. NAT・プロキシ・VPNで アドレスがどう変わるか
  4. TLSは どこで終端 し、検査機器はどこにあるか
  5. 名前解決は どのDNSサーバ を使うか
  6. 装置自身の通信(認証、DNS、NTP、更新、ログ転送)は許可されているか
  7. 許可ルールに 必要以上の範囲 はないか

~Yu Tokunaga