[Enterprise Security] SIEM IPS PFSENSE

TRY HARDER: A Blog About Discovery

Author: Brennan Turner @BLTSEC
[Enterprise Security] SIEM IPS PFSENSE

Scenario: This post will describe a virtual machine lab I put together to demonstrate network security monitoring (NSM) using a pfSense router, a Splunk SIEM server, and a Suricata IPS server. This post will also provide a high-level overview of how a SIEM could be integrated into an enterprise environment by adopting and scaling the architecture model I used in this NSM lab.

Disclaimer: This is a test environment and the methods shown below shouldn’t be done in a production environment without proper authorization and documentation. Use these techniques responsibly and ethically and always test every flag, switch, command, and exploit in your own test environment prior to running in a customer’s environment.

Breakdown: SIEM stands for Security Information and Event Management. The SIEM product I used, in this case, was Splunk, in this lab Splunk will have event logs and alerts forwarded to it with the use of a universal forwarder running on the Suricata IPS server. Suricata in this lab is used as an inline intrusion prevention system and is rule-based but could have been configured as an out-of-band intrusion detection system attached to a span port or network tap. The IPS server utilizes a feature of Suricata called AFPACKET bridging. This allows the two network interfaces of the IPS server, to function as a link, allowing communication between the two network segments, as long as the IPS server is powered on. This network design is called fail-closed networking. This setup is very versatile and if I wanted to analyze malware I could turn off the service on the IPS server or even power off the server completely and the malware wouldn’t have a route to the internal or external network. The network diagram below illustrates the architecture of the NSM lab.

pfSense: The first interface on the pfSense router is the WAN interface, this interface has a firewall rule that denies all inbound traffic to our lab network.

This rule does not prevent the lab machines from communicating with other hosts that are bridged to my physical network. That will be the job of the next interface. The LAN interface is my management interface and allows my hypervisor machine to communicate with the virtual machines e.g. Splunk. This interface has a lengthy firewall policy attached to it. The order of the firewalls is top down so the first rule encountered will be the one that takes precedence and the other’s will be ignored. The RFC 1918 addresses –,, and deny rule is the one that will prevent the virtual machines on this network from talking to anything on my physical network as well as any other machines on a separate virtual network.

The OPT1 interface also has an RFC1918 deny rule which denies traffic between the IPS server, vulnerable asset, the attacker system. and my physical network as well as any separate virtual networks.

Suricata IPS: In comparison to Suricata, Snort is another type of IDS/IPS platform that was first released in 1998, it is without a doubt an amazing product but Suricata has greatly improved upon Snort with some of its capabilities while still maintaining compatibility with various pieces of Snort such as language, normalization and even support for Snort’s output formats in order to have compatibility with most web applications and tools intended to be used with Snort (e.g. unified2 output, compatible with barnyard2, and various applications intended to display IDS alerts). Suricata is multi-threaded, meaning that it is much easier to scale up Suricata in order to inspect traffic on large, multi-gigabit networks. Suricata also supports using graphics cards to help offload and scale network inspection. In addition to the scalability, Suricata has the capability to log a lot more data than Snort does. More information about the benefits of Suricata can be read here.

Looking at the screenshot above the Suricata service is shown running as a daemon, using the suricata.yaml configuration file, and running in AFPACKET mode which two additional network interfaces on the IPS server were configured and added to the yaml file in order for Suricata to implement this bridging mode. The eve.json is the file Suricata outputs the alerts and events to and then this data is forwarded to Splunk using a Splunk forwarder service running on the IPS server. The alerts and events written to the eve.json file are shown below.

Splunk SIEM: I launched a port scan to discover services running on the vulnerable asset using my “attacker” machine. After enumerating the target I proceeded to launch a massive amount of attacks that targeted the discovered services. The attacks opened a few sessions on the target and generated a massive amount of alerts that were forwarded from the IPS server to the Splunk server for review. The search criteria index=main * event_type=alert | table alert.signature | dedup alert.signature in the screenshot below means I’m looking for data in the main index which was a value set in the Splunk forwarders inputs.conf file on the IPS server. In an enterprise environment, it would be best to name each forwarders index differently so you could determine which sensor gathered the alerts and forwarded them to Splunk. The next section looks specifically for any records that have the event_type field set to alert (denoting that it is a Suricata IDS alert). Then I’m only including the data in the alert.signature field. Then I’m taking the alert.signature field, and removing any duplicate entries.

Splunk’s filters are very easy to use and the alerts can be shown in a variety of ways that can help computer incident response teams (CIRTs) with detection, analysis, containment, and eradication.

Monitor: You can see from the screenshot below that once I viewed the alert details I could easily see that a backdoor was opened on the vulnerable asset.

You can see the category is listed as well as the destination and source addresses, alert severity, the signature of the service running on the asset as well as other important details such as the time and date the compromise occurred. From this point, the CIRT should start to contain and eradicate the backdoor on the asset by following their organization’s policies.

TCPDUMP: To show the benefits of running a SIEM in your enterprise I will show the low-level packet capturing process using tcpdump. In this example, I use the command tcpdump -A tcp port 21 which prints each packet in ASCII that meets the capture filter primitive of port 21 which is FTP traffic. The malicious payload that allowed the trojan backdoor seen above was…a smiley face 🙂

This is a very severe risk to the enterprise due to its low barrier of entry required to perform the exploitation. The reason this discovery is labeled as a risk is that a threat actor has exploited a vulnerability and there is a potential of loss for the organization. This should be resolved immediately.

CONCLUSION: Even though a full packet capture using a tool like tcpdump collects most if not all of the traffic details it comes at high cost. The amount of space needed to capture pcaps is tremendous and therefore usually infeasible. A SIEM provides the ability to perform cost-effective collection, indexing, storage and analysis of a large amount of information, including log and event data, as well as the ability to search and report on it and meet compliance regulations and guidelines. There are also many free solutions besides Splunk that will provide much of the same functionality and scalability. The role of security is to support the mission of the organization and to do it in a way that “advises” best practices and provides just enough security for the given situation. A SIEM helps to meet this role and allows organizations with small teams the ability to quickly monitor and investigate incidents that occur within an environment. Hopefully, this article helped you gain an insight into my lab environment as well as gain a high-level understanding of how network security monitoring could be integrated into your environment. If you have any questions feel free to reach out to me using the contact page or twitter: @BLTSEC. Happy Hunting!!