Project

General

Profile

Actions

Documentation #6022

closed
JF PA

devguide: explain how the engine identifies applayer protocols

Documentation #6022: devguide: explain how the engine identifies applayer protocols

Added by Juliana Fajardini Reichow almost 3 years ago. Updated 10 months ago.

Status:
Closed
Priority:
Normal
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

Important/interesting questions to answer:
- How Suricata determines application layer protocols (e.g. HTTP, HTTPS, TLS, etc.)?
- Does every Suricata-supported protocol try to parse the packet? And if so, what happens when 2 protocols are parsed successfully?

Initial explanation:

There are 3 levels of detection
1) PM (pattern matching)
2) PP (probing parser)
3) PE (expectation based)

Explanation:

1 is preferred, it is a clear pattern in an expected place, e.g. "GET|20|" as the first 4 bytes mean HTTP
2 is running a dedicated parser on traffic to see what it thinks. Does this look like DNS? If so we consider it DNS. We lock these to ports by default.
3 expectations are set up by other parsers. We use this for ftp-data, as the control channel "knows" the flow that will contain the ftp data channel

VJ Updated by Victor Julien over 2 years ago Actions #1

  • Assignee changed from Juliana Fajardini Reichow to OISF Dev

VJ Updated by Victor Julien over 1 year ago Actions #2

  • Target version changed from 8.0.0-beta1 to 8.0.0-rc1

VJ Updated by Victor Julien 11 months ago Actions #3

  • Target version changed from 8.0.0-rc1 to 8.0.0

VJ Updated by Victor Julien 10 months ago Actions #4

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Philippe Antoine

PA Updated by Philippe Antoine 10 months ago Actions #5

  • Status changed from Assigned to In Review

PA Updated by Philippe Antoine 10 months ago Actions #6

  • Status changed from In Review to Closed
Actions

Also available in: PDF Atom