Suricata 4.0.13_9 - pass list being ignored

sparkyjf

Hi there,

We have a pfSense 2.4.4 server running Suricata 4.0.13_9 (updated to this version today) which we have an ongoing problem with. We have set up Suricata in Legacy Mode, Block Offenders is enabled, and we have set up an Alias containing only IP addresses and subnets which is allocated in the Pass List parameter.

My understanding from the documentation and pinned posts on this forum is that in Legacy mode, this should be sufficient to prevent certain IP addresses from being blocked even if they cause an alert. However, the reality is that IP's that are in the Pass List are being blocked.

I presume that I might have something wrong in my configuration, but am unclear as to what. Can anyone help with this please?

0_1541518742782_3ccb00fd-7bc1-46d0-9c18-e8be52058fb4-image.png

0_1541518831153_bc1953d8-0afe-47f6-b6b3-3dce7f9db128-image.png

Many thanks!

James

bmeeks

Did you restart Suricata on the interface after assigning the pass list?

sparkyjf

Yes indeed - in fact the whole firewall has been rebooted since the configuration is put in place. Is there a way I can help debug this?

bmeeks

@sparkyjf said in Suricata 4.0.13_9 - pass list being ignored:

Yes indeed - in fact the whole firewall has been rebooted since the configuration is put in place. Is there a way I can help debug this?

I can tell you a few things to check, but that's about it. This almost has to be a problem with your specific configuration because if it was a package bug there would be tons of posts on the forum about it.

Once a Pass List is created, it must be manually assigned to a given interface on the INTERFACE SETTINGS tab. From the looks of your screenshot it appears you have done that already.

After the assignment, Suricata should be restarted. You said you rebooted the firewall, so that's the same thing.

The Pass List is written out to the interface configuration directory for the interface as a simple text file. That location is under /usr/local/etc/suricata/*** where the *** is a string composed of a random GUID and the physical interface name. There will be a separate sub-directory under /usr/local/etc/suricata for each active Suricata interface. Find the sub-directory for your interface and ensure the Pass List file is located there and contains the contents you expect it to have.

That's about all that can be checked. You can look in the suricata.log file for the interfaces (on the LOGS VIEW tab) and examine all the entries for Suricata start up. You should see some lines showing the Pass List file was loaded and IP addresses read from it. Any errors would be written to that log file as well.

sparkyjf

Thank you for this - I have done some extra debugging and I can see that the passlist is created in the directory as you described. It contains all the same IP addresses that are shown in the Web UI which is positive.

One thing I note (which may or may not be relevant) - all IP addresses that come from the alias are specified like this:

8.8.8.8

However the automatically generated entries are specified as follows:

10.1.2.3/32

I don't know if the /32 is relevant - however I assume not because as you rightly said earlier, the forum would be littered with posts if there was a wider problem with this package. The logs look ok as far as I can tell - here's the fragment where it loads the passlist:

7/11/2018 -- 11:00:41 - <Info> -- alert-pf output device (regular) initialized: block.log
7/11/2018 -- 11:00:41 - <Info> -- alert-pf -> Pass List /usr/local/etc/suricata/suricata_16295_igb3/passlist parsed: 29 IP addresses loaded.
7/11/2018 -- 11:00:41 - <Info> -- alert-pf -> Created firewall interface IP change monitor thread for auto-whitelisting of firewall interface IP addresses.
7/11/2018 -- 11:00:41 - <Info> -- alert-pf output initialized, pf-table=snort2c  block-ip=both  kill-state=on  block-drops-only=off
7/11/2018 -- 11:00:41 - <Info> -- alert-pf -> Firewall interface IP address change notification monitoring thread started.
7/11/2018 -- 11:00:41 - <Info> -- fast output device (regular) initialized: alerts.log
7/11/2018 -- 11:00:41 - <Info> -- http-log output device (regular) initialized: http.log
7/11/2018 -- 11:00:41 - <Info> -- Using 1 live device(s).
7/11/2018 -- 11:00:41 - <Info> -- using interface igb3
7/11/2018 -- 11:00:41 - <Info> -- Running in 'auto' checksum mode. Detection of interface state will require 1000 packets.
7/11/2018 -- 11:00:41 - <Info> -- Set snaplen to 1518 for 'igb3'
7/11/2018 -- 11:00:41 - <Info> -- RunModeIdsPcapAutoFp initialised

As I understand that it looks good. And the passlist file has 28 lines in it, so the loaded "29 IP addresses" looks ok, though I note it's 29 subnets, not individual IP's as the automatic passlist includes some of the locally routed subnets.

Given all this I'm really not sure where to look next. Do you know of an easy way to trigger Suricata, kind of like the EICAR virus but for an IDS? If so I can do some testing and see if the behaviour is consistent.

Thanks for all your help so far!

bmeeks

The "/32" on the end of some of those IP addresses should not matter. The IP address strings read from the Pass List text file are handed off to Suricata's internal functions to be converted into their binary equivalents. Those functions supposedly do not care if the /32 is present or not.

As for triggering Suricata at will, that depends on what your loaded rules are like. You will need to generate traffic that you have a rule watching for. My usual test scenario is to enable the ET Scan rules category and then use nmap from another host to port scan the firewall interface where Suricata is running. That will generate several alerts.