仕掛けられたバックドアの検出と対処：不正侵入の手口と対策（5）（2/2 ページ）

» 2003年02月10日 00時00分公開

[木村靖，三井物産セキュアディレクション株式会社]

前のページへ 1|2 　　　　　　

復旧 - 安全な状態に戻す

　「サーバを安全な状態に戻す」とは、すなわち攻撃者にバックドアを設置される前の状態に戻すことだが、具体的な復旧手順は以下のことを行う。

必要なデータのバックアップを取る
OSの再インストールと設定
ソフトウェアのアップグレード
データを戻す
最終確認と運用再開

1.必要なデータのバックアップを取る

　証拠保全と後述の「5. データを戻す」のため、対象サーバ上のデータのフルバックアップを記録メディアに採取しておく。

　【重要】バックアップした内容は、前述の調査結果とともに耐火金庫などに入れ、厳重に保管しておくとよいだろう。万が一紛失するようなことがあると、訴訟などを起こされた場合に不利になってしまうからだ。（※追加）

2.OSの再インストールと設定

　サーバ内に侵入されたと分かった時点で、OSの再インストール（ハードディスクのフォーマット含む）を強くお勧めする。なぜなら「第4回攻撃者が侵入後に行うバックドアの設置例」で紹介したとおり、バックドアの手法はさまざまで、検出ツールなどを使ったとしてもなかなか見つけ出せないものがあるからだ。また、バックドアの検出に時間を取られるよりは、いっそのことインストールし直した方が手っ取り早く復旧できるだろう。

3.ソフトウェアのアップグレード

　OSの再インストール後、使用する各種ソフトウェアを安全なバージョンにアップグレードする。特に、攻撃の脅威を外部からと限定するのであれば、外部にサービスを提供しているソフトウェアは必ず安全なバージョンにアップグレードした方がよいだろう。

4.データを戻す

　必要であればシステムファイルやコンテンツデータを戻す。もちろん、指定の場所に直接戻すのではなく、いったん別ディレクトリに展開し、内容が正しいことを確認してから戻すことをお勧めする。

5.最終確認と運用再開

　サーバを元の状態に戻したら、後は設定やコンテンツの最終確認を行い、問題なければサーバの運用を再開する。運用開始後しばらくの間は、サービスが正常に動作しているか、あるいは不審な動作が見られないかなどの状態確認を行う必要がある。

対策と日々のチェック

　ここで紹介するのは、対策というよりむしろ、侵入されたことを察知するための最善努力みたいなものだ。つまり、ここで紹介した対策を行ったからといって、侵入やバックドアの設置を未然に防げるわけではないことに注意しよう。

1.OpenSSH バックドアへの対策

　前回紹介したOpenSSHのバックドアは、sshを使いroot権限でリモートからのログインを可能にするバックドアであった。ここでは、そのバックドアを防御するための対処として、sshのrootログインを禁止する設定を紹介する。

（1）PermitRootLogin no の設定

　/etc/ssh/sshd_configファイルに PermitRootLogin no を追加する。Red Hat Linux 7.3のデフォルトでは、この設定項目がコメントアウト（有効）になっているので、以下のとおり明示的に禁止しなければならない。


変更前	#PermitRootLogin yes
変更後	PermitRootLogin no

　保存して終了した後、sshdサービスをリロード（kill -HUP）する。

# service sshd reload

（2）定期的な差分チェック

　いくら設定を変更したからといっても、攻撃者にこっそりとその設定ファイルを書き換えられてしまっては意味がない。それを回避するためには、対象となる設定ファイルの差分をcronなどで定期的にチェックするというのが現実的な対処法だろう＊2。

　差分をチェックするには、diffコマンドを用いてチェックするようなシェルスクリプトを自分で作るか、OS標準のスクリプト（BSD系UNIXなど）で定期的にチェックすればよい。あるいは、Tripwireなどのファイルの整合性をチェックしてくれるツールを利用するという手もある。

＊2当然だが攻撃者にcron自体を止められると、定期的なチェックは行えなくなる。

2.CGIバックドアプログラムへの対策

　setuid／setgidされたCGIプログラムの実行を禁止するには、理想をいえばサーバの設計段階でWeb関連のディレクトリ（/var/www）を個別のパーティションにし、/var/wwwのファイルマウント時にsetuid／setgidを無効（nosuidオプションを付加）にしてしまうことだ。しかし現実としては、サーバは既に運用中で、/var/wwwも個別に区分けしてないということの方が多いのではないかと思う。

　そうなると残された道は、直接的な対策ではないが、実行プログラムのsetuid／setgid権限を定期的にチェックするというのが最も無難な対処法となるだろう。setuid/setgidファイルは、先に紹介したとおり以下のように実行すれば見つけ出すことができるだろう。

# find / -type f \（ -perm -u+s -o -perm -g+s \） -ls

　このコマンドを定期的に実行することで、setuid／setgidされたCGIプログラムをチェックすることができる。

3.バックドア検出ツールの定期的な実行

　先ほど紹介したchkrootkitなどのバックドア検出ツールを定期的に実行し、既知のバックドアに備える。

　例：chkrootkitを毎日1時0分に実行する。実行結果はメールでrootあてに送る。その際のSubject:ヘッダは「chkrootkit daily output」とする。

（1）/etc/crontabへの追加

　エディタを使用して/etc/crontabファイルに以下の1行を追加する。

0 1 * * * root （cd /usr/local/chkrootkit-0.38; 
            ./chkrootkit -q 2>&1） | mail -s "chkrootkit daily output" 
            root

　保存した時点で設定した内容が有効になる。

（2）メールの確認

　rootあてに届いたメールの本文に、chkrootkitの実行結果が記述されていることを確認する。

4.不正なアクセスログの確認

　Logwatchなどのログチェックツールを使用して、ログに出力される不正な行為を監視する。Red Hat Linux 7.3では、デフォルトで毎日定期的にLogwatchを実行し、結果をrootにメールで送信している。今回は紹介だけにとどめるが、Logwatchの詳細については、次回説明する予定だ。

　今回は仕掛けられたバックドアへの対処と検知方法について解説した。次回は、ログの改ざんと検知、管理方法を紹介する。

参考文献
不正アクセス調査ガイド - rootkitの検出とTCTの使い方渡辺勝弘／伊原秀明著、ISBN4-87311-079-3

【お詫びと訂正】
「復旧 - 安全な状態に戻す」の「1.ネットワークから切り離す」に「先述の原因究明でも説明したが、従来ネットワークから対象サーバを物理的に切り離すことをお勧めする。」とありましたが、この項目を削除しました。（2003/1/28）

「復旧 - 安全な状態に戻す」の「1.必要なデータのバックアップを取る」の最後に「【重要】バックアップした内容は、前述の調査結果とともに耐火金庫などに入れ、厳重に保管しておくとよいだろう。万が一紛失するようなことがあると、訴訟などを起こされた場合に不利になってしまうからだ。」の一文を追加致しました。（2003/2/10）