mirror of
https://github.com/OISF/suricata.git
synced 2026-10-12 02:07:10 +00:00
Juliana Fajardini
f839581dba
Since the PostgreSQL protocol doesn't impose any clear limits to how many responses a backend could send, add one to the app-proto parser. Using 21-64 as the accepted values, and 64 as the default: The Start-up phase may have up to 17-18 ParameterStatus messages, plus AuthOk, BackendKeyData and ReadyForQuery: 20, with extra room to be on the safer side: 21 And 64 as upper limit, because as we currently summarize query responses, we already don't get flooded by DataRow and Copy responses messages, so we don't expect to see that many responses in a single transaction for the pgsql, with the current implementation. Ticket: #7263
10 lines
834 B
Plaintext
10 lines
834 B
Plaintext
# PGSQL app-layer event rules
|
|
#
|
|
# SID range start: 2241000
|
|
# SID range end: 2241999
|
|
alert pgsql any any -> any any (msg:"SURICATA PGSQL Too many transactions"; app-layer-event:pgsql.too_many_transactions; sid:2241000; rev:1;)
|
|
alert pgsql any any -> any any (msg:"SURICATA PGSQL Malformed request"; app-layer-event:pgsql.malformed_request; flow:to_server; sid:2241001; rev:1;)
|
|
alert pgsql any any -> any any (msg:"SURICATA PGSQL Malformed response"; app-layer-event:pgsql.malformed_response; flow:to_client; sid:2241002; rev:1;)
|
|
alert pgsql any any -> any any (msg:"SURICATA PGSQL Invalid length"; app-layer-event:pgsql.invalid_length; sid:2241003; rev:1;)
|
|
alert pgsql any any -> any any (msg:"SURICATA PGSQL Too Many Responses in a single transaction"; app-layer-event:pgsql.too_many_responses; flow:to_client; sid:2241004; rev:1;)
|