設定ファイルと起動スクリプト
コンピュータの動作を司る各種の設定ファイルと起動スクリプトを調べることも重要である。rootkitや，それに含まれるバックドア・プログラムを起動するための痕跡は，これらの設定ファイルと起動スクリプトを入念に調査することで発見することが可能になる。もちろん，不正アクセス者もこれらのファイルが調査されることを考慮し，非常にずるがしこい方法で目立たなく隠し込む。
調査を必要とするファイルは大量で，完全に調査するには気の遠くなるような時間を要する。完全を期すのなら，Tripwireなどのファイル整合性を確認できる環境をあらかじめ整えておくべきだろう。しかし，実際には事前に用意していない環境の方が多い（不正アクセスの備えをしていないコンピュータに限って不正アクセスを受けることが多い）。ここでは，それらの事前準備がされていないことを念頭に置き，手作業でファイルやスクリプトを調査していく。ただし，ここで説明するファイルとスクリプトだけでは，十分でないことを断っておく。
| ||
| ||
| ||
|
まずは，表2[拡大表示]に記載したディレクトリ，ファイルすべてに対して入念に目を通す。この際，ファイルに記述されたスクリプトやコメントのパターンを念頭に置いて調べるとよい。例えば，コメントの与え方が他の行と比べて不自然だとか，レイアウトが他のファイルと比べて不自然に感じる場合などをピックアップする。
ブートローダの設定ファイルにも注意する。liloを利用しているのなら/etc/lilo.conf，grubなら/etc/grub.confを調査する。
筆者がこれまでに調査した経験上，不正アクセス被害を受けたコンピュータ（Red Hat Linux 6.x系）では，/etc/inetd.confと/etc/rc.d/rc.sysinit，および/etc/passwdが改ざんされている場合がほとんどだった。
図22[拡大表示]はt0rnkitによって改ざんされた/etc/rc.d/rc.sysinitファイルの例である。最終行で，/usr/sbin/nscdを起動するように記述されている。このnscdは，リモート・バックドア・プログラムだと確認された。このファイルの場合，スクリプトの記述の後に，空白の行なしでコメントが始まり，単純にコマンド・ファイルだけを実行している。これは不自然である。
図23[拡大表示]は/etc/inetd.confファイルの改ざん例である。不自然な個所にtelnetのエントリが存在する。この例では，root権限でコンピュータにログインできるバックドアが設置されていた。/etc/inetd.confファイルも，inetdを使っているシステムではバックドアを仕掛けるための手段としてよく利用される。Red Hat Linux 7.x系なら，/etc/xinetd.confファイルと/etc/xinet.dディレクトリがこれに当たる。
このほか，シェルが利用するスクリプト/etc/profileや/etc/csh.cshrc，/etc/csh.loginなども調査する。同様に各利用者とrootのホームディレクトリ内に存在する.bashrc，.bash_profile，.cshrc，.loginの起動スクリプトも入念に調べて，不審なエントリが追加されていないかに注意する。
次に，rootのホームディレクトリを注意深く調べてみよう。コンピュータを攻略することに成功した不正アクセス者は，自分の痕跡を消し去るためにrootのコマンド・ヒストリ・ファイルに手を加えることがよくある。図24[拡大表示]の例も，筆者が調査したコンピュータでよく見られた手法である。コマンド・ヒストリを削除して，.bash_historyを/dev/nullにリンクすることで一切のコマンド・ヒストリを残らないようにする。これにより，不正アクセス者がrootアカウントを使用しどのような作業を行っても，それらは記録されない。コマンド・ヒストリが残らないため，不審に感じたシステム管理者が詳しく調査してみたところ，実は不正アクセスを受けていたことが判明したことがある。
ファイル・システム内を捜索
| ||
| ||
| ||
|
続いて，ファイル・システムの中から不審なファイルやディレクトリを探し出す。不正アクセス者はコンピュータ内でさまざまな行動をする。この時に，必ず何らかの痕跡をファイルあるいはディレクトリとして残す。ごくまれに存在しないこともあるが，ほとんどの場合はコンピュータに再度侵入する時のために作業用ディレクトリやツールなどを残している。これらのファイルやディレクトリは表3[拡大表示]のような特徴を持っている。
これらのファイルやディレクトリを探し出すには，findコマンドを使って図25[拡大表示]のように実行する。これらの検索によって，大量のファイルが発見されるはずだ。それらのほとんどは不正アクセスと縁のないファイルだが，本当に不正アクセスの被害を受けているのなら，リストアップされたファイルを入念に調べることによって，何らかの痕跡を発見できるだろう。
rpmを使った確認
Red Hat Linuxなど，rpmパッケージ・マネジャによって構築された環境では，簡単にシステム・ファイルやアプリケーションの整合性を確認することができる。rpmはシステム・ファイルやアプリケーション・プログラムをパッケージという単位で管理しており，すべてのパッケージの整合性を確認するための手段を提供している。
例えば，特定のファイルを含むパッケージの整合性を確認するのなら，次のように実行する。
# ./safe/rpm -Vf ＜ファイル名＞
同様に，特定のパッケージのすべての整合性を確認する場合は
# ./safe/rpm -V ＜パッケージ名＞
と実行する。また，インストール済みのパッケージすべての整合性を確認するなら，「rpm -Va」と実行する。パッケージからインストールしたファイルが，インストール直後の状態であれば，何もメッセージは表示されない。実際には，コンピュータの構築時に設定ファイルなどに手を加える必要があるため，多くのメッセージが表示される。これらすべてが不正アクセス者によって改ざんされたわけではない。注意が必要である。
図26[拡大表示]は，t0rnkitによって汚染されたコンピュータ上での「rpm -Va」の実行結果である。この例では，lsをはじめとする多くのコマンド・ファイルが書き換えられている。このように，コマンド・ファイル自身やシステムの重要な設定ファイルなどが書き換わっていないかに注意する。
ここで，「rpm -Va」によって表示されるメッセージの内容について説明しておこう。各行頭からの8文字は，変更の詳細を示している。それぞれの文字は表4[拡大表示]に示した意味を持つ。続いて表示される「c」の文字は，そのファイルが設定ファイルだということを示している。ファイル自身が失われている場合には，「missing /etc/rc.d/rc3.d/S60lpd」のように表示される。
以上のように，rpmコマンドを利用することで簡易的にシステムの整合性を確認できる。ただ，rpmコマンドの結果だけでは，そのファイルがシステム管理者によって変更されたのか，それとも不正アクセス者によるものなのかを判断できない。できればコンピュータの構築直後に「rpm -Va」を実行して，その結果を保存し，調査時の実行結果と比較するとよいだろう。
また，高度な不正アクセス者によってrpmコマンドやパッケージ情報を改ざんされたり，rootkitによるシステム情報の操作を行われた場合は，rpmコマンドの実行結果もまったく信用できない。あくまで簡易的な確認方法だと考えてほしい。
|
渡辺 勝弘 |
