この疑問が何の前触れもなく湧いてくることはめったにありません。サーバーが遅くなった、ホスティング会社から外向きトラフィックについて連絡が来た、あるいは自分では覚えのないログイン通知がメールに届いた。そこから不愉快な部分が始まります。何をどの順番で見ればよいのかがはっきりせず、最初に浮かぶ衝動——全部消して入れ直す——はほとんどの場合、性急にすぎます。

以下は約二十分で済み、多くの場合はっきりした答えが出る確認の手順です。安いものから高いものへと進みます。まずすぐに見えるもの、それから何らかの基準と突き合わせる必要があるものへ。

第一段階：誰がログインしたか

ログインから始めます。誰かが入り込んでいるなら、ほぼ確実に SSH 経由であり、その痕跡は残っています。

last -20
lastb | head -20
who

last は直近の成功したログインを、lastb は失敗したものを、who は今つながっている相手を表示します。重要なのは件数ではなく形です。二度と戻ってこないアドレスからの何千という失敗試行は、ごく普通の背景ノイズです。それはあらゆる公開アドレスに対して絶え間なく走っており、何も意味しません。

気にすべきなのは別のことです。

  • 自分の関係者が誰もいないアドレスからの成功したログイン；
  • 自分が作った覚えのないユーザー名でのログイン；
  • このマシンに実際に存在する名前に対する失敗試行——これは辞書を回しているのではなく、誰かがあなたのユーザー一覧を把握したことを意味します；
  • いま開いている、自分が開けたのではないセッション。

見慣れない鍵が増えていないかも別途確認してください。ファイル ~/.ssh/authorized_keys は居座るための最も一般的な手段です。パスワードは何度変えても、鍵は残ります。

cat ~/.ssh/authorized_keys
sudo cat /root/.ssh/authorized_keys

そこにある各行は誰かのアクセス権です。それが誰のものか言えないなら、他人のものとして扱ってください。

第二段階：システムの何が変わったか

侵入はほぼ必ずディスク上に痕跡を残します。差し替えられたバイナリ、設定に増えた一行、Web サーバーのディレクトリにある新しいファイル。それを目視で確認するのは絶望的です——比較する基準が要ります。

Debian と Ubuntu ではその基準がすでにあります。各パッケージは自分のファイルのチェックサムを知っているからです。

sudo apt install debsums
sudo debsums -c

このコマンドはディストリビューションが入れたものと異なるファイルを列挙します。結果の一部は正当なものです——/etc の設定ファイルは編集されるためにあります。しかし手で触った覚えのないサーバーで /usr/bin、/usr/sbin、/bin の実行ファイルが変わっているのは、まったく別の話です。

第二の手がかりは、新しいものがあるはずのない場所に現れた新しいファイルです。web shell はたいていアップロード用ディレクトリに居座り、無害そうな .php の顔をしています。

find /var/www -type f -name '*.php' -mtime -14 -ls

十四日というのは出発点にすぎません。何も公開していないと確信できる期間を使ってください。

第三段階：外へ何が出ているか

乗っ取られたサーバーが、そのサーバー自体のために破られることはめったにありません。使われるのです。スパムを送るため、採掘するため、他のネットワークへ手を伸ばすため、他人のファイルを置くため。そのすべてが、以前には無かった外向きの接続を生みます。

ss -tulpn
ss -tp state established

最初のコマンドは何が待ち受けているかを、二つ目は今何がつながっているかを示します。プロセスの列を読んでください。疑問を生むのは、0.0.0.0 で待ち受けている見知らぬプロセス、あなたのアプリケーションとは何の関係もないアドレスの高位ポートへの外向き接続、そして何より /tmp や /dev/shm から起動されたプロセスです——それらのディレクトリから正当なものが動くことはありません。

ついでに負荷も見ておきましょう。採掘プログラムは、まったく人気のないサイトなのにプロセッサをずっと忙しくさせることで自らを暴きます。

兆候が出ていたら

最初の衝動は素早く片付けることです。他人の鍵を消し、プロセスを止め、ファイルを削除する。やめてください——それと同時に、後になって彼らがどう入ったのかを説明できたはずのものが壊されます。そしてそこが不明なままなら、彼らは戻ってきます。おそらく明日にも。

データと全体像の両方を守る順序：

  1. 提供されているならプロバイダー側でディスクのスナップショットを取る。これは後からやり直せない唯一の手順です。
  2. マシンをネットワークから切り離すか、自分の IP 以外をすべて閉じる——ただし電源は落とさないこと。シャットダウンするとプロセス一覧と開いている接続が失われ、それは証拠の半分にあたります。
  3. ログをマシンの外へコピーする：/var/log/auth.log、Web サーバーのログ、上の三つのコマンドの出力。
  4. そのうえで初めて、どう入られたのかを突き止めます。

root 権限でアクセスを取られていたのなら、まっさらな再インストールが正しい締めくくりです。どんな掃除も何も残っていない保証は与えません。ただし原因を理解しないまま入れ直すのは無意味です。同じ穴を新しいシステムに置き直すことになります。

この疑問が不意打ちで来ないように

ここまでの一切は一回きりの手作業の確認であり、それが答えるのは「いま何が起きているか」です。厄介なのは、その問いがたいてい遅れて発せられることです。プロバイダーから連絡が来た後、あるいはサイトが落ちた後に。

これらの確認はどれも、継続的に見張れる独立したツールとして存在します。失敗ログインなら fail2ban、ファイルの変更なら AIDE、パッケージの完全性なら debsums、開いているポートなら ss の定期的なスナップショット。一つずつ入れること自体は難しくありません。難しいのは毎日ログインして六種類の出力を読む習慣をつけることで、だからこそ実際には誰も読まないのです。

それらをまとめたパネルの意味はまさにそこにあります。同じデータを、ただし一つのページに履歴つきで置く。そうすれば「昨日はこうではなかった」がわざわざ調べに行かなくても目に入ります。組み上がった状態がどう見えるかは、下のデモページが示しています。