<div dir="ltr"><div><div>In many ways I think the combination of the 2 would be best. i.e gamelinux PDNS only shows first and last time the address was queried and I feel the database is easier to search and apply analysis too in order to identify badness. Then once you have a start and end date you can transition into the more verbose logs to get each request and their times for searching other log formats (i.e proxies, ELSA etc).<br>
<br></div>PassiveDNS I think is excellent and while I have been using it in a lot of ways now I have  a few months of data I feel I can proceed onto analysis (i.e with other data reduction I was looking at querying the database for new entries first seen today for IP/Name to try and identify odd things although I still need some work; I get it down to a list of about 400 entries which to be honest is fine to quickly eye over because to a trained analyst FP domains and potential bad candidates stick out.<br>
<br></div>Cisco even does it: <a href="http://blogs.cisco.com/security/tracking-malicious-activity-with-passive-dns-query-monitoring/">http://blogs.cisco.com/security/tracking-malicious-activity-with-passive-dns-query-monitoring/</a> lol. I have found myself reading the blogs of other security companies like I mentioned previously who use a lot of passiveDNS intelligence and big data to search for ideas for what kind of things I could look for. <br>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 27 November 2013 10:30, Christophe Vandeplas <span dir="ltr"><<a href="mailto:christophe@vandeplas.com" target="_blank">christophe@vandeplas.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
<br>
Thank you for the long replies.<br>
@Kevin: gamelinux passivedns is indeed great, I've been using it for a while.<br>
@Peter and Coop: Elasticsearch, logstash and elsa are comparable to<br>
splunk, a tool to index data and search for it.<br>
<br>
The thing I'm more specifically looking for are practical uses of the<br>
DNS logging format of Suricata.<br>
The reason is that it's a LOT different from the output I'm used of<br>
gamelinux passivedns (and of some other pdns webinterfaces I have<br>
access on) and I'm currently evaluating if i) it is worth to switch to<br>
the suricata pdns now, or should I wait for the json output and the<br>
more philosophical ii) is<br>
<br>
<br>
A pdns database is great in the way that it can be used with multiple hats:<br>
1/ an incident response analyst finding infected systems knowing the CC server<br>
2/ an incident response analyst searching for relations with other dns<br>
names and CCs<br>
3/ an analyst searching for unknown badness based on some concepts<br>
<br>
Let me explain by comparing gamelinux passivedns output and suricata's<br>
for example: We have a database (or file) containing these fields:<br>
1385545938||10.0.1.2||10.1.1.10||IN||stores.ebay.fr.||CNAME||stores.shop.ebay.fr.||900<br>
1385545938||10.0.1.2||10.1.1.10||IN||stores.ebay.fr.||CNAME||stores.shop.intl.ebay.com.||900<br>
<br>
Now as Kevin explains you can find badness by searching for NXDOMAINS<br>
and other weird things. The interesting thing with the gamelinux<br>
format is that everything is on one line: type, request, type,<br>
response, ttl.<br>
<br>
Suricata on the other hand outputs data in multiple lines:<br>
<br>
11/27/2013-11:06:49.845594 [**] Query TX 82f3 [**] <a href="http://td.twitter.com" target="_blank">td.twitter.com</a> [**]<br>
A [**] x.x.x.x:15937 -> <a href="http://208.78.70.34:53" target="_blank">208.78.70.34:53</a><br>
11/27/2013-11:06:49.845594 [**] Response TX 82f3 [**] <a href="http://td.twitter.com" target="_blank">td.twitter.com</a><br>
[**] A [**] TTL 30 [**] 199.59.150.8 [**] <a href="http://208.78.70.34:53" target="_blank">208.78.70.34:53</a> -><br>
x.x.x.x:15937<br>
11/27/2013-11:06:49.845594 [**] Response TX 82f3 [**] <a href="http://td.twitter.com" target="_blank">td.twitter.com</a><br>
[**] A [**] TTL 30 [**] 199.59.149.231 [**] <a href="http://208.78.70.34:53" target="_blank">208.78.70.34:53</a> -><br>
x.x.x.x:15937<br>
11/27/2013-11:06:49.845594 [**] Response TX 82f3 [**] <a href="http://td.twitter.com" target="_blank">td.twitter.com</a><br>
[**] A [**] TTL 30 [**] 199.59.148.92 [**] <a href="http://208.78.70.34:53" target="_blank">208.78.70.34:53</a> -><br>
x.x.x.x:15937<br>
11/27/2013-11:06:49.845594 [**] Response TX 82f3 [**] <a href="http://twitter.com" target="_blank">twitter.com</a> [**]<br>
NS [**] TTL 20864 [**] <a href="http://ns3.p34.dynect.net" target="_blank">ns3.p34.dynect.net</a> [**] <a href="http://208.78.70.34:53" target="_blank">208.78.70.34:53</a> -><br>
x.x.x.x:15937<br>
11/27/2013-11:06:49.845594 [**] Response TX 82f3 [**] <a href="http://twitter.com" target="_blank">twitter.com</a> [**]<br>
NS [**] TTL 20864 [**] <a href="http://ns1.p34.dynect.net" target="_blank">ns1.p34.dynect.net</a> [**] <a href="http://208.78.70.34:53" target="_blank">208.78.70.34:53</a> -><br>
x.x.x.x:15937<br>
11/27/2013-11:06:49.845594 [**] Response TX 82f3 [**] <a href="http://twitter.com" target="_blank">twitter.com</a> [**]<br>
NS [**] TTL 20864 [**] <a href="http://ns2.p34.dynect.net" target="_blank">ns2.p34.dynect.net</a> [**] <a href="http://208.78.70.34:53" target="_blank">208.78.70.34:53</a> -><br>
x.x.x.x:15937<br>
11/27/2013-11:06:49.845594 [**] Response TX 82f3 [**] <a href="http://twitter.com" target="_blank">twitter.com</a> [**]<br>
NS [**] TTL 20864 [**] <a href="http://ns4.p34.dynect.net" target="_blank">ns4.p34.dynect.net</a> [**] <a href="http://208.78.70.34:53" target="_blank">208.78.70.34:53</a> -><br>
x.x.x.x:15937<br>
<br>
The output is a LOT more verbose than gamelinux pdns, this is great as<br>
I do expect to be able to see more "weird" things.<br>
However do notice that you need additional lookups to correlate the ID<br>
(82f3) between the query and response. If you data is indexed you will<br>
need to search for the ID, and considering the length of the ID you<br>
will get lots of duplicates.<br>
<br>
In the end I think I'll just wait for the json output, as it might be<br>
a lot easier.<br>
<br>
<br>
@Peter: do you think it'd be possible to also log the time between<br>
query/response? I'm wondering about the things that might come out of<br>
it.<br>
<br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888">Christophe<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
On Wed, Nov 27, 2013 at 10:16 AM, Kevin Ross <<a href="mailto:kevross33@googlemail.com">kevross33@googlemail.com</a>> wrote:<br>
> With DNS if you haven't already I would also suggest using this:<br>
><br>
> <a href="https://github.com/gamelinux/passivedns" target="_blank">https://github.com/gamelinux/passivedns</a><br>
> <a href="http://www.alienvault.com/open-threat-exchange/blog/identifying-suspicious-domains-using-dns-records" target="_blank">www.alienvault.com/open-threat-exchange/blog/identifying-suspicious-domains-using-dns-records</a><br>

> <a href="http://www.net-security.org/article.php?id=1844&p=1" target="_blank">http://www.net-security.org/article.php?id=1844&p=1</a>.<br>
><br>
> I use it and I find its ability to query quickly via web interface or having<br>
> a mysql database I can do other queries and try ideas on useful (such as<br>
> newly seen suspicious domains etc). Also blacklists & regex support and as<br>
> described in the last link provided I use this in combination with a SIEM to<br>
> identify domain generation algorithms and it has proven reliable against<br>
> Zeus and other DGA malware.<br>
><br>
> While it may not be as verbose in tracing down where queries are coming from<br>
> (especially if you can get a sensor in between your clients and DNS servers<br>
> to get the source) I find it excellent for large scale analysis and queries.<br>
> Also with the web interface I have Virustotal (which is excellent for<br>
> passiveDNS as it links malware from or speaking to the address and other<br>
> files), BFK and also my local PDNS as Snorby lookup sources and I find the<br>
> local one exceptionally useful as when you have a query you can see all the<br>
> domain names that we actually queried inside your network for this and then<br>
> can quickly determine other linked IPs, domain names etc seen in your<br>
> organisation. Also given that the database size in a large network with<br>
> 30,000 users is relatively small for now nearly 2 months of data (500MB) so<br>
> keeping large sets of historic data is possible to find later malicious<br>
> domains.<br>
><br>
> So far using this I have looked into using the data reliably to detect these<br>
> things:<br>
> - DGA malware<br>
> - Other malware domains<br>
> - Malicious domains (exploit kits, fake AVs etc).<br>
> - Now looking into fast flux detection and also other ways of detecting<br>
> malicious hosting infrastructure.<br>
><br>
> I think once I have some kind of decent data reduction on the basic queries<br>
> on the data already available I hoping to output that data from the database<br>
> and do other automatic analysis on it to reduce that set further with other<br>
> features (such as geoIP, creation dates etc).<br>
><br>
> Oh and reading the academic papers from Damballa<br>
> <a href="https://www.damballa.com/damballa-labs/publications.php" target="_blank">https://www.damballa.com/damballa-labs/publications.php</a> and openDNS/Umbrella<br>
> Labs <a href="http://labs.umbrella.com/blog/" target="_blank">http://labs.umbrella.com/blog/</a> may help give you other ideas of using<br>
> your DNS data to detect badness however you choose to collect your DNS data.<br>
><br>
> Hope that helps you a bit,<br>
> Kevin<br>
><br>
><br>
><br>
> On 26 November 2013 08:49, Christophe Vandeplas <<a href="mailto:christophe@vandeplas.com">christophe@vandeplas.com</a>><br>
> wrote:<br>
>><br>
>> Hi list,<br>
>><br>
>><br>
>> In the past I've been using another tool to do DNS logging, and now<br>
>> I'd like to use Suricata for this. The format of the file is<br>
>> completely different, and also a part of the interpretation (Suricata<br>
>> is a LOT more verbose and complete)<br>
>><br>
>> DNS logging of Suricata is mulitiple lines per DNS request (and<br>
>> response). So searching for things require multiple greps and<br>
>> filtering out duplicate ids.<br>
>><br>
>> I'm wondering how others use this DNS logging.<br>
>> All stories (on or off-list) and practical use-cases are welcome.<br>
>> I'll do my best to document these on the wiki so that others can<br>
>> benefit from this info.<br>
>><br>
>> As far as I understand there seem to be plans to transform the logging<br>
>> into json, is there already an idea about when that's to be expected?<br>
>><br>
>><br>
>> Thanks<br>
>> Kind regards<br>
>> Christophe<br>
>> _______________________________________________<br>
>> Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org">oisf-users@openinfosecfoundation.org</a><br>
>> Site: <a href="http://suricata-ids.org" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" target="_blank">http://suricata-ids.org/support/</a><br>
>> List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" target="_blank">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
>> OISF: <a href="http://www.openinfosecfoundation.org/" target="_blank">http://www.openinfosecfoundation.org/</a><br>
><br>
><br>
</div></div></blockquote></div><br></div>