Suricata GUI package v3.0_6 for pfSense 2.3 - Release Notes
-
The Suricata package for pfSense 2.3 has been updated to version 3.0_6. This update corrects a number of user-reported bugs in the GUI package.
Bug Fixes
1. The ALERTS, BLOCKS, LOGS VIEW and SID MGMT tabs are missing some or all breadcrumbs in the header.
2. Rule suppression using "by address" icons on the ALERTS tab results in garbled HTML resulting in the tooltip text being incorrectly displayed instead of the appropriate icon.
3. Disabling of rules by clicking the icon on the ALERTS tab not working and resulting in just a page reload.
4. Suppress List deletion is allowed for an assigned list, but it should be prevented and a warning message displayed instead.
5. Dashboard Widget not properly handling multiple interfaces (row sorting gets off).
6. Editing/saving of Custom Rules not working on RULES tab.
7. Pass Lists created on the PASS LIST tab are not available in the drop-down for selection on the INTERFACE SETTINGS tab for a Suricata instance.
8. Automatic log management does not default to "yes" on LOG MGMT tab.
9. Number of entries to display value on ALERTS tab not initialized in some instances.
10. Number of entries to display value on BLOCKS tab not initialized in some circumstances resulting in no blocked hosts being displayed even though blocks exist in the pf table for legacy mode operation.
11. Rules update process on UPDATES tab appears to not complete sometimes, and the lack of some visual feedback confuses users.The UPDATES tab now provides a little more visual feedback, but it is not yet where I want it to be. A future update will incorporate a new Bootstrap-compatible progress bar provided by Steve Beaver from the pfSense team to show the download progress of the rules package tarball files. One other item that will get some love in the near future is the XMLRPC Sync tab. Right now it is just basically ugly. It was low priority while the rest of the package was converted to Bootstrap and the inline IPS feature using Netmap was being added. Now that the big stuff is in, I can go back and work on those lower priority things. One feature coming to the SYNC tab is the ability to selectively sync just parts of the configuration instead of the whole enchilada.
Bill
-
Hello.
Its ok for me.
I can assign a custom pass list to the interface vía drop-down selection.
Thanks and regards.
-
Hi.
I use bridge mode. But I can't assign a custom Home Net to the interface vía drop-down selection.
How can I create a Home Net for WAN interface?
Thanks!
-
Hi.
I use bridge mode. But I can't assign a custom Home Net to the interface vía drop-down selection.
How can I create a Home Net for WAN interface?
Thanks!
Did you create the custome Home Net first? You do this on the PASS LIST tab. A Pass List is simply a collection of IP addresses, and that list can be assigned to an interface as either a HOME_NET setting or a Pass List. So first go create a custom Pass List on the PASS LIST tab. Uncheck all the check boxes for any default IP addresses you do not want in the custom home net. You probably will also want to first create an Alias under Firewall > Aliases containing the IP addresses you do want in the custom home net. Then assign the alias to the custom Pass List you create.
Now go the INTERFACE SETTNIGS tab and pick the list you created. It will be showing as a selection in the drop-down for HOME_NET. Save the change and then restart Suricata on the interface.
Bill
-
Yes, I follow this step. But I can only assign a custom pass list (Home NET can't assign, It is not showing). :(
-
Yes, I follow this step. But I can only assign a custom pass list (Home NET can't assign).
OK…my bad. Got in a hurry and missed another copy-paste error. You can fix it yourself for now and I will make a permanent fix in the next update.
Do this for temp fix for now --
1. Edit the file /usr/local/www/suricata/suricata_interfaces_edit.php.
2. Find line #914. It reads like this:
suricata_get_config_lists('whitelist')Change it to read like this instead:
suricata_get_config_lists('passlist')Should you want to have a custom EXTERNAL_NET as well, the same error exists there at line #935.
Bill
-
It works :)
Thanks!
-
Question:
I've done the steps in the first post and the alert.log is now reflecting DROP and the web interface as well. Would I expect to see these items stored in the snort2c table for an hour based on my settings or is that setting for the legacy mode? Are drops not inserting themselves into the firewall table to prevent the client from coming back for a defined period?
-
Question:
I've done the steps in the first post and the alert.log is now reflecting DROP and the web interface as well. Would I expect to see these items stored in the snort2c table for an hour based on my settings or is that setting for the legacy mode? Are drops not inserting themselves into the firewall table to prevent the client from coming back for a defined period?
Inline IPS mode is markedly different in operation than the old legacy mode. For starters, inline mode does not use the packet filter firewall nor any of its tables. The snort2c table is not used at all for inline mode blocks. With inline mode, every single packet first must go through Suricata before the operating system and the firewall even see the packet. Suricata will either pass on or drop packets. Dropped packets never go anywhere past the NIC (looking from the point of view of being located outside on the WAN side of your firewall looking in).
There is no "remembering" of dropped packets. They are simply dropped. If the same attacker comes by again, the packets will just be dropped again. No benefit at all to having the IP address stored in the firewall table. The packet never makes it that far using inline IPS mode.
Here is a simple diagram illustrating the path an inbound packet (from Internet to an internal LAN host) takes. Notice how the Suricata engine sits between the actual NIC driver and the remainder of pfSense's kernel. This is for an inbound packet. Outbound traffic is similar except in that case the kernel and firewall would see the packet first, then the Suricata engine and finally the NIC. For inbound traffic, the kernel and firewall will only see the traffic IF Suricata does not drop it. For outbound traffic, the NIC will only see the traffic for transmission IF Suricata does not drop it.
Also, using inline IPS mode, rules that "alert" just simply put an alert in the log and on the ALERTS tab. The traffic is still passed. Only rules whose action keyword has been changed to DROP can actually cause traffic to be dropped (the equivalent of the old "blocked' action in legacy mode). The distinction between ALERT and DROP is very critical and important to get your head around if you use the new inline IPS mode.
Bill
-
usign this already created thread to have a quick question:
using the latest version -> works on pppoe -> have all rules loaded but 0 alerts afer 24 hours!!!
snort on the other hand (when it was used) reported tons of alerts after 1 hour.
do i miss anything? -
usign this already created thread to have a quick question:
using the latest version -> works on pppoe -> have all rules loaded but 0 alerts afer 24 hours!!!
snort on the other hand (when it was used) reported tons of alerts after 1 hour.
do i miss anything?What kinds of alerts was Snort firing on? If it was the HTTP_INSPECT preprocessor alerts, then not seeing those in Suricata is normal. If other more traditional Snort VRT rules, then maybe your Suricata installation is not quite correct ???
Bill
-
usign this already created thread to have a quick question:
using the latest version -> works on pppoe -> have all rules loaded but 0 alerts afer 24 hours!!!
snort on the other hand (when it was used) reported tons of alerts after 1 hour.
do i miss anything?What kinds of alerts was Snort firing on? If it was the HTTP_INSPECT preprocessor alerts, then not seeing those in Suricata is normal. If other more traditional Snort VRT rules, then maybe your Suricata installation is not quite correct ???
Bill
yeah those alers…now the alert log is empty for 4 days.
if you say it's notmal...fine ...still wanted to see if this really works. 0 logs also -
yeah those alers…now the alert log is empty for 4 days.
if you say it's notmal...fine ...still wanted to see if this really works. 0 logs alsoWhat vendor rules package or packages are using? Snort VRT or Emerging Threats? Of those packages, what rule categories do you have enabled? After 4 days I would expect to see maybe a handful of alerts, but that would be extremely dependent on which rules are enabled.
It is difficult to judge posters' experience with IDS/IPS, so I will ask this about your experience level with systems of this type? Do you fully understand how Snort or Suricata work with various rules and that you must load and explicitly select rules to be used by the sensor? These packages are not just install and forget. They offer pretty much zero protection out-of-the-box until customized a bit. Snort will automatically enforce its preprocessor and decoder rules out of the box, and that HTTP_INSPECT preprocesssor rule is particularly noisy. You may know already know that, so forgive me for asking the obvious, but I have run into some novice IDS/IPS users of late who lacked a basic understanding of how the packages should be configured.
Bill
-
Here I have some pictures with my setup.
-
Here I have some pictures with my setup.
Your setup looks fine. It is possible you could go alert free for days. After I reflected a bit about my earlier reply, I realized that I go weeks sometimes between alerts on my LAN. I have a setup similar to your on my LAN. Just to see activity, I have the Emerging Threats IP lists enabled on my WAN. Those log several alerts/blocks per hour. They really serve no purpose since the firewall is default deny anyway, but the little bit of noise they show lets me know everything is working and gives me something to see on the ALERT and BLOCK tabs… ;).
Bill
-
still 0 alerts…damn...this is eather way good and bad i suppose :P not sure it really does anything
-
still 0 alerts…damn...this is eather way good and bad i suppose :P not sure it really does anything
You could run an nmap scan using an option that is sure to trigger some of your rules. For me, I enable the ET-Scan rules and then run an nmap services scan against the host to trigger alerts. I use virtual machines for my testing, but it can work on a physical host as well. There are web sites out there you can use to externally scan or "attack" a firewall to generate traffic that should alert. Of course "should" is the operative word because it depends on exactly what rules you have enabled. The ET-Scan rules are pretty good in my view for that kind of test.
Bill
-
Never restated…still 0 alerts.
Now...could it be because i use /var & /var are in RAM? I use ram disk for those and suricata keeps logs in /var. -
Never restated…still 0 alerts.
Now...could it be because i use /var & /var are in RAM? I use ram disk for those and suricata keeps logs in /var.The log files should get created, but depending on space in the RAM disk you may be exhausting it and logging fails. Also, a reboot will wipe out logs when they are a RAM disk.
If you have a NanoBSD installation, I can pretty much guarantee you that neither Suricata nor Snort will perform well. There are just too many limitations with NanoBSD. If you have conventional full install with a hard disk, then why would you be using the RAM disk option? Suricata and Snort log a bunch (and I mean a bunch) of stuff. Either package can easily overwhelm a RAM disk even with moderate network traffic.
Bill
-
I use amd64 install on a 8gb ecc.
/var has 1500 MB defined so i have enought space.I only use 15%.
There is something alse wrong…i don't get it yet :(
