Combining seen DNS data with traffic data: Tracking traffic to domains

[Carter Bullard]

Hey Markku,
We do have support for printing only the domain names of the addresses:

RA_PRINT_DOMAINONLY=yes

which can be set in the .rarc file, and we did have aggregation on
domain names, but that implementation is incomplete, so the hooks
are there for it, but it doesn't appear that you can do it right now.

The idea is to do the reverse lookup for the addresses, take the name
that is returned, grab the domain part of the name, and use that as the
value for the saddr or daddr when filtering, processing whatever.  This is
preferred, as deriving DNS information from packets on the wire can be easily
manipulated by an adversary, and you may not be able to grab the contents
of packets, as the snaplen may be small.

We do have DNS name labeling, and it did support this option, but it
appears to be incomplete as well.  So the design allows you to poke the
domain name in as a label, but I need to finish it.

There is a man page for ralabel that describes quite a bit, and all you have
to do is print the label field to see the label:

   ra -s +label

The default length is pretty small, so should put a length specifier:

   ra -s +label:32

You'll see the format when you print them out.  racluster has primitives for
greping labels, etc... and there should be some hints in the racluster.conf
man page.

And there is a ralabel.conf man page that describes the conf file.

We have extensive support for label processing, so that they can be filtered,
grep'ed, aggregated, etc....  so we can do a lot with the labels, but not much
traffic on the mailing list about them, so not much in the way of descriptions
etc....

So lets go through your example, and figure out what you really want for
domain name processing, and I'll reimplement the features we had, and
get it the way you want.  So how do you want to configure this animal ?

Carter

On Oct 15, 2012, at 2:07 PM, Markku Parviainen <maketsi at gmail.com> wrote:

> Hi,
> 
> I was wondering if you could track traffic to domains instead of IPs
> by combining knowledge from seen DNS traffic with IP addresses seen.
> This would be much more accurate than labeling the results of reverse
> lookups that often do not work. This would be useful in ratop and
> racluster, as you could directly see how much of your traffic is
> consumed for facebook or other famous CDN sites, or could track
> requests to suspicious domains that probably are signs of malware
> infection (xxcz92obzf.cn anyone?), or could map fast-flux domains
> visited.
> 
> The basic concept could be implemented quite easily:
> 
> 1) user does DNS request for A record of www.cdn.net
> 2) DNS responds that www.cdn.net has two A records: 1.1.1.1 and 2.2.2.2
> 3) We cache that information for later use, noting the TTL in the DNS response.
> 4) That same user (saddr) makes a HTTP request to 1.1.1.1 within N
> seconds from that DNS request, and within the TTL
> 5) We can assume that the user reached that IP by using name
> www.cdn.net and label the corresponding flow as being so.
> 6) racluster/ratop/whatnot by that label
> 
> Can this be done with existing tools?
> 
> There seem to be two problems:
> - Ralabel claims that it "inserts fixed form or free form metadata
> labels into argus(8)". But how exactly? Manual page or the sample
> configuration file ralabel.conf does not say how to create that
> ralabel.conf to insert foo=bar to flow X. It doesn't say how to view
> that data later either.
> - DNS requests need to be found and parsed from argus packets (could
> use a simple udp and dport 53 filter).
> - If the parsing is done on batches, we need to match and label flows
> manually, while also maintaining that time limit referred in step 4).
> 
> I guess that if the labeling works, I could implement a batch script
> for parsing the DNS data and inserting those labels into archived
> flows. That doesn't help for realtime analysis though.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2589 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121015/7a479520/attachment.bin>