Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Applayer plugin 5053 v3.14 #12127

Closed
wants to merge 17 commits into from

Conversation

catenacyber
Copy link
Contributor

Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/5053

Describe changes:

  • get ready to use dynamic number of app-layer protos (also work with static constant) in some places
  • preventive fix of macro with parenthesis cc @jufajardini

#12118 with needed rebase

instead of a global variable.

For easier initialization with dynamic number of protocols
for expectation_proto

Ticket: 5053
so that we can use safely EXCEPTION_POLICY_MAX*sizeof(x)
Ticket: 5053

delay after initialization so that StringToAppProto works
As too many cases are found when splitting tcp payload
As it is also used for HTTP/1
Remove it only for TCP and keep it for UDP.
Because some alprotos will remain static and defined as a constant,
such as ALPROTO_UNKNOWN=0, or ALPROTO_FAILED.

The regular already used protocols keep for now their static
identifier such as ALPROTO_SNMP, but this could be made more
dynamic in a later commit.

ALPROTO_FAILED was used in comparison and these needed to change to use
either ALPROTO_MAX or use standard function AppProtoIsValid
Ticket: 5053

The names are now dynamically registered at runtime.
The AppProto alproto enum identifiers are still static for now.

This is the final step before app-layer plugins.
There was an implicit limit of 32 app-layer protocols
used by probing parsers through a mask, meaning that
Suricata should not support more than 32 app-layer protocols
in total.

This limit is relaxed to each flow not being able to
run more than 32 probing parsers, meaning that for each source
and destination port combination, the sum of registered
probing parsers should not exceed 32, even if there are more
than 32 in total.
Copy link

codecov bot commented Nov 18, 2024

Codecov Report

Attention: Patch coverage is 79.42857% with 108 lines in your changes missing coverage. Please review.

Project coverage is 80.59%. Comparing base (5d766df) to head (f6d0173).
Report is 7 commits behind head on master.

Additional details and impacted files
@@             Coverage Diff             @@
##           master   #12127       +/-   ##
===========================================
+ Coverage   62.68%   80.59%   +17.91%     
===========================================
  Files         840      910       +70     
  Lines      153669   258303   +104634     
===========================================
+ Hits        96323   208190   +111867     
+ Misses      57346    50113     -7233     
Flag Coverage Δ
fuzzcorpus 56.61% <68.46%> (?)
livemode 19.40% <51.12%> (?)
pcap 44.44% <68.24%> (?)
suricata-verify 62.72% <74.09%> (+0.03%) ⬆️
unittests 58.57% <62.85%> (?)

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

Comment on lines +157 to +183
int SCPluginRegisterAppLayer(SCAppLayerPlugin *plugin)
{
AppProto alproto = AlprotoMax;
AppProtoRegisterProtoString(alproto, plugin->name);
if (plugin->Register) {
if (AppLayerParserPreRegister(plugin->Register) != 0) {
return 1;
}
}
if (plugin->KeywordsRegister) {
if (SigTablePreRegister(plugin->KeywordsRegister) != 0) {
return 1;
}
}
if (plugin->Logger) {
EveJsonLoggerRegistrationData reg_data = {
.confname = plugin->confname,
.logname = plugin->logname,
.alproto = alproto,
.LogTx = (EveJsonSimpleTxLogFunc)plugin->Logger,
};
if (OutputPreRegisterLogger(reg_data) != 0) {
return 1;
}
}
return 0;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@victorjulien Any thoughts on this (minus the plugin stuff in the name) becoming the standard way of registering an app-layer?

IMO there should be no difference in registration whether or not an app-layer is a plugin or not, the only differentiator is where it comes from - dynamically or statically loaded. Simplifies documentation, means we eat our own dog food, etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to try to have SNMP follow this later.

For now, I wonder if I should split this PR to make it simpler.

There are 3 things :

  • use dynamic number of app-layer protos
  • fuzz proto detect fix (in init)
  • plugins

Let me know if I should just take the one or 2 first items...

@suricata-qa
Copy link

WARNING:

ERROR: QA failed on SURI_TLPR1_alerts_cmp.

field baseline test %
SURI_TLPW1_stats_chk
.app_layer.error.tls.parser 1152 1203 104.43%
SURI_TLPR1_stats_chk
.app_layer.tx.ftp 95372 102194 107.15%
.ftp.memuse 2878 10638 369.63%

Pipeline 23423

@catenacyber
Copy link
Contributor Author

Next in #12163

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants