The Domain Name Service as an IDS
"How DNS can be used for detecting and monitoring badware in a network" http://staff.science.uva.nl/~delaat/snb-2005-2006/p12/report.pdf 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. :) http://dns.measurement-factory.com/tools/dsc/ https://oarc.isc.org/faq-dsc.html http://www.caida.org/tools/utilities/dsc/ [Duane's lecture on the tool at the 1st DNS-OARC Workshop] http://www.caida.org/projects/oarc/200507/slides/oarc0507-Wessels-dsc.pdf 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: http://www.caida.org/projects/oarc/200507/slides/oarc0507-Dagon.pdf [Paper] Modeling Botnet Propagation Using Time Zones: http://www.cs.ucf.edu/~czou/research/botnet_tzmodel_NDSS06.pdf ----- Abstract SURFnet is looking for technologies to expand the ways they can detect network traffic anomalies like botnets. Since bots started using domain names for connection with their controller, tracking and removing them has become a hard task. This research is a first glance at the usability of DNS traffic and logs for detection of this malicious network activity. Detection of bots is possible by DNS information gathered from the network by placing counters and triggers on specific events in the data analysis. In combination with NetFlow information and IP addresses of known infected systems, detection of bots of network anomalies can be made visible. Also the behavior of a bot can be documented and additional information can be gathering about the bot. Using DNS data as a supplement to the existing detection systems can give more insight in the suspicious network traffic. With some future research, this information can be used to compile a case against particular types of bot or spyware and help dismantling a remote controlled infrastructure as a whole. Note We started this research project with the question if the Passive DNS Software of Florian Weimer was useful for bot detection. We immediately found out that the sensor of the Passive DNS Software strips the source address from the collected data for privacy reasons, making this software not useful at all for our purpose. We deviated from the Research Plan (Plan van Aanpak) and took a more general approach to the question; ”Is gathered DNS traffic usable for badware detection”. ----- Gadi. -- http://blogs.securiteam.com/ "Out of the box is where I live". -- Cara "Starbuck" Thrace, Battlestar Galactica.
On 22/02/06, Gadi Evron <ge@linuxbox.org> 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
Chris Brookes wrote:
On 22/02/06, Gadi Evron <ge@linuxbox.org> 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:
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? Gadi.
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?
Gadi.
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. -- Mark Radabaugh Amplex mark@amplex.net 419.837.5015
On Thu, Feb 23, 2006 at 04:27:52AM +0200, Gadi Evron wrote: [snip]
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? http://www.nanog.org/mtg-0602/wessels.html http://www.nanog.org/mtg-0602/ishibashi.html http://www.nanog.org/mtg-0602/gibbard.html ...and two of the lighting talks on Wednesday? http://www.nanog.org/mtg-0602/pdf/kristoff.pdf http://www.nanog.org/mtg-0602/pdf/murphy.pdf Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
participants (4)
-
Chris Brookes
-
Gadi Evron
-
Joe Provo
-
Mark Radabaugh