debsumsでUbuntuの整合性をチェック:サーバーにルートキットを「巣食わせない」ために

Ubuntu tutorial - IT technology blog
Ubuntu tutorial - IT technology blog

lsコマンドが突然「裏切る」とき

午前2時、机の上のスマートフォンが激しく震えた。監視システムが、Ubuntu 22.04で動作している本番環境のNginxサーバーが500エラーを返し続けていることを知らせていた。SSHでログインして確認したが、Nginxのログはきれいで、設定ファイルもGit上のバックアップと全く変わっていなかった。しかし、ls -l /usr/sbin/nginxと入力したとき、手が止まった。バイナリファイルのサイズが、ステージング環境の標準ビルドと比べて約12KB異なっていたのだ。

最悪のシナリオが頭をよぎる。サーバーが侵害された可能性がある。攻撃者が実行ファイルをバックドア入りのものに置き換えたのかもしれない。こうなると、lsstatのような基本的なコマンドさえ信用できない。ディスク上のファイルがオリジナルであるかどうかを確実に知るためには、Ubuntuの公式リポジトリとチェックサム(checksum)を照合するツールが必要だ。

システムファイルが「変質」する3つの理由

運用の中で、システムファイルが変更されてしまう主な原因は3つあると考えている:

  • 物理的エラー(Bit Rot): コンポーネントの劣化により、ハードディスクやRAM上のデータが書き換わってしまう現象。確率は非常に低いが、長年稼働し続けているサーバーでは起こり得る。
  • ヒューマンエラー: sudo権限を持つ同僚が、デバッグのために/usr/bin内のファイルをvimで直接修正し、そのまま元に戻すのを忘れてしまった。
  • セキュリティインシデント: ハッカーがプロセスを隠蔽したりデータを盗んだりするために、psnetstatsshdなどの管理ツールを悪意のあるコードに置き換えた。

慌ててOSをフォーマットして再インストールしてはいけない。それでは再設定に何時間も費やすことになる。まずは、正しい判断を下すための確かな証拠が必要だ。

debsums:システムエラーを暴く「顕微鏡」

各ファイルのMD5/SHA256ハッシュを手動で比較しようと考えるかもしれないが、標準的なUbuntuシステムには/usr内に50,000以上のファイルがあり、それは不可能だ。dpkg -Vを使う人もいるが、出力が煩雑で情報のフィルタリングが難しい。

debsumsが優れているのは、ディスク上のファイルを/var/lib/dpkg/info/*.md5sumsにある標準のMD5データベースと直接照合できる点だ。たとえ1ビットの差異であっても、即座に警告を発してくれる。

1. debsumsのインストール

このツールはデフォルトではインストールされていない。apt経由で素早くインストールできる:

sudo apt update
sudo apt install debsums -y

2. 変更されたファイルを素早くスキャンする

オリジナルと異なる実行ファイルを見つけるには、以下のコマンドを使用する:

sudo debsums -c

-c(changed)フラグを使うことで、正常なファイルを除外できる。何も結果が返ってこなければ、システムは安全だ。もしファイルリストが表示されたなら、そこが今すぐ調査すべき箇所だ。

3. 設定ファイルのチェック

デフォルトでは、管理者が頻繁に設定を変更するため、debsumsは/etcディレクトリをスキップする。しかし、不審な設定が挿入されていないか疑わしい場合は、-a(all)フラグを使用する:

sudo debsums -ca

4. 特定のパッケージを指定してチェックする

先ほどのNginxのケースに戻ろう。ディスク全体をスキャンする代わりに、時間を節約するためにNginxパッケージだけに集中してチェックする:

sudo debsums nginx

もし以下のようにFAILEDと表示されれば、バイナリファイルが改ざんされていることは間違いない:

/usr/sbin/nginx                                     FAILED

システムファイルをクリーンな状態に復元する

エラーのあるファイルやハッキングされたファイルが特定できたら、最も安全な方法はaptにそのパッケージを再ダウンロードさせ、現在のファイルを上書きすることだ。例えば、nginx-coreパッケージでエラーが出た場合は、以下のコマンドを実行する:

sudo apt install --reinstall nginx-core

再インストール後、再びdebsumsを実行しよう。結果がOKになれば、ファイルはクリーンな状態に戻っている。

実践的な経験:自動化で枕を高くして眠る

サーバーに問題が発生してからチェックするのでは遅い。私は通常、毎週cronで実行される小さなスクリプトを設定している。このスクリプトはシステムを自動スキャンし、FAILEDファイルが検出された場合にTelegramへ通知を送る。

#!/bin/bash
# 変更されたシステムファイルをチェックする
LOG_FILE="/var/log/debsums_check.log"
RESULTS=$(debsums -c 2>&1)

if [ ! -z "$RESULTS" ]; then
  echo "警告:$(date) に変更されたファイルが検出されました" > $LOG_FILE
  echo "$RESULTS" >> $LOG_FILE
  # ここにTelegram通知を送信するcurlコマンドを追加
fi

重要な注意点: debsumsは「銀の弾丸」ではない。ハッカーが十分な期間root権限を奪取していた場合、/var/lib/dpkg/info/内のチェックサムデータベース自体を書き換えている可能性がある。その場合は、別のクリーンなサーバーと比較するか、外部ツール(オフラインチェック)を使用する必要がある。

まとめ

プロフェッショナルなサーバー管理において、推測は禁物だ。debsums is, システムの整合性について具体的な数値と証拠を与えてくれる。今日、sudo debsums -cを実行してみてほしい。これまで気づかなかった「興味深い」変更が見つかるかもしれない。

Share: