Suricata Package Updated to 3.1.2 – Release Notes

bmeeks

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