「誰にでも答える」お人好しは卒業しよう
こんにちは！「リナックス先生」です。
BIND9講座、第7回へようこそ。
これまでの講座で、あなたのDNSサーバーはかなり高機能になりました。
しかし、セキュリティの観点から見ると、まだ「脇が甘い」状態です。
DNSサーバーにとって最大のリスク、それは「オープンリゾルバ（Open Resolver）」になってしまうことです。
これは、世界中の誰からの質問にも「はいはい、調べてきますよ！」と答えてしまう状態のこと。
悪意ある攻撃者は、これを利用してあなたのサーバーに大量の偽装パケットを送りつけ、他人のサーバーをダウンさせる「DNSアンプ攻撃」の踏み台として悪用します。
これを防ぐ唯一の手段が、今回学ぶ「ACL（アクセスコントロールリスト）」です。
「身内（社内・自宅）」と「他人（インターネット）」を明確に区別し、プロとして恥ずかしくないセキュアなサーバーに仕上げましょう。
先生、オープンリゾルバって言葉、ニュースで聞いたことあります！
自分のサーバーが攻撃に使われるなんて怖すぎます…。
でも、IPアドレス制限なら第2回でちょっとやりましたよね？あれじゃダメなんですか？
第2回で書いた 192.168.1.0/24; みたいな直書きでも動くけど、管理するサーバーや拠点が増えたらどうする？
全部の設定ファイルにIPを書き足して回るの？
ACLを使えば「Trusted（信頼できる）」というグループを作って、一箇所で管理できるの。
これが「動けばいい」素人と「運用を考える」プロの違いよ。
1. ACL（Access Control List）とは？
BINDにおけるACLは、「複数のIPアドレスやネットワークをまとめて、名前をつけたグループ」のことです。
ACLを使うメリット
- 可読性が上がる： 設定ファイルの中に IPアドレスの羅列がなくなり、「trusted（信頼済）」や「slave-servers（スレーブ）」といった意味のある言葉で記述できます。
- 管理が楽になる： 拠点のIPが変わった時も、ACLの定義を一箇所書き換えるだけで、すべての適用箇所（問い合わせ許可、転送許可など）に反映されます。
- ミスが減る： 複雑なIP入力を何度も繰り返さなくて済むため、タイプミスによる事故を防げます。
2. ACLの定義方法
それでは named.conf を編集していきましょう。
ACLの定義には厳格なルールがあります。
【鉄則】ACLは設定ファイルの「一番上」に書くべし！
BINDの設定ファイルは上から順に読み込まれます。
ACLを実際に使う（optionsなど）場所よりも前に定義されていないと、「そんなグループ知らないよ」とエラーになります。
2-1. named.conf の編集
sudo vi /etc/named.conf
ファイルの先頭（optionsよりも前）に、以下のように記述します。
# ACL定義: 信頼できる内部ネットワーク
acl "trusted" {
127.0.0.0/8; # ローカルホスト（自分自身）
192.168.1.0/24; # 自宅・社内LAN
10.0.0.0/8; # VPNなど（必要なら）
};
# ACL定義: スレーブサーバー群
acl "slaves" {
192.168.1.11; # スレーブサーバー1
# 192.168.1.12; # スレーブサーバー2（増えたらここに足すだけ）
};
"trusted" や "slaves" という名前は自由に決められますが、誰が見ても分かる英単語にするのがマナーです。
2-2. 定義済みのACLキーワード
BINDには、最初から定義されている便利なキーワード（組み込みACL）もあります。
| キーワード | 意味 |
|---|---|
| any | すべてのアドレス（全世界）。使用は慎重に！ |
| none | 誰も許可しない。 |
| localhost | サーバー自身のIPアドレス（ループバックおよび付与されているIP全て）。 |
| localnets | サーバーが接続されているネットワークセグメント全て（自動判別）。 |
プロの現場では、誤判定を防ぐために localnets に頼らず、明示的にIP範囲を指定した自作ACL（trustedなど）を使うことが一般的です。
3. ACLを適用する（3つの防壁）
グループを作っただけでは意味がありません。
それを「どこで使うか」が重要です。
BINDには主に3つの制御ポイントがあります。
① allow-query（質問を受け付けるか？）
「このドメインのIP教えて？」というDNS問い合わせそのものを許可するかどうか。
キャッシュサーバーなら「身内（trusted）」のみ、公開サーバーなら「全世界（any）」にするのが基本です。
② allow-recursion（代わりに調べてあげるか？）
【最重要】ここがオープンリゾルバ対策の核心です。
「再帰問い合わせ（＝自分が知らないドメインをルートから調べてくる機能）」は、CPUも回線も使います。
これを部外者に使わせてはいけません。絶対に「身内（trusted）」だけに制限します。
③ allow-transfer（データを丸ごと渡すか？）
第5回でやったゾーン転送の許可です。
これは「スレーブサーバー（slaves）」だけに許可します。
4. 【実践】named.conf への適用
定義したACLを使って、options ブロックを書き換えてみましょう。
非常にスッキリして読みやすくなるはずです。
options {
listen-on port 53 { 127.0.0.1; 192.168.1.10; };
directory "/var/named";
# --- セキュリティ設定 ---
# Q: 誰からの質問に答える？
# A: 身内だけ（公開サーバーなら any にするが、recursionで制限する）
allow-query { trusted; };
# Q: 誰のためにインターネットを検索してあげる？
# A: 絶対に身内だけ！ (オープンリゾルバ対策)
allow-recursion { trusted; };
# Q: 誰に設定ファイルの中身（ゾーン）をあげる？
# A: スレーブサーバーだけ
allow-transfer { slaves; };
# ------------------------
};
どうでしょうか？192.168.1.0/24; 10.0.0.0/8; ... と数字が並んでいた頃より、意図が明確になりましたね。
5. 攻撃者を葬る「blackhole」機能
ここで一つ、上級者向けの機能を紹介します。
「特定のIPアドレスからの通信がしつこい！ログも汚れるし、返事もしたくない！」
そんな時は、blackhole オプションを使います。
ブラックリストACLの作成
acl "bad-guys" {
203.0.113.5; # 攻撃者のIP
198.51.100.0/24; # 攻撃元のネットワークごと
};
blackholeへの適用
options {
# (省略)
# ここに指定されたIPからのパケットは、処理せず即座に捨てる
blackhole { bad-guys; };
};
allow-query { ... }; で拒否した場合は、わざわざ「お前の質問は拒否する！」というエラー応答（REFUSED）を返してあげます。
しかし blackhole は「無視（Drop）」します。相手にリソースを一切割かないため、DDoS対策として非常に有効です。
6. 設定の反映と確認
設定が終わったら、必ずチェックを行います。
6-1. 構文チェック
sudo named-checkconf
もしACLの定義順序（使用箇所より後ろに書いているなど）が間違っていると、ここでエラーが出ます。
6-2. 動作テスト
ACLが正しく機能しているか確認するには、本来なら「許可されていない別のIPアドレス」を持ったPCから dig を打つのが一番です。
しかし、手元に1台しかない場合は、一時的にACL定義を書き換えてテストします。
実験：自分を締め出してみる
acl "trusted" {
# 127.0.0.0/8; # 一時的にコメントアウト
192.168.1.0/24;
};
リロード後、サーバー自身から問い合わせてみます。
dig @127.0.0.1 google.com
▼期待される結果（拒否）
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: ...
status: REFUSED （拒否されました）と出れば成功です！
ACLが正しく門番の役割を果たしています。
確認後は必ず元に戻しておいてくださいね。
REFUSED って出た時、普通なら「エラーだ！」って焦るけど、セキュリティテストだと「よしっ！」ってなりますね（笑）。blackhole 機能も強そうで気に入りました。
これで僕のサーバーも要塞化した気がします！
まとめ：ACLはDNSの「城壁」
第7回では、DNSサーバーを守るための最重要設定「ACL」を学びました。
- ACL はIPアドレスをグループ化して名前をつける機能。
- allow-recursion { trusted; }; はオープンリゾルバを防ぐための絶対の鉄則。
- allow-transfer はスレーブサーバーのみに許可する。
- blackhole を使えば、悪質なパケットを無視（Drop）できる。
- ACL定義は必ずファイルの上部（使用箇所より前）に書く。
これでセキュリティ対策も万全…と言いたいところですが、実務ではもう一つ、厄介な要件があります。
「社内からのアクセスにはプライベートIPを返して、社外からのアクセスにはグローバルIPを返したい」という、いわゆる「スプリットDNS（Split-Horizon）」の要望です。
これを実現するのが、BIND9の最強機能「View（ビュー）」です。
次回（第8回）は、見る人によって見せる世界を変える、DNSのマトリックス「View」の世界に飛び込みます。
設定ファイルの構造がガラッと変わる大工事になりますので、気合を入れて臨みましょう！
▼攻撃テストも試せるVPS
ACLによるアクセス制御や、blackhole機能の動作検証を行うには、外部からの接続が可能なVPS環境が最適です。学習用に自由に設定をいじれるおすすめVPSはこちら。
コメント