DNS server assessments

Carter Bullard carter at qosient.com
Thu Apr 30 14:33:34 EDT 2009


Gentle people,
I wanted to continue to add examples of some of the things that I do  
with the
new argus and argus-client programs.  Hopefully this will generate  
discussion
of the new features, and better ways of processing data.

Be sure and use the latest client code from the development server to  
use these
examples.  That's what I use to verify that these strategies work.

    ftp://qosient.com/dev/argus-3.0/argus-clients-3.0.2.beta.6.tar.gz

I like to keep track of the DNS servers that a site uses, and I like  
to checkout
the names in the queries, and the country codes, just as a high level  
check that all
is kosher.  Lots of reasons for this, but regardless of why, it  
generally boils down
to generating a database of DNS servers.  Here are some simple scripts  
for doing
this.  This is a simple/trivial start, so hopefully it will be useful.

I like to keep track of DNS servers on a daily basis, and so around 1-  
2am, I load up
the table, and start processing, to generate any reports for the  
following day.

I always store my argus() data in a standard archive format, which is:
    /path/to/archive/primitive/\$srcid/%Y/%m/%d/argus.%Y.%m.%d.%H.%M.%S

so to load up the database, I pick a specific argus probe as my data  
source,
in this case, I'll use the probe that monitors between my ISP and my  
exterior
border router, which is "x.y.z.w":

    racluster -R /path/to/archive/primitive/x.y.z.w/2009/04/29  -w - -  
port domain | \
          rasqlinsert  -M time 1d -m daddr proto dport -s daddr proto  
dport trans avgdur dhops dco \
                -w mysql://root@localhost/dns/dns_servers_%Y_%m_%d -  
dst port domain and src pkts gt 0 and dst pkts gt 0

So what are we doing?  We are clustering the domain traffic to get all  
the transactions reassembled,
and then we feed successful DNS data into rasqlinsert(), that will  
generate appropriate data to store the
DNS servers in a table that has the date in its name.  The schema has  
the IP address of the server,
the proto (tcp or udp) and the port (should be 80), the number of  
transactions, their average duration,
the estimated number of hops away and the country code of the DNS  
server.   This is a good set of data
to do some simple queries.

OK, so what's important.  Here are a few things.  First using ra*  
programs, and second using mysql().

Number of DNS servers per day:

% rasql -r mysql://root@localhost/dns/dns_servers_2009_04_29 -nn -s  
daddr -L-1 | wc
     1321    1321   25099

mysql> select count(*) from dns_servers_2009_04_29;
+----------+
| count(*) |
+----------+
|     1321 |
+----------+
1 row in set (0.00 sec)

So, that worked ok.  1,321 DNS servers in one day, not bad.



DNS servers by Country Code:

List of DNS servers from Japan (I like sushi, so Japan is a good  
thing).  Lets get the list from the database,
and I'm basically interested in how far away they are, because Japan  
is really far away.  To do this using
the database SELECT capability,  use the "-M sql='where clause'" option:

% rasql -s daddr dur avgdur dhops pkts dco -r mysql://root@localhost/ 
dns/dns_servers_2009_04_29 -M sql="dco=\"JP\""
            DstAddr        Dur     AvgDur dHops  TotPkts dCo
      124.40.52.133 27943.0898   0.213531    18       10  JP
     203.105.65.195 24765.0449   0.213976    16        8  JP
     203.105.65.196   0.515836   0.238742    16       40  JP
      210.81.13.181   0.195764   0.184833    17        4  JP
    210.138.175.244   0.023362   0.011993     5        4  JP
      210.153.1.162   0.222001   0.211320    20        4  JP
     202.239.113.26   0.227247   0.213818    16        8  JP
    202.234.232.202   0.230622   0.220066    20        4  JP
      210.153.1.164   0.202887   0.202887    20        2  JP


Wow, so there is something very interesting here.  All the round trip  
times to Japan
are all about 200 mSec, and 16-20 Hops away.  This is about right with  
physics
(New York to Tokyo is about 10878 km, and so a 0.1 sec one-way trip is  
roughly
1/3 the speed of light, which is pretty decent efficiency for mixed  
electrical,
optical switching with 20 Hops).

But, the address 210.138.175.244 claims to be Japanese, address  
managed by The
Japan Network Information Center, but there is no way that Japan is  
only 11.993 mSecs
away from NYC.  Well, interestingly enough, this is correct, as there  
is a Japanese DNS
server in NYC.  Very interesting!!!!!

% traceroute  210.138.175.244
traceroute to 210.138.175.244 (210.138.175.244), 64 hops max, 40 byte  
packets
  1  192.168.0.1 (192.168.0.1)  0.972 ms  0.574 ms  0.737 ms
  2  10.22.32.1 (10.22.32.1)  6.232 ms  7.385 ms  5.978 ms
  3  vl4.aggr1.nyw.ny.rcn.net (208.59.246.1)  11.977 ms  7.390 ms   
8.475 ms
  4  tge1-2.border1.nyw.ny.rcn.net (207.172.19.110)  8.473 ms  7.854  
ms  8.977 ms
  5  NYIIX.IIJ.Net (198.32.160.42)  10.464 ms  7.158 ms  7.974 ms
  6  nyc002bb01.IIJ.Net (216.98.96.141)  8.477 ms  6.851 ms  10.725 ms
  7  d.dns.jp (210.138.175.244)  8.477 ms  7.916 ms  14.434 ms

So this is an example of a number of features.   rasql() reads the  
binary argus record
that  rasqlinsert() inserted into the database for each row.  Because  
of this, we can
print fields that are not a part of the database schema.  So here,  
we're printing the
"Total Duration" and the "Total Pkts" from the argus record, ( it is
not a part of the MySQL database schema that rasqlinsert() used).




Something that I find very interesting, is to look at the actual DNS  
queries.  One
hint to finding Conficker issues, is to look for DNS queries to  
notable web-sites,
such as random generated domain names that Conficker uses as  
Rendezvous Points.
Here is how we get the list of DNS queried names from the database.
My argus() captures 256 bytes of user data, and that data is now  
stored in the database,
as rasqlinsert() provides that function.  So here are the first 20 DNS  
queries for April 3, 2009,
excluding the reverse lookups, out of the 2314 that I had that day.

    % rasql -r mysql://root@localhost/dns/dns_servers_2009_04_29 -nnw  
- | \
           ../bin/radump -s suser:128 | awk '{print $4}' | sort -u |  
fgrep -v in-addr.arpa | head -20

AC-DDNS-1.NET.CS.CMU.EDU.
AUTH1.DNS.RCN.NET.
AUTH2.DNS.RCN.NET.
AUTH4.DNS.RCN.NET.
BLACKHOLE-1.IANA.ORG.
C.GTLD-SERVERS.NET.
CON1R.NIPR.MIL.
DNS1.TELSTRA.NET.
I.GTLD-SERVERS.net.
NS-1.AMAZON.COM.
NS-3.AMAZON.COM.
NS.CAIS.COM.
NS01.SAVVIS.NET.
NS1.MOZILLA.COM.
NS1.THEPLANET.COM.
NS1.berkeley.edu.
NS1.coremetrics.com.
NS2.ES.NET.
NSA.1AND1.COM.
USE1.AKAM.NET.


OK, hopefully this helps to illustrate some simple, but interesting  
things you can do.

Carter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20090430/b6ef24d6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3815 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20090430/b6ef24d6/attachment.bin>


More information about the argus mailing list