ファイルは変わる。
これは、システム管理の歴史と同じくらい古い話だ。DebianやUbuntuのボックスにパッケージをインストールして、しばらくは世界が平和な状態にある。だが、ふとした拍子に、過剰にクリーンアップしすぎるスクリプトが走ったり、誰かが触ってはいけない設定ファイルをいじったり、あるいは予期せぬシャットダウンの後にディスクが反抗したりするかもしれない。突然、頭を抱えることになる。「これ、期待通りの状態のままだろうか？何かが、いや、何でもいいから、いじられていないだろうか？」
<a href="/tag/debsums/">debsums</a>がその答えをくれる。
いや、みんな経験あるはずだ。システムがおかしい、と感じながら、ログをgrepしたり、ディレクトリをdiffしたり、暗闇で手探りしたり、何時間も費やす。あるいは、まさにこうしたデジタルの探偵作業のために作られたツールを使えばいい。Debianベースのシステムにとって、そのツールこそがdebsumsだ。
派手さはない。見出しを飾ることもない。だが、パッケージがインストールしたファイルが、文字通り、ディスク上で変更されていないかを知りたいとき、これがお役立ちちなのだ。そして、正直に言おう、テクノロジーの熱狂の渦の中で、これほど根本的に実用的なものを見つけるのは勝利に他ならない。
脆弱性スキャンを超えて
さて、これを万能のセキュリティ対策だと混同しないでほしい。ブレーキを踏もう。debsecanツールを書いている連中は、既知の脆弱性――セキュリティチームを寝汗にさせるCVE――を探すのに忙しい。debsumsは全く別のゲームをしている。パッケージが脆弱かどうかを問うているのではない。そのパッケージがそこへ置いたファイルが、元のファイルのままだろうか、と問うているのだ。
こう考えてみてほしい。debsecanはお前のIDをチェックして、監視リストに載っていないか確認する警官だ。debsumsは、お前の荷物をマニフェストと照合する警備員だ。2つの異なる仕事、どちらも重要だが、容疑者尋問に荷物検査員を送ったりはしない。
debsumsの魔法は、システム上のファイルをMD5チェックサムと比較することで行われる。これらのチェックサムは、各パッケージについて/var/lib/dpkg/info/*.md5sumsにきれいにしまわれている。ディスク上のファイルの計算されたチェックサムが、その.md5sumsファイルに記録されているものと一致しなければ、debsumsはフラグを立てる。
何が検知できるのか？
- ローカルで変更されたパッケージファイル（典型的な原因）。
- 完全に紛失したファイル。
- 発生する可能性のある、特定の種類のデータ破損やビットローテーション。
しかし、manページが素早く指摘しているように――そして、これに注意すべきだ――これは完全なセキュリティ監査ではない。主に、ローカルで改ざんされたファイルや、ハードウェアの問題によって破損したファイルを見つけるためのものだ。その区別は、期待値を設定する上で極めて重要だ。
始め方：簡単（ほとんど）
DebianやUbuntuを使っているなら、debsumsの導入は標準的なコマンドをいくつか実行するだけだ。
sudo apt-get update
sudo apt-get install debsums
念のため、これがあることを確認するには、簡単なコマンドを打つ。
debsums --version
これで確認できる。
ただ様子を見ているときは、小さく始めるのが良い。もし特定のパッケージ、例えばbashがおかしいなら、こう実行する。
debsums bash
すべて問題なければ、おそらく何も表示されないだろう。システム管理者にとっては、それが良い沈黙だ。
より迅速なトリアージのために、特に問題だけを確認したい場合は、--silentフラグが役立つ。
debsums --silent bash
これは変更されていないファイルの出力をすべて抑制し、エラーのみを残す。便利だ。
さて、ホスト全体を素早くスキャンしたい場合――私がシステムヘルスチェックで使うようなコマンド――これがお勧めだ。
sudo debsums -c
-cフラグは--changedを意味し、--silentを内包している。つまり、実際に変更されたファイルのみを報告する。このコマンドが何も返さなければ、通常は安堵のため息をついていいだろう。
設定ファイル：慎重に扱え
ここでdebsumsが少しニュアンスが出てくる、そして正直、賢い点だ。
デフォルトでは、debsumsは/etcにある設定ファイルを積極的に無視する。なぜか？これらのファイルは変更されることが期待されているからだ。アプリケーションをインストールするとき、その設定を微調整することがよくある。これらのカスタム変更をパッケージのデフォルトで上書きするのは悲劇だ。
もし設定ファイルもチェックに含めたい――たとえば、意図しない変更が心配だ――という場合は、-aフラグ（--allの略）を使える。
sudo debsums -ca
そして、設定ファイルだけをチェックしたい場合も、カバーされている。
sudo debsums -ce
これらのオプションは慎重に使おう。変更された設定ファイルが必ずしも悪いことではない。時には、それは単に通常の、責任あるシステム管理の一部だ。
チェックサムが見つからない場合
すべてのパッケージに便利な.md5sumsファイルが付属しているわけではない。debsumsは、-lフラグを使って、これらの情報が欠けているパッケージを教えてくれる。
debsums -l
これは、これらのパッケージが本質的に侵害されているとか壊れているという意味ではない。単に、debsumsがローカルチェックサムに対してそのファイルを検証できない、なぜならそもそも比較対象がないからだ。これらのパッケージについては、個別に、リポジトリを信頼するか、より深い手動チェックを行うなどの方法で対応する必要がある。
チェックサムキャッシュの再構築
debsumsにもっと多くのデータを与えたい、特にチェックサムのないパッケージのためにどうすればいいか？Debianのmanページには便利なトリックがある：APTキャッシュにパッケージアーカイブをダウンロードすることだ。
まず、チェックサムが欠けているパッケージのリストを取得する。
debsums -l
次に、そのリストを使って対応する.debファイルをダウンロードする。
sudo apt-get --reinstall -d install $(debsums -l)
これで、/var/cache/apt/archivesディレクトリがポピュレーションされる。すると、debsumsはこれらのキャッシュされたアーカイブを使用して、以前は利用できなかった場所のチェックサムを生成できる。その後、-g（generate）と-p（path）フラグを使用して、より包括的なチェックを実行できる。
sudo debsums -cagp /var/cache/apt/archives
これらのフラグの意味はこうだ。
-c: 変更されたファイルを表示。-a: 設定ファイルを含める。-g: チェックサムを欠いているパッケージのチェックサムを生成する（キャッシュされた.debファイルを使用）。-p /var/cache/apt/archives: キャッシュされた.debファイルがあるディレクトリを指定する。
このコマンドシーケンスは、Debianホストで実行できる最も強力な整合性チェックの1つと言えるだろう。これは、単に迅速な変更を探すだけでなく、システム全体をスキャンするものだ。
システムチェックのための実践的なワークフロー
もし私がDebianサーバーの調子がおかしいというタスクを与えられたら、おそらく次のような順序で進めるだろう。
-
変更箇所のクイックスキャン：
bash sudo debsums -cこれは、インストール以来変更されたファイルがないか、即座に確認できる。これが最初の防御線だ。 -
設定ファイルを含める：
bash sudo debsums -ca最初のスキャンで何も検出されなかったが、まだ疑わしい場合は、設定ファイルを含めるように範囲を広げる。これらはしばしば意図的に変更されるものだが、何が変更されたかを知っておくのは良いことだ。 -
チェックサムのないパッケージの特定：
bash debsums -lこれは、debsumsが検証できないパッケージをフラグ付けする。これらのパッケージは別途調査が必要だ。 -
欠落しているパッケージアーカイブのダウンロード：
bash sudo apt-get --reinstall -d install $(debsums -l)必要なファイルをGrabして、より詳細なチェックの準備をする。 -
包括的な整合性スキャン：
bash sudo debsums -cagp /var/cache/apt/archivesこれがグランドフィナーレだ。利用可能なすべての情報を使用して、システムの整合性についての最も明確な画像を提供する、徹底的なチェックだ。
この構造化されたアプローチは、/usr以下のファイルをランダムにdiffして、正しい問題に偶然行き当たることを願うよりも、はるかに明確な信号を提供する。それは体系的だ。
変更からの復旧
さて、debsums -cが/usr/bin/example-toolのようなファイルを変更したと出力されたら、どうするか？それがどのパッケージに属するかを知る必要がある。dpkg -Sコマンドが役に立つ。
dpkg -S /usr/bin/example-tool
これはexample-package: /usr/bin/example-toolのようなものを教えてくれ、責任あるパッケージを明確に特定してくれる。
パッケージ名がわかったら、再インストールに進むことができる。debsumsのmanページにはこのためのパイプラインが記載されているが、ステップバイステップで分解すると、より多くの制御が得られる。
-
変更されたファイルを見つける：
bash sudo debsums -c -
変更されたすべてのファイルの所有パッケージを取得し、一意にする：
bash dpkg -S $(sudo debsums -c) | cut -d: -f1 | sort -u -
それらのパッケージを再インストールする：
bash sudo apt-get install --reinstall $(dpkg -S $(sudo debsums -c) | cut -d: -f1 | sort -u)
最後のコマンドには注意してほしい。パッケージ管理されたファイルを元の状態に復元するのに非常に役立つ。しかし、それはすべての変更されたファイルを盲目的に上書きすべきだという魔法の杖ではない。もしそのファイルが意図的に変更され、その変更がまだ必要なのであれば、完全な再インストールはシステムを壊す可能性がある。盲目的に復元する前に、常にファイルが変更された理由を理解すること。
これは絶対的で達成不可能なセキュリティに関するものではない。実用的で検証可能な整合性に関するものだ。そして、そのために、debsumsはDebian管理者のツールキットにおいて不可欠なツールだ。それは憶測を排除する。
🧬 関連インサイト
- さらに読む: GitHubのAIセキュリティ、リポジトリ内のあらゆるスクリプトと設定を網羅
- さらに読む: ローンチまで1週間：障害謝罪文を書くAI
