If a signature matches and contains pass, Suricata stops scanning the packet and skips to the end of all rules (only for the current packet).
Let’s say I have a rule something like below
drop http any any -> any any (msg:"Test";flow:to_server,established;http.method;content:"GET";http.uri;content:"/exploit/"; bsize:9;sid:28199650;rev:455;metadata:created_at 2023_04_21,updated_at 2023_04_21;)
pass http any any -> any any (msg:"favicon test";flow:to_server,established;http.method;content:"GET";http.uri;content:"/new/"; bsize:5;sid:28199653;rev:455;)
If I make a GET request for path /new/ this will be allowed, and if I do separate GET request for path /exploit/ this will be blocked.
Now issue comes , when I send initial get request for /new/ and through the same TCP stream
I’m able to send the request for path /exploit/
Based on the pass action in documnet it only applied to the packet, if this is the case the other packet with /exploit should get dropped right?
Packet here means the entire TCP tuple?(SRC , DST, Sour port, DST port, protocol)?
In this case, packet is probably not the right term. The flow is going to be bypassed for inspection once the pass rule is hit (this is a TCP transaction). The flow will be however your suricata.yaml is configured to determine what a flow is comprised of (if VLANs or LIVEIDs are included in addition to standard 5 tuple).
To complement what JT said, here’s the bit of documentation that covers this: “Pass rules are Suricata rules that if matching, pass the packet and in case of TCP the rest of the flow.” (9.7. Ignoring Traffic — Suricata 7.0.0-rc2-dev documentation)
I guess one key point here is that pass rules should not be used lightly, but only with trusted sources and/or for performance reasons - say, for instance, to pass tls traffic once traffic is established (although that could be done via suricata yaml, actually - 9.7. Ignoring Traffic — Suricata 7.0.0-rc2-dev documentation).
I think it is also worth noticing that pass and bypass are different, for Suricata. With pass you’d still see app-layer events logged for the flow. The rules won’t be evaluated for it, but you would still see http events. Suricata has a bypass keyword, but it’s a bit different than a rule action - 6.12. Bypass Keyword — Suricata 7.0.0-rc2-dev documentation
Is there anyway or any rules to prevent such behavior, someone fuzzing the network may get 200 OK and it may be because of pass action we defined.
Any rules you recommend to stop threat going through same TCP session?
I tried making use of flowbits but still working on it to understand how I can implement this.
Also @jmtaylor90 do you think the docs should be updated to something like this
If a signature matches and contains pass, Suricata stops scanning the packet(s) and skips to the end of all rules (Any further packets will not be evaluated for the flow).
The pass behavior is really the expected behavior. With pass you will/can still get the app-layer EVE json log entries so you still have some idea of what activity is occuring in the flow. If you do not wish to do any inspection of the flow past a point, bypass would be the keyword to use.
I don’t really have any recommendations since everyone has different priorities regarding threats and what they consider to be a threat for their environment and assets they are protecting in that environment.
I definitely agree on the doc update, I will make a note to see what we can do there.