There are lots of ways to use Osquery to query the underlying system. However, no one wants a slow computer.
Some query methods are more performant than others especially when joining tables. Or continually querying from non-cache-able tables with high disk reads. Whilst we’re not going to dive into too many examples. I do want to look at the tools Query gives you to monitor and audit, query execution. There are a few things you can do to limit the impact on system performance. As well as some common pitfalls and general optimizations. If you are heavily using certain tables.
Before we dive in I want to talk about 3 awesome features Osquery provides to help you test and benchmark your queries. …
There are a number of really useful tables within Osquery to determine information about a systems hard drive. Not least the availability of disk space but the disks encryption status and even some performance metrics.
One thing to bear in mind is that there is no common hard drive table within Osquery. Each operating system platform has its own distinct tables. These tables also need to be joined together in most instances to get a full picture.
Kicking off with Windows.
In windows the primary table you’ll want to use to grab a system disk information is the
logical_drives table. Which will give you the Windows drive letter and basic disk stats including the primary drive marker (boot partition). …
As with most tables in Osquery. You can gleam a whole load more information by joining tables together. Or enriching results with external data sources.
wifi_survey table is a perfect example of this. We’re given all the data we need in order to work out the exact location of our asset via Google’s geolocation services.
wifi_survey table is currently only available for Mac OS as of Osquery 4.6.0. It also goes without saying the asset you’re querying will need a working WiFi card. Which you can check the status of by querying the
osquery> SELECT interface, channel, country_code FROM…
Osquery provides a huge amount of flexibility for querying various different aspects of your system which we’ve covered in many posts. What’s really awesome is Osquery also lets you query Docker containers, images, networks and their respective volumes. Which gives you a great insight into sub-systems running on your host you may not ordinarily be able to inspect with conventional tooling.
As of 4.5.1 there are currently 17 tables within Osquery dedicated to Docker. In this post we’re going to explore each one and see how they work.
This goes without saying that’ll you’ll obviously need Docker installed and running on either Mac OSX or Linux. …
Whilst Osquery provides a huge amount of flexibility for retrieving lots of different pieces of information about a system. Sometimes however, there may be a specific part of the system you’re after that isn’t covered by Osquery’s included tables.
Within Osquery there’s a table called
augeas it’s super helpful for parsing configuration files across Mac OSX and Linux. Important for tasks like compliance, auditing and checking the configuration of deployed services.
Augeas parses configuration files in their native formats and transforms them into a tree. This tree is then translated into a query-able table by Osquery.
If you’re unfamiliar with Osquery or don’t already have it installed checkout our guide here. …
Following on from our post of getting Kubernetes stood up atop VMware’s vSphere. The next stage in deploying Zercurity to Kubernetes is to have a reliable backend database. Which can normally be a headache. However, the team over at Crunchy Data have built an awesome tool to deploy and manage a PostgreSQL cluster.
The Crunchy PostgreSQL Operator (
pgo) can build PostgreSQL replica sets, manage backups and scale up and scale down additional nodes as well as scale the CPU and memory requirements of running Kubernetes pods. Backups can also be managed and scheduled via the
pgo command line tool. Crunchy PostgreSQL also provides a number of add-in pods such as performance metrics via Grafana and Prometheus. …
For a change of gear away from our usual Osquery posts. Over the last year we’ve done a number of Zercurity deployments onto Kubernetes. With the most common being done on-prem with VMware’s vSphere. Fortunately, as of the most recent release of VMware’s vCenter you can easily deploy Kubernetes with VMware’s Tanzu Kubernetes Grid (TKG).
This post will form part of a series of posts on running Zercurity on top of Kubernetes in a production environment.
As with all things, there a number of ways to deploy and manage Kubernetes on VMware. If you’re running the latest release of vCenter (7.0.1.00100) you can actually deploy a TKG cluster straight from the Workload Management screen. Right from the main dashboard which has a full guide to walk you through the setup process. …
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.
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:
osquery> SELECT DISTINCT family, protocol FROM process_open_sockets;
| family | protocol |
| 1 | 17 |
| 1 | 6 |
| 2 | 6 |
| 2 | 17 |…
With remote server support in Osquery you can remotely grab files from systems using the
carves table within Osquery as simply as:
path LIKE '/Users/tim/Downloads/%'
AND carve = 1
The query above will fetch all the files residing within the users home directory. The wildcard
% can be used anywhere within the directory path. Carving is supported across Windows, Mac OSX and Linux.
Osquery will round up all the files that match the path and bundle them up into an archive as either a
.zst and uploaded back to the remote server.
We’re pleased to announce Zercurity is now generally available on Docker for free available via our GitHub page.
Since January we’ve been working on de-coupling our platform from AWS (which we still run our platform from). However, the demand for on-premise deployments of Zercurity has risen with more companies focused on keeping control over their data.
Zercurity is also available as both a standalone via OVA and Kubernetes cluster for larger deployments.
Or if you know what you’re…