NEW - Suricata 1.4.6 IDS pkg. v0.2-BETA Released

bmeeks

Suricata Basic Setup Instructions

Install the package under System…Packages from the Available Packages tab.

When the installation is complete, go to Services…Suricata from the pfSense menu to launch the Suricata GUI.

Click on the Global Settings tab and make your initial configuration selections (such as choosing the rule sets) and save them.

Click on the Update Rules tab and then click the Check button to download the rules you enabled on the Global Settings tab.

When the download completes, click on the Suricata Interfaces tab and then click the plus (+) sign on the right to add an interface.

Check the Enable box and choose the interface you wish to run Suricata on and give it a friendly name. Either WAN or LAN is a good choice depending on which traffic you want to inspect. Look through the other settings and configure them as you desire. Click Save when done.

You will be returned to the Suricata Interfaces tab. Double-click on the newly added interface (or click the e icon on the right) to edit the settings again.

This time click the Categories tab and select the rule categories you wish to use. Click Save when done.

You can alter settings on the other tabs as desired, but if you are just starting out with Suricata the defaults should be fine.

Click the Suricata Interfaces tab again and click on the red X icon to toggle Suricata to the running state. It will take a few seconds to start. Be patient.

When the icon changes to a green arrow, click the Logs Browser tab and then select the suricata.log file in the "Log file to view" drop-down. Read through the log and see if Suricata started successfully. Here is an example of a successful startup:

4/3/2014 -- 10:52:58 - <info>-- all 4 packet processing threads, 1 management threads initialized, engine started.
4/3/2014 -- 10:53:03 - <info>-- 2 rule files processed. 14175 rules successfully loaded, 0 rules failed
4/3/2014 -- 10:53:12 - <info>-- 14183 signatures processed. 614 are IP-only rules, 4037 are inspecting packet payload, 11013 inspect application layer, 76 are decoder event only
4/3/2014 -- 10:53:12 - <info>-- building signature grouping structure, stage 1: adding signatures to signature source addresses... complete
4/3/2014 -- 10:53:12 - <info>-- building signature grouping structure, stage 2: building source address list... complete
4/3/2014 -- 10:53:16 - <info>-- building signature grouping structure, stage 3: building destination address lists... complete
4/3/2014 -- 10:53:18 - <info>-- Signature(s) loaded, Detect thread(s) activated.
4/3/2014 -- 10:54:09 - <info>-- No packets with invalid checksum, assuming checksum offloading is NOT used</info></info></info></info></info></info></info></info>

The last line shown above takes several seconds to appear as Suricata automatically examines the packets it sees and from them determines if checksum offloading is used or not. If you don't see the checksum offloading line yet, don't worry.

The other logs available on the Logs Browser tab are populated according to the specific features you enable on the Settings tab for the particular interface. The default setup described above does not enable all of the features.

To enable the Dashboard Widget, return to the pfSense Dashboard and click the plus icon (+) to add a new widget. Select Suricata Alerts from the list. Click Save to save the new Dashboard configuration.

Note – pretty much every clickable icon and button in the Suricata GUI contains a tool tip to show what it does. Just hover your mouse over an icon or button and wait for the tool tip to appear.

Bill

Supermule

Can this be ported to the 2.0.3 release??

Reason I am asking is that a lot of people have driver issues and panics in 2.1 rel.

bmeeks

@Supermule:

Can this be ported to the 2.0.3 release??

Reason I am asking is that a lot of people have driver issues and panics in 2.1 rel.

Well, not without a fair amount of rework. It makes use of system calls and features that are only available in the 2.1 code base. The goal originally was to target 2.1 and higher for Suricata.

EDIT – let me rephrase "a fair amount of rework" to "some amount of rework". I have not tested it personally yet, but does the new 2.1.1 pre-release work better for folks?

Bill

Supermule

Seeing a lot of questions regarding drivers not finding the hardware and Squid not working….

2.0.3 seems to be the most stable yet for production when its loaded with traffic. I had to revert on one FW that slowed down to a grinding halt efter a few hours.

bmeeks

@Supermule:

Seeing a lot of questions regarding drivers not finding the hardware and Squid not working….

2.0.3 seems to be the most stable yet for production when its loaded with traffic. I had to revert on one FW that slowed down to a grinding halt efter a few hours.

How about this? I will trade you your Internet connection for a 2.0.3 version of the Suricata package… ;D

I am envious of your speeds posted in your Forum signature. Where I am located in the Southeastern U.S. we are just being offered 24 Mbps cable modem service for residential use.

Bill

Supermule

You can have access to that when you use my cloud services ;)

BBcan177

Hi Bill,

I updated my Suricata and noticed the following:

I noticed a 10% memory increase. Without any changes to my settings.
When I view an alert, and either Suppress or Remove a Rule, it doesn't bring the page refresh back to the same location. (Snort package does it correctly.)
In the Suricata Dashboard, i see alerts that are not in the Main Alerts Tab? (See the attachment). After I added the Dashboard, Saved, and edited the number of alerts to display
(20), it gave an error. (Didn't record the error). I did a page refresh and it seemed to work after that.
–Maybe its using the wrong descriptor for the Detail Column?--

Suricata1.png_thumb

bmeeks

@BBcan17:

Hi Bill,

I updated my Suricata and noticed the following:

I noticed a 10% memory increase. Without any changes to my settings.

Not 100% sure, but this could be caused by fixing a bug in the first release where the default decoder-events, file, http-events, smtp-events and stream-events rules files were not being included in the default enabled rules. That's fixed in this update. Those extra files mean some extra rules being loaded. That could be the difference.

When I view an alert, and either Suppress or Remove a Rule, it doesn't bring the page refresh back to the same location. (Snort package does it correctly.)

Do you mean upon return to the ALERTS tab, if you have a long list of alerts, it doesn't scroll down to where you were? If so, Snort is doing that more by accident than design. Suricata (and the new upcoming Snort package) uses a more secure method of passing parameters, but this takes away the automatic ability for the browser to scroll back to previous history. I may be able to emulate that a bit with some tricks. I will investigate for a future release.

In the Suricata Dashboard, i see alerts that are not in the Main Alerts Tab? (See the attachment). After I added the Dashboard, Saved, and edited the number of alerts to display (20), it gave an error. (Didn't record the error). I did a page refresh and it seemed to work after that.
–Maybe its using the wrong descriptor for the Detail Column?--

If you can capture the specific error message for me, that would be helpful. That doggone Dashboard Widget has been a royal pain to get working even mostly correctly. Not surprising to hear there may still be problems. I fiddled with it for about 3 days learning by trial and error… :P. If there is someone who is a better Ajax and jQuery programmer than me, I could use some help with that widget. The two files are here on the box:

/usr/local/www/widgets/javascript/suricata_alerts.js
/usr/local/www/widgets/widgets/suricata_alerts.widget.php

Bill

DigitalDeviant

2 things I've noticed. First is that unless I'm messing something up bad, and that's certainly known to happen, I don't think the suppress list is working. I added an item to the default suppress list and did a full stop/restart of Suricata and still got alerts.

The other is I don't think there is any port scanning detection. I noticed a lack of any port scan hits in the alerts so I ran GRC's Shields Up! and did a full service port scan and nothing new was in my Suricata logs.

bmeeks

@DigitalDeviant:

2 things I've noticed….

I don't think the suppress list is working. I added an item to the default suppress list and did a full stop/restart of Suricata and still got alerts.

I just noticed this in my testing as well. I will look into it. The curious part is if you look in the suricata.log file, you will see where it parsed the list (they call it threshold) and read the entries from it. However, it still does not seem to actually suppress the alerts.

The other is I don't think there is any port scanning detection. I noticed a lack of any port scan hits in the alerts so I ran GRC's Shields Up! and did a full service port scan and nothing new was in my Suricata logs.

I get alerts on scans. I have a virtual machine test environment where a Kali Linux VM scans my various firewall VMs. When I do a nmap scan against the Suricata VM I get alerts. However, you do have to enable the Emerging Threats scan rules (or at least that's what I did). From some Mailing List posts, it appears Suricata does not contain a native port scan processor like Snort does. The omission is apparently by design according to this thread:

https://lists.openinfosecfoundation.org/pipermail/oisf-users/2011-April/000598.html

There is some validity to the "false positive" comment in that thread. I see port scan FPs frequently in my Snort setups.

Bill

DigitalDeviant

@bmeeks:

@DigitalDeviant:

2 things I've noticed….

I don't think the suppress list is working. I added an item to the default suppress list and did a full stop/restart of Suricata and still got alerts.

I just noticed this in my testing as well. I will look into it. The curious part is if you look in the suricata.log file, you will see where it parsed the list (they call it threshold) and read the entries from it. However, it still does not seem to actually suppress the alerts.

The other is I don't think there is any port scanning detection. I noticed a lack of any port scan hits in the alerts so I ran GRC's Shields Up! and did a full service port scan and nothing new was in my Suricata logs.

I get alerts on scans. I have a virtual machine test environment where a Kali Linux VM scans my various firewall VMs. When I do a nmap scan against the Suricata VM I get alerts. However, you do have to enable the Emerging Threats scan rules (or at least that's what I did). From some Mailing List posts, it appears Suricata does not contain a native port scan processor like Snort does. The omission is apparently by design according to this thread:

https://lists.openinfosecfoundation.org/pipermail/oisf-users/2011-April/000598.html

There is some validity to the "false positive" comment in that thread. I see port scan FPs frequently in my Snort setups.

Bill

~~I just ran an nmap remotely and show nothing on my alerts and I'm running all ET open rules except the p2p rules.~~

It does seem to pick up nmap scans after I figured out a few PEBKAC issues. However, the scanning tool here triggers a TCP portscan in Snort and nothing in Suricata. I guess there isn't much you can do about it since it's by design so it will be somewhat of a tradeoff with Snort.

Cino

were any fixes put in to correct the multiple instances because of filter reload when interfaces go up and down? You were able to correct it for snort (barnyard2 in snort still fires up multiples tho)


root   65751  6.0  1.8 73192 55536  ??  SNs   3:45PM   0:01.19 /usr/pbi/suricata-i386/bin/suricata -i em3 -D -c /usr/pbi/suricata-i386/etc/suricata/suricata_34793_em3/suricata.yaml --pidfile /var/r
root   65005  0.6  0.0  3644  1440  ??  IN    3:45PM   0:00.01 /bin/sh /usr/local/etc/rc.d/suricata.sh start
root   65187  0.3  0.9 31008 27220  ??  SN    3:45PM   0:00.23 /usr/pbi/suricata-i386/bin/suricata -i em3 -D -c /usr/pbi/suricata-i386/etc/suricata/suricata_34793_em3/suricata.yaml --pidfile /var/r

bmeeks

@Cino:

were any fixes put in to correct the multiple instances because of filter reload when interfaces go up and down? You were able to correct it for snort (barnyard2 in snort still fires up multiples tho)


root   65751  6.0  1.8 73192 55536  ??  SNs   3:45PM   0:01.19 /usr/pbi/suricata-i386/bin/suricata -i em3 -D -c /usr/pbi/suricata-i386/etc/suricata/suricata_34793_em3/suricata.yaml --pidfile /var/r
root   65005  0.6  0.0  3644  1440  ??  IN    3:45PM   0:00.01 /bin/sh /usr/local/etc/rc.d/suricata.sh start
root   65187  0.3  0.9 31008 27220  ??  SN    3:45PM   0:00.23 /usr/pbi/suricata-i386/bin/suricata -i em3 -D -c /usr/pbi/suricata-i386/etc/suricata/suricata_34793_em3/suricata.yaml --pidfile /var/r

No, I'm sorry that one slipped my mind in the rush to get Suricata 0.2 out. I will write it down on my list of TODO fixes for the next version.

So you are saying you get multiple instances of Barnyard2 on Snort with the exact same command-line parameters? I did not know that was still happening for anyone.

Bill

Cino

@bmeeks:

No, I'm sorry that one slipped my mind in the rush to get Suricata 0.2 out. I will write it down on my list of TODO fixes for the next version.

So you are saying you get multiple instances of Barnyard2 on Snort with the exact same command-line parameters? I did not know that was still happening for anyone.

Bill

Np, it happens. Hoping its an easy fix… Barnyard2, yes. I will see multiple instances of it running. I can reproduce on the fly by resetting my cable modem. I think I may have reported it but to be honest, I can't remember...

bmeeks

@Cino:

@bmeeks:

No, I'm sorry that one slipped my mind in the rush to get Suricata 0.2 out. I will write it down on my list of TODO fixes for the next version.

So you are saying you get multiple instances of Barnyard2 on Snort with the exact same command-line parameters? I did not know that was still happening for anyone.

Bill

Np, it happens. Hoping its an easy fix… Barnyard2, yes. I will see multiple instances of it running. I can reproduce on the fly by resetting my cable modem. I think I may have reported it but to be honest, I can't remember...

Since you reported this, I checked last night and I am seeing that Barnyard2 problem on my Snort setup as well. When my cable modem reboots and bounces my firewall's WAN interface, Barnyard2 is not reliably restarting. I'm working on it. Hopefully it's just a dumb typo someplace since Snort works OK. They are both supposed to be using essentially the same shell script commands. I will put my glasses on and examine the code carefully to find the mistake. There has to be one someplace… :-[

Bill

priller

Very minor thing, but passing it along. When the widget gets an IPv6 alert, it causes the right side border to extend past the normal alignment. The Snort widget wraps the address.

Here it is with only IPv4 alerts and with an IPv6 alert changing the alignment.

suricata-ipv6.jpg_thumb

suricata-ipv4.jpg_thumb

priller

** Problem - Cannot Disable Interface **

Problem: Cannot disable Suricata on an interface, it faults to "The following input errors were detected: The value for Maximum-Pending-Packets must be between 1 and 65,000!"

Steps to Reproduce:

Have Suricata enable and running on an interface. Max Pending Packets is at the default 1024.
Uncheck "Enable" and hit "Save".
The error box "The following input errors were detected: The value for Maximum-Pending-Packets must be between 1 and 65,000!" pops up.
Go back to interfaces and the disable action did not take.

max_pending.jpg_thumb

BBcan177

@priller:

** Problem - Cannot Disable Interface **

FYI - This also occurred in the previous version. Hope that helps diagnose.

bmeeks

@priller:

** Problem - Cannot Disable Interface **

Problem: Cannot disable Suricata on an interface, it faults to "The following input errors were detected: The value for Maximum-Pending-Packets must be between 1 and 65,000!"

Steps to Reproduce:

Have Suricata enable and running on an interface. Max Pending Packets is at the default 1024.

Uncheck "Enable" and hit "Save".

The error box "The following input errors were detected: The value for Maximum-Pending-Packets must be between 1 and 65,000!" pops up.

Go back to interfaces and the disable action did not take.

I will fix it. I screwed up the order of input validation and also forgot to skip it all when just disabling the interface. My bad… :-[

I will post the Pull Request today, and hopefully one of the Core Team devs will have a chance to review and approve.

Bill

bmeeks

@priller:

Very minor thing, but passing it along. When the widget gets an IPv6 alert, it causes the right side border to extend past the normal alignment. The Snort widget wraps the address.

Here it is with only IPv4 alerts and with an IPv6 alert changing the alignment.

I will try to get this fixed in the next update as well. The only way I've found around this is to insert zero-length spaces next to every colon in an IPv6 address. These don't display, but they offer the browser a "line break" opportunity. This makes the prettiest line break (breaking on a colon, that is). The other option is a forced wrap, but that can happen in odd places and makes readability more difficult.

Related to this, what is the preference among users for how to delimit ports when displaying IPv6 addresses? The IPv4 standard is a colon at the end of the address, but since IPv6 already has colons, things are more confusing.

Bill