The Domain Name Service as an IDS

"How DNS can be used for detecting and monitoring badware in a network"

This is a very interesting although preliminary work by obviously skilled people. I haven't learned much but I am extremely happy others work on this than the people I already know! They also weren't too shy with credit, mentioning Florian Weimer and his Passive DNS project already at the abstract (quoted below). They even mention me for some reason.

Great paper guys!

Moving past Passive DNS Replication and blacklisting, they discuss what so far has been done for years using dnstop, and help us take it to the next level of DNS monitoring.

Someone should introduce them to Duane Wessels' (from ISC OARC) follow-up dnstop project, DSC. :slight_smile:
[Duane's lecture on the tool at the 1st DNS-OARC Workshop]

There has been some other interesting work done in this area by our very own David Dagon from Georgia Tech:
[Presentation from the 1st DNS-OARC Workshop] Botnet Detection and Response - The Network is the Infection:
[Paper] Modeling Botnet Propagation Using Time Zones:

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

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.



Chris Brookes wrote:

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

Hi Chris, thanks for your reply. I was just told by the admin team to
keep DNS operational issues off-list. Would you mind if we take this
to the DNS operations mailing list run by the ISC OARC?


Let's see - a description of an interesting way to use DNS metrics to
detect network abuse - network abuse that routinely causes headaches on
our network and results in customer complaints. Seems pretty on topic
for a network operations mailing list.


Hi Chris, thanks for your reply. I was just told by the admin team to
keep DNS operational issues off-list.

I deo not believe this. You didn't notice the Monday plenary session
at NANOG 36 meeting was all DNS?
...and two of the lighting talks on Wednesday?