Project

General

Profile

Actions

Bug #3348

open

Possible detection issue with VXLAN parser

Added by Tiago F. almost 3 years ago. Updated almost 3 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

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

vxlan.pcap (336 KB) vxlan.pcap vxlan pcap Tiago F., 11/20/2019 12:39 AM

Related issues 1 (1 open0 closed)

Related to Bug #3258: VXLAN exceeds MTU maximumFeedbackCommunity TicketActions
Actions #1

Updated by Tiago F. almost 3 years ago

Truncated when being mirrored to Suricata from the two clients.

Actions #2

Updated by Victor Julien almost 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!

Actions #3

Updated by Andreas Herz almost 3 years ago

  • Subject changed from Possible issue with VXLAN parser to Possible detection issue with VXLAN parser
Actions #4

Updated by Tiago F. almost 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

Actions #5

Updated by Peter Manev almost 3 years ago

Wondering if this should be just "doc" or there is something we could also detect on start up with af-packet.

Actions #6

Updated by Victor Julien almost 3 years ago

  • Related to Bug #3258: VXLAN exceeds MTU maximum added
Actions

Also available in: Atom PDF