|
|
|
|
# Suricata Reserved SID Allocations
|
|
|
|
|
|
|
|
|
|
See https://sidallocation.org/ for more information.
|
|
|
|
|
|
|
|
|
|
Unless otherwise noted, each component or protocol is allocated 1000
|
|
|
|
|
signature IDs.
|
|
|
|
|
|
|
|
|
|
## Components
|
|
|
|
|
|
|
|
|
|
| Component | Start | End |
|
|
|
|
|
| ----------------- | ------- | ------- |
|
|
|
|
|
| Decoder | 2200000 | 2200999 |
|
|
|
|
|
| Firewall | 2201000 | 2201999 |
|
|
|
|
|
| Stream | 2210000 | 2210999 |
|
|
|
|
|
| Generic App-Layer | 2260000 | 2260999 |
|
|
|
|
|
|
|
|
|
|
## App-Layer Protocols
|
|
|
|
|
|
|
|
|
|
| Protocol | Start | End |
|
|
|
|
|
| -------- | ------- | ------- |
|
|
|
|
|
| SMTP | 2220000 | 2220999 |
|
|
|
|
|
| HTTP | 2221000 | 2221999 |
|
|
|
|
|
| NTP | 2222000 | 2222999 |
|
|
|
|
|
| NFS | 2223000 | 2223999 |
|
|
|
|
|
| IPsec | 2224000 | 2224999 |
|
|
|
|
|
| SMB | 2225000 | 2225999 |
|
|
|
|
|
| Kerberos | 2226000 | 2226999 |
|
|
|
|
|
| DHCP | 2227000 | 2227999 |
|
|
|
|
|
| SSH | 2228000 | 2228999 |
|
|
|
|
|
| MQTT | 2229000 | 2229999 |
|
|
|
|
|
| TLS | 2230000 | 2230999 |
|
|
|
|
|
| QUIC | 2231000 | 2231999 |
|
|
|
|
|
| FTP | 2232000 | 2232999 |
|
|
|
|
|
| POP3 | 2236000 | 2236999 |
|
|
|
|
|
| LDAP | 2237000 | 2237999 |
|
|
|
|
|
| SNMP | 2238000 | 2238999 |
|
|
|
|
|
| SCTP | 2239000 | 2239999 |
|
|
|
|
|
| DNS | 2240000 | 2240999 |
|
|
|
|
|
| PGSQL | 2241000 | 2241999 |
|
|
|
|
|
| mDNS | 2242000 | 2242999 |
|
|
|
|
|
| Bittorent| 2243000 | 2243999 |
|
imap: implement parser
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
9 months ago
|
|
|
| IMAP | 2244000 | 2244999 |
|
|
|
|
|
| MODBUS | 2250000 | 2250999 |
|
|
|
|
|
| DNP3 | 2270000 | 2270999 |
|
|
|
|
|
| SIP | 2280000 | 2280999 |
|
|
|
|
|
| HTTP2 | 2290000 | 2290999 |
|
