North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: The Domain Name Service as an IDS

  • From: Chris Brookes
  • Date: Wed Feb 22 19:41:01 2006
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lAan8R9LPKwPuqVnxCU409X3WOJqzSLun2gEwBNRveOh4GGESyJFxADcPZG8B2DoyO96vwC3G0L4k61mVQVwLY7kuXvxZn17FI8s25CIjig09oXutiWnwKRQUf0QnhZfrbUgi/jw4xdjo2NUJLHKRUpGz6Jlm/tLWmyhw2fkIwA=

On 22/02/06, Gadi Evron <[email protected]> wrote:

> and help us take it to the next level of DNS monitoring.

In the large corporation I work for, I have a home grown DNS
monitoring system I put together. I have the luxury of full control
over every DNS server used by network connected devices, and so each
and every single query is logged for a duration of 30 days to a SQL
database.

Amongst others, I've developed the following services with it for my
internal customers:

1) Malicious activity detection/monitoring

We baseline what queries each device normally makes, so when a device
suddenly starts trying to resolve n% more destinations than usual,
it's often malicious code such as spyware. In addition, each
destination name appearing in the database is analysed to see how many
devices are querying for it. If a new name pops up, and in the last n
minutes it's being resolved by a significant amount of devices, it's
almost always a virus or worm outbreak. Once malicious activity is
confirmed and dealt with by desktop groups, the system is then used to
provide additional verification that a given client really has been
cleaned up.

2) Server move impact assessment

All devices on the network invariably use DNS to find each other, and
by them using DNS you can reasonably assume an IP connection was made
from one device to the other.  With all queries logged, we generate
surprisingly detailed reports on exactly what devices have a
relationship with what other devices. The value of relationships is
determined by a variety of factors, but these include: does the
resolution happen in a reoccurring daily pattern? do both devices in
the relationship try to resolve each other? what percentage of the
overall queries made by the source is for this specific target? The
reports easily draw out issues such as what web servers will be
impacted by taking a given app server down?

In addition, by cross referencing with our QIP environment we can work
out which IP addresses belong to users and which ones dont. When a
server is being taken offline we can report on exactly which users
will be impacted, and where they are geographically.

3) Server footprint info

Devices on the network are named in a somewhat intelligent fashion so
we produce quick reports that reveal server characteristics such as:
is the machine keeping up to date with Antivirus (is it making
reoccurring queries for the AV update server), is the machine Unix or
Windows based (is it resolving our NIS environment or our AD systems),
is the machine monitored by Openview (are the polling stations
resolving it every day) etc etc

4) Hard Coded IP analysis

Our internal customers shuffle client server based applications
around. Sadly, IP addresses get used in configurations all too often,
and IP addresses change. So, we take a sniff of TCP/IP connections
made to a given system, and then run it through the query database,
taking each TCP/IP connection and checking whether the client resolved
the name of the destination IP. When there's no evidence of the source
querying for the target, but the source is querying for other targets,
that typically points firmly to a hard coded IP.

5) DNS delete validation/server retirement analysis

Nothing is deleted from DNS unless the query database clearly shows
complete lack of resolution for the given name.

... and those were just the first 5 things I came up with. Mining our
DNS data is providing all kinds of opportunities for our security,
server, and chanage management groups.

I'd be very interested to hear from anyone else who's working on this
sort of DNS log mining.

Regards

Chris