Suricata GUI package v3.0_6 for pfSense 2.3 - Release Notes

javcasta

Hello.

Its ok for me.

I can assign a custom pass list to the interface vía drop-down selection.

Thanks and regards.

ntct

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!

bmeeks

@ntct:

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

ntct

Yes, I follow this step. But I can only assign a custom pass list (Home NET can't assign, It is not showing). :(

cats.jpg_thumb

cats2.jpg_thumb

bmeeks

@ntct:

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

ntct

It works :)

Thanks!

pyrodex

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?

bmeeks

@pyrodex:

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

packet_flow.png_thumb

nikkon

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?

bmeeks

@nikkon:

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

nikkon

@bmeeks:

@nikkon:

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

bmeeks

@nikkon:

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

What 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

nikkon

Here I have some pictures with my setup.

Screenshot_2016-04-23-07-19-57.png_thumb

Screenshot_2016-04-23-07-20-10.png_thumb

Screenshot_2016-04-23-07-20-55.png_thumb

Screenshot_2016-04-23-07-21-36.png_thumb

Screenshot_2016-04-23-07-21-58.png_thumb

bmeeks

@nikkon:

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

nikkon

still 0 alerts…damn...this is eather way good and bad i suppose :P not sure it really does anything

bmeeks

@nikkon:

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

nikkon

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.

bmeeks

@nikkon:

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

nikkon

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 :(

bmeeks

@nikkon:

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 :(

Give me two more pieces of information. Post a screenshot of the main INTERFACES tab in Suricata (so I can see the enabled interfaces and their current running state), and then post the contents of the suricata.log file (if it exists). To see that file, go to LOGS VIEW, select your WAN interface (if that's where Suricata is configured) and then choose suricata.log in the drop-down. The contents of the log file will be shown if the file exists.

Bill