Ubuntu 24.04 LTSには「AppArmor」という機能が標準で入っていますが、多くの人はインストール時に有効になっていることすら意識していません。aa-statusというコマンド一つで、今のプロセスがどこまで守られているか、逆に守られていないプロセスがどれかを確認できます。難しい設定作業ではなく「見るだけ」で数分で終わるので、まずは自分のサーバー・PCの現状を把握するところから始めましょう。

aa-statusとは何を確認するコマンドか

AppArmorは、プロセスごとに「このファイルは読んでいい」「この通信はしていい」という許可リストを適用する仕組みです。仮にsshdやNginxのようなプログラムに脆弱性があって乗っ取られても、AppArmorのプロファイル（許可リストの設定ファイル）が付いていれば、被害をそのプログラムに許可された範囲だけに抑えられます。Ubuntuはこの機能をデフォルトで有効にして出荷している数少ないディストリビューションの一つです。

aa-statusは、今読み込まれているプロファイルが「enforce（強制）」「complain（記録のみ）」「unconfined（プロファイルなし）」のどれになっているかを一覧で見せてくれるコマンドです。3つのモードの違いは次の通りです。

モード

動作

安全性

enforce

許可されていない動作を実際にブロックする

高い（本来の状態）

complain

ブロックはせず、違反をログに記録するだけ

低い（テスト中の状態）

unconfined

プロファイル自体が適用されていない

AppArmorによる保護なし

sudo aa-statusを実行して出力を読む

実際に確認してみます。設定を変更するコマンドではなく状態を表示するだけなので、実行しても環境に影響はありません。

sudo aa-status

出力例（値は例示用の架空のものです）

apparmor module is loaded.
53 profiles are loaded.
30 profiles are in enforce mode.
   /usr/lib/snapd/snap-confine
   /usr/sbin/sshd
   /usr/sbin/cups-browsed
   /usr/sbin/tcpdump
   ...
20 profiles are in complain mode.
   /usr/sbin/nginx
   /usr/sbin/mysqld
   ...
3 processes have profiles defined.
2 processes are in enforce mode.
   /usr/sbin/sshd (1234)
   /usr/sbin/cups-browsed (1522)
1 processes are in complain mode.
   /usr/sbin/nginx (2001)
0 processes are unconfined but have a profile defined.

見るべき箇所は3つです。

  • 「◯ profiles are in enforce mode」の数――実際にブロックが効いているプロファイルの数。全体（loaded数）に対してこの数が少なすぎないか。
  • 「◯ profiles are in complain mode」の一覧――記録だけで守られていないプロファイル。ここに公開しているサービス（Webサーバーやsshdなど）の名前があれば要注意。
  • 「◯ processes are unconfined but have a profile defined」――プロファイルは用意されているのに、今動いているプロセスには適用されていない状態。0でなければ確認が必要です。

特に注目したいのはnginxがcomplainモードで載っている例です。外部からアクセスを受けるプロセスがcomplainのままだと、実際の攻撃が来てもAppArmorは記録するだけで止めてくれません。

enforce・complain・unconfinedをプロセス単位で見分ける

aa-statusに載らない「そもそもプロファイルがない」プロセスを探す

aa-statusが表示するのは「プロファイルが存在するもの」だけです。プロファイル自体が用意されていないプログラムは一覧に出てきません。ネットワークを待ち受けている（ポートを開いている)のにプロファイルが一切ないプロセスは、次のコマンドで別途洗い出せます。

sudo aa-unconfined

出力例

1234 /usr/sbin/sshd confined by 'sshd (enforce)'
2001 /usr/sbin/nginx confined by 'usr.sbin.nginx (complain)'
2450 /usr/local/bin/app-server not confined

末尾がnot confinedになっている行が、プロファイルが存在せず無防備なままネットワークに接続されているプロセスです。自分で入れた独自アプリやDockerで動かしているプロセスがここに出やすい傾向があります。

この確認が今なぜ意味を持つか

2026年に入ってから、Linuxカーネルではログイン済みの一般ユーザーがroot権限を奪う「ローカル特権昇格」の脆弱性が立て続けに報告されています。ネットワークのbonding機能に約19年間気づかれずに存在していたCVE-2026-43456や、SCTPスタックのCVE-2026-64564（SCTPhantom）、米CISAが悪用確認済みとして注意喚起したCVE-2026-53362（Frag Gap）などです。IPAの「情報セキュリティ10大脅威」でも「システムの脆弱性を悪用した攻撃」が上位に挙げられています。こうした脆弱性はカーネル側のパッチ適用が第一の対策ですが、万が一プロセスを乗っ取られても、AppArmorがenforceで効いていれば奪われた権限の使い道を制限できるという二重の備えになります。complainやunconfinedのままだと、この備えが実質機能していません。

complainのままのプロファイルをenforceに切り替える（元に戻す方法つき）

切り替えにはsudoが必要で、動いているアプリの挙動に影響する可能性がある設定変更です。いきなり全部を切り替えず、まずは1つずつ試すことをおすすめします。

# enforceに切り替える
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

# 元のcomplainに戻す
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

# プロファイル自体を無効化する（さらに戻すにはaa-enforceかaa-complainを使う）
sudo aa-disable /etc/apparmor.d/usr.sbin.nginx

切り替え後は該当サービスが正常に動くか（Webサーバーならページが表示されるか等）を必ず確認してください。enforceにした直後に動作がおかしくなった場合は、一旦aa-complainで元に戻し、次の項目で紹介するログを見て何がブロックされたのかを確認してから、プロファイルの許可設定を調整します。

拒否ログの確認方法とディストリごとの違い

AppArmorが実際に何かをブロック・記録した場合、カーネルログに残ります。次のコマンドで直近の記録を確認できます。

sudo journalctl -k | grep -i apparmor

出力例

Sep 14 09:12:03 myserver kernel: audit: type=1400 audit(1757...): apparmor="DENIED" operation="open" profile="usr.sbin.nginx" name="/etc/shadow" pid=2001 comm="nginx"

apparmor="DENIED"の行があれば、そのプロファイルが実際に何かをブロックした証拠です。name=の部分に見覚えのないファイルパスがあれば、正規の動作なのか異常なのかを見極める材料になります。正規のアプリ動作であればプロファイルに許可を追加し、身に覚えのない動きであれば侵害の可能性を疑って調査を進めてください。

ディストリの違いについて、AppArmorが標準で有効なのはUbuntu系です。Debianはパッケージ自体は用意されていますが、sudo apt install apparmor apparmor-utilsでの導入と有効化が別途必要で、標準では無効の環境が珍しくありません。RHEL系（AlmaLinux・Rocky Linuxなど）はAppArmorではなくSELinuxが標準なので、この記事のコマンドはそのままでは使えません（sestatusで代替確認します）。なお、Debian 11（Bullseye）は2026年8月31日に公式サポートが終了しているため、まだ使っている場合はAppArmorの点検以前に、まずDebian 12（Bookworm）へのアップグレードを検討してください。

ログイン試行やプロセスの不審な挙動をあわせて確認したい場合は、SSH総当たり攻撃をjournalctlで即検知2026年9月版やlsmodで不要カーネルモジュール点検2026年9月版もあわせて確認しておくと、AppArmorだけではカバーしきれない範囲も点検できます。

まとめ

sudo aa-statusは、Ubuntu 24.04 LTSで実際にどのプロセスが守られていて、どのプロセスが記録だけ・無防備なのかを数分で確認できるコマンドです。enforce・complain・unconfinedの意味を押さえ、公開サービスがcomplainのまま放置されていないか、aa-unconfinedでプロファイル自体が無いプロセスがないかをチェックしましょう。2026年はカーネルのローカル特権昇格の脆弱性報告が続いており、AppArmorが効いているかどうかは被害の広がり方を左右します。切り替えはaa-enforce・aa-complainでいつでも戻せるので、まずは今の状態を知ることから始めてください。