1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

Ubuntu Server 20.04.3 LTS 構築#24 セキュリティ設定10(DNSサーバー)

Posted at

実施日:2022/04/18~2022/04/25

【今回の内容】
DNSサーバーのセキュリティ設定

DNSサーバーのセキュリティ対策

ローカル上で出来ること。
・ゾーン転送の制限
⇒マスターDNSサーバーからスレーブDNSサーバーにゾーン転送をする範囲を設定します。
 転送範囲を制限することで、ゾーン情報の全体を外部から問い合わせが出来なくなります。

・DNS問い合わせの制限
⇒DNS問い合わせの範囲を自信が管理する範囲内に制限をする。
 管理する範囲内にすることで不正なDNSサーバー利用を阻止することが出来る。

・バージョン番号の隠蔽
⇒BINDのバージョンを隠蔽することでそのバージョンが抱えている脆弱性を突かれて不正な
 アクセスから防御する。但し、バージョンを隠蔽したからとって安全を確保したわけではない。
 
・root以外によるnamedの実行
⇒root権限で実行しているとセキュリティホールを突かれて侵入されたときに被害が甚大になるため、
 被害を最小限に抑えるために一般ユーザー権限で被害を最小限にする。

DNSサーバーへの攻撃方法

・DNSキャッシュポイズニング攻撃
⇒ホスト名とIPアドレスを改ざんし、有害なサイトへと導く。

・ゾーン転送要求による攻撃
⇒同じゾーン内に負荷分散するために複数のDNSサーバーを配置する。これらのDNSサーバー内のゾーン情報を
 同期する必要があります(ゾーン要求という)。そうしないと、名前解決の負荷分散が出来ないため。
 ゾーン要求を外部から行い、その応答に対して不正なDNS情報を送ることが出来る。
 
・カミンスキー攻撃
⇒キャッシュサーバーにキャッシュ情報があれば、権威DNSサーバーに問い合わせをしない。
 存在しないホスト名で問い合わせを行うとキャッシュサーバーにキャッシュ情報がないため
 権威DNSサーバーに問い合わせをする。この問い合わせ時に攻撃者が不正な情報を送ること。

DNSサーバーへの攻撃方法の対処法

・DNSキャッシュポイズニング攻撃
⇒TTLの時間を長くする。
 ※但し、カミンスキー攻撃の対応策としては不十分である。

・ゾーン転送要求による攻撃
⇒マスターサーバーからスレーブサーバーへのゾーン転送時に共有秘密鍵を使用して転送の安全性を高める
 このような仕組みをTSIG(Transaction SIGnatures(トランザクション署名))という。

・カミンスキー攻撃
⇒権威DNSサーバーからの応答が信頼できるものからの応答であることを証明出来れば、不正な攻撃から守ることが出来る。
 権威DNSサーバーとキャッシュサーバー間での応答が信頼できるものであることを証明する機能をDNSSECという。

設定

これらの外部からの攻撃に備えるため、実際に設定をしていきます。
・ゾーン転送の制限
・ゾーン転送要求による攻撃
⇒現在、スレーブサーバーは建てていませんので、設定は見送ります。

・DNS問い合わせの制限
⇒DNS問い合わせの範囲を以下のように設定しました。

 /etc/bind/named.conf.optionsを開き
 allow-query { localhost; 192.168.1.0/24; };
 #問い合わせの許可範囲をローカル上、LAN内に設定

・バージョン番号の隠蔽
⇒何も設定していないとバージョンは確認できます。

  dig @localhost version.bind chaos txtでバージョンを確認できます。Anser sectionに表示されます。
 #修正方法
 /etc/bind/named.conf.optionsを開き
 option内にversion"任意の文字列"を記入し
 sudo systemctl restart namedを実行します。
 #設定後、dig @localhost version.bind chaos txtで確認すると、変更した任意のものに変わります。

・root以外によるnamedの実行
⇒BINDをパッケージでインストールすると、一般ユーザーが作成され、その権限で動作しています。
 ただ、更にセキュリティ面を強化するとすれば、chroot以下に動作させれば、chroot以下の箇所しか
 アクセス出来ないためセキュリティ面は強固になります。

#設定方法
#chrootのディレクトリを作成して、パーミッション設定してまではイメージ出来ていましたが、
#そのまま丸ごとchrootディレクトリ内に移動して良いのだろうかと疑問に思い、調べてみました。
#以下のサイトで詳しく説明があったので、参考にさせて頂きました。

#まずはchrootディレクトリとその配下のディレクトリを作成します。
sudo mkdir -p /chroot/named
cd /chroot/named
sudo mkdir -p dev etc/namedb/slave var/run

#次に所有権とアクセス権の変更をします。
sudo chown root:root /chroot
sudo chmod 700 /chroot
sudo chown bind:bind /chroot/named
sudo chown bind:bind /chroot/named/etc/namedb/slave
sudo chown bind:bind /chroot/named/var/run
sudo chmod 700 /chroot/named

#bindディレクトリにあったnamed.confファイルを/chroot/named/etcにコピーします。
sudo cp /etc/bind/named.conf /chroot/named/etc

#デバイスファイルを作成する。
sudo mknod /chroot/named/dev/null c 1 3
sudo mknod /chroot/named/dev/random c 1 8
#※mknodというコマンドがあることを初めて知りました。
#解説しているサイトを見つけましたので、そちらでどういうものか確認しました。

#PIDと統計データを格納する
sudo chown bind:bind /chroot/named/var/run

#起動オプションの編集
#/etc/default/bind9内を以下に変更します。
OPTIONS="-u bind"
↓
OPTIONS="-u bind -t /chroot/named -c /etc/named.conf"
#※/etc/default/bind9が見当たらない場合は/etc/default/namedで存在していると思います。
#実際、私はnamedでした。

< 参考サイト >
トルコラルラリア様
Linuxコマンド.NET様

・カミンスキー攻撃対策
⇒DNSSECを導入する。
※導入にあたり、自身で行う作業と上位の権威サーバーに設定が必要な箇所があります。
 今回は対策としてDNSSECがあるということのみ記載します。

今回はここまで。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?