気がついたら自分で管理しているDNSサーバーの/etc/bindにtmp-で始まるファイルが大量に掃き出されていました。
... -rw-r--r-- 1 bind bind 5267 Sep 3 08:35 tmp-0r4ItfPTMx -rw-r--r-- 1 bind bind 5267 Sep 3 08:47 tmp-s8Wik7LX69 -rw-r--r-- 1 bind bind 5267 Sep 3 09:01 tmp-az3Ek2NMn7 ...
結論：対応方法
DDNSやMaster/Slave構成などで.jnlファイルを使用しているBINDプロセスは定期的にジャーナルファイルの内容を書き出すので、zoneセクションでfileに指定しているファイルにも書き込み権限が必要になります。
解決策は簡単で、.jnlファイルとそれに対応するファイルの両方について、namedを実行しているbindユーザーの所有にすればエラーはなくなります。
変更後しばらく観察していると、tmp-*が作成される代りにzoneファイルが更新される事が分かるはずです。
本題：原因について
どうしてこういう事が発生したのかが問題です。 サーバーを構築した時は正しく権限を設定していて、動作も確認していました。
ここからの大前提として設定ファイルを格納している/etc/bindディレクトリは、root:bindの所有でtビットが立っています。
$ ls -ld /etc/bind
drwxrwsr-t 2 root bind 20480 Sep 3 11:59 /etc/bind
この設定によってnamedプロセスが上書きして欲くないファイルはroot:bindの所有として保護しています。 また動的に生成するファイルはbind:bindの所有となります。
DNSSEC固有の事情
zoneファイルの権限が変更された原因は、DNSSECを有効にしていたことに起因します。
エントリや鍵ファイルの更新のため定期的にzonesignerコマンドを実行していたのですが、 ここに少しばかり問題がありました。
操作の対象となるのは次の3つのファイルです。
対象ファイル
-rw-r----- 1 root bind 900 Sep 3 11:59 db.yadiary.net -rw-r--r-- 1 bind bind 9731 Sep 3 11:59 db.yadiary.net.signed -rw-r--r-- 1 bind bind 3489 Aug 30 05:23 db.yadiary.net.signed.jnl
db.yadiary.netは署名前のオリジナルファイルで、勝手に上書きされても困るので、rootの所有となっています。 この状態でzonesignerを実行すると次のようにパーミッションが変化します。
zonesigner実行後
-rw-r--r-- 1 root bind 9731 Sep 3 11:59 db.yadiary.net.signed
そうしたらsudoをbindユーザーで実行したらどうなるのでしょう。
sudo -u bind zonesigner -zone yadiary.net db.yadiary.net
zonesigner実行時のエラー
unable to open zone file db.yadiary.net at /usr/sbin/zonesigner line 841, <KEYREC> line 73.
namedが乗っ取られてコードを実行された場合を考えれば、DNSSECの署名に必要な鍵ファイルはbindユーザーに見られたくありません。 というわけでbindユーザーでは署名に必要なファイルが見つからないのでエラーとなって、これに直接対応する事はやめました。
とりあえずの対応策
zonesignerを実行するときのコマンドラインのメモの最後に、; chown bind db.yadiary.net.signedを加えました。
でも全体としてバランスが悪いので、他の解決策が用意されていないか探してみようと考えています。
まとめ
いろいろ調べる途中でみた設定例によると、/etc/bindディレクトリにスティッキービット(t)を立てずに紹介しているところもありました。
ファイルのセキュリティについては、chroot環境について触れているものもありました。 しかし、DNSサーバーとして不適切なエントリの追加を防止するためには、chrootだけでは十分ではありません。
namedのファイルパーミッションはいろいろ悩ましいところではあるので、少し試行錯誤してみたいと思います。
0 件のコメント:
コメントを投稿