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

Mqtt rust keywords 4863 v1 #11316

Closed

Conversation

catenacyber
Copy link
Contributor

So that MQTTTypeCode::CONNECT does not become c_o_n_n_e_c_t
As needed for MQTTTypeCode which accepts both CONNECT uppercase
and unassigned lowercase
for easier later matching
Ticket: 4863

On the way, convert some keywords to use the first-class integer
support.
And imports in pure rust the support for multi-buffer.
@@ -159,5 +164,6 @@ mod test {
transform_name("UnassignedMsgType"),
"unassigned_msg_type".to_string()
);
assert_eq!(transform_name("SAMECASE"), "samecase".to_string());
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

Fine in a test.

@@ -89,6 +94,8 @@ mqtt.reason_code

Match on the numeric value of the reason code that is used in MQTT 5.0 for some message types. Please refer to the specification for the meaning of these values, which are often specific to the message type in question.

mqtt.reason_code uses an :ref:`unsigned 8-bits integer <rules-integer-keywords>`.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

We can now use all the operators

@@ -137,6 +144,8 @@ mqtt.connect.flags

Match on a combination of MQTT CONNECT flags, separated by commas (``,``). Flags may be prefixed by ``!`` to indicate negation, i.e. a flag prefixed by ``!`` must `not` be set to match.

mqtt.connect.flags uses an :ref:`unsigned 8-bits integer <rules-integer-keywords>`
Copy link
Contributor Author

Choose a reason for hiding this comment

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

We can now match on the unassigned bit and the qos 2 bits if we want

@@ -109,6 +109,7 @@ exclude = [
"IPPROTO_TCP",
"IPPROTO_UDP",
"SRepCatGetByShortname",
"SIG_FLAG_TOSERVER",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@satta why is MQTT detection only to server ?

Copy link
Contributor

Choose a reason for hiding this comment

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

Good question. I just grepped through detect-mqtt-* and saw many instances of SIG_FLAG_TOSERVER... well, not all of the things that are alerted on in the detection keywords are sent to the broker, but most are (e.g. anything with CONNECT or PUBLISH, but not CONNACK, the reason code, etc.).
Could be a copy-paste artifact; interesting that these keywords still seem to work though.

Maybe I should also revisit the code and check if maybe the transactions the parser produces are deliberately registered as being toserver because I didn't know an alternative (even though they likely contain messages in various directions) and that's why we want to apply the keywords to toserver.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

And there is no SIG_FLAG_TOCLIENT

@@ -701,9 +701,8 @@ pub unsafe extern "C" fn rs_mqtt_state_get_tx_count(state: *mut std::os::raw::c_

#[no_mangle]
pub unsafe extern "C" fn rs_mqtt_tx_is_toclient(
tx: *const std::os::raw::c_void,
tx: &MQTTTransaction,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

needed so that MQTTTransaction is exported by cbindgen

FAIL_IF_NULL(sig);

sig = DetectEngineAppendSig(
de_ctx, "alert ip any any -> any any (mqtt.protocol_version:3; sid:2; rev:1;)");
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@satta why put another time the same signature with a different sid ?

Copy link
Contributor

@satta satta Jun 19, 2024

Choose a reason for hiding this comment

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

The second one should certainly have been mqtt.protocol_version:5.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

will fix in next version

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks!

return Some(rcode);
}
}
_ => return None,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@satta why do we not continue with the loop ?

Copy link
Contributor

Choose a reason for hiding this comment

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

Right, we should. Good catch! This is likely an oversight when extending transactions to multi-operations.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

will fix in next version

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks!

if let MQTTOperation::UNSUBSCRIBE(ref unsubv) = msg.op {
if (local_id as usize) < unsubv.topics.len() + offset {
let topic = &unsubv.topics[(local_id as usize) - offset];
if !topic.is_empty() {
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 wonder if we treat right the empty topic case here

Copy link
Contributor

Choose a reason for hiding this comment

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

You mean, in that empty topics should be returned nevertheless? Well, the spec does not forbid zero length topic strings (e.g. in MQTT5 if the topic alias property is used) so we might just return length of 0 and a null pointer, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, we should...

@catenacyber
Copy link
Contributor Author

This is a follow up on #11291

There are more protocols to do...

Copy link

codecov bot commented Jun 18, 2024

Codecov Report

Attention: Patch coverage is 87.52108% with 148 lines in your changes missing coverage. Please review.

Project coverage is 82.48%. Comparing base (49ecf37) to head (959b28a).
Report is 3 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #11316      +/-   ##
==========================================
+ Coverage   82.47%   82.48%   +0.01%     
==========================================
  Files         934      918      -16     
  Lines      252270   252086     -184     
==========================================
- Hits       208055   207944     -111     
+ Misses      44215    44142      -73     
Flag Coverage Δ
fuzzcorpus 60.29% <85.01%> (+0.03%) ⬆️
livemode 18.78% <32.24%> (+0.02%) ⬆️
pcap 43.77% <33.73%> (-0.01%) ⬇️
suricata-verify 61.37% <78.76%> (+0.05%) ⬆️
unittests 59.86% <54.04%> (-0.05%) ⬇️

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

@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline 21114

@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline 21128

@satta
Copy link
Contributor

satta commented Jun 19, 2024

Thanks for the porting work and also for taking a closer look at the code! Will give it a deeper look later and reply here.

@catenacyber
Copy link
Contributor Author

Thanks for the porting work and also for taking a closer look at the code! Will give it a deeper look later and reply here.

ok waiting for it then, thanks

@catenacyber
Copy link
Contributor Author

Continued in #11374

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