Suricata 6.0.3_4 Package Update Release Notes (currently for DEVEL only)
-
Suricata-6.0.3_4
This package update for Suricata adds a couple of new features and addresses two bug reports. This new version is first being released for the Development Snapshot branch of pfSense. After some time there for wider testing, it will be migrated over to the Release branch of pfSense.
New Features:
-
Added the ability to specify multiple IP addresses, network subnets, or host and network aliases (including fully-qualified-domain-name aliases) to a Pass List. This duplicates a similar ability added to Snort earlier this year.
-
Added GUI support for configuring the
bypass:
anddrop-invalid:
settings for streams. The new parameters are on the FLOW/STREAM tab for an interface.
Bug Fixes:
-
Suricata instance reload on Suppress List change fix. Redmine Issue #12506. Bug fix submitted by @viktor_g.
-
Suricata extra rules input validation fix. Redmine Issue #12533. Bug fix submitted by @viktor_g.
New Pass List Feature Highlight
Admins can now add additional IP addresses, IP subnets, and even FQDN (fully-qualifed domain name) aliases to a Pass List when using Legacy Mode blocking. When you add a FQDN alias, the custom blocking module will test the IP address in a packet against the most recently resolved IP for the FQDN alias when deciding whether the suspect IP is on the Pass List or not. Note that FQDN aliases are defined under FIREWALL > ALIASES in pfSense, and they are resolved, by default, once every 5 minutes by pfSense.In the screenshot below showing the new Pass List feature, you use the +Add IP button to add a new row to the table. You can enter only a valid IP address, IP subnet definition, or a previously-defined alias (either network, host, or FQDN). Use the Delete button beside an entry to remove it from the list. Remember that when assigning a Pass List to a Suricata Legacy Mode interface, or editing an already assigned list, you must restart Suricata on the interface for the change to be picked up!
-
-
@bmeeks
Hello Bill,
Can you explain more about this one:
"When using Inline mode, Suricata will drop packets that are invalid with regards to streaming engine." ?For example, when can we hit this case?
In Suricata's documentation I see this explanation:"The drop-invalid option can be set to no to avoid blocking packets that are seen invalid by the streaming engine. This can be useful to cover some weird cases seen in some layer 2 IPS setup."
I don't understand when I would want this option to be enabled or disabled
Thanks -
@nrgia said in Suricata 6.0.3_4 Package Update Release Notes (currently for DEVEL only):
@bmeeks
Hello Bill,
Can you explain more about this one:
"When using Inline mode, Suricata will drop packets that are invalid with regards to streaming engine." ?For example, when can we hit this case?
In Suricata's documentation I see this explanation:"The drop-invalid option can be set to no to avoid blocking packets that are seen invalid by the streaming engine. This can be useful to cover some weird cases seen in some layer 2 IPS setup."
I don't understand when I would want this option to be enabled or disabled
ThanksThere are several reasons why the TCP stream engine may mark a given packet as invalid. Problems with the timestamp being incorrect, packets with an invalid ACK, an invalid checksum, etc., result in a packet being flagged by the engine as "invalid".
"Drop" in this context means the analysis engine does not inspect the packet payload (or really much of anything else). The idea for enabling this option would be to not burden the signature analysis/compare engine with needlessly testing packets the OS is probably going to discard anyway and never forward.
The default for this setting is "no", thus the help text says the default state for the new checkbox is unchecked. On a very busy system, there is the potential for a slight performance gain if this feature is enabled.
-
@bmeeks said in Suricata 6.0.3_4 Package Update Release Notes (currently for DEVEL only):
The idea for enabling this option would be to not burden the signature analysis/compare engine with needlessly testing packets the OS is probably going to discard anyway and never forward.I understand, but now I'm concerned about the following use case:
If a special crafted payload is sent in order to avoid the engine, this option will help to evade Suricata.
Are you sure the packets will be droped by the OS? I mean I inderstood the performance gain, but there is any reason for concern about security?
I don't want to trade security for some performance gain.
Just asking you're opinion here, nothing else.
Thanks
-
@nrgia said in Suricata 6.0.3_4 Package Update Release Notes (currently for DEVEL only):
@bmeeks said in Suricata 6.0.3_4 Package Update Release Notes (currently for DEVEL only):
The idea for enabling this option would be to not burden the signature analysis/compare engine with needlessly testing packets the OS is probably going to discard anyway and never forward.I understand, but now I'm concerned about the following use case:
If a special crafted payload is sent in order to avoid the engine, this option will help to evade Suricata.
Are you sure the packets will be droped by the OS? I mean I inderstood the performance gain, but there is any reason for concern about security?
I don't want to trade security for some performance gain.
Just asking you're opinion here, nothing else.
Thanks
You are way overthinking this ... . The default forever in the package has been to "not drop invalid" (the checkbox was essentially "not checked" because it did not exist), so just leave it unchecked if you are concerned. I simply added the ability for more control over how the application is configured. And don't forget that the overwhelmingly vast majority of all traffic passing through your firewall is encrypted, so Suricata is not inspecting most payloads anyway since it can't peer into encrypted data.
-
-
-
-