pfSense into ELSA

Introduction
One good piece of open source software deserves another right? It is time for a match made in heaven: pfSense and ELSA. pfSense is my favorite open source firewall. I run it in multiple places and it has always been rock solid. If you have read my blog at all you know my appreciation of ELSA. Therefore, I thought it would be a good post to combine the two.

Prepping pfSense
Before you start firing off syslogs to your ELSA server you will need to fix a small issue with pfSense. Apparently, pfSense logs to a binary data file which is then sent to tcpdump to parse. Something in the parsing causes issues with newlines. Single log entries will be sent as two syslogs making parsing them in ELSA (or any other parser) extremely difficult. Fortunately, this site has a simple script and fix for the issue. A PHP script is used to modify the filter file in pfSense. It uses SED in a clever way to weed out all the newlines in the log entries giving you one syslog per entry. You can check out the link above for more information but, I have included the script for convenience. Before you run the script you will probably have to remount the file system as read/write. If you haven't already done so enable SSH on you pfSense firewall to perform these actions.

Mount the file system as read/write

# /etc/rc.conf_mount_rw

Use vi on the firewall to create this file. Make sure to enclose script in PHP brackets

$filter=file_get_contents ('/etc/inc/filter.inc');
$filternew =
    str_replace(
        "-ttt -i pflog0 | logger -t pf -p local0.info",
        "-ttt -i pflog0 | /usr/bin/sed -e 'N;s/\\\\n //;P;D;' | logger -t pf -p local0.info",$filter);
if (strcmp($filter, $filternew) !=0) {
    file_put_contents('filter.inc.new',$filternew);
    file_put_contents('filter.inc.org',$filter);
}

Execute the script to create the new filter and move it over. I had to reboot my device for this to take effect.

# chmod +x chgfilter.php
# php chgfilter.php
# mv filter.inc.new /etc/inc/filter.inc

Now your pfSense firewall should be syslogging correctly. Just point it at your ELSA server and you should be done configuring it.

Creating the patterndb XML file
First kudos to InfoSec matters blog on configuring Vyatta for ELSA. It made my work a lot easier here. Essentially I used two preexisting ELSA classes, FIREWALL_ACCESS_DENY and FIREWALL_CONNECTION_END, for parsing the pfSense firewall logs. The FIREWALL_CONNECTION_END log is for pass traffic and the FIREWALL_ACCESS_DENY log is for blocked traffic. You might have to turn on logging in pfSense for whatever rules you want to send to syslog. Below is the XML you can add to the patterndb.xml file.
After you have added that code simply restart syslog-ng and all your pfSense firewall logs should be parsing correctly in ELSA.

# service syslog-ng restart

Conclusion
I would like to get some dashboards up soon. The code for the above examples is also on Github. Hopefully, that will be another blog post in the near future. As always, I welcome your comments and feedback.

Process Data to ELSA

Process Data to ELSA

Introduction

It seems the useful things ELSA can help a security professional with are endless. A couple of weeks ago I thought it would be interesting to include a snapshot of running process data from Windows hosts in ELSA. Therefore, I wrote a simple script in Python to input a list of hosts, by IP address, capture all the running processes via WMI, and send them to the ELSA via syslog. If you want to use this script but do not have Python installed on a machine, I created a Windows executable.  Check my GitHub account to download the Python script/Windows executable, MySQL file to alter the ELSA database schema and XML file for appending patterndb.xml  used with syslog-ng. First let's take a look at how to configure ELSA for use with the script and then we will look at what you can do with it.

Setup

For this example I will assume you downloaded the Windows executable version of my script. You will also want to download patterndb_process.xml and PROCESS_db_setup.sql. First cut all of the text from patterndb_process.xml and add it to patterndb.xml as shown.

Next, update the MySQL database schema and restart syslog-ng since you modified patterndb.xml. 

# mysql < PROCESS_db_setup.sql
# service syslog-ng restart

Now your ELSA installation should be configured and ready to accept syslogs containing Windows process data. 

Go to the Windows host which you will want to run the script from. It might be helpful to create a separate folder. Copy the script into that folder and create a text file containing the list of hosts which you plan on analyzing process information. The script reads one address per line. The script will require a hosts file with which to pull syslog data from (-i), a Windows username (-u) and password (-p), and the ELSA server IP address (-l). Here is a screenshot on how to run the script from Windows.

You can also include a file called scanID.txt. The script might throw an error the first time looking for the file, however if you run it again it with the same parameters it should create the file automatically and work fine. The idea behind the scanID.txt file is to give each scan or process data pull a unique scan ID number to more easily track them in ELSA. Every subsequent time you run the script, this ID will increment. I designed the script to work well as a scheduled task in Windows. 

Analysis

I tried to capture interesting information about processes that would be helpful to an analyst or security professional. Data such as process name, operating system type, process ID, executable directory, parent process ID and parent process name (if available) are all collected. 

I think the opportunities from a security perspective can be pretty interesting. For example suppose an analyst wants to see all the places where Java is currently running in the environment. You could simply do a query in ELSA such as 'class=PROCESS +java'. 

Furthermore, suppose an attacker is hiding a backdoor in an unusual directory. You can search ELSA for process names and sort by directory. 

In the example I searched for cmd.exe and noticed it was running in three different places. However, in the last log entry it is not running in the standard directory. Hmm.....

There is a lot more interesting data that can be mined from taking periodic snapshots of processes. An example might be searching for anomalies in parent processes. Searching for a parent process of iexplorer.exe might yield some interesting results. I would love to hear other cool ideas on how to use this data. As always I welcome you feedback.