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

dns: add dns.rcode keyword v6 #10233

Closed

Conversation

hadiqaalamdar
Copy link
Contributor

@hadiqaalamdar hadiqaalamdar commented Jan 24, 2024

Feature #6621

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

Previous PR: #10203

Describe changes:

  • made the suggested changes from the previous PR
  • fixed the commit history.
  • modified the code to implement DetectUintData<u8> instead of simple u8
  • SV tests are running successfully
  • Added documentation for rcode in doc/userguide/rules/dns-keywords.rst file.
  • successfully ran the following tests:
  • from rust dir: make check
  • from rust dir: cargo test
  • from rust dir: cargo clippy --all-features
  • from rust dir: rustfmt src/dns/*
  • from suricata dir: ./scripts/clang-format.sh check-branch
  • from suricata dir: ./scripts/clang-format.sh branch
  • from suricata dir running ./src/suricata -u showed that one unit test had failed.
  • from suricata dir running ./src/suricata -u -U dns showed 7 tests passed.

SV_BRANCH=OISF/suricata-verify#1578

Feature OISF#6621
It matches the rcode field in DNS
It's an unsigned integer match
valid ranges = [0-23]
Does not support prefilter
Supports flow in client direction
@hadiqaalamdar hadiqaalamdar force-pushed the detect-dns-rcode-6621-v6 branch from 97cd65b to a122126 Compare January 24, 2024 12:34
Copy link

codecov bot commented Jan 24, 2024

Codecov Report

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

Comparison is base (3cb7112) 82.18% compared to head (a122126) 82.22%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #10233      +/-   ##
==========================================
+ Coverage   82.18%   82.22%   +0.03%     
==========================================
  Files         977      978       +1     
  Lines      271894   272014     +120     
==========================================
+ Hits       223465   223657     +192     
+ Misses      48429    48357      -72     
Flag Coverage Δ
fuzzcorpus 63.29% <26.92%> (+0.30%) ⬆️
suricata-verify 61.42% <82.69%> (-0.07%) ⬇️
unittests 62.81% <69.16%> (+<0.01%) ⬆️

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

@hadiqaalamdar hadiqaalamdar marked this pull request as ready for review January 24, 2024 13:35
@@ -39,6 +39,7 @@ pub enum DetectUintMode {

#[derive(Debug)]
#[repr(C)]
#[derive(PartialEq)]
Copy link
Contributor

Choose a reason for hiding this comment

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

You can merge lines like #[derive(Debug, PartialEq)]

arg1: 4,
arg2: 0,
},
(0b0000_0000_0000_0100 & 0xf) as u8,
Copy link
Contributor

Choose a reason for hiding this comment

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

Strange way to write 4

Copy link
Contributor Author

Choose a reason for hiding this comment

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

should I remove this or change it to this (0b0000_0000_0000_0100) as u8,? The opcode code had something similar so that's why I wrote it like this.

Copy link
Contributor

Choose a reason for hiding this comment

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

opcode did this because there was some bits shifting.
4u8 should be more readable

return 0;
}
} else {
// Not to server or to client??
Copy link
Contributor

Choose a reason for hiding this comment

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

You can assume this never happens (so else instead of else if flags & Direction::ToClient as u8 != 0)

return 0;
};

let rcode = (header_flags & 0xf) as u8;
Copy link
Contributor

Choose a reason for hiding this comment

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

@jasonish should we use tx.rcode() here ?

Copy link
Contributor

Choose a reason for hiding this comment

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

And @hadiqaalamdar how can this be 23 ? cf commit message saying valid ranges = [0-23]

Copy link
Member

Choose a reason for hiding this comment

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

@jasonish should we use tx.rcode() here ?

That won't get you the rcode for a request, even if its odd to do so. Could extend it to, or just leave this as is for now.

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'm sorry but I'm a bit confused. Please let me know if I should change something here?

Copy link
Contributor

Choose a reason for hiding this comment

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

@jasonish is the owner of DNS knowledge and he said

just leave this as is for now.


Match on DNS requests where the **rcode** is not between 7 and 15:

dns.rcode:!7-15;
Copy link
Contributor

Choose a reason for hiding this comment

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

This is not yet the case, and out of the scope of this PR I think

sigmatch_table[DETECT_AL_DNS_RCODE].AppLayerTxMatch = DetectDnsRcodeMatch;

DetectAppLayerInspectEngineRegister(
"dns.rcode", ALPROTO_DNS, SIG_FLAG_TOSERVER, 0, DetectEngineInspectGenericList, NULL);
Copy link
Contributor

Choose a reason for hiding this comment

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

Why does the commit message say Supports flow in client direction ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Please correct me if I'm wrong but I think that while creating SV tests for dns rcode, someone had suggested that rcode is only sent in the client direction. If my understanding is correct should I remove "dns.rcode", ALPROTO_DNS, SIG_FLAG_TOSERVER, 0, DetectEngineInspectGenericList, NULL);?

Copy link
Contributor

Choose a reason for hiding this comment

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

Please correct me if I'm wrong but I think that while creating SV tests for dns rcode, someone had suggested that rcode is only sent in the client direction. If my understanding is correct should I remove "dns.rcode", ALPROTO_DNS, SIG_FLAG_TOSERVER, 0, DetectEngineInspectGenericList, NULL);?

That someone was me.
But Jason Ish, owner of DNS knowledge, said this keyword should work both ways.
To, the code is correct, but the commit message is not

/* Copyright (C) 2019 Open Information Security Foundation
/* Copyright (C) 2024 Open Information Security Foundation
Copy link
Contributor

Choose a reason for hiding this comment

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

When updating copyright years for existing files, we keep the initial year, like so, in this case:
2019-2024

@hadiqaalamdar
Copy link
Contributor Author

New PR: #10249

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