Suricata

For per packet anomaly events (decoder, stream) should we not log app-layer.

We need to consider thresholding these events.

Could also log app-layer and other expensive records only once per {decoder,stream} events.

Per protocol review of limits of sizes of fields to log.

What is the next step ?
Looking for other protocols besides SSH ?

#6900 is a variant where it is not an especially long field, but an array of 30k elements...

I guess the question is now, with a field like MQTT msg cf #6984 could an attacker trigger the logging of this arbitrary long value an arbitrary number of times ?

Philippe Antoine wrote in #note-19:

I guess the question is now, with a field like MQTT msg cf #6984 could an attacker trigger the logging of this arbitrary long value an arbitrary number of times ?

The only way I see to do that requires that there is a PACKET_ALERT_FLAG_STREAM_MATCH, that means a signature using content on stream without any app-layer transaction keyword

1. The attacker creates a first transaction with a big MQTT msg, but does not end it, (no response from the other side except TCP ACK)
2. The attacker creates then a very big MQTT PDU, for which Suricata will skip the body, but sends many packet matching the signatures.

So, We have alert ip any any -> any any (content: "evilpattern"; sid: 1;)
We have one MQTT flow with a first MQTT PDU being a CONNECT with a big and binary will message (limited by app-layer.protocols.mqtt.max-msg-length 1Mbyte by default)
The server acks it, but does not send a mqtt CONNACK
The client sends a MQTT header with a payload length greater than app-layer.protocols.mqtt.max-msg-length like 256 Mbyte
The client then sends many packets with "evilpattern" up to 256 Mbytes
For each packet, we get an alert, and we log the closest tx app-layer metadata

TL;DR
Keeping track of modified txs and having AppLayerParserGetTransactionInspectId return PACKET_ALERT_NOTX when there was no modified tx would solve this (and other problems)

Keeping track of modified txs and having AppLayerParserGetTransactionInspectId return PACKET_ALERT_NOTX when there was no modified tx would solve this (and other problems)

Not enough if I match on the stream data of the transaction (like a big file over HTTP/2), after having had too many/big headers to log...

Investigating if we can avoid to duplicate logging the same app-layer metadata for multiple alerts over one stream-only signature

There were already some fixes merged and going on like #7280

I wonder what we want to do next here...