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

[Dave Edelman]

I imagine that this is possible but there are a few more things to consider
in this logic.

1 - A DNS name resolution request can be sent using either UDP or TCP at the
sole discretion of the requesting process. The filter would have to include
both.
2 - A response to a request can be one or more A records; one or more  NS
records; a CNAME record and some of this stuff comes with glue records and
other bits and pieces. Some of these may already be cached There is also the
question of who is doing the recursion. Web proxy servers at your network
edge may be hiding all of this from Argus
3 - Browsers sometimes (often) do their own DNS caching and sometimes
(often) have no respect for the TTL of the DNS resource record. The same
(MM) for actual page elements. The same holds for the proxy servers. The
some holds for NSCD and UNSCD.
4 - Web servers have been known on rare occasions to respond with something
besides a 200 OK  The result codes in the 300 - 399 range may well point the
browser to a very different location (possibly with a different TTL) If the
new location is in a cache then you may not see anything on the wire. If you
see something, you might not be able to associate it with the request that
you are investigating. There is also a growing trend to send 200 OK
responses instead of 404 Not Found and display a highly customized page with
all sorts of search options. In this case the URL requested may not be the
page delivered.

I am not sure that this is a trivial task and I haven't even mentioned what
various wide-area and server load balances can do to make it even more
interesting :)

--Dave


> -----Original Message-----
> From: argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu
> [mailto:argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu] On
> Behalf Of Markku Parviainen
> Sent: Monday, October 15, 2012 2:07 PM
> To: argus-info at lists.andrew.cmu.edu
> Subject: [ARGUS] Combining seen DNS data with traffic data: Tracking
traffic
> to domains
> 
> 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.