【入門編】 DNSベースのマルウェア対策(DNSセキュリティ / Response Policy Zone: RPZ) – サイバーセキュリティとプライバシー保護実践ガイド

ネットワークの「関所」を賢く守ろう!DNSフィルタリングでマルウェアを未然に防ぐ方法

こんにちは!ネットワークセキュリティの世界へようこそ。

インフラエンジニアとして現場を歩いていると、毎日いろいろな相談を受けます。「最新のファイアウォールを入れたのに、なぜかマルウェアに感染した」という嘆きもその一つ。実は、敵は正面突破だけを狙っているわけではないんです。

今日は、そんな巧妙な攻撃を水際で食い止める、DNSを使った強力な防御術についてお話しします。難しそうな用語も、身近な例え話で紐解いていくので、リラックスして読んでくださいね。

—

そもそも、なぜDNSが狙われるの?

皆さんがWebサイトを見る時、ブラウザにURLを入力しますよね。でも、ネットワークの世界で通信相手を特定するのは、名前(ドメイン名)ではなく「住所(IPアドレス)」です。

ここで登場するのがDNS(Domain Name System)です。DNSは、いわば「住所録」ですね。「google.com は 142.250.xxx.xxx ですよ」と教えてくれる案内係です。

さて、悪意ある攻撃者がどうやってマルウェアを仕込むかというと、「偽の案内係」を悪用するんです。PCが「悪いサイトの住所を教えて!」と尋ねたとき、DNSが素直にその住所を教えてしまったら……PCは疑うこともなく危険な場所へアクセスしてしまいますよね。

これが、DNSを狙った攻撃の恐ろしさです。

—

郵便配達の仕組みで理解する「DNS Sinkhole(シンクホール)」

では、どうやってこれを防ぐか。ここで登場するのがDNS Sinkhole(シンクホール)という考え方です。

想像してみてください。あなたは郵便局の仕分け人です。ある日、「詐欺グループの住所宛ての荷物」が届きました。普通ならそのまま配達してしまいますよね。でも、もしあなたが「この宛先は危険だから、郵便局内の『隔離ボックス』に強制転送しよう」と決めたらどうでしょう?

荷物は詐欺グループには届かず、安全な隔離場所に保管されます。これが「シンクホール」です。

ネットワークの世界では、PCが危険なドメインの名前解決を要求した瞬間に、本来のIPアドレスではなく、安全な「おとり(偽)のIPアドレス」を返して、アクセスを無効化してしまうんです。

—

RPZ(Response Policy Zone)で賢い守りを実現する

DNS Sinkholeを実現するための技術がRPZ(Response Policy Zone)です。これは、DNSサーバーに対して「もしこのリストにあるドメインが聞かれたら、こうやって返事してね」という特別なルールブックを渡す仕組みです。

BIND 9での設定例

多くのインフラで使われている BIND 9 というDNSサーバーソフトで、実際にどのようにルールを書くか見てみましょう。

// named.conf(設定ファイル)への追記例
zone "rpz.blocked.local" {
    type master;
    file "/etc/bind/db.rpz.blocked.local"; // ここにブロックリストを記述します
};

options {
    // DNSサーバーにRPZを適用する設定
    response-policy { zone "rpz.blocked.local"; };
};

次に、ブロックしたいドメインをリスト化します。

// db.rpz.blocked.local(ブロックリストの内容)
$TTL 60
@ IN SOA localhost. root.localhost. (2 60 60 60 60)
  IN NS localhost.

; ここで悪意あるドメインを「おとり」のIP(127.0.0.1)に飛ばします
bad-malware-site.com CNAME .
another-threat.net    CNAME .
  • CNAME . という記述がポイントです!これを使うと、「そのドメインは存在しません(NXDOMAIN)」という回答を返し、通信を綺麗に遮断してくれます。

—

初学者がまず意識すべきこと

この対策の素晴らしいところは、PCやスマホの設定を一切変える必要がない点です。ネットワークの「関所」であるDNSサーバーを一度設定してしまえば、社内すべての端末が自動的に守られます。

ただ、一つだけ注意点があります。「完全に信頼できるリスト」をどうやって入手するかです。世の中には無料のフィード(悪意あるドメインのリスト)も公開されていますが、時には「誤検知(本当は安全なのにブロックしてしまうこと)」が起きることもあります。

まずは、社内で「なぜかこのサイトだけ見られない!」という問い合わせが来ても慌てないよう、「どのドメインが、どのリストによってブロックされているか」をログで確認する癖をつけておきましょう。

tail -f /var/log/syslog | grep rpz

このコマンドで、DNSサーバーが日々どんな悪いやつを退けているか監視するだけでも、立派なセキュリティエンジニアへの第一歩ですよ!

—

最後に:ネットワークに「絶対」はないけれど

DNSフィルタリングは、防御の最前線として非常に効率的ですが、これだけで万全とは言えません。しかし、攻撃者の「入り口」を一つずつ塞いでいく姿勢が、結果として組織のセキュリティレベルを大きく引き上げます。

最初はコマンドを打つ手も震えるかもしれませんが、パケットの流れを想像しながら設定してみれば、きっとネットワークが少しずつ「自分が見える味方」になってくるはずです。

皆さんのネットワークが、今日も安全であることを祈っています!また次の技術解説でお会いしましょう。

コメント

タイトルとURLをコピーしました