Suricata Package Updated to 3.1.2 – Release Notes

ntct

@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