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

7.0.x 7323 mqtt/v1 #12155

Closed
wants to merge 2 commits into from
Closed

Conversation

jasonish
Copy link
Member

@jasonish jasonish requested review from catenacyber and removed request for victorjulien November 26, 2024 23:21
Comment on lines 65 to +66
DetectAppLayerInspectEngineRegister2("mqtt.connack.session_present", ALPROTO_MQTT,
SIG_FLAG_TOSERVER, 1, DetectEngineInspectGenericList, NULL);
SIG_FLAG_TOCLIENT, 1, DetectEngineInspectGenericList, NULL);
Copy link
Member Author

Choose a reason for hiding this comment

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

@catenacyber Here in the C version of registering this keyword we use a progress of 1. However, over in master when going through Rust its always a progress of 0. Should these be 0 over here? What was the reason for always using a progress of 0 instead of carrying over the values from C.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think there was no reason.

Does that change behavior ?

See cca59cd for some similar stuff...

You can try to have a MQTT transaction with a request and no answer yet (so tx progress is 1 to server, but 0 to client) and a rule to_client that gets evaluated and dropped before getting the data...
Does that make sense ?

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't know mqtt enough right now. But looks to be an oversight in the Rust registration of keywords?

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess a review of all progresses could be beneficial (some inconsistent progress seen in TLS for multi-buffer IIRC)

Comment on lines +90 to +91
DetectAppLayerMpmRegister2(BUFFER_NAME, SIG_FLAG_TOCLIENT, 2, PrefilterGenericMpmRegister,
GetData, ALPROTO_MQTT, 1);
Copy link
Member Author

Choose a reason for hiding this comment

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

Same here, we've changed the progress from 1 to 0 with the migration to Rust for keyword registration.

Backport of commit 5d82521.

Ticket: 7323
@jasonish
Copy link
Member Author

Tests not backported, I think they require other changes, or perhaps side affects of the Rust migration. For example, the rule in this test:

https://github.com/OISF/suricata-verify/blob/master/tests/mqtt-connect-rules-2/test.rules#L1

One cannot actually match on a non-zero reason code in 7.0.x it seems.

Copy link

codecov bot commented Nov 26, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.14%. Comparing base (fccb328) to head (d474393).

Additional details and impacted files
@@              Coverage Diff               @@
##           main-7.0.x   #12155      +/-   ##
==============================================
+ Coverage       83.13%   83.14%   +0.01%     
==============================================
  Files             922      922              
  Lines          260821   260845      +24     
==============================================
+ Hits           216826   216877      +51     
+ Misses          43995    43968      -27     
Flag Coverage Δ
fuzzcorpus 64.08% <84.00%> (+0.01%) ⬆️
suricata-verify 63.33% <100.00%> (+0.02%) ⬆️
unittests 62.39% <52.00%> (+<0.01%) ⬆️

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

@suricata-qa
Copy link

WARNING:

field baseline test %
SURI_TLPW2_autofp_stats_chk
.uptime 145 140 96.55%

Pipeline 23562

@catenacyber
Copy link
Contributor

One cannot actually match on a non-zero reason code in 7.0.x it seems.

Sounds like a bug...
Why could we not ?

@jasonish
Copy link
Member Author

One cannot actually match on a non-zero reason code in 7.0.x it seems.

Sounds like a bug...

Why could we not ?

Just an observation so far. I don't know why.

@jasonish
Copy link
Member Author

Within the scope of the backport do things look OK though?

Any other changes in master ring a bell as to why this simple rule doesn't work in 7?

alert mqtt any any -> any any (msg:"MQTT CONNACK reason code 134"; mqtt.reason_code:134; sid:4;)

@catenacyber
Copy link
Contributor

Fixed in #12157 ;-)

@jasonish
Copy link
Member Author

Within the scope of the backport do things look OK though?

Any other changes in master ring a bell as to why this simple rule doesn't work in 7?

alert mqtt any any -> any any (msg:"MQTT CONNACK reason code 134"; mqtt.reason_code:134; sid:4;)

Just found this removal of an early return in 0a1062f that fixes the reason code issue.

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.

4 participants