RFC: alert/noalert and config keyword extensions

[victorjulien]

Other than the alert addition from #10154, this adds a way to disable stream reassembly completely and app-layer parsing (for TCP only atm).

E.g.

config smb any any -> any any (config:stream disable, type reassembly, scope flow; sid:1;)
config tcp any any -> any 445 (config:stream disable, type reassembly, scope flow; sid:2; alert;)
config tcp any any -> any 80 (flow:to_server; config:app-layer disable, type parser, scope flow; sid:3; alert;)
alert tcp any any -> any 80 (flow:to_server; content:"HTTP/1.0"; sid:4;)

Sid 1 and 2 both disable all stream reassembly for that flow.

Sid 3 only disables app parsers for on port 80. Content inspection still works (sid 4).

Would like some feedback on how to express things, and on what toggles to add.

[suricata-qa]

Information:

ERROR: QA failed on SURI_TLPW2_autofp_suri_time.

field	baseline	test	%
	SURI_TLPW2_autofp_stats_chk
.uptime	181	192	106.08%

Pipeline 17500

[codecov[bot]]

Codecov Report

Attention: 39 lines in your changes are missing coverage. Please review.

Comparison is base (1dcf69b) 82.19% compared to head (cb11aa8) 82.08%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #10157      +/-   ##
==========================================
- Coverage   82.19%   82.08%   -0.11%     
==========================================
  Files         974      974              
  Lines      271825   271901      +76     
==========================================
- Hits       223416   223190     -226     
- Misses      48409    48711     +302     

Flag	Coverage Δ
fuzzcorpus	62.65% <59.82%> (-0.37%)	:arrow_down:
suricata-verify	61.39% <57.26%> (-0.02%)	:arrow_down:
unittests	62.84% <63.90%> (-0.01%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

[inashivb]

feedback on how to express things

1. not sure about the hyphen in app-layer in rule lang.
2. For stream, other type that comes to mind: memcap [allow to disable memcap limits when say one is interested in getting full stream matching a certain criteria]
3. logging makes more sense as a type to me than a subsystem so we can allow more control about what part of the system we want to disable logging on. Like, say, we want to disable logging but only for stream engine or an applayer parser or a tx (this means that tx seems more suited as a subsystem)

What do you think?

[victorjulien]

feedback on how to express things

1. not sure about the hyphen in `app-layer` in rule lang.

What would you suggest as an alternative? app_layer?

2. For stream, other type that comes to mind: `memcap` [allow to disable memcap limits when say one is interested in getting full stream matching a certain criteria]

While this would be nice it will also be quite some work. Currently memcap is not tracked/handled with per flow/session limits, so changing that would require quite a bit of work.

3. `logging` makes more sense as a type to me than a subsystem so we can allow more control about what part of the system we want to disable logging on. Like, say, we want to disable logging but only for stream engine or an applayer parser or a tx (this means that tx seems more suited as a subsystem)

I conceptualize subsys as "capture", "decode", "stream", "app", "detect" and "output". (where logging == output here, I guess I thought it to be clearer at the time)

In any case, logging is already in 7 (and 6 I think), as a "subsys". Can rework that of course.

[inashivb]

What would you suggest as an alternative? app_layer?

Yes. Or even applayer. Both are consistent with our general rule keywords.

While this would be nice it will also be quite some work. Currently memcap is not tracked/handled with per flow/session limits, so changing that would require quite a bit of work.

I see. Thank you!

I conceptualize subsys as "capture", "decode", "stream", "app", "detect" and "output". (where logging == output here, I guess I thought it to be clearer at the time)

ok. I didn't see it that way indeed.

In any case, logging is already in 7 (and 6 I think), as a "subsys". Can rework that of course.

[suricata-qa]

Information: QA ran without warnings.

Pipeline 17531

[catenacyber]

Is there a redmine ticket for this ?

[jufajardini]

Is there a redmine ticket for this ?

For the pass-alert thing: https://redmine.openinfosecfoundation.org/issues/5466

[catenacyber]

Any update on this ?

[suricata-qa]

Information: QA ran without warnings.

Pipeline 17531

[victorjulien]

Replaced by #11260.