Vulnerability management for FreeBSD

Introduction

According to Wikipedia the definition of vulnerability management is: the cyclical practice of identifying, classifying, prioritizing, remediating, and mitigating software vulnerabilities. A vulnerability is a weakness in software that can be exploited to allow unauthorized access, elevation of privileges or denial of service.

If you run a FreeBSD system, you want to run it healthy you want to keep it up to date. A system in this case can be a physical system, a virtual machine or even a jail. And keeping it up to date means not only implementing newer versions of the Operating System and or packages, because of i.e. increased functionality, but also keep track of vulnerabilities of both and patch them when necessary. This is vulnerability management!

Identifying FreeBSD vulnerabilities

Several ways exist to identify a vulnerability on a FreeBSD system. The FreeBSD community provides resources and information about FreeBSD and FreeBSD ports related vulnerabilities, such as:

FreeBSD has also a security mailing list which provides information about FreeBSD operating system vulnerabilities.

When logged in a FreeBSD system you can use the pkg command to identify if you have vulnerable packages on your system:

$ pkg audit -F

A single command does not exist to identify if your FreeBSD OS is vulnerable (maybe that can be added to the freebsd-version command?). You have to use the above mentioned resources for that. If you want something on your system, you can use the shell script mentioned in my blog post How to check for FreeBSD updates with Nagios.

All documented FreeBSD OS and - package vulnerabilities are also listed in the central Common Vulnerabilities and Exposures database. Each vulnerability in this database is listed with a unique identification number, the CVE number.

Ideally, you want to get an automatically generated alert if a FreeBSD system or - package contains a vulnerability. One way of getting an alert is by performing periodic vulnerability scans. A vulnerability scanner for FreeBSD is i.e. Vuls. Vuls is also available in the ports collection.

At SoCruel.NU Nagios is used for FreeBSD monitoring purposes, but also for vulnerability monitoring! How this is done, is described in 2 older blog posts:

Classify and prioritize FreeBSD vulnerabilities

The CVE database itself does not provide vulnerability severity or classification information. But the CVE database is fed into the National Vulnerability Database (NVD) of NIST and the National Vulnerability Database (NVD) does provide a severity score for each CVE, called the Common Vulnerability Scoring System.

But be aware, the Common Vulnerability Scoring System scores are general and might not be suitable for your situation. What if e.g. all your existing vulnerabilities have a score high? How to classify and prioritize then? Here at SoCruel.NU we run around 30-ish FreeBSD based systems, so not that much. But what if you have thousends of systems and assets and also using dozens of vendors?

To be able to answer that question some work and investigations need to be done. The first thing to do is to classify each and every (FreeBSD) asset in terms of criticality. The more critical an asset the higher the score. Criteria for criticality should be at least:

Does the system or asset contain sensitive data?
Does the system or asset contain data at all?
Is the asset directly accessible from the internet?
Is the asset in-directly accessible from the internet, i.e. through a reverse proxy or load balancer?
Does the asset hold user accounts and or credentials, i.e. an LDAP server?

The second thing to do is to investigate if a vulnerability is actively exploited (or not). All vulnerabilities represent weaknesses, but exploitable vulnerabilities reflect real risk! Resources which can be used and help in finding if a vulnerability is exploitable are:

Based on the outcome of these 2 excersizes you can decide in which order you have to mitigate your vulnerabilities.

Remediate and mitigate FreeBSD vulnerabilities

The best way to mitigate a vulnerability is to patch it. But in an enterprise environment this is not always possible, i.e. because of business reasons, or workforce capacity reasons or technical reasons. This is why it is so important to patch the right assets and i.e. not only the easy, ‘the low hanging fruit’ assets.

In enterprise environments sometimes the concept of virtual patching is used to mitigate a vulnerability.

Here at SoCruel.NU the following procedure is roughly used to prioritize and mitigate the vulnerabilities:

patch the test systems first
if the patch runs ok on the test systems for a day or so then
- if applicable patch sensitive data systems first
- if applicable patch directly connected internet systems second
patch the most important internal systems
patch the remaining systems

Most of the time all FreeBSD based systems are patched within a couple of days. In a multi vendor multi cloud enterprise environment this is impossible to achieve!

Resources

Some (other) resources about this subject:

Updated: October 29, 2020