PAMバックドアPlague点検2026年9月最新

2026年に入ってから、SSHの認証をすり抜けて居座る「Plague」というLinux向けPAM(パム)バックドアの報告が相次いでいる。PAMとはLinuxのログイン認証をまとめて処理する仕組みのことで、ここに不正なモジュールが仕込まれると、正しいパスワードを知らない攻撃者でもSSHでログインできてしまう。この記事では、自分のUbuntu/Debian環境のPAMが改ざん・不正追加されていないかを、dpkg -V libpam-modulesと/etc/pam.d/の目視点検だけで見分ける方法をまとめる。読み取り専用のコマンドが中心なので、初めてでも壊す心配なく実行できる。

「Plague」とは何か - PAM認証をすり抜けてSSHに居座る手口

PAMは「Pluggable Authentication Modules」の略で、SSHログインやsudoのパスワード確認など、Linuxのあらゆる認証処理を一手に引き受けている仕組みだ。実体は/usr/lib/x86_64-linux-gnu/security/(環境により/lib/security/)にある.soという拡張子の小さなプログラム(モジュール)群で、どのモジュールをどの順番で使うかを/etc/pam.d/配下の設定ファイルが指定している。

Plagueと呼ばれるバックドアは、この仕組みの正規モジュールに成りすます、あるいは正規モジュールに紛れ込ませる形で自分自身を常駐させ、特定のパスワードやバックドア用の合言葉を使うとSSH認証を素通りできるようにする手口だ。厄介なのは、通常のログインログやss・psで見る通信・プロセスの点検では気づきにくい点にある。認証そのものを乗っ取っているため、表面上は普段どおりのSSH接続に見えてしまう。だからこそ、パッケージが本来インストールしたPAMモジュールと、実際にディスク上にあるモジュールが一致しているかを直接確認する必要がある。

ライブラリの読み込み経路を悪用する持続化手口としては、ld.so.preload点検|Auto-Color2026/9で扱った手口も系統が近い。あわせて点検しておくと安心材料が増える。

dpkg -V libpam-modules でPAMモジュールの改ざんを確認する

Ubuntu/Debianでは、apt(パッケージ管理システム)がインストールしたファイルのチェックサム(内容から計算した指紋のようなもの)を記録している。dpkg -Vはこの記録と実際のファイルを比較し、パッケージインストール後に中身が書き換えられていないかを確認するコマンドだ。sudoは不要で、設定を変更するコマンドではないので何度実行しても安全。

dpkg -V libpam-modules

正常な場合、このコマンドは何も表示せずに終わる。何か行が出てきたら、そのファイルがパッケージ本来の状態から変化している合図だ。

$ dpkg -V libpam-modules
??5?????? /usr/lib/x86_64-linux-gnu/security/pam_unix.so

出力の見方は次の通り。9文字のうち3文字目が実際の内容の差を表す。

ここで重要なのは、libpam-modulesが持つファイルはほぼすべて.soの実行モジュールで、設定ファイル(conffile)のように管理者が日常的に手を入れる対象ではないという点だ。5が出た場合、それは「誰かが意図的に書き換えた」か「インストール自体が壊れている」かのどちらかであり、放置してよい差分はほぼ存在しない。

該当ファイルがどのパッケージ由来かも確認する

もし見覚えのないファイルパスが混ざっていたら、そもそも正規パッケージが配置したものかを次のコマンドで確かめる。

dpkg -S /usr/lib/x86_64-linux-gnu/security/pam_unix.so

$ dpkg -S /usr/lib/x86_64-linux-gnu/security/pam_unix.so
libpam-modules-bin: /usr/lib/x86_64-linux-gnu/security/pam_unix.so

正常なら上記のように所属パッケージ名が返る。もし

$ dpkg -S /usr/lib/x86_64-linux-gnu/security/pam_extra.so
dpkg-query: no path found matching pattern /usr/lib/x86_64-linux-gnu/security/pam_extra.so

のように「no path found」と返ってきたら、それはどのパッケージも配置していないファイルがそこに存在するという意味で、攻撃者が後から置いたモジュールである強い疑いがある。

/etc/pam.d/ の設定ファイルを目視点検して不正な追加を見つける

/etc/pam.d/配下のファイルは「どの認証モジュールを、どの順番で、どんな条件で使うか」を書いた設定ファイルで、これは前述のdpkg -Vとは別に(パッケージとしてはlibpam-runtime由来)、意図的な編集が想定されているファイル群のため、書き換わっていても機械的な検知はできない。SSHの認証に関わる部分は必ず目視で確認する。

cat /etc/pam.d/sshd

典型的な内容は次のようになっている(コメント行は省略した抜粋例)。

@include common-auth
account    required     pam_nologin.so
@include common-account
password   @include common-password
@include common-session

確認するポイントは2つ。

• 見覚えのない行が増えていないか。特にauth sufficient pam_permit.soのように「これさえ通れば無条件で認証成功」とするタイプの行や、標準にはないファイル名の.soを呼び出す行は要注意
• 行の並び順が変わっていないか。PAMは上から順に評価するため、本来は最後に評価されるはずの許可判定が先頭に移動しているだけでも、実質的に認証をスキップできてしまう

比較対象がないと判断しづらい場合は、変更履歴のあるパッケージ管理の仕組みを使う。conffileとして管理されているため、次のコマンドで「パッケージが最初に配置した内容」との差分を確認できる。

sudo apt install --reinstall --dry-run libpam-runtime
diff /etc/pam.d/sshd /usr/share/pam-configs/unix 2>/dev/null

厳密な差分比較用のコマンドではないため参考程度だが、身に覚えのない大きな構成変更がないかの当たりをつけるのに使える。

共通設定ファイルもあわせて見る

個別サービスの設定だけでなく、多くのサービスが読み込む共通ファイルも忘れずに確認する。

cat /etc/pam.d/common-auth

ここはsshdを含む複数のサービスから@includeで参照される中枢部分のため、1か所の改ざんで影響範囲が広い。行数が普段より増えていないか、日付やパーミッションに違和感がないかをls -la /etc/pam.d/で見ておくとよい。

異常が見つかったときの対応と、点検の位置づけ

点検自体はすべて読み取り専用のコマンドで、システムの設定は一切変更しない。ただし異常が見つかった後の対応は、手順を誤るとSSHで二度とログインできなくなるリスクがあるため、順序を守ることが大切だ。

1. 今の接続を切らない。SSHで作業しているなら、そのセッションはそのまま開いたまま、必ず別のターミナルでもう1つ新規にSSH接続を試す。設定変更後にログインできなくなった場合の逃げ道を残すため
2. 疑わしい設定ファイルはまず削除・上書きせずバックアップを取る。sudo cp -a /etc/pam.d/sshd /etc/pam.d/sshd.bak.$(date +%Y%m%d)
3. 不正な行だけをテキストエディタで取り除き、新しいSSHセッションでログインできることを確認してから、元の作業セッションを閉じる
4. dpkg -Vでモジュール本体の改ざんが出た場合は、設定ファイルの修正だけでは不十分。sudo apt install --reinstall libpam-modules libpam-modules-bin libpam-runtimeでパッケージそのものを再インストールし、モジュールを正規の状態に戻す
5. 侵入経路が他にも残っている可能性があるため、他のユーザーアカウントの追加や、authorized_keysへの見覚えのない鍵の追加がないかも合わせて確認する

なお、ディストリビューションによって細部は異なる。RHEL/CentOS/Fedora系はdpkgではなくrpm -V pamで同様の検証ができ、モジュールの配置先も/usr/lib64/security/になる。Arch系はpacman -Qkk pamが相当するコマンドだ。この記事の手順はUbuntu/Debian(apt/dpkg系)を前提にしている。

PAMの改ざんは検知が難しい分、月1回など定期的にdpkg -V libpam-modulesを習慣にしておくことが最大の対策になる。カーネル側の権限昇格に関わる別系統の点検としてはCVE-2026-31431点検|userns制限2026年9月も合わせて確認しておくと、ログイン後に権限を奪われる経路もカバーできる。

関連する選択肢

手元のPCを開いている間しか動かない、という問題を避けるなら、常時起動しているサーバーを借りてそこに置く方法があります。料金はプランによって変わります。

SSDプランが月々698円から使える！さくらのVPS

※ 広告を含みます（A8.net）。リンク経由でお申し込みがあった場合、手数料を受け取ることがあります。

まとめ

Plagueのような PAM バックドアは、SSHのプロセスや通信ポートを見ただけでは気づけない、認証そのものを乗っ取る手口だ。対策は難しくなく、dpkg -V libpam-modulesでモジュール本体の改ざんを確認し、/etc/pam.d/配下を目視で確認して見覚えのない行や順序の変化がないかを見るだけでよい。いずれも読み取り専用のコマンドで、実害が出ている場合だけ設定ファイルの修正やパッケージ再インストールに進む。まずは自分のサーバーでdpkg -V libpam-modulesを1回実行し、何も表示されないことを確かめるところから始めてほしい。