suricata-verify
suricata-verify copied to clipboard
OISF
flow: Add test for excluding pkt recursion from flow
Add tests for verifying matching packet flows when including and excluding pkt recursion from flow matching.
Bug: #6260
Redmine ticket: https://redmine.openinfosecfoundation.org/issues/6260
I see that IPS mode is mentioned in the README, but didn't see a test that simulated ips mode. Shouldn't there be one, or isn't that relevant for the changes?
I see that IPS mode is mentioned in the README, but didn't see a test that simulated ips mode. Shouldn't there be one, or isn't that relevant for the changes?
IPS simulation shouldn't make a difference as this feature is related to stitching traffic together when one side is detected before tunnel encapsulation and the other side is detected before tunnel decapsulation. e.g. For an ipv6 tunnel request: IPv4]ICMP] -> |IPS| -> IPv6]IPv4]ICMP] reply: <- |IPS| <- IPv6]IPv4]ICMP]
This is relevant when the IDS/IPS is also the tunnel terminator.
@jufajardini As both IDS and IPS mode would work in this scenario, I am happy to enable --simulate-ips if it makes more sense.
I see that IPS mode is mentioned in the README, but didn't see a test that simulated ips mode. Shouldn't there be one, or isn't that relevant for the changes?
IPS simulation shouldn't make a difference as this feature is related to stitching traffic together when one side is detected before tunnel encapsulation and the other side is detected before tunnel decapsulation. e.g. For an ipv6 tunnel request: IPv4]ICMP] -> |IPS| -> IPv6]IPv4]ICMP] reply: <- |IPS| <- IPv6]IPv4]ICMP]
This is relevant when the IDS/IPS is also the tunnel terminator.
@jufajardini As both IDS and IPS mode would work in this scenario, I am happy to enable --simulate-ips if it makes more sense.
[Sorry for the very late answer] considering that it should work for both, I think that ideally we would have tests for both scenarios :P