Connection (network socket) monitoring with Osquery

Osquery offers a number of ways to monitor outbound network connections from your Windows, Linux or Mac OS hosts. This post was written using Osquery 4.5.1. Support for new tables and platforms may have been added since this article was posted. Please check the Osquery website for the latest query schema.

Socket events captured in Zercurity with Osquery

A little bit about network protocols

Firstly, if you’re not that familiar with networking protocols there are a few things of note. As all the tables we’ll be exploring in this post will use numerical representations for address families and protocols. For example:

Whilst it looks fairly daunting, if we take each column. Firstly, the address protocol family — which for all intensive purposes the two most common values you’ll see are for IPv4 (1) and IPv6 (2). A full list is available here:

Similarly, for the protocol column we can do the same. Again, the two most common numbers you’ll see are TCP (6) and UDP (17) you may also encounter ICMP (1), HOPOPT (0) and maybe GRE (47) which is mainly used for VPN traffic. A full breakdown of all the protocol numbers is available here:

Armed with these two references we can actually convert these values on the fly with SQL. However, I’d recommend converting the numbers in code post query. As storing them numerically will give you better performance for searching and sorting.

Osquery socket tables

There are a few key tables used to give you access to the socket events being created on your computer. First and foremost is the socket_events table which will give you a complete audit of connections for both Linux and Mac OS as of Osquery 4.5.1. However, the socket_events table does require some additional configuration which we’ll dive into. If however, you’re looking for a quicker insight into what connections processes are marking then listening_ports and process_open_ports require no additional configuration and work across all platforms.

socket_events

This is the most relevant table for tracking system network connections to and from the system. Unfortunately, as of 4.5.1 the socket_events table only works with Linux and Mac OS. There are however, a few additional command line arguments you need to add in order for the socket_events table to work. Otherwise, you’ll get this error:

Note (Mac OS): If you’re running Mac OS you’ll need to ensure that openbsm is correctly configured. If you check your sudo nano /etc/security/audit_control it should resemble this:

You’ll want to ensure that the flags configuration option has the nt option set. A full list of of flags can be found here. The nt flag enables the auditing of socket events. Once you’ve updated the file you can either run audit -s or restart the system.

Note (Linux): If you’re running Linux however, you firstly need to ensure that auditd is installed.

Lastly, you’ll also need to use the osqueryd or osqueryi command with the following arguments in order to see the audited socket events:

Note (Troubleshooting): Firstly the --verbose flag can be added to both the Mac and Osquery command line to enable additional output. You can also double check that the socket_events table is active like so:

Note (Troubleshooting Mac OS): If you’re using Mac OS you can also check that openbsm is enabled and working correctly:

These openbsm audit files can be parsed using the following command to check that socket events are being correctly traced:

Note (Troubleshooting Linux): If you get the netlink error on Linux its because auditd is installed and enabled.

You’ll need to use this command instead to let Osquery know to use auditd instead of the netlink socket.

--disable_audit=false By default this is set to true and prevents Osquery from opening the kernel audit's netlink socket. By setting it to false, we are telling Osquery that we want to enable auditing functionality.

--audit_persist=true By default this is true and instructs Osquery to “regain” the audit netlink socket if another process also accesses it. However, you should do your best to ensure there will be no other program running which is attempting to access the audit netlink socket.

Querying the socket_events table

Phew! — and with all that you should now be able to query the socket_events table.

process_open_sockets

This table will show you all the open socket connections in use by processes on the system. This table will show all the inbound and outbound connections to and from running processes. Please be aware this will only give you a snapshot in time and not a complete audit of all the socket events.

listening_ports

Lastly, the listening ports table will show you all the current running processes with listening (bound) network sockets and ports. Similar to the lsof command on Linux. Whilst this table won’t give you any network events. It can still be useful to at least show what, if any what ports are open on the system. Which can be tied back to netflow events on the network if you have monitoring there. Which can be a better strategy to monitoring network events rather than taxing each host.

The listening_ports is currently supported across all platforms.

Its all over

I hope that’s helped get you up and running with connection monitoring on Osquery. If you need some help do drop a comment or get in touch.

Real-time security and compliance delivered.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store