サーバーに今、知らないプロセスが動いていないか——確認しようとしても、psコマンドやnetstatの出力を目で追うだけでは限界があります。osqueryは、Linuxのシステム状態を「テーブル」として抽象化し、SQLで照会できるオープンソースのエンドポイント監視ツールです。不審なプロセス、開いていないはずのポート、増えたユーザーアカウント——こうした変化をリアルタイムに検知できます。
この記事では、osqueryのインストールから基本クエリの書き方、継続監視の設定まで、現場で使えるレベルで解説します。

osqueryとは?Linuxシステム状態をSQLで照会するツール
osqueryは、Facebook(現Meta)のエンジニアチームが2014年に開発し、OSSとして公開したエンドポイント監視フレームワークです。Linux・macOS・Windowsに対応しており、OSの内部状態をリレーショナルデータベースのテーブルとして見せてくれます。
仕組みのポイント
通常、Linuxのシステム情報を取得するには/procファイルシステムやカーネルAPIを直接操作する必要があります。osqueryはこれらを抽象化し、「processesテーブル」「listening_portsテーブル」「usersテーブル」などとして扱えるようにします。管理者は慣れ親しんだSQLで照会できるため、専門的なシェルスクリプトを書かなくても複雑な条件での調査が可能です。
主な用途
・インシデント調査: 侵害の痕跡(IoC)を素早くクエリで探す
・定期監査: セキュリティポリシー違反の設定や権限を自動検出する
・コンプライアンス確認: PCI DSS・ISO 27001などの要件に対する状態確認
・インベントリ管理: インストール済みパッケージ・ユーザー一覧の把握
他ツールとの違い
同じLinuxセキュリティ監視ツールであるFalco(eBPF)がリアルタイムのシステムコール監視に強みを持つのに対し、osqueryは「今この瞬間のシステム状態」をスナップショットとして照会することに優れています。Falcoとosqueryはアプローチが異なり、組み合わせることで監視の死角を埋められます。
Linuxへのインストール方法
osqueryは公式のリポジトリから導入するのが最も安全です。
1. Ubuntu/Debian系
# 公式GPGキーの取得 curl -L https://pkg.osquery.io/deb/pubkey.gpg | sudo gpg --dearmor -o /usr/share/keyrings/osquery-archive-keyring.gpg # リポジトリの追加 echo "deb [signed-by=/usr/share/keyrings/osquery-archive-keyring.gpg] https://pkg.osquery.io/deb deb main" \ | sudo tee /etc/apt/sources.list.d/osquery.list # インストール sudo apt update sudo apt install osquery
2. CentOS/RHEL系
# 公式RPMリポジトリの追加 curl -L https://pkg.osquery.io/rpm/GPG | sudo tee /etc/pki/rpm-gpg/RPM-GPG-KEY-osquery sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-osquery sudo tee /etc/yum.repos.d/osquery.repo <<EOF [osquery] name=osquery baseurl=https://pkg.osquery.io/rpm enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-osquery EOF sudo dnf install osquery
3. インストール確認
# バージョン確認 osqueryi --version # 対話モードを起動 sudo osqueryi
sudo osqueryiを実行すると対話シェルが起動します。rootではなくsudoで実行するのが基本です(全テーブルへのアクセスにroot相当の権限が必要なため)。
osqueryi対話モードで学ぶ重要クエリ
セキュリティ監視の観点で特に有用な5つのユースケースを解説します。
1. 実行中プロセスを確認する
不審なプロセスを見つけるには、通常のパスにないプロセスをフィルタリングします。
-- root権限(uid=0)で動作し、標準パス以外にある実行ファイル SELECT pid, name, path, cmdline, uid, start_time FROM processes WHERE uid = 0 AND path NOT LIKE '/usr/%' AND path NOT LIKE '/bin/%' AND path NOT LIKE '/sbin/%' AND path NOT LIKE '/lib/%' AND path != '' ORDER BY start_time DESC;
このクエリは、rootとして動いているにもかかわらず標準的なシステムパス以外から起動しているプロセスを列挙します。バックドアやウェブシェルの実行プロセスが潜んでいた場合に発見しやすくなります。
2. リッスン中のネットワークポートを確認する
-- 待ち受けポートとプロセス名を一覧表示 SELECT l.port, l.address, l.protocol, p.pid, p.name, p.path, p.cmdline FROM listening_ports l JOIN processes p ON l.pid = p.pid WHERE l.port != 0 ORDER BY l.port;
netstat -tlnpやss -tlnpと同様の情報が得られますが、プロセスの詳細情報と結合できるため、予期しないポートを開けているプロセスのフルパスやコマンドライン引数まで一気に確認できます。
3. 不審なアウトバウンド接続を検出する
-- ESTABLISHEDな外部接続を確認 SELECT p.pid, p.name, p.path, c.local_address, c.local_port, c.remote_address, c.remote_port, c.state FROM process_open_sockets c JOIN processes p ON c.pid = p.pid WHERE c.state = 'ESTABLISHED' AND c.remote_address NOT LIKE '127.%' AND c.remote_address NOT LIKE '10.%' AND c.remote_address NOT LIKE '192.168.%' AND c.remote_address NOT LIKE '172.1%' ORDER BY p.name;
マルウェアがC2(コマンド&コントロール)サーバーと通信している場合、外部IPへのESTABLISHED接続として現れます。定期的にこのクエリを実行して差分を確認する習慣が侵害の早期発見につながります。
4. ユーザーアカウントとroot権限を確認する
-- uid=0(root相当)のユーザーを全列挙 SELECT username, uid, gid, description, directory, shell FROM users WHERE uid = 0; -- ログインシェルを持つ通常ユーザー一覧 SELECT username, uid, gid, directory, shell FROM users WHERE uid >= 1000 AND shell NOT LIKE '%nologin%' AND shell NOT LIKE '%false%';
攻撃者がシステムに侵入した後、永続化のために隠しアカウントをuid=0で作成するケースがあります。想定外のrootアカウントがあればすぐに調査が必要です。
5. 重要ファイルの変更を検出する
-- 過去24時間以内に変更された/etc以下のファイル SELECT path, mtime, size, uid, gid, permissions FROM file WHERE path LIKE '/etc/%' AND mtime > (strftime('%s', 'now') - 86400) ORDER BY mtime DESC;
/etc/passwd、/etc/sudoers、/etc/crontabなどの重要設定ファイルへの予期しない変更は侵害の痕跡になり得ます。ファイル整合性監視ツール(AIDEなど)と組み合わせると監視の精度が上がります。
osquerydデーモンで継続監視する
osqueryiは手動での調査向けです。継続的な監視にはosquerydデーモンを使います。
1. 設定ファイルの作成
/etc/osquery/osquery.confを作成します。
{ "options": { "config_plugin": "filesystem", "logger_plugin": "filesystem", "logger_path": "/var/log/osquery", "schedule_splay_percent": 10, "events_expiry": 3600, "verbose": false, "worker_threads": 2 }, "schedule": { "process_monitor": { "query": "SELECT pid, name, path, cmdline, uid FROM processes WHERE uid = 0 AND path NOT LIKE '/usr/%' AND path NOT LIKE '/bin/%' AND path != '';", "interval": 300, "description": "Monitor for unexpected root processes" }, "listening_ports": { "query": "SELECT l.port, l.address, p.name, p.path FROM listening_ports l JOIN processes p ON l.pid = p.pid WHERE l.port != 0;", "interval": 600, "description": "Monitor listening network ports" }, "user_accounts": { "query": "SELECT username, uid, gid, directory, shell FROM users WHERE uid = 0;", "interval": 3600, "description": "Monitor root-equivalent accounts" }, "etc_file_changes": { "query": "SELECT path, mtime, uid, permissions FROM file WHERE path LIKE '/etc/%' AND mtime > (strftime('%s', 'now') - 3600);", "interval": 3600, "description": "Monitor changes to /etc files" } } }
intervalはクエリ実行間隔(秒)です。頻度が高いほどCPU負荷が増えるため、重要度に応じて調整してください。
2. フラグファイルの設定
/etc/osquery/osquery.flagsを作成します。
--config_path=/etc/osquery/osquery.conf --logger_path=/var/log/osquery --pidfile=/var/run/osquery.pid --audit_allow_config=true --audit_persist=true --disable_audit=false
3. デーモンの起動と自動起動設定
# サービスの起動 sudo systemctl start osqueryd sudo systemctl enable osqueryd # 状態確認 sudo systemctl status osqueryd # ログ確認 sudo tail -f /var/log/osquery/osqueryd.results.log | python3 -m json.tool
結果ログは/var/log/osquery/osqueryd.results.logにJSON形式で出力されます。前回の実行からの差分(追加・削除されたレコード)がdiffTypeフィールド("added"/"removed")として記録されるため、変化した部分だけを追えます。
4. SIEMへの転送
osqueryのJSONログはWazuhをはじめとするSIEMツールと連携しやすい形式です。FilebeatやFluentdでログを収集し、Elasticsearch/OpenSearchやSIEMプラットフォームに転送することで、複数サーバーの状態変化を一元管理できます。
中小企業でも今日からできること
「SIEM連携まで整備するのはハードルが高い」という場合でも、以下のステップから始められます。
・まず osqueryi を手元で試す: 本番サーバーにインストールして月1回程度、不審プロセスと聴取ポートのクエリを手動で流すだけでも意外な発見があります
・重要クエリ3本をcronで定期実行: osqueryi をバッチモードで呼び出してログファイルに記録するシンプルな方法です。osqueryi --json "SELECT pid, name, path FROM processes WHERE uid=0" > /var/log/osquery_root_procs.jsonのように使えます
・変化があったときだけアラートを上げる: osquerydのdiff機能を活用すれば、変化がない限り無音のログになります。added/removedが記録されたときのみメール通知するスクリプトと組み合わせると実用的です
・Linux の基礎的な権限管理と組み合わせる: osqueryで「何が動いているか」を把握しつつ、Linuxのファイルパーミッションやユーザー権限の設定も適切に保つことで、監視と防御の両輪が揃います。Linuxのパーミッション管理の詳細は姉妹サイトLinuxMaster.JPでも解説しています
よくある誤解と注意点
「osqueryを入れれば安全になる」は誤り
osqueryは監視ツールです。問題を検知するためのもので、攻撃を防御する機能はありません。検知した結果をもとに人間が対応することが前提です。ファイアウォールやSELinux、fail2banといった防御ツールとセットで使うことで意味を持ちます。
root権限での実行と保護
osquerydはrootとして動作するため、攻撃者にosquery設定ファイルや実行バイナリを改ざんされると監視が機能しなくなります。chattr +iでosqueryの設定ファイルを不変にするか、ファイル整合性監視でosquery自身を守ることを検討してください。
クエリのパフォーマンスに注意
fileテーブルに対してSELECT * FROM file WHERE path LIKE '/%'のような広すぎるクエリを投げると、ファイルシステム全体をスキャンして高負荷になります。スケジュールクエリは対象パスを限定して書くことが重要です。
ハルシネーションに注意するクエリ設計
osqueryに存在しないテーブル名や列名を指定してもエラーになるだけです。使用前に.tablesコマンドで利用可能なテーブル一覧を確認し、.schema processesのようにスキーマを確認してからクエリを書く習慣をつけましょう。

まとめ
osqueryは「Linuxサーバーの今の状態をSQLで調べる」という直感的なアプローチでエンドポイント監視の敷居を下げてくれるツールです。
| ユースケース | 主なテーブル | 難易度 |
|---|---|---|
| 不審プロセスの検出 | processes | 低(すぐできる) |
| 開放ポートの確認 | listening_ports + processes | 低(すぐできる) |
| 外部通信の検出 | process_open_sockets + processes | 中 |
| ファイル変更の検知 | file / hash | 中 |
| 継続的な状態監視 | osqueryd + スケジュール設定 | 中(設定が必要) |
| SIEM連携 | JSON出力 + Filebeat等 | 高 |
まずはosqueryiをインストールして手動クエリを試し、慣れてきたらosquerydで自動化する流れがおすすめです。月1回の定期確認から始めるだけでも、サーバーの「あるべき状態」と「現在の状態」のギャップに気づく機会が生まれます。
PR
SELinux・firewalld・PAMなどLinuxセキュリティの実践的な設定手順を体系的に解説した一冊。osqueryで不審な挙動を発見したあとにどう対処するか、サーバー堅牢化の全体像をつかみたい方におすすめです。
