Bug #3348
open
Possible detection issue with VXLAN parser
Added by Tiago F. about 5 years ago.
Updated about 5 years ago.
Description
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.
Files
Related issues
1 (1 open — 0 closed)
Truncated when being mirrored to Suricata from the two clients.
- 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!
- Subject changed from Possible issue with VXLAN parser to Possible detection issue with VXLAN parser
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
Wondering if this should be just "doc" or there is something we could also detect on start up with af-packet.
- Related to Bug #3258: VXLAN exceeds MTU maximum added
Also available in: Atom
PDF