Feature #1249
closedFeature #2318: matching on large amounts of data with dynamic updates
http/dns ip-reputation alike technique
Description
(as a reference) https://lists.openinfosecfoundation.org/pipermail/oisf-users/2014-July/003975.html
- applying different concepts within the IDS: like the IP
reputation/md5list that let's you load a file containing IOCs. However
importing hostnames and domainnames from a file, and match them on http/dns app layerYeah, I would like to support this. In your case I think you have almost
a 100% exact matches. For this hash lookups would be fine. The advanced
rule logic isn't necessary. Then a single rule can be used, and using
the json output we could add what we matched on. Not supported
currently, but I think this is the way forward.
That feature would be great. One small correction about the match. For
hostnames it's 100% match.
What we call domains is foo.com and *.foo.com.
What I'm doing now is: (for dns, but the same applies to http)
- dns_query; content:"malicioushostname.com"; nocase; pcre:
"/(|[^A-Za-z0-9-\.]) malicioushostname\.com$/i";
- dns_query; content:"mailliciousdomain.com"; nocase; pcre:
"/(|[^A-Za-z0-9-]) maliciousdomain\.com$/i";
(the second regex could also be (^|\s|\.)foo.com$ , but I'm not sure
which one is the best)
Updated by Andreas Herz over 8 years ago
- Tracker changed from Bug to Feature
- Assignee set to Anonymous
- Target version set to TBD
Updated by David Wharton almost 6 years ago
I agree that having DNS Reputation would be valuable. It could be called "dnsrep" since it would be like iprep but for domain names.
Certainly it would inspect DNS requests. It could also be extended to look at the SNI field of TLS client requests and the HTTP Host header although I’m not convinced these are necessary. The nice thing is that these fields are already parsed out and normalized, and rules could be written (or programmatically generated) currently to identify traffic based off of domain names. However, this becomes onerous once you start dealing with a dynamic DNS blacklist of non-trivial size.
The DNS blacklist file should be just that -- a text file that Suricata reads and can reload quickly without significant internal effort. Reload should be able to be triggered via signal/socket/API call.
Since DNS blacklist matching involves multi-pattern match, Hyperscan could/should be utilized if available (although this would increase load/reload time since the Hyperscan database would have to be built/rebuilt but this is likely worth it given the frequency or reload; see below comment). Using Hyperscan as the MPM would also enable the powerful ability to use PCRE to match domain names, while maintaining performance.
I expect the frequency of dnsrep reloads in practice to be somewhere between a few times an hour to a few times a day, with the latter end of the spectrum being more likely.
Updated by Victor Julien almost 6 years ago
- Status changed from New to Assigned
- Assignee changed from Anonymous to Victor Julien
Updated by Victor Julien about 5 years ago
- Status changed from Assigned to Closed
- Target version changed from TBD to 5.0rc1
DNS
alert dns any any -> any any (dns.query; datarep:dns_string, >, 200, load dns_string.rep, type string; sid:3;)
HTTP HOST
alert http any any -> any any (http.host; datarep:dns_string, >, 200, load dns_string.rep, type string; sid:4;)
https://github.com/OISF/suricata/pull/4166
https://suricata.readthedocs.io/en/latest/rules/datasets.html