What Is osquery and Why Run It on a Server

Osquery is an open-source tool that turns an operating system into a database: processes, network connections, installed packages, and files can be queried with plain SQL. The utility was created by Meta and handed over to the community, and it is now maintained by the Linux Foundation. On a VPS or a dedicated server, osquery replaces a dozen separate commands with one universal interface.

The key difference from ps, netstat, or ss is that the result comes back as a table you can filter, compare against yesterday's snapshot, and forward to a monitoring system. That is why osquery is useful both for routine inventory and for investigating an incident after a suspected breach.

How to Install osquery on a Linux Server

Osquery packages are built for the major distributions and are pulled from the official repository. On Ubuntu and Debian, adding a key, a repository, and installing the package is enough:

curl -L https://pkg.osquery.io/deb/pubkey.gpg | gpg --dearmor -o /usr/share/keyrings/osquery.gpg
echo "deb [signed-by=/usr/share/keyrings/osquery.gpg] https://pkg.osquery.io/deb deb main" > /etc/apt/sources.list.d/osquery.list
apt update && apt install osquery
systemctl enable osqueryd --now

On RHEL, AlmaLinux, and CentOS the package is installed through yum or dnf from the pkg.osquery.io repository, the daemon configuration lives in /etc/osquery/osquery.conf, and the interactive shell starts with the command osqueryi.

How to Check Processes and Network with SQL Queries

The main way to work with osquery is the interactive shell osqueryi, where one query language replaces a dozen separate utilities. Below are the typical tables used for server inventory.

Table	What It Shows
processes	Running processes, binary path, parent PID
listening_ports	Ports the server is listening on and the owning process
deb_packages / rpm_packages	Installed packages and their versions
crontab	Cron jobs for every user
authorized_keys	SSH keys allowed to log in

An example query that lists every process listening on a network port together with the path to its executable:

SELECT p.name, p.pid, p.path, lp.port, lp.address
FROM processes p
JOIN listening_ports lp ON p.pid = lp.pid
WHERE lp.port > 0;

This single query shows in a second what usually takes several chained calls to lsof and netstat.

How to Look for Signs of a Breach with osquery

During an incident investigation, the goal is to spot deviations from the normal picture: an unknown process, an extra cron job, a modified binary. Osquery helps narrow down the list of suspicious objects fast.

Processes with no file on disk, a sign of in-memory injection: SELECT name, pid FROM processes WHERE on_disk = 0;
New cron jobs added in the last day, found by comparing against a baseline snapshot of the crontab table
Extra keys in authorized_keys that are not on your access list
Binaries with a recent modification date in system directories: SELECT path, mtime FROM file WHERE directory = '/usr/bin' ORDER BY mtime DESC LIMIT 20;

These queries do not replace a full SIEM, but they give a fast first look in the first minutes after an anomaly is found. To check for hidden backdoors, pair osquery with the rkhunter scanner, and write down the next steps in advance in an incident response plan.

How to Configure osqueryd for Continuous Monitoring

One-off queries are useful, but lasting protection comes from the osqueryd daemon running on a schedule with differential logging: it remembers the previous query result and logs only the changes. The configuration is set in a JSON file:

{
  "schedule": {
    "listening_ports": { "query": "SELECT * FROM listening_ports;", "interval": 300 },
    "crontab": { "query": "SELECT * FROM crontab;", "interval": 3600 }
  },
  "file_paths": {
    "ssh_keys": [ "/root/.ssh/authorized_keys", "/home/%/.ssh/authorized_keys" ]
  }
}

Results are written to /var/log/osquery/osqueryd.results.log and from there flow easily into a central log collector or a SIEM such as Wazuh for correlation with other server events.

Checklist for Rolling Out osquery on a Server

Install the osquery package and enable the osqueryd service at boot
Set up a schedule for the key tables: processes, ports, cron, authorized_keys
Turn on file integrity monitoring for critical directories through file_paths
Route results to syslog or a dedicated log management system
Take a baseline snapshot of the tables every week and compare it to the current state
Keep incident investigation query history separate from routine operational logs

osquery: Server Inventory and Breach Traces