Possible detection issue with VXLAN parser
It seems there is an issue, which I haven't been able to drill down, with the VXLAN parser which is causing failures on detection.
How to reproduce and use the attached PCAP:
- Filtering for http shows, on IP 10.0.0.131 (same host as Suricata) successful detection of 2013414 (ET POLICY Executable served from Amazon S3) and 2018959 (ET POLICY PE EXE or DLL Windows file download HTTP)
- Still filtered on http , for both IP 10.0.0.205 and 10.0.0.144 , no detection happens for the (apparently) same traffic
- In the last test (which simulates id check returned root) , both 10.0.0.205 and 10.0.0.144 successfully detect /uid/index.html which triggers 2100498 (GPL ATTACK_RESPONSE id check returned root)
Any additional information I can provide, please let me know.
Updated by Victor Julien about 3 years ago
- Status changed from New to Feedback
- Assignee set to Tiago F.
- Target version changed from 5.0.0 to TBD
- Affected Versions 5.0.0 added
Hi Tiago, could you turn the pcap into a Suricata-Verify test? Would help speed up analysis and make sure we don't regress in the future. Thanks!
Updated by Tiago F. about 3 years ago
After some awesome troubleshooting with Peter, some further developments:
- When using Suricata in PCAP mode, all alerts were coming up (traffic from vxlan and not-vxlan)
- After adjusting the default-packet-size to take into account (VXLAN - 50; VLAN - 4), alerts in af-packet started working
- We're using 1575 but we tested 1568 and that also works