This introduces a parser for IMAP protocol, replacing the
detection-only implementation.
An IMAP transaction has two states driven by the 'complete' field:
- Open (complete = false): waiting for a matching tagged response.
- Complete (complete = true): tagged response received, or special
conditions met (BYE, server greeting).
Completion logic (is_complete):
- If a tagged request exists: requires a matching tagged response.
- No tagged request + BYE: complete (server closing).
- No tagged request + any response: complete (server greeting).
Transactions are created in three places:
1. Request parser: every parsed command creates a new tx.
2. Response parser (tagged, no matching request): midstream/async;
orphan tagged response gets its own tx.
3. Response parser (untagged, no incomplete tx): server greeting or
unsolicited response.
Once open, messages accumulate:
- Request side: continuation and literal data attach to the most
recent incomplete tx.
- Response side: untagged responses attach to the most recent
incomplete tx; tagged responses attach via find_request(tag).
Literals, sent by the client (e.g. APPEND) or by the server (e.g.
FETCH), are consumed incrementally and their content is not retained.
Hard limits prevent unbounded growth:
- IMAP_MAX_TX (256, configurable): total transactions. Exceeded:
all incomplete txs force-completed with TooManyTransactions event.
- IMAP_MAX_MSGS_PER_TX (512): requests per tx. Exceeded: request
dropped, DataLimitReached event.
- IMAP_MAX_LINES (512): response lines per tx. Exceeded: line
dropped, DataLimitReached event.
- IMAP_MAX_LINE_BYTES_PER_STATE (100MB): retained request and
response data per flow. Exceeded: data dropped, DataLimitReached
event.
- IMAP_MAX_LINE_SIZE (8KB): request/response line max length.
Exceeded: LineTooLong event.
- Literal size: bounded by declared size in {N} specifier.
IMAP_MAX_TX only is configurable limit via app-layer.protocols.imap.max-tx.
Ticket #8276
Extend the SCTP decoder to parse chunk headers after the 12-byte common
header. Each chunk is validated for minimum header size and length
consistency per RFC 4960 sec 3.2.
Add SCTPChunkHdr and SCTPVars structs to track per-packet chunk metadata
Add five new decoder events for protocol violations:
- SCTP_CHUNK_TOO_SMALL: insufficient data for a chunk header
- SCTP_CHUNK_LEN_INVALID: chunk length < 4 or exceeds packet
- SCTP_INIT_CHUNK_NOT_ALONE: INIT/INIT_ACK bundled (RFC 4960 sec 6.10)
- SCTP_INIT_WITH_NON_ZERO_VTAG: INIT with vtag != 0 (RFC 4960 sec 8.5.1)
- SCTP_DATA_WITH_ZERO_VTAG: DATA chunk with vtag == 0
Ticket #4251
Ticket: 3958
- transactions are now bidirectional
- there is a logger
- gap support is improved with probing for resync
- frames support
- app-layer events
- enip_command keyword accepts now string enumeration as values.
- add enip.status keyword
- add keywords :
enip.product_name, enip.protocol_version, enip.revision,
enip.identity_status, enip.state, enip.serial, enip.product_code,
enip.device_type, enip.vendor_id, enip.capabilities,
enip.cip_attribute, enip.cip_class, enip.cip_instance,
enip.cip_status, enip.cip_extendedstatus
We only try to parse a small subset of what is possible in
RFB. Currently we only understand some standard auth schemes
and stop parsing when the server-client handshake is complete.
Since in IPS mode returning an error from the parser causes
drops that are likely uncalled for, we do not want to return
errors when we simply do not understand what happens in the
traffic. This addresses Redmine #5912.
Bug: #5912.
Common /usr/share/suricata/rules or /usr/local/share/suricata/rules.
The rules provided by the distribution are installed here as part
of the Suricata install process so will always be installed, even
without the use of install-rules.
Decode Modbus request and response messages, and extracts
MODBUS Application Protocol header and the code function.
In case of read/write function, extracts message contents
(read/write address, quantity, count, data to write).
Links request and response messages in a transaction according to
Transaction Identifier (transaction management based on DNS source code).
MODBUS Messaging on TCP/IP Implementation Guide V1.0b
(http://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf)
MODBUS Application Protocol Specification V1.1b3
(http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf)
Based on DNS source code.
Signed-off-by: David DIALLO <diallo@et.esia.fr>
Giuseppe Longo
Philippe Antoine
Victor Julien
Jason Ish
Juliana Fajardini
Philippe Antoine
Sascha Steinbiss
Andreas Herz
Victor Julien
Pierre Chifflier
Jason Ish
Eric Leblond
DIALLO David