1. ホーム
  2. 記事一覧
  3. 【BIND高度実践】chroot環境を構築してみよう【後編】

2023.10.01

【BIND高度実践】chroot環境を構築してみよう【後編】

こちらの記事は、chroot環境の構築(ハンズオン)の後編です。前編は以下の記事で紹介しています。

https://envader.plus/article/229

また、chroot環境の構築に関する解説は以下の記事で紹介しています。不明点がある場合は、その記事を参照しながら本ハンズオンを進めてください。

https://envader.plus/article/228

本記事で行うchroot環境の構築手順

本記事では以下の手順でchroot環境の構築を行います。

  1. chroot環境内に適切な権限を設定する
  2. named.serviceの変更
  3. AppArmorのポリシーの変更
  4. 変更の反映
  5. named(BIND)の稼働状態の確認
  6. DNSリクエストのテスト

1. chroot環境内に適切な権限を設定する

chroot環境内の各ディレクトリ・ファイルには、その役割や機能に応じて適切な権限を設定する必要があります。また、前回の権限変更によってubuntuユーザーの各種実行権限が足りなくなります。もし実行権限が不足した場合はsudo、またはsudo suで実行してください。

1-1. /chroot/named以下のディレクトリの設定

以下のコマンドを実行します。

# /chroot/named 以下のすべてのディレクトリの権限を 755 に設定
$ sudo find /chroot/named -type d -exec chmod 755 {} \;

上記の権限設定の詳細は以下の通りです。

  • 所有者

    ディレクトリ内のファイルやサブディレクトリを管理するために、chroot環境内のプロセスがディレクトリにフルアクセスを持つことが必要です。所有者に読み取り、書き込み、実行権限を与えることで、ディレクトリ内での作業が可能になります。

  • グループ

    グループに読み取りと実行権限を与えることで、特定のプロセスグループ内のユーザーがディレクトリ内のファイルやサブディレクトリにアクセスできるようになります。書き込み権限は不要なため、セキュリティを維持しながらアクセスを許可できます。

  • その他ユーザー

    その他のユーザーに読み取りと実行権限を与えることで、chroot環境内の他のプロセスがディレクトリ内のファイルやサブディレクトリにアクセスできるようになります。書き込み権限は不要ですが、読み取りと実行権限は必要です。

755の権限は、セキュリティとアクセス制御のバランスをとった設定であり、chroot環境内で必要な操作を実行できるようにする一方で、不必要な書き込み権限を制限して安全性を確保します。

1-2. /chroot/named以下のファイルの設定

以下のコマンドを実行します。

# /chroot/named 以下のすべてのファイルの権限を 644 に設定
$ sudo find /chroot/named -type f -exec chmod 644 {} \;

上記の権限設定の詳細は以下の通りです。

  • 所有者

    ファイルを読み取り、必要に応じて変更できるため、chroot環境内のプロセスがファイルを操作するのに必要です。

  • グループ

    ファイルを所属グループ内のプロセスが読み取れるようにするため、他のプロセスにも一部のアクセス権を付与しますが、書き込みは制限されています。

  • その他ユーザー

    chroot環境内の他のユーザーがファイルを読み取れるようにするため、一般的な読み取りアクセス権が与えられています。

644の権限は、ファイルのセキュリティを維持しつつ、必要なプロセスがファイルを読み取り、必要な情報を取得できるようにする効果的な方法です。同時に、不必要な書き込みアクセスを制限し、データの完全性を保護します。

1-3. デバイスファイルの設定

以下のコマンドを実行します。

# 全てのユーザーの読み書きを許可
$ sudo chmod 666 /chroot/named/dev/{null,random,urandom}

これらのデバイスファイルは全てのユーザーに対して読み取りと書き込みの権限を許可します。

  • /dev/null

    /dev/nullは、書き込み操作を行なっても何も記録されず、読み取り操作は常に空のデータを返します。つまり、このデバイスにデータを書き込むことは、データを破棄することと同義です。/dev/nullの主な利用目的である、データの破棄と空のデータの返却のために読み取りと書き込みを許可します。

  • /dev/randomおよび/dev/urandom

    /dev/randomおよび/dev/urandomは、ランダムなデータを生成するために使用されます。読み取り操作によってランダムなデータの取得を行い、書き込み操作によって特定のランダムデータをデバイスに供給することができます。

デバイスファイルに読み取りと書き込みの権限を設定することで、chroot環境内のプロセスがこれらのデバイスにアクセスでき、必要なデータの読み取り、書き込みができるようになります。特にセキュリティ関連の操作やランダムなデータの生成など、さまざまな用途でこれらのデバイスファイルへのアクセスが必要とされる場合があるため、666の権限を設定します。

1-4. /chroot/named/var/cacheの設定

以下のコマンドを実行します。

# ユーザー・グループのみ読み書き実行を許可
$ sudo chmod 770 /chroot/named/var/cache

上記の権限設定の詳細は以下の通りです。

  • 所有者

    BINDの実行プロセスは、一般的に非特権ユーザー、ubuntuであればbindとして動作します。ディレクトリにキャッシュデータや一時的なデータを生成、更新、削除するため、読み書きおよび実行の権限が必要です。

  • グループ

    特定の環境や設定では同じグループのメンバーがBINDのプロセスと協力して操作を行うことがあります。また、BINDを運用をサポートするためのツールやスクリプトが存在する場合、それらを実行するユーザーもグループの権限を使ってキャッシュデータにアクセスできるようにすることが考えられます。そのため、所有者同様に全ての権限を付与します。

  • その他のユーザ

    一切のアクセスの権限を与えません。

770の権限は、指定されたユーザーとグループのみにフルアクセスを許可し、それ以外のユーザーからのアクセスを完全に制限することで、セキュリティを強化します。

1-5. /chroot/named/run/namedの設定

以下のコマンドを実行します。

# ユーザー・グループのみ読み書き実行を許可
$ sudo chmod 770 /chroot/named/run/named

こちらもキャッシュディレクトリと同様の理由から770の権限に設定します。

1-6. keysディレクトリ内のファイルの設定

以下のコマンドを実行します。

# ユーザのみ読み書きを許可
$ sudo chmod 600 /chroot/named/etc/keys/*

keysディレクトリ内のファイルには600の権限を付与し、BINDのプロセスによってのみ読み書きを行うことを許可します。

keysディレクトリはBINDのキーファイルを保存するディレクトリです。ここに格納するキーファイルは、DNSのゾーン転送や更新などのセキュアな操作を行うために使用される暗号鍵を含む可能性があります。これらのキーが第三者に漏洩すると、DNSサービスが不正に操作されるリスクがあるため、ファイルへのアクセスは厳格に制限される必要があります。

2. named.serviceの変更

/etc/default/namedを変更し、namedがchroot環境のファイルを読み込むように設定します。

$ sudo vim /etc/default/named

#
# run resolvconf?
RESOLVCONF=no

# startup options for the server
# 以下を変更 -4は任意(IPv4を使用)
OPTIONS="-4 -u bind -t /chroot/named -c /etc/named.conf"

上記の設定した内容を以下にまとめました。

引数意味
-4IPv4モードで動作(IPv6は無効化)
-u bindbindユーザーとして実行
-t /chroot/namedbindが動作するルートディレクトリを変更
-c /etc/named.confchroot環境内のnamed.confの場所を指定

3. AppArmorのポリシーの変更

/chroot/named以下の全てのファイルは読み取り専用、/chroot/named/var/cache/chroot/named/run/named/以下の全てのファイルは読み書き可能と定義します。

File Access Permissionsポリシー内に、以下の内容を追加します。

$ sudo vim /etc/apparmor.d/usr.sbin.named

# vim:syntax=apparmor
# Last Modified: Fri Jun  1 16:43:22 2007
#include <tunables/global>

/usr/sbin/named flags=(attach_disconnected) {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  capability net_bind_service,
  capability setgid,
  capability setuid,
  capability sys_chroot,
  capability sys_resource,

  # /etc/bind should be read-only for bind
  # /var/lib/bind is for dynamically updated zone (and journal) files.
  # /var/cache/bind is for slave/stub data, since we're not the origin of it.
  # See /usr/share/doc/bind9/README.Debian.gz
  /etc/bind/** r,
  /var/lib/bind/** rw,
  /var/lib/bind/ rw,
  /var/cache/bind/** lrw,
  /var/cache/bind/ rw,

  # 以下を追加
  /chroot/named/** r,
  /chroot/named/var/cache/** rw,
	/chroot/named/run/named/** rw,

  ...
}

4. 変更の反映

  1. AppArmorの設定の反映

    $ sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.named
  2. named.serviceの設定の反映

    ユニットファイルであるnamed.serviceを変更したため、最初に以下のコマンドで新しい設定をsystemdに反映させます。

    $ sudo systemctl daemon-reload
  3. namedの設定の反映

    $ sudo systemctl restart named

5. namedの稼働状態の確認

namedの稼働状態を確認します。

$ sudo systemctl status named

named.service - BIND Domain Name Server
        Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled)
        Active: active (running) since Thu 2023-09-14 04:00:58 UTC; 16s ago
        Docs: man:named(8)
    Main PID: 17812 (named)
        Tasks: 5 (limit: 1126)
        Memory: 10.8M
        CGroup: /system.slice/named.service
                └─17812 /usr/sbin/named -f -4 -u bind -t /chroot/named -c /etc/named.conf

Sep 14 04:00:58 ip-10-255-242-121 named[17812]: zone 0.in-addr.arpa/IN: loaded serial 1
Sep 14 04:00:58 ip-10-255-242-121 named[17812]: zone 242.255.10.in-addr.arpa/IN: loaded serial 2023070301
Sep 14 04:00:58 ip-10-255-242-121 named[17812]: zone 127.in-addr.arpa/IN: loaded serial 1
Sep 14 04:00:58 ip-10-255-242-121 named[17812]: zone 255.in-addr.arpa/IN: loaded serial 1
Sep 14 04:00:58 ip-10-255-242-121 named[17812]: zone dns.com/IN: loaded serial 2023070301
Sep 14 04:00:58 ip-10-255-242-121 named[17812]: zone localhost/IN: loaded serial 2
Sep 14 04:00:58 ip-10-255-242-121 named[17812]: all zones loaded
Sep 14 04:00:58 ip-10-255-242-121 named[17812]: running
Sep 14 04:00:58 ip-10-255-242-121 named[17812]: managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)
Sep 14 04:00:59 ip-10-255-242-121 named[17812]: resolver priming query complete

稼働状態(Active)がactive(running)であることを確認します。また、CGroupControl Group)セクションで/usr/sbin/named -f -4 -u bind -t /chroot/named -c /etc/named.confとなっていることから、namedがchroot環境で稼働していることが分かります。

6. DNSリクエストのテスト

正引きテスト・逆引きテストを行い、名前解決が行えるか確認します。

正引きテスト

$ sudo dig bind.dns.com A

; <<>> DiG 9.16.1-Ubuntu <<>> bind.dns.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31816
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;bind.dns.com.			IN	A

;; ANSWER SECTION:
bind.dns.com.		6538	IN	A	10.255.246.216

;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Sep 14 04:54:13 UTC 2023
;; MSG SIZE  rcvd: 57

ANSWER SECTION:で、bind.dns.comのIPv4アドレスは10.255.246.216と返っていることから、正しく解決されていることが分かります。

逆引きテスト

$ sudo dig @bind.dns.com -x 10.255.246.216

; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48565
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 34fe5ab55a8b186c010000006502928e8c1bc11735412193 (good)
;; QUESTION SECTION:
;10.255.246.216.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
216.246.255.10.in-addr.arpa. 86400 IN	PTR	bind.dns.com.

;; Query time: 0 msec
;; SERVER: 10.255.246.216#53(10.255.246.216)
;; WHEN: Thu Sep 14 04:56:46 UTC 2023
;; MSG SIZE  rcvd: 110

ANSWER SECTION:で、10.255.246.216のドメインはbind.dns.comと返っていることから、正しく解決されていることが分かります。

まとめ

この後編では、BINDにおけるchroot環境の続きを実践し、DNSリクエストのテストまで行い、chroot環境で問題なくBINDが動作しているかの確認まで行いました。後編の中でのchroot環境の構築における大事な部分は「chroot環境内に適切な権限を設定すること」です。これは、セキュリティの強化、データの保護、システムの安定性を確保するために不可欠です。

chroot環境を適切に構築することで、DNSサーバーのセキュリティを向上させることができます。また、各手順や設定の背後にある理由を理解することで、より効果的な運用が可能となります。不明点や詳細な情報が必要な場合は、関連する解説記事もご参照ください。

エンベーダー編集部

エンベーダーは、ITスクールRareTECHのインフラ学習教材として誕生しました。 「遊びながらインフラエンジニアへ」をコンセプトに、インフラへの学習ハードルを下げるツールとして運営されています。

RareTECH 無料体験授業開催中! オンラインにて実施中! Top10%のエンジニアになる秘訣を伝授します! RareTECH講師への質疑応答可

関連記事

2020.02.25

完全未経験からエンジニアを目指す爆速勉強法

USBも知らなかった私が独学でプログラミングを勉強してGAFAに入社するまでの話

  • キャリア・学習法
  • エンジニア

2023.11.26

gitのコミット履歴を整理するためにsquashを使いこなそう

Squashは、複数のコミットを1つのコミットにまとめる操作です。Squashを使用すると、コミットの履歴を整理したり、コミットのメッセージや変更内容を変更したりすることができます。

  • インフラエンジニア
  • git

2023.07.17

DevOpsエンジニアってどんな仕事?必要なスキルや資格など

DevOpsとは、「Development(開発」と「Operations(運用)」を組み合わせた造語です。従来は分断されていた開発と運用を連携し、同一のプロセスとして扱おうという考え方から生まれました。

  • インフラエンジニア

2023.12.27

エンジニアとしてガバメントクラウドを扱うことになったら

ガバメントクラウドは、クラウドコンピューティング技術を政府機関の業務に適用したシステムです。このシステムは、データの保存・アクセス・管理を改善し、政府の効率性と柔軟性を高めることを目的としています。日本においてガバメントクラウドの導入は、政府業務のデジタル変革と公共サービスの向上に不可欠な役割を果たしています。

  • インフラエンジニア