こちらの記事は、chroot環境の構築(ハンズオン)の後編です。前編は以下の記事で紹介しています。
https://envader.plus/article/229
また、chroot環境の構築に関する解説は以下の記事で紹介しています。不明点がある場合は、その記事を参照しながら本ハンズオンを進めてください。
https://envader.plus/article/228
本記事で行うchroot環境の構築手順
本記事では以下の手順でchroot環境の構築を行います。
- chroot環境内に適切な権限を設定する
- named.serviceの変更
- AppArmorのポリシーの変更
- 変更の反映
- named(BIND)の稼働状態の確認
- 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"
上記の設定した内容を以下にまとめました。
引数 | 意味 |
---|---|
-4 | IPv4モードで動作(IPv6は無効化) |
-u bind | bindユーザーとして実行 |
-t /chroot/named | bindが動作するルートディレクトリを変更 |
-c /etc/named.conf | chroot環境内の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. 変更の反映
-
AppArmorの設定の反映
$ sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.named
-
named.service
の設定の反映ユニットファイルであるnamed.serviceを変更したため、最初に以下のコマンドで新しい設定をsystemdに反映させます。
$ sudo systemctl daemon-reload
-
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)
であることを確認します。また、CGroup(Control 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サーバーのセキュリティを向上させることができます。また、各手順や設定の背後にある理由を理解することで、より効果的な運用が可能となります。不明点や詳細な情報が必要な場合は、関連する解説記事もご参照ください。
【番外編】USBも知らなかった私が独学でプログラミングを勉強してGAFAに入社するまでの話
プログラミング塾に半年通えば、一人前になれると思っているあなた。それ、勘違いですよ。「なぜ間違いなの?」「正しい勉強法とは何なの?」ITを学び始める全ての人に知って欲しい。そう思って書きました。是非読んでみてください。
「フリーランスエンジニア」
近年やっと世間に浸透した言葉だ。ひと昔まえ、終身雇用は当たり前で、大企業に就職することは一種のステータスだった。しかし、そんな時代も終わり「優秀な人材は転職する」ことが当たり前の時代となる。フリーランスエンジニアに高価値が付く現在、ネットを見ると「未経験でも年収400万以上」などと書いてある。これに釣られて、多くの人がフリーランスになろうとITの世界に入ってきている。私もその中の1人だ。数年前、USBも知らない状態からITの世界に没入し、そこから約2年間、毎日勉学を行なった。他人の何十倍も努力した。そして、企業研修やIT塾で数多くの受講生の指導経験も得た。そこで私は、伸びるエンジニアとそうでないエンジニアをたくさん見てきた。そして、稼げるエンジニア、稼げないエンジニアを見てきた。
「成功する人とそうでない人の違いは何か?」
私が出した答えは、「量産型エンジニアか否か」である。今のエンジニア市場には、量産型エンジニアが溢れている!!ここでの量産型エンジニアの定義は以下の通りである。
比較的簡単に学習可能なWebフレームワーク(WordPress, Rails)やPython等の知識はあるが、ITの基本概念を理解していないため、単調な作業しかこなすことができないエンジニアのこと。
多くの人がフリーランスエンジニアを目指す時代に中途半端な知識や技術力でこの世界に飛び込むと返って過酷な労働条件で働くことになる。そこで、エンジニアを目指すあなたがどう学習していくべきかを私の経験を交えて書こうと思った。続きはこちらから、、、、
エンベーダー編集部
エンベーダーは、ITスクールRareTECHのインフラ学習教材として誕生しました。 「遊びながらインフラエンジニアへ」をコンセプトに、インフラへの学習ハードルを下げるツールとして運営されています。
関連記事
2020.02.25
完全未経験からエンジニアを目指す爆速勉強法
USBも知らなかった私が独学でプログラミングを勉強してGAFAに入社するまでの話
- キャリア・学習法
- エンジニア
2023.08.28
インフラエンジニア初学者のためのログ管理入門
この記事の目的はログとその管理の基本的な概念を初学者に解りやすく伝えることです。システムやアプリケーションの健全な運用をサポートするためのログの役割やその管理方法についても詳しく紹介します。
- インフラエンジニア
2024.09.28
Trivyで実現するクラウド環境のCI/CDパイプラインでの自動脆弱性チェック
Trivyは、コンテナやIaC(Infrastructure as Code)ファイル、Kubernetesクラスターなどの脆弱性を検出するオープンソースツールとして、クラウド環境のセキュリティ対策に貢献しています。
- サイバーセキュリティ
- インフラエンジニア
2024.02.07
インフラエンジニア初学者のためのsyslogログローテーション入門
ログローテーションは、ログファイルの管理を自動化し、ディスク容量を節約し、古いログデータをアーカイブするための重要なメカニズムです。Syslogと組み合わせることで、ログ管理をさらに効率化し、システムの安定性と信頼性を向上させることができます。
- インフラエンジニア