第12回「 System Call Auditing ノススメ」
Tweet
調査対象となるプロセスがすでに判明している場合の挙動を追跡するには strace を使用します。しかし、毎年数件あるトラブル問合せの一例なのですが、「誰かがプロセスにシグナルを送信して強制終了させてしまっている可能性がある」という場合には、全プロセスを調査対象にするために System Call Auditing を使用します。
ステップ1：監査の対象とするシステムコールを確認する
System Call Auditing ではシステムコール名でルールを記述しますので、どのシステムコールを監査対象にするかを判断します。そのためには、audit パッケージのソースコードを確認します。
$ rpm -qf /sbin/auditd audit-2.3.7-5.el6.x86_64 $ yumdownloader --source audit-2.3.7-5.el6 $ rpm --checksig audit-2.3.7-5.el6.src.rpm audit-2.3.7-5.el6.src.rpm: rsa sha1 (md5) pgp md5 OK # yum-builddep -y audit-2.3.7-5.el6.src.rpm $ rpm -ivh audit-2.3.7-5.el6.src.rpm $ rpmbuild -bp ~/rpmbuild/SPECS/audit.spec $ cat ~/rpmbuild/BUILD/audit-2.3.7/lib/x86_64_table.h
シグナルの送信を監視する場合は、以下のシステムコールを対象とします。
kill tkill tgkill rt_sigqueueinfo rt_tgsigqueueinfo
定義されているシステムコールはアーキテクチャやカーネルバージョンにより異なる場合があります。例えば、 RHEL 5 のカーネルには rt_tgsigqueueinfo システムコールは存在しませんので、 RHEL 5 の場合は以降の手順に含まれている -S rt_sigqueueinfo という部分をルールから削ってください。
ステップ2：記録するためのルールを定義する
すでに auditd サービスが起動していることを確認後、 auditctl コマンドを使用してルールを追加します。
# auditctl -a exit,always -F arch=b64 -S kill -S tkill -S rt_sigqueueinfo -k signal_send # auditctl -a exit,always -F arch=b32 -S kill -S tkill -S rt_sigqueueinfo -k signal_send # auditctl -a exit,always -F arch=b64 -S tgkill -S rt_tgsigqueueinfo -k signal_send # auditctl -a exit,always -F arch=b32 -S tgkill -S rt_tgsigqueueinfo -k signal_send
RHEL の x86_64 カーネルでは32ビットプログラムも動作するようになっているので、 arch=b64 を指定したルールと arch=b32 を指定したルールの両方を指定します。逆に、 x86_32 カーネルでは64ビットプログラムは動作しませんので、 -F arch=b64 を指定したルールは不要です。
現在設定されているルールは、 auditctl コマンドの -l オプションで確認できます。
# auditctl -l -a always,exit -F arch=x86_64 -S kill,rt_sigqueueinfo,tkill -F key=signal_send -a always,exit -F arch=i386 -S kill,rt_sigqueueinfo,tkill -F key=signal_send -a always,exit -F arch=x86_64 -S tgkill,rt_tgsigqueueinfo -F key=signal_send -a always,exit -F arch=i386 -S tgkill,rt_tgsigqueueinfo -F key=signal_send
ステップ3：事象の発生後、ログの内容を確認する
問題事象が発生したら、シグナルの送信履歴を ausearch コマンドで確認します。
# ausearch -k signal_send
調査対象となるシグナル番号がすでに判明している場合には、シグナル番号も明示した上でルールを記述することにより監査ログの量を減らすことができます。しかし、どの引数がシグナル番号に対応しているかを man ページなどで確認する必要があり、当該システムコールの知識が必要になります。
ステップ4：設定を元に戻す
問題が解決して監査ログの取得が不要になったら、 auditctl コマンドで追加した行の -a という部分を -d に変更したものを auditctl コマンドで追加することにより、ルールを削除することができます。
# auditctl -d exit,always -F arch=b64 -S kill -S tkill -S rt_sigqueueinfo -k signal_send # auditctl -d exit,always -F arch=b32 -S kill -S tkill -S rt_sigqueueinfo -k signal_send # auditctl -d exit,always -F arch=b64 -S tgkill -S rt_tgsigqueueinfo -k signal_send # auditctl -d exit,always -F arch=b32 -S tgkill -S rt_tgsigqueueinfo -k signal_send
補足：永続的な設定を行う場合
auditd サービスの再起動後あるいはシステムの再起動後も含めて永続的に監視したい場合、 auditctl コマンドで追加したルールを /etc/audit/audit.rules にも追加します。なお、 augenrules コマンドを使用する設定になっている場合は、 /etc/audit/audit.rules の内容は /etc/audit/rules.d/*.rules の内容に基づいて上書きされますので、 /etc/audit/audit.rules にではなく /etc/audit/rules.d/audit.rules にルールを追加します。
---------- audit.rules の末尾に追加する内容 ここから ---------- -a exit,always -F arch=b64 -S kill -S tkill -S rt_sigqueueinfo -k signal_send -a exit,always -F arch=b32 -S kill -S tkill -S rt_sigqueueinfo -k signal_send -a exit,always -F arch=b64 -S tgkill -S rt_tgsigqueueinfo -k signal_send -a exit,always -F arch=b32 -S tgkill -S rt_tgsigqueueinfo -k signal_send ---------- audit.rules の末尾に追加する内容 ここまで ----------
（半田哲夫）
コーヒーブレーク「予期せぬトラブルへの備え」
センターで受ける問い合わせの中には、一種定番と言えるようなパターンがあります。「予期せぬサーバーの再起動」はそのひとつです。年中そうした問い合わせに対応しているわけですが、中には、対応できない問い合わせがあります。それは、 RHEL や使用しているバージョン、発生した日時くらいしか情報がなく、ログや設定ファイルも登録されていない場合です。
サポートセンターの技術者が問題を解決するプロセスは大きくは、
- ユーザーから提供されたメッセージから疑問点や解決すべき課題を定義し
- それを解決するために提供された情報を元に調査や検証を行う
の2つのステップにより構成されています。疑問点や課題は、基本的に依頼元から提示されるものですが、「予期せぬサーバーの再起動」の場合は、（まずは）再起動の原因を調べることであり明確です。調査や検証は、熟練した技術者にとってはお手の物で、過去の事例と培った経験をもとに各種ツールを駆使して淡々と作業します。しかし、いかに優秀な技術者がいても調査の対象がなければ、問題解決に向けた作業が始まりません。そこで、情報が不足する場合は依頼元には追加の情報の提供を依頼する連絡が送られることになります。そのやりとりの時間が惜しいといつも思います。
サポートセンターの中にいると、どうして必要な情報が提供されない問い合わせがあるか不思議なのですが、その理由のひとつは、サポート技術者が何をもとに調査や解析を行うかがあまり知られていないことにあるような気がします。本コラムでは、主に RHEL （カーネル）についてどのように調査を行うかをご紹介しているわけですが、カーネルに限った話ではなく、 Apache , PostgreSQL , Pacemaker 等調査に必要な情報は対象ごとに決まっています。 NTT OSS センタのポータルサイトのトップページには、問い合わせを登録する際に参考にしてもらうことを目的として、 OSS 製品毎の調査に必要な情報が詳細にまとめられたページへのリンクが置かれていますが、トラブルが発生して「とにかく早く質問を」と思う方の目には入らないのかもしれません。
「調査に必要な情報」については、商用、OSS を問わずほかのサポートセンターでも同様の情報が提供されているのではないかと思います。一年の計は元旦にありと言います。無事を祈念しつつも、予期せぬトラブルに備え、利用されているサポートセンターの説明をあらためて確認してみませんか？そして、もちろん本コラムもどうぞ引き続きおつきあいください。
（原田季栄）
Tweet