<div dir="ltr"><div><div><div><div><div><div>Logging the query and answer in two different log lines reduces the need to do the tracking of "dns-sessions" inside suricata, hence saving memory. Reassembling the query and answer from the logs should be possible, before one inserts them to a DB as one record etc. <br>
<br></div>passivedns aggregates all this in memory, and outputs all in one log line. The main reason for this, was that I want to be able to reduce the amount of logs to my likings :)<br></div>passivedns caches queries and responses if they are the "same" (regardless of the client that did the query or the server that answered), and just increments a counter for each query+answer+record+type. You can turn off the caching, but that will resolve in more log lines :) but you will get each client request ie :)<br>
<br></div>I would love it if suricata had the config option to do something similar in the future ;)<br></div> - enable caching<br></div> - enable aggregated output<br></div> - memory limit on caching<br><div><div><div><div>
<br></div><div>I store my passivedns logs in Elasticsearch... I do have some code for this, but its just not public atm.<br></div><div>Normally I do some coding around Xmas, hopefully it can be the pdns2es  code that I release this year :)<br>
</div><div><br></div><div>But my use of passivedns might be different from others. Im making a historic archive of what pointed where...<br></div><div>But I guess many uses pdns to find the clients that did the query to the bad domain, so that is two totally different ways I see that implemented in a backend.<br>
<br><br></div><div>E<br></div><div><br><br><br></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 27, 2013 at 11:30 AM, 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>
Christophe<br>
<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>
_______________________________________________<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>
</blockquote></div><br><br clear="all"><br>-- <br>Edward Bjarte Fjellskål<br>Senior Security Analyst<br><a href="http://www.gamelinux.org/" target="_blank">http://www.gamelinux.org/</a>
</div>