Adam Kiripolsky [Tue, 14 Jan 2025 11:58:47 +0000 (12:58 +0100)]
dpdk/rss: add rte_flow rss support for mlx5
The configuration of this rule is the same as for ixgbe driver except
the hash function is not RTE_ETH_HASH_FUNCTION_DEFAULT but
RTE_ETH_HASH_FUNCTION_TOEPLITZ.
The syntax in dpdk-testpmd for this rule with attributes:
port index == 0
used rx queue indices == 0 1 2 3
<hash_key> == 6d5a symmetric hash key
is as follows:
"flow create 0 ingress pattern eth / end actions rss types ipv4 ipv6
end queues 0 1 2 3 end key <hash_key> key_len 40 func toeplitz / end"
Adam Kiripolsky [Tue, 10 Dec 2024 15:27:23 +0000 (16:27 +0100)]
dpdk/rss: add rte_flow rss support for ice
ice driver requires 2 rte_flow rules for matching and
redistributing incoming traffic with RSS.
The rules set up by iceDeviceSetRSSFlowIPv4() and
iceDeviceSetRSSFlowIPv6() are different only in the pattern
("pattern eth / ipv4 / end" or "pattern eth / ipv6 / end"
in dpdk-testpmd syntax) and in the hash type (ipv4 src dst / ipv6 src
dst). ice will match all ipv4 or ipv6 traffic independently of
following l4 protocol. The rules can not have queues configured,
implicitly they will use all queues available.
The hash function is set to RTE_ETH_HASH_FUNCTION_TOEPLITZ.
The hash key can not be set.
The syntax in dpdk-testpmd for rule to match all ipv4 traffic
with attributes:
port index == 0
is as follows:
"flow create 0 ingress pattern eth / ipv4 / end actions rss types ipv4
end queues end func toeplitz / end"
(queues need to be set to NULL)
Adam Kiripolsky [Tue, 10 Dec 2024 15:26:49 +0000 (16:26 +0100)]
dpdk/rss: add rte_flow rss support for ixgbe
ixgbe driver requires different configuration of RSS rte_flow
rule than i40e, with just one generic rule matching all traffic.
The generic rule configured by DeviceCreateRSSFlowGeneric() has pattern
equivalent to "pattern eth / end" in dpdk-testpmd syntax. The rule must
have rx queues configured. The rule hashes traffic to different queues
based on ipv4 and ipv6 hash types (ipv4 src dst / ipv6 src dst).
The hash key is 40 bytes long symmetric hash key. ixgbe does not
support any other hash function than RTE_ETH_HASH_FUNCTION_DEFAULT.
The syntax in dpdk-testpmd for this rule with attributes:
port index == 0
used rx queue indices == 0 1 2 3
<hash_key> == 6d5a symmetric hash key
is as follows:
"flow create 0 ingress pattern eth / end actions rss types ipv4 ipv6
end queues 0 1 2 3 end key <hash_key> key_len 40 func default / end"
Adam Kiripolsky [Thu, 12 Dec 2024 12:28:02 +0000 (13:28 +0100)]
dpdk/rss: move and change rss rte_flow functions
Move and adjust the base of RSS configuration from util-dpdk-i40e.c to
a new file that can be later utilized by other cards.
RSS configuration can be configured via rte_flow rules. This is useful
for possible future features such as specific header offload
(vxlan, nvgre) also implemented via rte_flow rules, as rte_flow
rules can be chained via groups and priorities.
i40e uses multiple different rte_flow rules to setup RSS. At first,
function DeviceSetRSSFlowQueues() is used to setup rx queues.
This rule matches all types of traffic, so the equivalent
to dpdk-testpmd pattern would be "pattern end"
This rule can not contain hash types (ipv4, ipv6 etc.) nor hash key.
The hash function used here is RTE_ETH_HASH_FUNCTION_DEFAULT.
The syntax in dpdk-testpmd for this rule with attributes:
port index == 0
used rx queue indices == 0 1 2 3
is as follows:
"flow create 0 ingress pattern end actions rss queues 0 1 2 3 end
func default / end"
The other rules configured by i40eDeviceSetRSSFlowIPv4() and
i40eDeviceSetRSSFlowIPv6() match specific type of traffic by l4 protocol
(none, TCP, UDP, SCTP). For example, pattern to match l3 ipv4 with l4
tcp traffic in dpdk-testpmd syntax would be equivalent of
"pattern eth / ipv4 / tcp / end".
These rules can not have rx queues configured, but have hash types
(l3 src and dst address). This means that the traffic distribution
is affected only by l3 addresses, independent of the l4 specifics.
Also these pattern matching rules have symmetric 6d5a
hash key configured. The length of the key is dependent on DPDK version.
The hash function (either RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ or
RTE_ETH_HASH_FUNCTION_TOEPLITZ, depending on DPKD version) used
in these rules hashes symmetricaly due to the symmetric hash key.
The syntax in dpdk-testpmd for rule to match ipv4-tcp traffic with
attributes:
port index == 0
<hash_key> == 52 bytes long 6d5a symmetric hash key
is as follows:
"flow create 0 ingress pattern eth / ipv4 / tcp / end actions rss types
ipv4-tcp l3-src-only l3-dst-only end queues end key <hash_key>
key_len 52 func toeplitz / end"
(queues need to be set to NULL)
Victor Julien [Wed, 22 Nov 2023 09:41:47 +0000 (10:41 +0100)]
af-packet: clean up IPS config check
Don't emmit generic error statements on things that are not errors. Instead,
for cases where (part of) the config is missing, use the defaults and log
only a more detailed explanation at the 'config' level.
protodetect: simplify code since DCERPC UDP detection is improved
Protocol detection code is simplified. Removed dependency on explicit
alproto constants from the common part of code that must not be aware of
the each specific protocol features.
Frames of the following types have been added for toserver direction:
1. Pdu: The entire Protocol Data Unit
2. Hdr: Header of the request
3. Data: PDU data
With the introduction of AppLayerResult::incomplete API, fragmented data
is no longer handled fully in the dcerpc code. Given that these code
paths are already covered by the following s-v tests, these tests can now be
safely removed.
- dce-gap-handling
- dcerpc-dce-iface-*
Instead of own internal mechanism of buffering in case of fragmented
data, use AppLayerResult::incomplete API to let the AppLayer Parser take
care of it. This makes the memory use more efficient.
Remove any unneeded variables and code with the introduction of this
API.
TCP data can be presented to the protocol parser in any way e.g. one
byte at a time, single complete PDU, fragmented PDU, multiple PDUs at
once. A limit of 1MB can be easily reached in some of such scenarios.
Remove the check that rejects data that is more than 1MB.
Shivani Bhardwaj [Thu, 23 Jan 2025 05:39:46 +0000 (11:09 +0530)]
app-layer: update flow counter if an alproto is detected
If alproto for the current direction was not detected but the opposite
side was successfully detected, if the Pattern Matching and Pattern
Probing on the flow was also successfully done and the current
direction's alproto is still unknown, a decoder event is set to indicate
that the protocol detection only happened in one direction.
This event is set after having sent the current data to the applayer
parser. Now, the respective applayer parser may or may not successfully
parse the data. However, the alproto on flow is already set from the
other direction so there will be a flow event generated by Suricata. In
order to keep this consistent with the stats, also make sure to
increment the flow counter when the decode event is set so that the flow
counter is incremented irrespective of the parsing status reported by
the applayer parser.
This patch makes stats for several specific applayer flow count equal to
the number of flow events logged for those specific applayer protocols.
Victor Julien [Thu, 23 Jan 2025 15:07:08 +0000 (16:07 +0100)]
detect/iponly: use flow first flags
Instead of ip-only specific flags, reuse the FLOW_PKT_TOSERVER_FIRST and
FLOW_PKT_TOCLIENT_FIRST flags.
Fixes false positives on one sided streams that trigger a opposing flow
timeout packet at the flow's end. That pseudo packet would trigger a
match even though it shouldn't.
Eric Leblond [Fri, 29 Nov 2024 17:46:11 +0000 (18:46 +0100)]
util/debug: increase max length of message
When a signature is incorrect, its full content is logged in a
message with some other information such as rules file name. As
a result, the log message must be longer than a maximum signature
length which is 8192.
Cole Dishington [Tue, 8 Aug 2023 19:47:12 +0000 (07:47 +1200)]
flow: optionally use pkt recursion for hash
If a Suricata inline IPS device is routing traffic over a
non-encrypted tunnel, like IPv6 tunnels, packets in a flow
will be dropped and not be matched. e.g.
The following example is a Suricata inline IPS with an IPv6 tunnel:
request: IPv4]ICMP] -> |IPS| -> IPv6]IPv4]ICMP]
reply: <- |IPS| <- IPv6]IPv4]ICMP]
Both the IPv4 request and IPv6 reply will be seen by Suricata on
ingress. The flows will not be matched due to flow recursion level.
Optionally use pkt recursion level in flow hash. Excluding recursion
level in flow hash allows matching of packet flows and defrag on an
inline IPS Suricata scenario where the IPS device is a tunnel
terminator.
- debug visibility was reduced making it unusable from an external crate
- the plugins view of the log level was broken
To fix:
- make debug pub
- minor change to initialization of the log LEVEL as seen by the plugin
so its seen by the plugin. I'm not really sure why the previous
version wasn't working though, but this one does
Jason Ish [Wed, 22 Jan 2025 22:32:35 +0000 (16:32 -0600)]
lua: add "builtins" file to consolidate registration
Use a single array of built-ins and provide 2 functions for
registering them:
- SCLuaLoadBuiltIn: for loading built-in modules in sandboxed
environments.
- SCLuaRequirefBuiltIns: registers built-in modules with the standard
package tool, allows built-ins to be loaded by output scripts that are
not restricted
I hope to refactor the sandbox so they can use SCLuaRequirefBuiltIns
as well.
Philippe Antoine [Thu, 23 Jan 2025 12:31:05 +0000 (13:31 +0100)]
detect/base64: remove unused macro warning
when compiling without unit tests
detect-transform-base64.c:47:9: warning: macro is not used [-Wunused-macros]
47 | #define DETECT_TRANSFORM_FROM_BASE64_MODE_DEFAULT (uint8_t) Base64ModeRFC4648
Alice Akaki [Mon, 20 Jan 2025 18:16:26 +0000 (14:16 -0400)]
detect: add ldap.responses.count
ldap.responses.count matches on the number of LDAP responses
This keyword maps to the eve field len(ldap.responses[])
It is an unsigned 32-bit integer
Doesn't support prefiltering
Alice Akaki [Mon, 20 Jan 2025 18:12:02 +0000 (14:12 -0400)]
detect: add ldap.responses.operation
ldap.responses.operation matches on Lightweight Directory Access Protocol response operations
This keyword maps to the eve field ldap.responses[].operation
It is an unsigned 8-bit integer
Doesn't support prefiltering
Alice Akaki [Mon, 20 Jan 2025 18:06:03 +0000 (14:06 -0400)]
detect: add ldap.request.operation
ldap.request.operation matches on Lightweight Directory Access Protocol request operations
This keyword maps to the eve field ldap.request.operation
It is an unsigned 8-bit integer
Doesn't support prefiltering
Jason Ish [Mon, 20 Jan 2025 16:00:19 +0000 (10:00 -0600)]
dhcp: cleanup visibility and naming
- remove "rs_" prefix from functions that are not exported
- prefix exported functions with "SC"
- don't export functions that are only used by pointer
Jason Ish [Mon, 20 Jan 2025 15:46:09 +0000 (09:46 -0600)]
rust/applayer: clean visibility of export macros
Both the macros export_tx_data_get and export_state_data_get can
generate non-pub functions as the function they generate is only used
as a pointer during registration.
Remove "pub" and "no_mangle" from the generated functions and update
the names of the generated functions to follow Rust rules as they are
no longer exported into the global C namespace.
Jeff Lucovsky [Mon, 20 Jan 2025 14:35:01 +0000 (09:35 -0500)]
gen: Remove _AL_ usage in detect keywords
This commit removes the `_AL_` usage in detect keywords for improved
readability.
Some of the HTTP rule keywords already had counterparts without using
"_AL_". These rule keywords are the legacy content modifier keywords
that now have sticky buffer equivalents.
For these, "_AL_" was removed and a suffix was added to the #define:
src/detect-engine-register.h:151: DETECT_HTTP_COOKIE_CM
src/detect-engine-register.h:153: DETECT_HTTP_METHOD_CM
src/detect-engine-register.h:161: DETECT_HTTP_HEADER_CM
src/detect-engine-register.h:173: DETECT_HTTP_RAW_HEADER_CM
src/detect-engine-register.h:175: DETECT_HTTP_URI_CM
src/detect-engine-register.h:179: DETECT_HTTP_STAT_MSG_CM
src/detect-engine-register.h:181: DETECT_HTTP_STAT_CODE_CM
src/detect-engine-register.h:185: DETECT_HTTP_HOST_CM