Installing and enabling Known Exploit Detection

One of the most critical things to do to secure your system (and, more importantly, the data in the system) is to implement the ability to detect when the bad guys are trying to break in. Ksplice has a unique feature called Known Exploit Detection (KED) that will report on known attacks against the kernel. Normally, only exploits that allow the hacker to access additional privileges are instrumented for KED and, for these to trigger, the kernel should already have been spliced for the vulnerability.

Getting ready

To do this, you will need a test system running Oracle Linux 8, with Ksplice set up.

How to do it…

This is done via tripwire code, which is triggered when specific events are detected. Normally, only events that enable the attacker to gain privileged access are monitored. This package is available on both x86 and ARM systems.

To enable this, the pack must first be installed by using the following command:

dnf install -y ksplice-known-exploit-detection

Regardless of whether the installation is on an ARM or x64 server, the installation is almost identical, with the major differences being more about the software already installed on each system. This brings a point to mind: regardless of whether ARM or x64, the admin tasks are the same.

Note

When KED is installed, postfix is also installed to enable sending emails as part of the notification system.

The output from installing this on an ARM-based system is shown in the following screenshot:

Figure 7.16 – KED installation on ARM

The output from installing this on an x86_64-based system is shown in the following screenshot:

Figure 7.17 – KED installation on x64

Once KED is installed, the feature needs to be enabled. This is done by adding the following lines to /etc/uptrack/uptrack.conf:
[Known-Exploit-Detection]
enabled = yes

Next, you will need to Ksplice the kernel to enable the feature in the running kernel:
ksplice –yes  kernel upgrade

The output for this is shown in the following screenshot:

Figure 7.18 – Enabling KED in a running kernel

As a note, if no Ksplice patches are available, you will get a notification that the kernel is up to date, as shown in the preceding screenshot. But if the system requires patches, Ksplice will patch the kernel at this time while enabling KED.

To verify that KED is enabled, cat /proc/sys/kernel/known_exploit_detection and look for an output of 1. If the file is missing or there is a zero there, KED is not enabled so won’t be monitoring your system:

Figure 7.19 – Checking whether KED is enabled

Notifications from KED are controlled from the /etc/log-known-exploit.conf configuration file. A sample configuration file is shown in the following screenshot:

Figure 7.20 – KED notifications configuration

In the config file, you can control the following actions:

• [syslog]: Most admins log events to syslog for capture and analysis using log analytics tools such as OCI Log Analytics or Splunk. The enabled: 0 setting will disable logging to syslog.
• [email]: This section allows you to enable emails to be sent when a tripwire is triggered. Add email addresses for recipients as needed. This will also require that the system can send emails, either through a cloud service such as the OCI Email Delivery Service or your own Simple Mail Transport Protocol (SMTP) relay.
• [actions]: You can specifically disable notifications for a specific CVE. This is helpful if you have an accidental false positive on a system. To disable a CVE, add a line with the CVE and ignore. The default: parameter sets the default behavior for all CVE.

Note

If you enable email notification, make sure your email subsystem is configured before enabling emails from KED.

You can also test the system with the log-known-exploit command. This will log a test message in the kernel:
/usr/sbin/log-known-exploit -f -d ; tail /var/log/messages

The test event will look like the following in /var/log/messages:
Apr 22 23:01:02 ol8splice2 /log-known-exploit[4192]: exploit attempt detected; id=CVE-2012-1234 pid=1337 uid=1000 comm=./dummy-exploit lost=0

In the log, you will see the time, the CVE that was triggered, and also the Process ID (PID) and User ID (UID) of the process and user that triggered the event.

How it works…

Ksplice installs a piece of tripwire code in the kernel for specific exploits, detecting when something tries to exploit the exploit. These triggers then kick off the notification subsystem, letting you know when an attack happens.