Splunking pfSense

I’ve decided to switch to Splunk for my syslog parser. I was using Syslog Watcher, however I realized that I need something that I can customize to correctly parse the data coming from pfSense. The reason being is because of the way pfSense generates the firewall events. The output is split into two lines instead of one; this format causes a problem with many popular syslog & SIEM applications. Combining the lines into one will be required if you want to do proper analytics & reporting. With just a few tweaks, Splunk handles the parsing the way I want it to.

I run Splunk 6.1 Enterprise on a CentOS server. The RPMs can be found on splunk.com.

Here is a link to a quick youtube video that gives a quick run through of the installation.
Installing Splunk 6 on Linux (CentOS, Red Hat).

A few commands and things to note:

Start/Stop/Restart Splunk

$SPLUNK_HOME/bin/splunk start <stop, restart>

Configure Splunk to start at boot time with a startup (init) script
$SPLUNK_HOME/bin/splunk enable boot-start

Splunk runs on default port 8000

 How to configure Splunk to handle pfSense data
This is the really cool thing about Splunk. It is the ultimate SIEM application in terms of customization. There are two config files that give you the ability to parse the data and output it the way you want:

props.conf – allows Splunk to recognize the multi-line pfSense events as one.

transforms.conf – the parsing of the data received into the fields that you want to see.

Full credit goes to this blog for the awesome regex tailor-made to parse pfSense.

Splunk Configuration

  1. Check that pfSense is configured to send log messages to remote syslog server.
  2. From the Splunk Web GUI go to Settings – Data inputs – UDP.

This is where Splunk is configured to listen on UDP 514 (syslog). Here are my custom settings:


Now you can go to the App: Search & Reporting and you will see your indexed data. Click the Data Summary button and it will launch a window where you can view the various sources that Splunk is listening to.


4. You can use the search field to customize your search. The results can be saved as a report, dashboard or alert. My query displays in table format showing the fields: _time, src_ip, src_port, dest_ip, dest_port, protocol, action.


The result is pretty neat compared to reading the raw data format.

Here are some helpful Splunk links for Search. I still have some playing around to do to create some nice visually appealing charts and reports. I plan on making some custom search queries to cover various time periods such as: 24hr, week, month and year, to make it easy to pull statistics and perform analytics.

  1. The Search Tutorial
  2.  The Search Manual

Happy Splunking 🙂


WiFi Security – Time to turn off WPS

I recently read some interesting slides posted online by Swiss security specialist Dominique Bongard regarding refined attacks against WiFi Protected Setup (WPS), reducing the length of time to crack a WiFi network’s WPA passphrase within seconds. It suddenly dawned on me that I probably forgot to disable this feature when I swapped out my old Linksys for a DLink Gateway around two years ago.

What is WPS?

  • It is a protocol aimed at easily connecting to WiFi networks
  • Gives the WPA passphrase to stations providing the right PIN
  • Two main modes: Push Button and 8 digit PIN code

Sure enough I logged on the D-Link Gateway interface and found that it was in fact enabled. Needless to say, I turned it off immediately as WPS has been found to be a troubled protocol dating back to when researcher Stefan Viehböck reported an implementation flaw that makes brute-force attacks against WPS feasible.

Wikipedia has a good summary

The vulnerability centers around the acknowledgement messages sent between the registrar and enrollee when attempting to validate a PIN. The PIN is an eight-digit number used to add new WPA enrollees to the network. Since the last digit is a checksum of the previous digits,[7] there are seven unknown digits in each PIN, yielding 107 = 10,000,000 possible combinations.

When an enrollee attempts to gain access using a PIN, the registrar reports the validity of the first and second halves of the PIN separately. Since the first half of the pin consists of four digits (10,000 possibilities) and the second half has only three active digits (1000 possibilities), at most 11,000 guesses are needed before the PIN is recovered. This is a reduction by three orders of magnitude from the number of PINs that would have to be tested. As a result, an attack can be completed in under four hours (183 minutes to be precise). The ease or difficulty of exploiting this flaw is implementation-dependent, as Wi-Fi router manufacturers could defend against such attacks by slowing or disabling the WPS feature after several failed PIN validation attempts.[4]

Given the seriousness of the WPS vulnerability that leaves you open to brute-force attacks by anybody within the vicinity of your network,  I was curious about the number of AP’s around me that have WPS enabled. I fired up Kali and performed a scan using the wash command:


The results after a brief scan show that there are four machines within range that are vulnerable to “reaver” attacks. Reaver is an open-source tool specifically designed to exploit the WPS security flaw and is available in Kali Linux. As stated on the Google code site for reaver-wps:

On average Reaver will recover the target AP’s plain text WPA/WPA2 passphrase in 4-10 hours, depending on the AP. In practice, it will generally take half this time to guess the correct WPS pin and recover the passphrase.

Yikes! I strongly suggest to check your WiFi Gateway settings and turn off WPS. Here is a screen shot of where it is found on my DLink.


While you’re at it, double check your WiFi security level. The minimum security standard should be WPA with a strong passphrase known as the Pre-Shared Key (PSK).