suricata/rules/pgsql-events.rules

# 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;)
pgsql: add events Events for: - parsing error when parsing pgsql packet length - parsing error for pgsql requests (post length parsing) - parsing error for pgsql responses (post length parsing) - too many transactions Include `pgsql-events.rules` file, and PGSQL events SID range definition Task #5566 2 years ago			`# 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;)`
pgsql: bound tx.responses (configurable) 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 2 months ago			`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;)`