Open Source Firewall project... Day 3, Time for Splunk!

So I scrapped the full UTM solution seeing that Snort has some serious memory requirements.  I did not want to add any other packages to this device.  If you are curious as to what would have been done you can check out SmallNetBuilder's UTM Guide.  If I can obtain some better hardware I may move to a beefier solution, but for now, I will be happy just seeing more detailed firewall and IDS/IPS data.

So if you have worked with pfSense at all, you will notice that it has limited internal logging capacity.  You can adjust but eventually logs will be overwritten.  With the addition of Snort, you now have another important log to look at.  There is an option for each of the managed interfaces in Snort to send data to the System logs, but remember, you will now overwrite those with more data.  So best solution is to send all this information to a Syslog server.  There are a couple solutions out there such as KiwiSyslog, but I sent the information to my Windows 2008 server running Splunk.  There is a decent guide on SeattleIT.Net.  That one includes using the Google Maps app in splunk to track the geo-IP location of external hosts.  The guide does contain two important config files needed, which is why I referenced it.  You will need those so Splunk knows how to parse the information it receives from pfSense.  On the pfSense box you will need to enable logging to a Syslog server.  This is done from Status-->System Logs-->Settings (see fig 3.1).

Fig 3.1 - Log Settings pfSense

From here you can add the server and the logs you want to use.  Unfortunately, pfSense only supports the UDP port 514 for Syslog data.  This is the default configuration, there are some guides out there that instruct you how to change this setting but that is beyond the scope of this discussion.  One more thing needs to be done here before we head over to Splunk.  I want to make sure I capture the Snort logs as well.  I haven't found an individual setting for Snort in pfSense to send logs to an external source, but there is an option to send them to the System Log for pfSense.  This will work out seeing that I already set the System logs up to go to a Syslog server.  Head over to Services-->Snort and edit each interface you the logs for.  You will want to check off the option to "Send alerts to the main lSystem logs (see fig 3.2).

Fig 3.2 Sending snort alerts to System Logs

Now that we have logs to collect, it is time to turn on the feed in Splunk.  This was tricky at first then I realized I made a dumb mistake and it worked perfectly.  If you are using a Windows server with the firewall enabled, you may have to allow the UDP 514 traffic from the pfSense box.  The easiest way to add the information to Splunk is to go under the Search section and "Add more data" (See fig 3.3).

Fig 3.3 Add Data to Splunk Search

From the next section you will be able to choose the type of data you want to add.  For this we will choose "Syslog" (See fig 3.4).

Fig 3.4

Choose the type of Syslog you want, for this I used "Consume syslog over UDP" (See Fig 3.5).

Fig 3.5

This brings you to the configuration screen.  Set the port to 514 since that is the default used by pfSense.  Then configure the remaining settings and check off "More Settings" for additional options (See Fig 3.6-7). 

Fig 3.6

Fig 3.7

Use the manual option for Source Type so you can set the correct name that coincides with the props.conf and transforms.conf files created in the SeattleIT.net blog.

Also notice in Fig 3.7 the "Restrict to Host" option.  This will help lock down the what host Splunk will listen for, any other syslog servers will be ignored.


Once the Splunk server has been rebooted, you should start seeing information flow in from pfSense.  At this point you can start searching for specific events from Snort or the Firewall logs.  Right now the logs from Snort are mixed up with the System log activity of pfSense.  If you choose the SourceType="pfsense-firewall" you will see only the firewall logs.  For now I created an event type based off a simple search string 'source="udp:514" snort'.  I will most likely move to pulling out the Snort logs as a separate feed but for now this will work just fine.

At this point I have called it a day and the initial project is done.  I will most likely tweak the configuration and try pull out some more useful information that will assist in setting up some decent block rules in Snort.  But that is enough work on my vacation and the Xbox is calling!  If you have any questions, feel free to leave a comment or hit me up in Twitter.  I hope you all kick the new year off right!

Open Source Firewall project... Day 2ish

OK so this is a couple days combined.  We left off with getting access to the WebGUI and making sure everything was good to go for connectivity.  I put a hold on configuring additional firewall rules for OpenVPN but will look to getting that up in the next day.  I spent some time checking out the new data I was logging for external access attempts.  Eventually this information will be sent to a log management solution for better data gathering, more on that later.

Over the last couple days I worked on getting Snort installed and configured as well as setting up the Dynamic DNS service I use.  DynDNS (dyn.com) is a nifty service that allows you to have a dynamic public facing IP address (typical for residential ISP customers) but you can assign a static DNS record to that interface.  The service utilizes an agent based, manual, and/or account based method to update the host information.  Most broadband routers and SOHO style firewall services have the ability to communicate with Dynamic DNS services.  The typical free solutions give you some pre-defined domains to use, but if you want to get fancy, you can just create a CNAME with your current DNS host and point it to the DynDNS domain for example: remote.mydomain.com --> remote.dyndnsdomain.com.

Now that all that is settled, we can proceed to getting the IDS/IPS up and running.  For that we add the snort package.  If you are following the guide from SmallNetBuilder, then you see it is pretty simple.  Always remember when configuring your IDS/IPS, only turn up the rules/Categories related to your network.  For example, if you do not have Oracle Servers, then don't turn on the Oracle rules.  This cuts down on the amount of alerts you will receive from the IPS.  If this is your first IPS solution on your network, you may also just want to enable the IDS portion first just to see what is going on.  If you see immediate activity that you know should not be occurring, then enable the IPS portion for that specific activity.  Upper management tends to frown on bringing the business to a screeching halt because your custom application looked like bad network activity to Snort.  For a home network straight Snort is good enough, but for business you may want to consider the SourceFire appliance.  It is much easier to call support to fix something ASAP rather than scouring Google.

I initially turned up the block rules for the WAN and left them off for LAN.  I had some issues though with the blocking on the WAN since it was blocking the pfsense package management traffic.  I am currently just in IDS mode on both interfaces since my main goal here was to see what is happening on the home network.  Later I may build up some suppression/whitelist rules,

The final part of the guide instructs you to install IP-Blocklist.  The application is basically a managed blackhole solution for the firewall side of pfsense.  You configure it to look at some blacklists and it will drop packets for IP addresses on those lists.  This is great if you want to block traffic from specific countries.  The IP-Blocklist is no longer fully supported by pfsense, they offer pfblocker which works much the same way and is added to your Firewall controls.  I did not do much to configure this yet.  Again I want to see where traffic is coming from then I will look at initiating some blocks.

Once Snort was running I did notice some errors popping up repeatedly on the console.  Many where due to ACPI errors.  I found some discussions pointing to a variety of items for FreeBSD and hardware issues.  The one that the issue may be related to was with the onboard Realtek NIC.  Disabling the NIC in the BIOS and rebooting seemed to stop the errors.  Of course that angered pfSense and forced me through the config prompts.  After fixing all that, re-enabled the onboard NIC and received the ACPI errors again.  Rebooted using Safemode and a number of errors were auto-corrected.  Unlike a Windows Safemode reboot, no services were disabled.

This is where I pretty much called it a day.  Next up is adding this new found information to Splunk.