You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
osquery exposes an operating system as a high-performance relational database. This allows you to
write SQL-based queries to explore operating system data. With osquery, SQL tables represent
abstract concepts such as running processes, loaded kernel modules, open network connections,
browser plugins, hardware events or file hashes.
SQL tables are implemented via a simple plugin and extensions API. A variety of tables already exist
and more are being written: https://osquery.io/schema. To best
understand the expressiveness that is afforded to you by osquery, consider the following SQL
queries:
Check the processes that have a deleted executable:
SELECT*FROM processes WHERE on_disk =0;
Get the process name, port, and PID, for processes listening on all interfaces:
SELECT DISTINCTprocesses.name, listening_ports.port, processes.pidFROM listening_ports JOIN processes USING (pid)
WHERElistening_ports.address='0.0.0.0';
Find every macOS LaunchDaemon that launches an executable and keeps it running:
SELECT name, program || program_arguments AS executable
FROM launchd
WHERE (run_at_load =1AND keep_alive =1)
AND (program !=''OR program_arguments !='');
Check for ARP anomalies from the host's perspective:
SELECT address, mac, COUNT(mac) AS mac_count
FROM arp_cache GROUP BY mac
HAVINGcount(mac) >1;
Alternatively, you could also use a SQL sub-query to accomplish the same result:
SELECT address, mac, mac_count
FROM
(SELECT address, mac, COUNT(mac) AS mac_count FROM arp_cache GROUP BY mac)
WHERE mac_count >1;
These queries can be:
performed on an ad-hoc basis to explore operating system state using the
osqueryi shell
executed via a scheduler
to monitor operating system state across a set of hosts
launched from custom applications using osquery Thrift APIs
Download & Install
To download the latest stable builds and for repository information
and installation instructions visit
https://osquery.io/downloads.
We use a simple numbered versioning scheme X.Y.Z, where X is a major version, Y is a minor, and Z is a patch.
We plan minor releases roughly every two months. These releases are tracked on our Milestones page. A patch release is used when there are unforeseen bugs with our minor release and we need to quickly patch.
A rare 'revision' release might be used if we need to change build configurations.
Major, minor, and patch releases are tagged on GitHub and can be viewed on the Releases page.
We open a new Release Checklist issue when we prepare a minor release. If you are interested in the status of a release, please find the corresponding checklist issue, and note that the issue will be marked closed when we are finished the checklist.
We consider a release 'in testing' during the period of hosting new downloads on our website and adding them to our hosted repositories.
We will mark the release as 'stable' on GitHub when enough testing has occurred, this usually takes two weeks.
Build from source
Building osquery from source is encouraged! Check out our build
guide. Also
check out our contributing guide and join the
community on Slack.
Osquery fleet managers
There are many osquery fleet managers out there. The osquery project does not endorse, recommend, or test these. They are provided as a starting point