On my home network, I run OpnSense and have enabled the Intrusion Prevention System (IPS) based on Suricata with the key from proofpoint to enable the rules. The first time that I enabled the IPS, I had a sense to turn on the rule sets slowly to understand what would break. My routine was to enable a few sets of rules, and then for a week monitor, and then repeat.

For most of the rules that had been enabled up until this most recent set, nothing interesting had appeared in the logs, but I was now aware of how often my IP address was being scanned, and probed for various well known vulnerabilities.

I enabled the ET open/threatview_CS_c2 and within moments, I saw a new set of alerts from the LAN interface all being marked as blocked. Looking at the source IP, I knew it was not any of the infrastructure, my laptop, phone, or workstation. I took the external IP address and used the Cisco Talos to determine that this was attempting to send packets to a low reputation IP address.

I needed to identify the device on my network that was attempting to reach out to a Command-and-Control IP address. Looking at the DHCP leases, I identified it as my partner’s Mac.

I went over to her, and asked if I could poke around the machine, and install a malware scanner. Within minutes, it picked up a suspicious application, as well as several suspicious cookies in chrome. I cleaned up the suspicious application and noted that the attempts to connect to the known Command-and-Control had ceased. I then cleaned up the cookies and called it a day.

These are the steps that I took when I first enabled the IPS, and solidified my understanding, and application of an IPS as a tool to ensure that the network is protected. I use this example to highlight how important it is for clients to explore the options of an IPS to improve their security posture. In this instance, the IPS literally found and blocked something, that the operating systems built in systems did not.