こんにちは！ネットワークセキュリティの世界へようこそ。
インフラやネットワークの勉強を始めたばかりの頃って、次から次へと専門用語が出てきて、「いったい何から手をつければいいの…？」と途方に暮れてしまいますよね。
でも、安心してください。今日は、現代の企業セキュリティの最前線である「SASE（サセ）」や「CASB（キャスブ）」の世界から、「DNSセキュリティ（DNS Security）」という、ちょっとカッコよくてめちゃくちゃ重要なテーマを取り上げます。
「DNSって、あのURLをIPアドレスに変換するやつでしょ？」
大正解です！でも実は、その「名前解決」の仕組みを悪用して、社内のPCをこっそり乗っ取りに来るワルい奴らがいるんです。今日は、身近な例えを交えながら、DNSセキュリティがどうやって会社のネットワークを守っているのか、一緒に一歩ずつ紐解いていきましょう！
—
1. 郵便配達で例える「DNS」と「C2通信」の罠
まずは、私たちが普段何気なく使っているDNSの仕組みを、身近な「郵便配達」に例えて考えてみましょう。
あなたがネットショッピングで新しい服を買ったとき、宛先には「東京都〇〇区…」という住所を書きますよね。でも、郵便配達員さんはその住所をパッと見てすぐにピンと来ません。そこで、裏側で「この住所は、あの地域の配達センターの管轄だな」と地図で調べて（名前解決して）、正確な建物の場所（IPアドレス）を特定して荷物を届けます。
インターネットの世界でもまったく同じです。私たちがブラウザに example.com と打ち込むと、DNSサーバーという「住所案内板」が、「そのサイトの本当のIPアドレスは 93.184.216.34 だよ」と教えてくれて、はじめて通信ができるようになります。
マルウェアの「おうちへの帰り道」（C2通信）
さて、ここからが少し不気味な本題です。
もし、うっかり社員のPCにマルウェア（悪意のあるプログラム）が侵入してしまったら、どうなるでしょうか？
マルウェアは、侵入した後に必ず「親玉（攻撃者のサーバー）」と連絡を取ろうとします。この親玉のことを、C2（Command and Control）サーバーと呼びます。
「ボス、そちらの準備はできました！ 次の指示をください！」と報告するための連絡網ですね。
昔は、このC2サーバーの「住所（IPアドレス）」が固定されていることが多く、ファイアウォールでそのIP宛ての通信をガチッとブロックすれば防げました。しかし、攻撃者も頭が良いので、セキュリティ対策をすり抜けるために巧妙な手口を使います。それが「DGA（Domain Generation Algorithm）」です。
—
2. 攻撃者の隠れミノ：「DGAドメイン」の恐怖
DGAとは、簡単に言うと「毎日、自動的にデタラメな文字列の住所を何千個も生み出すアルゴリズム」のことです。
例えば、攻撃者は今日使うドメインとして、こんな文字列を自動生成させます：
xj82hs7d6s9a.comq9w8e7r6t5y4.netzxcvbnmasdfg.org
まるで猫がキーボードの上を歩いたような、意味不明な文字列ですよね。
マルウェアは、毎日このデタラメなドメインのリストに向かって、「今日のおうちはここですか？」と一斉にDNSクエリ（名前解決の要求）を投げまくります。攻撃者はその中のたった1つだけを事前に登録しておき、そこからC2通信を確立するのです。
ファイアウォールから見れば、これは普通の名前解決の問い合わせに見えるため、「どれが本物のC2通信なのか」をIPアドレスだけで見抜くのは至難の業です。ここで登場するのが、今回主役のDNSセキュリティです。
—
3. SASEとDNSセキュリティ：門番のアップグレード
私たちがオフィスにいても、リモートワークでカフェにいても、すべての通信はクラウド上の安全なゲートウェイ（SASE）を経由する現代。このSASEの中に組み込まれているDNSセキュリティ機能は、まさに「怪しい手紙の宛先をすべてチェックする超優秀な郵便局の検閲官」です。
DNSセキュリティは、社内から飛んでくるすべてのDNSクエリをリアルタイムで検査し、次のような脅威をビシッと見つけ出してシャットアウトします。
1. 既知のC2ドメインのブロック:
世界中のセキュリティ脅威インテリジェンスと連携し、「あ、この宛先はすでに犯罪者のアジトとして登録されているな」と分かった瞬間、名前解決の要求を即座に拒否します。
2. DGA（動的ドメイン）の検知:
「なんだかこのドメイン、人間が作ったものにしては不自然にランダムすぎるぞ（エントロピーが高い）」という特徴をAIや機械学習で嗅ぎ取り、怪しいドメインへの名前解決を未然に防ぎます。
宛先（ドメイン）の名前解決そのものを失敗させてしまえば、マルウェアはC2サーバーのIPアドレスを知ることができません。つまり、「そもそも連絡網が分からないから、親玉と連絡が取れない＝攻撃を未然に無力化できる」というわけです！
—
4. 実務で役立つ設定と検証のアプローチ
「なるほど、DNSセキュリティがすごいのは分かったけど、実際の現場ではどう設定するの？」
ここからは、実務やインフラ構築で役立つ具体的なアプローチを覗いてみましょう。
多くのSASE製品（Cloudflare OneやPalo Alto Networks Prisma Accessなど）では、ダッシュボード上でポリシーをポチポチと有効化するだけでDNSセキュリティが動き出します。しかし、インフラエンジニアとしては「本当にブロックできているか？」を自分の手でテストしたくなりますよね。
安全な検証用環境において、あらかじめ安全が確認されているテスト用ドメイン（EICARのようなテスト文字列に似たもの）を使って名前解決を試す際の、Linux（dig コマンド）のサンプルを見てみましょう。
実務でのDNSクエリテスト例（CLI）
以下のコマンドは、ターミナルから特定のドメインに対してDNSの問い合わせ（名前解決）を行うものです。DNSセキュリティが正しく機能していれば、ブロック対象のドメインに対しては「そんな住所は教えられません（あるいは偽の安全なページに誘導）」という応答が返ってきます。
# 【検証用】通常の安全なドメインへの問い合わせ
# 正常にIPアドレスが返ってくることを確認します
dig +noall +answer example.com A
# 【実務設定のイメージ】
# もしここにマルウェアがアクセスするような悪性ドメイン（例: dga-sample-malware-domain.com）を指定した場合、
# SASEのDNSセキュリティが割り込み、名前解決をブロック（NXDOMAINや、安全な警告ページ用IPを返却）します。
dig +noall +answer dga-sample-malware-domain.com Aセキュリティポリシー設定のJSONサンプル（概念モデル）
APIやIaC（Infrastructure as Code）を使ってセキュリティポリシーを管理する現代のインフラ現場では、次のようなJSONやYAML形式の設定ファイルをベースにDNSセキュリティルールを定義することも少なくありません。
{
"dns_security_policy": {
"rule_name": "Block-Malicious-C2-and-DGA",
"enabled": true,
"target_groups": [
"all_corporate_devices",
"remote_workers"
],
"actions": {
"known_threats": "block", // 既知のC2サーバーリストに合致した場合はブロック
"dga_detection": "block", // DGA（ランダム生成ドメイン）の挙動を検知してブロック
"cryptojacking": "block" // ついでにマイニング関連の通信もブロック
},
"fallback_action": "allow", // 上記以外は通常のDNS解決を許可
"notification": {
"alert_soc_team": true, // ブロック発動時にSOC（セキュリティ監視チーム）へアラート通知
"log_retention_days": 90
}
}
}このように、インフラのコード化やポリシーの集中管理を行うことで、社内にいても外にいても、全社員のPCが常に最新のDNSセキュリティの網で守られる環境が完成します。
—
5. おわりに：ゼロトラストの基本は「名前解決」の瞬間から
いかがでしたでしょうか？
「DNSセキュリティによるC2通信ブロックとDGAドメインの検知」という言葉を聞くと、最初はすごく難しそうに感じられたかもしれませんが、フタを開けてみれば「社内から外への怪しい手紙の宛先チェックを、郵便局（SASE）の段階で水際防止している」という非常にシンプルで強力な仕組みでした。
ゼロトラストアーキテクチャの基本は、「誰も信用しない、すべてを検査する」ことです。
WebブラウザでURLを叩く、そのコンマ数秒前の「名前解決の瞬間」からセキュリティの目を光らせることで、巧妙化するサイバー攻撃の芽をしっかりと摘み取ることができます。
ネットワークやセキュリティの道は奥が深いですが、こうして一つひとつの技術の役割を身近な例えと結びつけていくと、ぐっと楽しくなりますよね。
日々のインフラ運用や学習のモチベーションになれば幸いです。それでは、また次回の技術解説でお会いしましょう！
コメント