SQL powered operating system instrumentation, monitoring, and analytics.
Go to file
2014-09-03 23:47:00 -07:00
CMake cleaning up the root CMakeLists.txt 2014-08-30 03:40:26 -07:00
lib@e163809165 [vtable_listening_ports] Listening sockets, IPv4, IPv6 2014-08-19 15:25:16 -07:00
osquery example unit test 2014-09-03 23:46:24 -07:00
package 0.0.1 Release 2014-09-02 18:40:51 -07:00
third-party@4dac47d96d updating third-party 2014-08-11 16:57:44 -07:00
tools migrating project to use CMake's CTest to run unit tests 2014-09-02 11:14:21 -07:00
.clang-format update the formatting in .clang-format 2014-08-15 12:41:47 -07:00
.gitignore Deploy infrastructure for OS X 2014-08-20 00:47:14 -07:00
.gitmodules Deploy infrastructure for OS X 2014-08-20 00:47:14 -07:00
CMakeLists.txt Fix performance issue with the disk serializer 2014-09-02 13:13:12 -07:00
Makefile updating cleaning of machine artifacts 2014-09-02 15:37:43 -07:00
osquery.supp Close #79 2014-09-02 12:45:50 -07:00
README.md Update README.md 2014-09-03 22:40:13 -07:00
requirements.txt Initial commit 2014-07-30 17:35:19 -07:00

osquery

osquery is an operating system instrumentation toolchain for *nix based hosts. osquery makes low-level operating system analytics and monitoring both performant and intuitive.

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

SQL tables are implemented via an easily extendable API. A bunch of tables already exist and more are constantly being written. To best understand the expressiveness that is afforded to you by osquery, consider the following SQL queries:

--------------------------------------------------------
-- get the name, pid and attached port of all processes 
-- which are listening on all interfaces
--------------------------------------------------------
SELECT DISTINCT 
  process.name, 
  listening.port, 
  process.pid
FROM processes AS process
JOIN listening_ports AS listening
ON process.pid = listening.pid
WHERE listening.address = '0.0.0.0';
--------------------------------------------------------
-- find every launchdaemon on an OS X host which 
--   * launches an executable when the operating 
--     system starts
--   * keeps the executable running 
-- return the name of the launchdaemon and the full 
-- path (with arguments) of the executable to be ran.
--------------------------------------------------------
SELECT 
  name, 
  program || program_arguments AS executable 
FROM launchd 
WHERE 
  (run_at_load = 'true' AND keep_alive = 'true') 
AND 
  (program != '' OR program_arguments != '');

These queries can be:

  • performed on an ad-hoc basis to explore operating system state
  • executed via a scheduler to monitor operating system state across a distributed set of hosts over time
  • launched from custom applications using osquery APIs

Building the code

Check out the "building the code" page on the wiki.

Table Development

Top easy virtual tables

High impact virtual tables

Testing your table for memory leaks

Use valgrind to test your table for memory leaks before you commit it. The osqueryd daemon is a very long running processes, so avoiding memory leaks is critical. The "run" tool is useful for testing a specific query. From the root of the osquery repository, run the following (substitute your table name in the query):

valgrind --tool=memcheck --leak-check=yes --suppressions=osquery.supp ./build/tools/run --query="select * from time;"