"MALWARE-OTHER dns request with long host name segment - possible data exfiltration attempt"
This is a F/P and needs tuned out. I DO NOT want to disable the alert, but the two IPs are internal IPs and the firewall, so as far as tuning it out in the threshold[.]conf, not possible . . . to my knowledge.
It's triggering on a DNS request from our networks anti-virus. So it'd be great to tune that URL out.
Coming from a Splunk background the first thing I thought was to just tune out the URL. In Splunk we have searches that look for IDS alerts then | (pipe) them in to further searches for more detail opposed to just the IDS alert, but unfortunately Elastic doesn't work that way (but hopefully will in the future).
So any advice on keeping the alert enabled but still suppressing for the URL?
--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
To post to this group, send email to securit...@googlegroups.com.
Visit this group at https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.
Sophos AV by any chance?
On Tue, 22 May 2018, 15:32 'Josh Silvestro' via security-onion, <security-onion@googlegroups.com> wrote:
Hello! Looking for ideas or whatever anyone else is currently doing. I have an alert firing on the network:
"MALWARE-OTHER dns request with long host name segment - possible data exfiltration attempt"
This is a F/P and needs tuned out. I DO NOT want to disable the alert, but the two IPs are internal IPs and the firewall, so as far as tuning it out in the threshold[.]conf, not possible . . . to my knowledge.
It's triggering on a DNS request from our networks anti-virus. So it'd be great to tune that URL out.
Coming from a Splunk background the first thing I thought was to just tune out the URL. In Splunk we have searches that look for IDS alerts then | (pipe) them in to further searches for more detail opposed to just the IDS alert, but unfortunately Elastic doesn't work that way (but hopefully will in the future).
So any advice on keeping the alert enabled but still suppressing for the URL?
--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onion+unsubscribe@googlegroups.com.
To post to this group, send email to security-onion@googlegroups.com.
Visit this group at https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.
--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onion+unsubscribe@googlegroups.com.
To post to this group, send email to security-onion@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onion+unsubscribe@googlegroups.com.
To post to this group, send email to security-onion@googlegroups.com.
Visit this group at https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to a topic in the Google Groups "security-onion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/security-onion/K73PGQg94BI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-onion+unsubscribe@googlegroups.com.
To post to this group, send email to security-onion@googlegroups.com.
Visit this group at https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.
There's a few things you can do with Suricata rules for this.
1) If the signature came from ET (ET Pro), you can report the FP to them with the domain it's firing on or include a pcap for them so they can easily check their changes.
2) You can do a content negation for the dns name. DNS signatures in Suricata can be a bit tricky sometimes as they can do a very detailed subdomain comparison but doing a full content:!"<domain>" may work for you. If you do this, you should put the rule in your local.rules file so it stays more permanant until ET (if that's where it came from) can fix it. If you change the rule, then it gets a revision that doesn't include the fix, your changes will be lost.
Here's the negation section of the Suricata documentation. They're awesome at documenting how to building custom signatures.
http://suricata.readthedocs.io/en/suricata-4.0.4/rules/differences-from-snort.html#negated-content-match-special-case
How have you been attempting to disable the rule?
Mike,
How have you been attempting to disable the rule?
You received this message because you are subscribed to a topic in the Google Groups "security-onion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/security-onion/K73PGQg94BI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-onion+unsubscribe@googlegroups.com.
To post to this group, send email to security-onion@googlegroups.com.
I, too, am looking to modify 30881:3. However, at the top of the modifysid.conf file it says "Note that this will only work with GID:1 rules, simply because modifying GID:3 stub rules would not actually affect the rule, thusly it will remain non modifyable!"
30881 says that it is a "gid:3" rule. It seems that modifying this rule will not work by changing it in modifysid.conf.
Other than suppression, have you found a way to effectively mute this rule for the sophos (or other long domain name) domains?
--Josh