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

decode/ethertype: Event on unknown ethertype #11455

Closed
wants to merge 2 commits into from

Conversation

jlucovsky
Copy link
Contributor

Continuation of #11442

Issue: 7129

Create a decode/engine event if unknown ethertypes are observed.

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

Describe changes:

  • Add an event created when unknown ethertypes are observed
  • Update schema with event counter
  • Add rule for event.

Updates

  • Typo update
  • s-v test update

Provide values to any of the below to override the defaults.

  • To use an LibHTP, Suricata-Verify or Suricata-Update pull request,
    link to the pull request in the respective _BRANCH variable.
  • Leave unused overrides blank or remove.

SV_REPO=
SV_BRANCH=OISF/suricata-verify#1954
SU_REPO=
SU_BRANCH=
LIBHTP_REPO=
LIBHTP_BRANCH=

jlucovsky added 2 commits July 9, 2024 08:19
Issue: 7129

Create a decode/engine event if unknown ethertypes are observed.
Copy link

codecov bot commented Jul 9, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.49%. Comparing base (a28666d) to head (79752ba).

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #11455      +/-   ##
==========================================
- Coverage   82.50%   82.49%   -0.01%     
==========================================
  Files         938      938              
  Lines      247915   247916       +1     
==========================================
- Hits       204533   204526       -7     
- Misses      43382    43390       +8     
Flag Coverage Δ
fuzzcorpus 60.50% <100.00%> (+<0.01%) ⬆️
livemode 18.73% <100.00%> (+0.01%) ⬆️
pcap 43.79% <100.00%> (-0.07%) ⬇️
suricata-verify 61.50% <100.00%> (+<0.01%) ⬆️
unittests 59.42% <100.00%> (+<0.01%) ⬆️

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

@@ -71,6 +71,7 @@ alert pkthdr any any -> any any (msg:"SURICATA UDP header length too small"; dec
alert pkthdr any any -> any any (msg:"SURICATA UDP invalid length field in the header"; decode-event:udp.len_invalid; classtype:protocol-command-decode; sid:2200120; rev:2;)
alert pkthdr any any -> any any (msg:"SURICATA SLL packet too small"; decode-event:sll.pkt_too_small; classtype:protocol-command-decode; sid:2200041; rev:2;)
alert pkthdr any any -> any any (msg:"SURICATA Ethernet packet too small"; decode-event:ethernet.pkt_too_small; classtype:protocol-command-decode; sid:2200042; rev:2;)
alert pkthdr any any -> any any (msg:"SURICATA Ethertype unknown"; decode-event:ethernet.unknown_ethertype; threshold: type limit, track by_rule, seconds 60, count 1; classtype:protocol-command-decode; sid:2200121; rev:1;)
Copy link
Member

Choose a reason for hiding this comment

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

one issue with thresholding here is that the rule is not per ether type, but a generic "we encountered a type we dont know/support", so if there are multiple unknown ether types, the rule may alert only for some of them due to the thresholding. Not sure what can be done about it.

Copy link
Contributor

Choose a reason for hiding this comment

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

Then, one can use another rule with the event

@suricata-qa
Copy link

WARNING:

field baseline test %
SURI_TLPW1_stats_chk
.decoder.invalid 75 756 1008.0%
SURI_TLPR1_stats_chk
.decoder.invalid 194 902190 465046.39%

Pipeline 21498

@victorjulien
Copy link
Member

WARNING:
field baseline test %
SURI_TLPW1_stats_chk
.decoder.invalid 75 756 1008.0%
SURI_TLPR1_stats_chk
.decoder.invalid 194 902190 465046.39%

Pipeline 21498

Is "invalid" correct? Or just "unsupported" by Suricata?

@jlucovsky
Copy link
Contributor Author

WARNING:
field baseline test %
SURI_TLPW1_stats_chk
.decoder.invalid 75 756 1008.0%
SURI_TLPR1_stats_chk
.decoder.invalid 194 902190 465046.39%
Pipeline 21498

Is "invalid" correct? Or just "unsupported" by Suricata?

Good point. I think an argument could be made for each being correct.

However, may I suggest that we count unknown ethertypes (and later, unknown IP protocols) as decoder.unknown?

@jlucovsky
Copy link
Contributor Author

WARNING:
field baseline test %
SURI_TLPW1_stats_chk
.decoder.invalid 75 756 1008.0%
SURI_TLPR1_stats_chk
.decoder.invalid 194 902190 465046.39%
Pipeline 21498

Is "invalid" correct? Or just "unsupported" by Suricata?

Good point. I think an argument could be made for each being correct.

However, may I suggest that we count unknown ethertypes (and later, unknown IP protocols) as decoder.unknown?

Strike that -- we already have a counter for unknown_ethertype so I don't know if decoder.unknown adds value.

@jlucovsky
Copy link
Contributor Author

@victorjulien

Thoughts on

  • Changing the event type to mark the packet as "unknown" instead of "invalid"
  • Counting the "unknown" events as "ethertype unknowns" (and move the increment of counter_ethertype_unknown from DecodeNetworkLayer to PacketDecodeFinalize

@victorjulien
Copy link
Member

@victorjulien

Thoughts on

* Changing the event type to mark the packet as "unknown" instead of "invalid"

* Counting the "unknown" events as "ethertype unknowns" (and move the increment of `counter_ethertype_unknown` from DecodeNetworkLayer to PacketDecodeFinalize

"unknown" makes more sense to me

@jlucovsky
Copy link
Contributor Author

Continued in #11546

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.

5 participants