ファイヤーウォールのロックダウンへの備えとして最も使える予防策のひとつが、ファイヤーウォールのリセットを行うスクリプトがおよそ 5分毎に実行されるように cron を設定しておく方法だ。ファイヤーウォールが完璧に機能することが確認できたら、その cron ジョブはすかさず削除する。ジョブは下記のようなものになるだろう。コマンド cron -e で入力できる。
*/5 * * * * /etc/init.d/rc.flush-iptables.sh stop
作業対象サーバが固まる恐れのちょっとでもある作業を開始する前に、その cron ジョブが間違いなく動作して予定通りの作用をしてくれることを必ず確認しておかなければならない。
syslog 機構もまた、スクリプトのデバグで常用するツールのひとつだ。 syslog は、八百よろずのプログラムの吐き出すログメッセージをログするための機構だ。実際のところ、カーネルも含め、大きなプログラムの大多数は syslog によるロギングをサポートしている。 syslog へ送られるメッセージは必ず、ふたつの基本的な変数を保持している。 ファシリティ (facility) と、レベルまたはプライオリティ (level/priority) だ。このことは覚えておいて損はない。
ファシリティは syslog に対して、そのログエントリが何者からのものでどこに記録されるべきかを伝える。定義済みのファシリティは何種類もあるが、今対象となるのは kern ファシリティ。またの名を kernel ファシリティという。 netfilter から生成されるメッセージは全て、このファシリティを使って送られる。
ログレベルは syslog に、そのログメッセージの重篤度を伝える。利用可能なプライオリティには以下のものがある。
debug
info
notice
warning
err
crit
alert
emerg
syslog.conf の設定により、これらプライオリティに応じて異なったファイルへログを送ることができる。例えば warning プライオリティを持った kern ファシリティのメッセージを全て /var/log/kernelwarnings というファイルへ送るには、下記のように命令する。これは /etc/syslog.conf に書く文言だ。
kern.warning /var/log/kernwarnings
ご覧の通り、極めて単純。うまくいけば (syslog サーバをリスタートするか HUP を送った後) netfilter のログが /var/log/kernelwarnings に書かれているのを確認できるはずだ。もちろん、これは netfilter のロギングルールでどのログレベルを指定しているかにもよる。ログレベルは --log-level オプションで指定できる。
ルールセット中でしかるべき log ルールの与えてある行を通ったパケットならば、このファイルから必ず情報が得られるはずだ。この方法を使えば、おかしな徴候を具体的に知ることができる。例えば、どのチェーンにも末尾に log ルールを設定しておけば、各チェーンを過ぎて持ち越されるパケットがあるかどうかを調べることができる。ログに現れるエントリは下記に類するものになるだろう。見ての通り様々な情報を含んでいる。
Oct 23 17:09:34 localhost kernel: IPT INPUT packet died: IN=eth1 OUT=
MAC=08:00:09:cd:f2:27:00:20:1a:11:3d:73:08:00 SRC=200.81.8.14 DST=217.215.68.146
LEN=78 TOS=0x00 PREC=0x00 TTL=110 ID=12818 PROTO=UDP SPT=1027 DPT=137 LEN=58
このように、 syslog はルールセットのデバグに非常に役に立つ。採取したログを調べれば、開けたいポートが開かない理由を知る糸口がつかめるだろう。