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

[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

[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.

[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

[nikkon]

thx for helping me.
here you have them :)


[bmeeks]

@nikkon:

thx for helping me.
here you have them :)

Ahh…I see you are using PPPoE.  I am not 100% positive that is supported by the Netmap driver.  I did some limited Google research, but failed to find a definite answer.  PPPoE support on FreeBSD is relatively new to Suricata.  I really don't know about Netmap and PPPoE, though.  I don't see any errors in your suricata.log, but if you are not getting alerts then something may well not be working.

Have you done nmap scans against your WAN and not triggered any of the ET-Scan rules?  I know if you do the nmap services scan against your firewall and you have the Emerging Threats Scan rules active that you will get some alerts when things are working.

Bill

[nikkon]

i did the scan. nothing happend.
it seems version 3.0.x supports pppoe.this was on a bug list on 2.2.x

[bmeeks]

@nikkon:

i did the scan. nothing happend.
it seems version 3.0.x supports pppoe.this was on a bug list on 2.2.x

Yes, but aren't you using the new Inline Mode?  If so, that uses the new Netmap driver and I'm not sure that driver supports PPPoE encapsulation properly.

Have you tried running Suricata in the Legacy Mode for IDS?  If not, go to the INTERFACE SETTINGS tab and change the mode from Inline to Legacy.  Save the change and then restart Suricata.  Run the nmap scan again and report.

Trying to narrow down if this is indeed a Netmap-related problem.  Snort does not use Netmap.  Unfortunately I do not have  PPPoE connection to test with.

Bill

[nikkon]

legacy mode set!
we'll perform the test and report the result asap

[nikkon]

same behaviour - 0 alerts

[bmeeks]

@nikkon:

same behaviour - 0 alerts

That is indeed strange.  As I said, I do not have a PPPoE connection to test with.  Just for grins, stand up a Suricata instance on your LAN, give it more or less the same rules (certainly give it the ET-Scan rules) and then run an nmap services scan from a LAN host against the firewall.  That should generate some alerts (may not block depending on Pass List settings, but it should alert).  The idea for this test is to make sure your basic Suricata configuration is correct.  If you get alerts on the LAN but not the WAN, then the PPPoE part of Suricata is potentially not working.  However, if you still get no alerts on the LAN, then you more likely have a firewall/Suricata configuration issue.

The nmap command is```
nmap -sV [target_ip]

Bill