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

detect: log app-layer metadata in alert with single tx #12166

Closed

Conversation

catenacyber
Copy link
Contributor

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

May also solve https://redmine.openinfosecfoundation.org/issues/7406 and https://redmine.openinfosecfoundation.org/issues/7350

Describe changes:

  • detect: log app-layer metadata in alert with single tx

SV_BRANCH=OISF/suricata-verify#2141

Is this the right way to solve most of the cases as I remember discussing with someone ?

#12161 with better check and comment for one live transaction

Ticket: 7199

When there is a single live transaction, we cannot pick a wrong
transaction to log, even if the rule does not use app-layer
keywords.
Copy link

codecov bot commented Nov 27, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 49.83%. Comparing base (bd7d38e) to head (cd4cf6b).

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #12166      +/-   ##
==========================================
+ Coverage   49.81%   49.83%   +0.02%     
==========================================
  Files         909      909              
  Lines      257904   257904              
==========================================
+ Hits       128467   128522      +55     
+ Misses     129437   129382      -55     
Flag Coverage Δ
fuzzcorpus 61.02% <100.00%> (+0.07%) ⬆️
livemode 19.43% <16.66%> (+<0.01%) ⬆️
pcap 44.44% <100.00%> (+0.02%) ⬆️
suricata-verify 62.74% <100.00%> (-0.01%) ⬇️
unittests 8.98% <0.00%> (ø)

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 23584

txid = AppLayerParserGetTransactionInspectId(pflow->alparser, dir);
if ((alert_flags & PACKET_ALERT_FLAG_STREAM_MATCH) ||
(s->alproto != ALPROTO_UNKNOWN && pflow->proto == IPPROTO_UDP) ||
AppLayerParserGetTxCnt(pflow, pflow->alstate) == txid + 1) {
Copy link
Member

Choose a reason for hiding this comment

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

This is not what I had in mind. The idea was that for a protocol like tls, where we have only one tx max, we use that tx. However, in other protocols the "live" tx may not necessarily be relevant? There are protocols like smb, nfs that have transactions with different life times. I'm not sure how reliable it would be to pick the last. Before accepting a patch on that I would like to see a per protocol analysis of how we can be sure that this condition provides us with a relevant tx. We've decided it's worse to log the wrong one, than to log 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.

Oh.

I understand that you say that only one tx is not enough, what is important is to know if every byte of the stream belong to the transaction...

Even for TLS, this is not obvious, as the encrypted bytes do not belong to the transaction, and the inspect id logic should work but not obvious to me...

On top of my head :

  • HTTP1 : every byte is in a transaction ✅
  • HTTP2 : every byte is in a transaction ✅
  • DNS : every byte is in a transaction ✅
  • TLS : only the first bytes before encryption are in a transaction ⚠️
  • SMTP : first commands are not in a transaction 🔴
  • SSH : seems to be like TLS ⚠️ even if I am not sure if we want to make the plaintext records part evolve...
  • SMB, NFS : I do not know ❓
  • many others...

Should we have a dirty patch to allow only certain app-layer protocols ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Another problematic case :
signature is like alert ip any any -> any any (sid: 1; flow.age: >1; flow: to_server; )

  • 3 way handshake
  • first HTTP2 request
  • acked
  • after one second, second HTTP2 request begins with a packet with the start of big HTTP2 frame :
    • parser returns AppLayerResult::incomplete, does not create tx
    • signature triggers
    • the only transaction present is the first one (AppLayerParserGetTxCnt==1) but the first request had all its data before flow.age was 1 second old, so should not be logged

@catenacyber
Copy link
Contributor Author

Something next in #12168

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