Suricata Package Updated to 3.1.2 – Release Notes

bmeeks

Thank you for the information.
One side note:
Yes we are trying to block usually external traffic but if you leave the local networks in the default passlist you won't block any external traffic at all. The passlist will allow all the traffic FROM and TO the local networks. We can't change this behavior because in the generated rules the sources and the destinations are any any.
ie:```
pass ip 127.0.0.1/32 any <> any any (msg:"Pass List Entry - allow all traffic from/to 127.0.0.1/32"; sid:1000001;)

You are correct. This is my mistake. Should have used the options of SRC, DST or BOTH as part of the logic when generating the PASS rules. Using "any" and "any" for the SRC and DST is not good. Let me think this over in my head and fix it, but I need to think about it carefully. Any suggestions from users are welcomed!

Bill

bmeeks

@Redyr:

Hello Bill,

Thank you for making Suricata 3.1.2 possible. Some of us, including me wanted this to happen, and as usual with new stuff things can go wrong, I understand. I will give you a feedback in regards to the new version, because right now I keep it disabled, due to issues that @mind12 reported.

First the pass list includes all the network ranges plus 2 external IPs marked in red, which are not mine, not my ISP's, just external hosts…Why Suricata will include those by default? - Please see the attached picture.

The pass list for WAN and for LAN contains the same list of IPs, is it ok?

If I try to manually edit the pass list file, the same IPs will be present next time I restart the service.

If I try to manually create a custom pass list, the GUI will say the alias is not eligible. Please see the attached Screenshot. What kind of alias should I define? I tried all the types.

If Suricata is enabled, no traffic will be analyzed, and I cannot change that default pass list, even if I delete it, it will be re-written.

I tried to uninstall Suricata, and I unchecked the "Settings will not be removed during package deinstallation." option. Why after reinstalling the same configuration is still present? I notice this with other packages for eg. Squid

Also which IPs should I include in the pass list for WAN or for LAN in order to be safe, and not get blocked?

The suppresed user rules from 3.0 version, are now present in Wansurpress and Lansurpress lists, but the Suricata log states that "no such rules are present"

Please take your time, and come back with some hints.

When using inline IPS mode, those pass list files you see are generated but not used. All of the Pass List IP address stuff is stored in the config.xml file of the firewall in the section for the Suricata package. In fact pretty much all of the configuration information is stored there. Each time you save a change in the GUI or start/restart Suricata from the INTERFACES tab in the GUI, the configuration information is read from the config.xml file of the firewall and written to the various Suricata configuration files. So any manual edit you make to suricata.yaml or any pass list or any threshold list will be overwritten the next time you save a change in the GUI or start/restart Suricate from the GUI.

As for the new Pass List functionality for IPS mode –

It uses PASS rules generated automatically and written to a new file called passlist.rules in the /rules sub-directory of each interface. This is explained in the long notes I posted as part of the Release Notes at the top of this thread. So inline IPS mode totally ignores the pass list file you see in each interface sub-directory. That file is only used by Legacy mode. It is still created with IPS mode, but then it is just ignored.

I will see about fixing the issues with the new PASS rules. I was hurrying the update and I did not clearly think through the ramifications of my "fix" for Pass Lists in IPS mode.

Bill

bmeeks

@mind12:

Hi Redyr,

Regarding creating a custom Passlist:

first create an alias at Firewall/Aliases/IP menu containing the networks that you would like to always pass (ie. I used - firewall interfaces, dnsbl address), don't add the protected local networks to it

go to services/suricata/pass lists, create a new list and add the alias to it

go to the suricata interface settings and pick the created list

save and restart suricata

These steps worked for me.

+1. @mind12 is correct. This is the way to handle customizing the Pass List. I will work on correcting the "any" <> "any" problem I created in the PASS rules. I will also add an option in the GUI to completely disable the "default" pass list so it will not get in the way of any customized list.

Bill

Redyr

@bmeeks:

@mind12:

Hi Redyr,

Regarding creating a custom Passlist:

first create an alias at Firewall/Aliases/IP menu containing the networks that you would like to always pass (ie. I used - firewall interfaces, dnsbl address), don't add the protected local networks to it

go to services/suricata/pass lists, create a new list and add the alias to it

go to the suricata interface settings and pick the created list

save and restart suricata

These steps worked for me.

+1. @mind12 is correct. This is the way to handle customizing the Pass List. I will work on correcting the "any" <> "any" problem I created in the PASS rules. I will also add an option in the GUI to completely disable the "default" pass list so it will not get in the way of any customized list.

Bill

Thanks again

mind12

@bmeeks:

@mind12:
Thank you for the information.
One side note:
Yes we are trying to block usually external traffic but if you leave the local networks in the default passlist you won't block any external traffic at all. The passlist will allow all the traffic FROM and TO the local networks. We can't change this behavior because in the generated rules the sources and the destinations are any any.
ie:```
pass ip 127.0.0.1/32 any <> any any (msg:"Pass List Entry - allow all traffic from/to 127.0.0.1/32"; sid:1000001;)
You are correct. This is my mistake. Should have used the options of SRC, DST or BOTH as part of the logic when generating the PASS rules. Using "any" and "any" for the SRC and DST is not good. Let me think this over in my head and fix it, but I need to think about it carefully. Any suggestions from users are welcomed!

Bill

I thought about the problem but there's no easy answer. It strongly depends on the usage.
I woudn't use the 'any' keyword in a rule's SRC or DST because you expose yourself to attacks by not filtering in the choosen direction.
If I need to pass something there must be an exact src and dst for the traffic.

What's the benefit using a passlist in inline mode anyway? There's no dropped connections by default.

I checked the rule syntax and I assume the networks in the pass rules are only in the SRC address, am I correct?
But the message states "from/to IP".
I completely lost now because if there are no DST rules suricata alerts should have appered before regarding traffic going to my inside networks.

Here are my rules:

pass ip 127.0.0.1/32 any <> any any (msg:"Pass List Entry - allow all traffic from/to 127.0.0.1/32"; sid:1000001;)
pass ip 172.16.5.1/32 any <> any any (msg:"Pass List Entry - allow all traffic from/to 172.16.5.1/32"; sid:1000002;)
pass ip 172.16.5.251/32 any <> any any (msg:"Pass List Entry - allow all traffic from/to 172.16.5.251/32"; sid:1000003;)
pass ip ::1/128 any <> any any (msg:"Pass List Entry - allow all traffic from/to ::1/128"; sid:1000004;)

bmeeks

@mind12:

I thought about the problem but there's no easy answer. It strongly depends on the usage.
I woudn't use the 'any' keyword in a rule's SRC or DST because you expose yourself to attacks by not filtering in the choosen direction.
If I need to pass something there must be an exact src and dst for the traffic.

What's the benefit using a passlist in inline mode anyway? There's no dropped connections by default.

I checked the rule syntax and I assume the networks in the pass rules are only in the SRC address, am I correct?
But the message states "from/to IP".
I completely lost now because if there are no DST rules suricata alerts should have appered before regarding traffic going to my inside networks.

Here are my rules:
pass ip 127.0.0.1/32 any <> any any (msg:"Pass List Entry - allow all traffic from/to 127.0.0.1/32"; sid:1000001;)
pass ip 172.16.5.1/32 any <> any any (msg:"Pass List Entry - allow all traffic from/to 172.16.5.1/32"; sid:1000002;)
pass ip 172.16.5.251/32 any <> any any (msg:"Pass List Entry - allow all traffic from/to 172.16.5.251/32"; sid:1000003;)
pass ip ::1/128 any <> any any (msg:"Pass List Entry - allow all traffic from/to ::1/128"; sid:1000004;)

I quickly copied the rule syntax late at night from a Suricata documentation example on the web. I was hurrying to get the package put together in the limited free time I had. The "from/to" phrase is mine and my intention was that traffic either sourced from or destined to the given IP address would be allowed to pass (not dropped). The old Legacy Mode has a custom blocking plugin I wrote that lives in the Suricata binary. That plugin gets a copy of every alert generated by Suricata (in other words, a rule has fired and generated an alert already). That custom plugin then looks at the IP addresses in the SRC and DST fields of the alert packet and compares them to the list of IP addresses in the Pass List. You have a setting for Legacy Mode that says which IP to block (SRC or DST or BOTH). The plugin compares the SRC and DST addresses in the alerting packet to those in the Pass List. If a match is found with both direction (SRC or DST) and the actual address, the IP is not blocked. I wanted to duplicate that with PASS rules when using inline IPS mode, but the logic of my first attempt is a bit flawed … :-[.

Bill

ntct

@bmeeks:

@ntct:

Hi Bill,

How to denote this package?? :)

I don't understand your question. Can you clarify what you mean by "denote"?

Thanks,
Bill

Sorry, donate…... :D

bmeeks

@ntct:

@bmeeks:

@ntct:

Hi Bill,

How to denote this package?? :)

I don't understand your question. Can you clarify what you mean by "denote"?

Thanks,
Bill

Sorry, donate…... :D

Oh … :D. I have a Paypal account at bmeeks8(at)bellsouth.net (remove the "at" and use the standard ampersand as this is my feeble attempt to hide from spammers).

Bill

bmeeks

@mind12:

@bmeeks:
@mind12:
Thank you for the information.
One side note:
Yes we are trying to block usually external traffic but if you leave the local networks in the default passlist you won't block any external traffic at all. The passlist will allow all the traffic FROM and TO the local networks. We can't change this behavior because in the generated rules the sources and the destinations are any any.
ie:```
pass ip 127.0.0.1/32 any <> any any (msg:"Pass List Entry - allow all traffic from/to 127.0.0.1/32"; sid:1000001;)
You are correct. This is my mistake. Should have used the options of SRC, DST or BOTH as part of the logic when generating the PASS rules. Using "any" and "any" for the SRC and DST is not good. Let me think this over in my head and fix it, but I need to think about it carefully. Any suggestions from users are welcomed!

Bill
I thought about the problem but there's no easy answer. It strongly depends on the usage.
I woudn't use the 'any' keyword in a rule's SRC or DST because you expose yourself to attacks by not filtering in the choosen direction.
If I need to pass something there must be an exact src and dst for the traffic.

What's the benefit using a passlist in inline mode anyway? There's no dropped connections by default.

I checked the rule syntax and I assume the networks in the pass rules are only in the SRC address, am I correct?
But the message states "from/to IP".
I completely lost now because if there are no DST rules suricata alerts should have appered before regarding traffic going to my inside networks.

Here are my rules:
pass ip 127.0.0.1/32 any <> any any (msg:"Pass List Entry - allow all traffic from/to 127.0.0.1/32"; sid:1000001;)
pass ip 172.16.5.1/32 any <> any any (msg:"Pass List Entry - allow all traffic from/to 172.16.5.1/32"; sid:1000002;)
pass ip 172.16.5.251/32 any <> any any (msg:"Pass List Entry - allow all traffic from/to 172.16.5.251/32"; sid:1000003;)
pass ip ::1/128 any <> any any (msg:"Pass List Entry - allow all traffic from/to ::1/128"; sid:1000004;)

Some more info –

The idea behind having a Pass List is that some environments have a trusted host or hosts they never want blocked (or have their traffic dropped). For example, you probably never want the LAN IP address of your firewall interface blocked (dropped) by Suricata. If that happens, you can't connect to the firewall at all from the LAN side. You're back to serial cable or direct console access. Same thing for say your default gateway on the WAN. Likely don't want it blocked (or traffic to/from it dropped) because then all network connectivity to the outside is lost. So the idea of a Pass List was born way back in the Snort package. The idea was copied over into the Suricata package. The change to inline IPS mode recently caused the old pass list technology used in Legacy mode to no longer work. The reasons are a bit too technical for here, but the underlying blocking (dropping) architecture is totally different and thus the old way of implementing the pass list no longer worked with inline IPS mode.

There are several reasons for potentially needing a list of IP addresses whose traffic is never dropped. Granted things are a little different with inline mode since there is no use of the pf firewall and its tables anymore. Some users here were complaining about traffic being dropped for some critical trusted hosts due to false positives. They wanted to be able to say "never block this host" and not be bothered with constantly tweaking rules or suppress lists to prevent false positives. There are different schools of thought along that line for sure. Some security purists will legitimately argue you are sacrificing security with a pass list, but some pragmatists point out that ultimately the purpose of a network is to dependably route traffic from here to there, and a network can be "too secure" in their minds (as in so secure almost nothing can move due to alerts or drops caused by false positives).

Now back to the PASS rules auto-generated by Suricata. The way I read the rule synatx it should pass any traffic where the Pass List IP address is in either the SRC or DST field of the packet. The direction symbol in the rule is "<>", which means "either direction". This is opposed to the normal syntax of either "->" or "<-" which mean "to" and "from", respectively. So no matter if the flow is to the Pass List host from any other host, or from the Pass List host to any other host, it will be allowed and not dropped so long as one of the IP addresses matches that of the pass list host given in the rule. Note that any traffic "passed" is considered to be safe and thus generates no alert. So you will never see "passed" traffic in the alert logs.

Is that not how it is working for you?

Bill

mind12

@bmeeks:

@mind12:
@bmeeks:
@mind12:
Thank you for the information.
One side note:
Yes we are trying to block usually external traffic but if you leave the local networks in the default passlist you won't block any external traffic at all. The passlist will allow all the traffic FROM and TO the local networks. We can't change this behavior because in the generated rules the sources and the destinations are any any.
ie:```
pass ip 127.0.0.1/32 any <> any any (msg:"Pass List Entry - allow all traffic from/to 127.0.0.1/32"; sid:1000001;)
You are correct. This is my mistake. Should have used the options of SRC, DST or BOTH as part of the logic when generating the PASS rules. Using "any" and "any" for the SRC and DST is not good. Let me think this over in my head and fix it, but I need to think about it carefully. Any suggestions from users are welcomed!

Bill
I thought about the problem but there's no easy answer. It strongly depends on the usage.
I woudn't use the 'any' keyword in a rule's SRC or DST because you expose yourself to attacks by not filtering in the choosen direction.
If I need to pass something there must be an exact src and dst for the traffic.

What's the benefit using a passlist in inline mode anyway? There's no dropped connections by default.

I checked the rule syntax and I assume the networks in the pass rules are only in the SRC address, am I correct?
But the message states "from/to IP".
I completely lost now because if there are no DST rules suricata alerts should have appered before regarding traffic going to my inside networks.

Here are my rules:
pass ip 127.0.0.1/32 any <> any any (msg:"Pass List Entry - allow all traffic from/to 127.0.0.1/32"; sid:1000001;)
pass ip 172.16.5.1/32 any <> any any (msg:"Pass List Entry - allow all traffic from/to 172.16.5.1/32"; sid:1000002;)
pass ip 172.16.5.251/32 any <> any any (msg:"Pass List Entry - allow all traffic from/to 172.16.5.251/32"; sid:1000003;)
pass ip ::1/128 any <> any any (msg:"Pass List Entry - allow all traffic from/to ::1/128"; sid:1000004;)
Some more info –

The idea behind having a Pass List is that some environments have a trusted host or hosts they never want blocked (or have their traffic dropped). For example, you probably never want the LAN IP address of your firewall interface blocked (dropped) by Suricata. If that happens, you can't connect to the firewall at all from the LAN side. You're back to serial cable or direct console access. Same thing for say your default gateway on the WAN. Likely don't want it blocked (or traffic to/from it dropped) because then all network connectivity to the outside is lost. So the idea of a Pass List was born way back in the Snort package. The idea was copied over into the Suricata package. The change to inline IPS mode recently caused the old pass list technology used in Legacy mode to no longer work. The reasons are a bit too technical for here, but the underlying blocking (dropping) architecture is totally different and thus the old way of implementing the pass list no longer worked with inline IPS mode.

There are several reasons for potentially needing a list of IP addresses whose traffic is never dropped. Granted things are a little different with inline mode since there is no use of the pf firewall and its tables anymore. Some users here were complaining about traffic being dropped for some critical trusted hosts due to false positives. They wanted to be able to say "never block this host" and not be bothered with constantly tweaking rules or suppress lists to prevent false positives. There are different schools of thought along that line for sure. Some security purists will legitimately argue you are sacrificing security with a pass list, but some pragmatists point out that ultimately the purpose of a network is to dependably route traffic from here to there, and a network can be "too secure" in their minds (as in so secure almost nothing can move due to alerts or drops caused by false positives).

Now back to the PASS rules auto-generated by Suricata. The way I read the rule synatx it should pass any traffic where the Pass List IP address is in either the SRC or DST field of the packet. The direction symbol in the rule is "<>", which means "either direction". This is opposed to the normal syntax of either "->" or "<-" which mean "to" and "from", respectively. So no matter if the flow is to the Pass List host from any other host, or from the Pass List host to any other host, it will be allowed and not dropped so long as one of the IP addresses matches that of the pass list host given in the rule. Note that any traffic "passed" is considered to be safe and thus generates no alert. So you will never see "passed" traffic in the alert logs.

Is that not how it is working for you?

Bill

Ohh it's clear now, it's working as it should.
I missed the direction symbols in the syntax.
Every time I learn new things from you, you should work as a teacher :). I really appreciate your dedication to the community.

mind12

ntct

Oh … :D. I have a Paypal account at bmeeks8(at)bellsouth.net (remove the "at" and use the standard ampersand as this is my feeble attempt to hide from spammers).

Bill

I appreciate your efforts. 8)

bmeeks

@ntct:

Oh … :D. I have a Paypal account at bmeeks8(at)bellsouth.net (remove the "at" and use the standard ampersand as this is my feeble attempt to hide from spammers).

Bill

I appreciate your efforts. 8)

Thank you for your kindness! I recevied an email notification from PayPal.

Bill

allu

Just to report, same here, suricata.log shows

22/1/2017 – 09:02:19 - <notice>-- This is Suricata version 3.0 RELEASE

and package manager now shows 3.1.2. Had to re-install to actually upgrade it.</notice>

Redyr

@allu:

Just to report, same here, suricata.log shows

22/1/2017 – 09:02:19 - <notice>-- This is Suricata version 3.0 RELEASE

and package manager now shows 3.1.2. Had to re-install to actually upgrade it.</notice>

How did you update the package from WebGui or from CLI?

I updated from CLI which also restarts the box, and suricata -V reported 3.1.2 version from the start

allu

From the WebGUI, thus no reboot.

Redyr

@allu:

From the WebGUI, thus no reboot.

As I suspected. @bmeeks if you are seeing this, maybe you can update the release notes ( if you consider this an useful information ). That's why for some worked from the start, and for others after uninstalling first

doktornotor

The dependency is already fixed, no need to do anything here. https://github.com/pfsense/FreeBSD-ports/blob/devel/security/pfSense-pkg-suricata/Makefile#L16