[Rule Tuning] Abnormally Large DNS Response#5922
[Rule Tuning] Abnormally Large DNS Response#5922eric-forte-elastic wants to merge 11 commits intomainfrom
Conversation
…se-11013227-0301-4a8c-b150-4db924484475
|
⛔️ Test failed Results
|
…se-11013227-0301-4a8c-b150-4db924484475
|
⛔️ Test failed Results
|
…se-11013227-0301-4a8c-b150-4db924484475
|
⛔️ Test failed Results
|
|
⛔️ Test failed Results
|
|
⛔️ Test failed Results
|
|
⛔️ Test failed Results
|
…se-11013227-0301-4a8c-b150-4db924484475
|
⛔️ Test failed Results
|
…se-11013227-0301-4a8c-b150-4db924484475
|
⛔️ Test failed Results
|
…se-11013227-0301-4a8c-b150-4db924484475
|
⛔️ Test failed Results
|
| or network.protocol:"dns" | ||
| or event.dataset:(network_traffic.dns or zeek.dns)) | ||
| and destination.bytes > 60000 | ||
| and event.type:("allowed" or "end" or "protocol" or "start") |
There was a problem hiding this comment.
The query change itself looks good, just wanted to clarify on whether event.type:connection events from any target integrations are being intentionally excluded.
There was a problem hiding this comment.
Good question, short answer: yes exclusion is intentional, but nuanced.
Long Answer:
event.type:connection has a dual use. First is that is almost always populated, you will regularly see things like: event.type = ["start", "connection"]. This doc/event should be interpenetrated as the start of a connection or more directly, the event that was the attempt to start the connection. Following this entry there will be doc(s) that have event.type = ["connection"] which contain a summary of the total events from the connection.
Notionally and over simplified you could see something like:
Doc 1: event.type = ["start", "connection"]... size 4b
Doc 2: event.type = ["allowed", "connection"] ... size 6b
Doc 3: event.type = ["end", "connection"] ... size 2b
Doc 4: event.type = ["connection"] ... size 12b
In the above case, the Doc 4 of size 12b is a summary of Docs 1-3, not additional data. Where this applied to the rule, is that we need to exclude the summary docs which have just event.type:connection, while keeping the docs that have that event type which are not the summary. Otherwise, the destination.bytes size would be applied to the summary of the connection interactions as opposed to the triggering event itself, thereby creating many false positives.
| (event.dataset:zeek.dns or type:dns or event.type:connection) and network.bytes > 60000 | ||
| ((event.category:(network or network_traffic) and destination.port:53) | ||
| or network.protocol:"dns" | ||
| or event.dataset:(network_traffic.dns or zeek.dns)) |
There was a problem hiding this comment.
| or event.dataset:(network_traffic.dns or zeek.dns)) | |
| or data_stream.dataset:(network_traffic.dns or zeek.dns)) |
Pull Request
Issue link(s):
Resolves #5509
Summary - What I changed
Tuning to update DNS traffic detection to include Zeek DNS traffic identification. Additionally, reduces false positive/duplicate alerts by removing the connection by removing
event.type is "connection"as this will cause the rule to fire not only on the start/end of the connection but on flows after the connection is established and first alert is created on the flow (thereby being a duplicate). Furthermore, the fieldnetwork.bytesin practice is not the number of bytes for the request, but the session total from the connection in the established connection case. As such it is still useful in the start/end of a connection, but not for the overall session total. This has been changed todestination.bytesas this will include directionality in the filtering paired with the event type filteringevent.type:("allowed" or "end" or "protocol" or "start")to exclude summary messages.How To Test
Verify in telemetry.
Checklist
bug,enhancement,schema,maintenance,Rule: New,Rule: Deprecation,Rule: Tuning,Hunt: New, orHunt: Tuningso guidelines can be generatedmeta:rapid-mergelabel if planning to merge within 24 hoursContributor checklist