[Discussion] features (mainly dns)

[David Dagon]

On Sun, Dec 07, 2008 at 08:59:14AM +0100, Florian Weimer wrote:

> >> How do you mean? Loke looking for a client that's making repeated dns
> >> queries within the TTL? Maybe poorly coded bots?

<snip>

> And all UNIX-like clients which do not perform local caching by
> default. 8-(

I've found that linux hosts can be filtered by keeping state on AAAA
lookups, followed by A lookups (glibc has this behavior).  But with
the growth of Vista, and other OS that perform AAAA lookups first,
this filtering step is less and less useful.  Subsequent checks for
wpad resolutions can help, since vista revived this proxy discovery
technique (for a period in a dangerous manner).  

Of course these heuristics have a limited shelf life.  In a
statistical sense, the failure to negatively cache or the failure to
observe TTLs is a useful filter, but the results must then be
correlated with other data (NS data sets, SLB data sets, perhaps
p0f-style data sets) to remove FPs.

I suggest the tool should consider keeping a window of state (e.g.,
AAAA --> A lookups, etc.), so that this filtering does not have to
happen offline/post alert.  Of the unappealing aspects of snort is
that its alerts are too packet-specific (yes, there are flow bits, and
simple ways to accumulate state).

Here are some additional notes:

  -- if the tool is configured to reconstruct DNS sessions, you should
     handle DNS TC truncation bit packets; simply filtering per-packet
     allows for both IP and TC fragmentation.

  -- Consider filters for RFC suggested limits on NS counts (7 I
     believe).  This is a good way to spot flux.  Here is a
     distribution of NS counts for the top million or so (mostly
     whitelistable) domains (log scale count x NS count):

        http://fritz.cc.gt.atl.ga.us/ns_count_top1M_domains.txt

     (Note the drop at 12 NS; this is related to why we have only 13
     root servers--512 byte payloads are difficult to pack with more
     labels, even after line compression.)

     The administrative burden of large numbers of NS is large, and
     the number of sites that exceed this for legitimate reasons is
     vanishingly small.  Often, flux networks use >7 NS.  This
     threshold, multiplied by AS diversity counts, is a very strong
     filter currently (FPs are only those global CDNs like akamai,
     which can be white listed).  See the work of Thorsten Holz for
     early insights.

     I realize by suggesting this, flux networks can "reduce and
     evade".  But this would be a good development since such networks
     are more brittle, and the lowered NS count makes them sensitive
     to diurnal patterns in victims.  (Evolution can also weaken a
     species, and applying pressure to force flux conformance with
     usual DNS deployment patterns will diminish their capabilities.)

     This goes after a central weakness of flux: professional DNS is
     usually deployed on high availability systems--several 9s.  But
     flux networks uses victim resources (ranked, but often poor in
     comparison to normal DNS resources), and handing authority to a
     non-reachable host results in failure signaling and possible
     botnet fragmentation.

There are other layers of heuristics; hopefully these ideas let you
design an architecture where one can express them in a simple syntax.

-- 
David Dagon              /"\                          "When cryptography
dagon at cc.gatech.edu      \ /  ASCII RIBBON CAMPAIGN    is outlawed, bayl
Ph.D. Student             X     AGAINST HTML MAIL      bhgynjf jvyy unir
Georgia Inst. of Tech.   / \                           cevinpl."