Ubuntu 24.04でUSBメモリを差したとき、見た目には何も起きていないようでも、裏ではudisksdが自動でパーティションを認識してマウントしています。この仕組みは便利な反面、「いつの間にか身に覚えのないUSB機器が繋がっていた」「離席中にサーバーの前で誰かが何かした形跡がある」といった不安には答えてくれません。この記事では、USB自動マウントの挙動そのものをudisksctl・lsblk・journalctlで点検し、見覚えのない接続や自動実行の痕跡を見分ける方法を、コマンドと出力例つきで解説します。Ubuntu 24.04 LTS基準で、Debianとの違いも明記します。
Ubuntuが「自動マウント」する仕組みと、Linuxにautorun.infが効かない理由
Windowsで知られるautorun.infによるプログラム自動実行は、Linuxのファイルシステムドライバでは解釈されません。USBメモリの中身に何が入っていても、差しただけで実行ファイルが勝手に走ることはない、というのがまず押さえておきたい前提です。
ただし「何も起きない」わけではありません。Ubuntu 24.04のようなデスクトップ環境では、USBメモリを差すと次の流れでファイルが見える状態になります。
- カーネルがUSBデバイスを検出し、
udevがデバイスノード(/dev/sdb1など)を作成 udisks2デーモンがパーティション情報を取得- ログイン中のデスクトップセッション(GNOME/Nautilus、XFCEならThunar-volman、KDEならDevice Notifier)がポリシー(polkit)の許可を得て自動でマウント
ここで重要なのは、自動マウントはデスクトップセッションが動いているときだけ発生するという点です。GUIログインしていないヘッドレスなサーバーでは、USBメモリを挿しても自動ではマウントされず、udisksctl mountで手動マウントするまでファイルは見えません。自宅サーバーのような常時稼働機で「勝手にマウントされていた」ら、それ自体が誰かがコンソールにログインした痕跡である可能性を疑う材料になります。
差し込まれたUSBの正体を lsblk と udisksctl status で確認する
lsblk でパーティション情報を見る
まず、今何が繋がっているかを一覧します。lsblkはブロックデバイス(ディスク・パーティション)の一覧を見るコマンドで、sudoは不要・設定変更もありません。
lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINT,MODEL,SERIAL出力例:
NAME SIZE FSTYPE LABEL MOUNTPOINT MODEL SERIAL
sda 1T ext4 / ST1000LM048 S3P1AB2C
sdb 58G SanDisk_Ultra 4C531001A2B3C4D5
└─sdb1 58G vfat USBDISK /media/kaz/USBDISK
見るべき場所はMODEL・SERIAL・MOUNTPOINTの3つです。自分が普段使っているUSBメモリの型番・シリアル番号と一致していれば正常。見覚えのないMODELが表示されている、あるいはMOUNTPOINTが/media/自分のユーザー名/以外の妙な場所になっている場合は、いつ・誰が接続したものかを次のjournalctlの手順で確認します。
udisksctl status で自動マウントを担うドライブ一覧を見る
udisksctl status出力例:
MODEL REVISION SERIAL DEVICE
----------------------------------------------------------------
SanDisk Ultra 1.00 4C531001A2B3C4D5 sdb
lsblkの結果と型番・シリアルが一致するか突き合わせるためのコマンドです。ここもsudo不要・変更なしで安全に実行できます。
journalctl でUSB接続の履歴を洗い出す
カーネルログから接続イベントを拾う
journalctl -kはカーネルが記録したログ(dmesg相当)を、再起動をまたいでも遡って見るコマンドです。USB機器の抜き差しは必ずここに記録されます。
journalctl -k --since "24 hours ago" | grep -i usb権限がなく読めない場合は先頭にsudoを付けてください(読み取り専用・設定変更なし)。出力例:
Aug 31 09:12:01 nashi-server kernel: usb 1-2: new high-speed USB device number 5 using xhci_hcd
Aug 31 09:12:01 nashi-server kernel: usb 1-2: New USB device found, idVendor=0781, idProduct=5591
Aug 31 09:12:01 nashi-server kernel: usb 1-2: Product: Ultra
Aug 31 09:12:01 nashi-server kernel: usb 1-2: Manufacturer: SanDisk
正常/異常の見分け方を表にまとめます。
チェック項目 | 正常 | 異常の可能性 |
|---|---|---|
タイムスタンプ | 自分が物理的に操作した時刻と一致 | 離席中・不在時の時刻に接続イベントがある |
Manufacturer/Product | 手元のUSBメモリのブランド名と一致 | 空欄、または心当たりのない名称 |
接続の回数 | 1回挿して1回抜いた、の単純な履歴 | 短時間に接続・切断を繰り返している |
journalctl -u udisks2 --since todayを使うと、udisks2デーモンが実際にマウント処理を行った記録だけに絞って確認できます。カーネルログとあわせて見ると「デバイスは検出されたがマウントはされていない」といった状態の切り分けもできます。
ストレージ以外の顔を持っていないかを lsusb -t で確認する
USBメモリのはずなのに、実はキーボードやネットワークアダプタとしても認識される、というのは正規のUSBメモリでは起きません。usbutilsパッケージのlsusbで、接続機器がどんな種類として認識されているかを確認します(サーバー用途で未導入ならsudo apt install usbutils。パッケージを追加するだけで設定変更はなし、不要ならsudo apt remove usbutilsで戻せます)。
lsusb -t出力例:
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
|__ Port 2: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M
USBメモリならClass=Mass Storageの1行だけが出るのが正常です。同じデバイス番号(Devの数字)に対してClass=Human Interface DeviceやClass=Communications(ネットワーク)の行が追加で出ている場合は、ストレージ以外の機能を隠し持った機器の疑いがあります。この状態を見つけたら、すぐに抜いて、そのマシンで何も入力しないこと(キーボードとして偽装されていた場合、入力した内容が奪われる恐れがあるため)。安全が確認できるまで別マシンでの再利用も避けてください。
自動実行の設定と、あやしい udev ルールを確認する
GNOMEの「自動実行」設定を確認する
GNOME環境(標準のUbuntuデスクトップ)には、USBの中身が「ソフトウェア」だとみなされた場合に実行を促すダイアログを出す仕組みがあります。これが有効なままだと、細工されたUSBメモリを差したときに実行を促されるリスクがあるため、無効になっているか確認します。sudo不要・自分のログインユーザーの設定のみが変わります。
gsettings get org.gnome.desktop.media-handling autorun-nevertrueなら自動実行が無効化されている状態(多くのUbuntu環境の初期状態)です。falseが返ってきたら、誰か(または何らかのインストーラ)がオンにした可能性があるため、次のコマンドで戻せます。
gsettings set org.gnome.desktop.media-handling autorun-never true元の状態(スキーマの既定値)に戻したい場合はgsettings reset org.gnome.desktop.media-handling autorun-neverで取り消せます。
USB挿入をトリガーにするudevルールが仕込まれていないか
udevルールには、特定のデバイスが接続されたときに任意のコマンドを実行するRUN+=という書き方があります。これ自体はドライバの初期化などに正規で使われますが、USB接続をきっかけに見覚えのないスクリプトを実行するルールが紛れ込んでいないかは点検しておく価値があります。読み取りのみならsudo不要です。
grep -r "RUN+=" /etc/udev/rules.d/ /run/udev/rules.d/ 2>/dev/null自分でインストールした覚えのあるドライバ・ツール(プリンタやスキャナ用など)に関するものであれば正常です。見覚えのないスクリプトパスが書かれたルールがあれば、削除する前に必ずバックアップを取ってください。
sudo cp /etc/udev/rules.d/該当ファイル ~/udev_backup_$(date +%Y%m%d).bak
sudo rm /etc/udev/rules.d/該当ファイル誤って必要なルールを消してしまっても、バックアップからsudo cpで戻せば復旧します。この点検はSSHの鍵管理を扱ったSSHログとauthorized_keys突合2026年8月版と同じ「自分の環境に、身に覚えのない設定が紛れ込んでいないか」という考え方の点検です。
異常を見つけたときの対処と、マウント時の権限を絞る予防策
まず安全にアンマウントする
怪しいUSBメモリが自動マウントされている場合、ファイルマネージャの取り出しボタンではなくコマンドで確実にアンマウントします。
udisksctl unmount -b /dev/sdb1デバイス名はlsblkの結果に合わせて置き換えてください。アンマウントは元に戻す操作(再度挿せば通常どおりマウントされる)なので、実行してデータが壊れる心配はありません。
マウント時に実行権限を持たせない設定に変える
調査の結果「特定の実害は確認できないが念のため備えておきたい」場合は、リムーバブルメディアを実行不可・setuid無効でマウントするようudisks2に指示できます。sudoが必要な設定変更です。
sudo tee /etc/udisks2/mount_options.conf <<'EOF'
[defaults]
vfat_defaults=uid=$UID,gid=$GID,noexec,nosuid
EOF再起動やサービス再起動は不要で、次にUSBメモリを挿し直した時点から適用されます。元に戻す場合はsudo rm /etc/udisks2/mount_options.confで削除すれば、次回の接続から従来の挙動に戻ります。この設定は、権限昇格の観点で紹介したSUID/Capability権限昇格チェック2026年8月版とも関連します——USBメモリ上にSUIDビット付きの実行ファイルが置かれていても、noexecがあれば実行そのものがブロックされます。
Debianや他ディストリビューションとの違い
Debian 13(Trixie)でもudisks2・lsblk・journalctlの使い方は同一です。差が出るのはデスクトップ環境側で、XFCEなら自動マウントを担うのはThunar-volman、KDEならDevice Notifierになります。GNOME以外の環境ではgsettings org.gnome.desktop.media-handlingの設定項目自体が存在しないため、自動実行の可否は各デスクトップの設定パネル(XFCEなら「リムーバブルドライブとメディア」)から確認してください。RHEL/Fedora系ではパッケージ導入コマンドがdnfになる点以外は同様です。
2026年7月30日にIPAが発表した夏季の注意喚起でも、機器の接続状況を定期的に見直すことが呼びかけられています。USBメモリの点検も、特別な事件が起きたときだけでなく、月に一度など決まったタイミングでlsblkとjournalctlを見る習慣にしておくと、変化に気づきやすくなります。
関連する選択肢
自動化や検証を常時動かすなら、使っていないPCを1台あてる方法もあります。新品である必要はなく、長く動かすので保証の有無の方が効いてきます。
長期保証付きで常時400種4000台の中古PCを販売【PC WRAP】
※ 広告を含みます(A8.net)。リンク経由でお申し込みがあった場合、手数料を受け取ることがあります。
まとめ
Ubuntu 24.04ではUSBメモリを差すとudisksdが自動でマウントしますが、autorun.infのようなプログラム自動実行はLinuxでは起きません。それでもlsblk・udisksctl statusで型番とシリアルを確認し、journalctl -kで接続時刻とベンダー名を過去のログから洗い出し、lsusb -tでストレージ以外の顔を持っていないかを見れば、身に覚えのない接続はほぼ発見できます。異常があればudisksctl unmountで切り離し、必要なら/etc/udisks2/mount_options.confで実行権限を絞ることで、次の接続からリスクを減らせます。どの手順も読み取りが中心で、変更を伴うものもすべて元に戻せます。