1. The ICSI HoneyfarmCui, Paxson, Weaver ICSI Honeyfarm Status Weidong Cui Vern Paxson Nicholas Weaver

2. The ICSI HoneyfarmCui, Paxson, Weaver Page 2 General Concept: A Breeding Ground for Worms We want a controlled, automatic breeding ground for worms and other self-propagating attacks: –Worm attacks a "monitored" address and begins to propagate in our system As the worm propagates, we have a suite of automatic analyzers to study the worm –What it can infect? –Any particulars of interest? –How does it attack? And automatically analyze defense strategies –Does this signature block the worm? All within a very short time: a few seconds –And with a single point of trust for exporting information Also want to leverage the infrastructure for detecting other things: –Human attackers/non-self-propagating attacks –Non-random worms

3. The ICSI HoneyfarmCui, Paxson, Weaver Page 3 Honeyfarm: Objectives We use network telescopes and a honeyfarm to detect scanning worms –Network Telescopes Distributed unallocated IP address ranges –Honeyfarm: Centralized cluster of honeypots On-demand: emulating a large number of hosts on a small number of honeypots Detecting self-propagation –Detect self-propagation inside the honeyfarm by redirecting propagations from one honeypot to other honeypots Other detectors possible: –Tripwire/modification detectors –Monitored honeypots, etc… Global Internet Honeypots Controller Honeyfarm

4. The ICSI HoneyfarmCui, Paxson, Weaver Page 4 The Overall Goal Framework for automatically detecting and analyzing new worms and other attacks –For self-propagating attacks, we want to generate: Vulnerability signatures: What is vulnerable Behavior signatures: What the worm needs to propagate Attack signatures: Signatures which detect and block the attack All signatures should be verified for effectiveness –For non-self-propagating attacks, as much of the above as possible –Based on providing a fertile ground for constrained propagation Receive data from multiple sources –Small distributed telescopes, Large telescopes –Spam, Crawling? For a RANDOM worm, with k addresses, V victims, and M systems infected: –P detect = 1 – ((V-k)/V) M after M machines infected –High probability of detection when M = V/k

5. The ICSI HoneyfarmCui, Paxson, Weaver Page 5 ICSI's Honeyfarms Honeyfarm Safety ICSI's features: –Windows Centric –Hot Telescope –Replay Replay-based filtering –Spam Telescope The Main ICSI Honeyfarm Other possibilities: –"Run this" Wormholes

6. The ICSI HoneyfarmCui, Paxson, Weaver Page 6 ICSI Focus: Windows Microsoft Windows is our primary (currently only) hosted OS This requirement dictates VM choice: –VMWare Workstation or ESX server –Workstation: prototyping Limited scalability Runs on everything –ESX Server: production Stringent hardware requirements Memory sharing for (some) scalability –Could be better –But can work across multiple close variants due to coalescing For now, NO host-OS specific customization –Dictates mechanism for demand allocation: NAT, instead of customization –Allows the possibility of non-virtual honeypots as well ?Apple Systems?

7. The ICSI HoneyfarmCui, Paxson, Weaver Page 7 ICSI's Architecture GRE Tunnel Honeyfarm Network Telescope Filtering Attacker MappingContainment Policing VM Clusters Detection VManager Filtering Containment Policing Detection

8. The ICSI HoneyfarmCui, Paxson, Weaver Page 8 Note on Architecture Most components implemented in Click –Provides a modular, reusable framework Components in red we want to merge with UCSD –Need to better coordinate in this area –Relatively low overlap so far, but need

9. The ICSI HoneyfarmCui, Paxson, Weaver Page 9 Safety: A Common Focus Of Both UCSD and ICSI What if a worm propagates through the honeyfarm and then infects somebody else? –"But they would get infected anyway" doesn't cut it… Two safety features: –Containment: the basic decision making on what is allowed outbound Connections back to the infecting host Some "phone-home" channels may also be allowed –Much malcode/attacks grab code from a third-party site –An independent policing module Shutdown the honeyfarm once it detects any abnormal behavior on outbound connections This is a safety belt, it should NEVER actually be invoked Want a third safety feature as well: –A monitoring system which observes the control-plane –Has the ability to turn-off the honeyfarm by power-sequencing the network connections Much more details on policies in UCSD's talk

10. The ICSI HoneyfarmCui, Paxson, Weaver Page 10 The Telescopes We have 4 /16s arranged as two (almost) contiguous /15s belonging to ESNet… –Network is directly advertised and routed by ESNet But we also have, on loan, a "special" /23 netblock –Also advertised and routed by ESNet Much malcode is NOT random: –Linear scanners starting from the local address: Blaster and others –Local subnet preference Nimda, etc By selecting highly-likely addresses, we can gain an advantage in detection time –Local subnet preferences in particular have proven very effective

11. The ICSI HoneyfarmCui, Paxson, Weaver Page 11 How Hot Is The Hot Address Range?

12. The ICSI HoneyfarmCui, Paxson, Weaver Page 12 Filtering But we can't allow all communication: –Honeypot allocation/deallocation is very expensive for us VMWare doesn't support a lightweight clone We want to filter out known threats –But we still want to detect new attacks for existing vulnerabilities We want to detect Welchia as well as Blaster: –New attacks may require new signatures –New variants may be substantially more disruptive –And we would like to avoid identification by attackers as a honeypot system Thus we need a low-cost mechanism to say whether an attack is worth forwarding to a real honeypot

13. The ICSI HoneyfarmCui, Paxson, Weaver Page 13 Basic Filtering Scan filtering –Allow traffic to the first N destinations from a source. –Intuition: Scans from a source is homogeneous Init-Data filtering –Detect known attacks by looking at the first data transfer from a source –Intuition: Many simple attacks (e.g., CodeRed, Blaster, Slammer) can be filtered. –Scheme: Acknowledge to SYNs and any data packets following it University of Michigan scheme Is this enough? –Far too many active sources on the Internet –No, many attacks require complicated "conversations" before exposing its unique malicious attention See Pang et al "Characterizing Internet Background Radiation" Application-level responders are expensive in terms of development –Also, can't do "cut-through forwarding" if the attack deviates from the known script Our idea: replay-based filtering

14. The ICSI HoneyfarmCui, Paxson, Weaver Page 14 Application Independent Replay To positively identify a probe as being from a known or unknown source, it requires a complex dialog –EG, Windows SMB file transfer We can't build target-specific responders –Too many variants and new targets Can we use an existing dialog as a script for replaying an application session? –Take one or two instances of a dialog Eg, a recorded attack by a particular worm against one of our honeypots –Recognize certain idioms: Addresses, ports, and names encoded in the dialog Ports which open for subsequent transfers "Cookies" or session identifiers Length fields Prestated arguments Then use the current interaction as a guide –Update ports/addresses/subsequent connections as appropriate –Mimic back cookies and other changes

15. The ICSI HoneyfarmCui, Paxson, Weaver Page 15 Responder-Side Replay Original FlowReplay Flow AttackerVictim Infected! AttackerFilter Detected! 1 2 3 4 5 1’ 2’ 3’ 4’ 5

16. The ICSI HoneyfarmCui, Paxson, Weaver Page 16 Replay Status This works for single dialogs –For both the initiator (client) and responder (server) Tested with: –NFS file manipulation –FTP file transfer Including changing the filename argument for the client –CIFS/SMB file transfers –The Blaster worm –W32.Randex.D worm Performs attack through open file shares Currently expanding to support multiple, simultaneous dialogs –Primarily for server-side replay to act as a radiation filter –Possibility: Recognize commands by where dialogs diverge? Also desire replay for: –"Toxicology Screen": For this attack, what can get infected –Testing network devices, evaluating servers, interacting with Internet servers for measurement purposes…

17. The ICSI HoneyfarmCui, Paxson, Weaver Page 17 Replay-Based Filters There are 1700 different application dialogs among 143224 connections to port 445/tcp –Connections to active honeypots –Used tethereal to generate a one-line summary for each data packet –Formulated each dialog in a canonical format Want to ignore anything in the "known" dialogs set, while allowing anything in the "unknown" set So use replay: –Replay as the server with the group of known dialogs If replay successful, classify and ignore that source –If replay fails, begin replaying the new dialog against a honeypot as the client Using the previous dialog as the starting script Also, mark source as unknown and allow it to contact a live honeypot if seen again

18. The ICSI HoneyfarmCui, Paxson, Weaver Page 18 Attacker Filter VM 1 2 3 4 5 1 2 3 4 5 Known? Responder-Side Replay Initiator-Side Replay Infected!

19. The ICSI HoneyfarmCui, Paxson, Weaver Page 19 The Spam Telescope Half of the emails to @acme.com are sent to our email server –100,000 messages per day –6000 unique executables in 4 days We implemented a real time process to parse emails and retrieve attachments –Hash attachments to gain some statistics We plan to run attached executables on our honeypots to detect new email worms or multimode worms –Use email to penetrate the firewall, then exploit with local exploits

20. The ICSI HoneyfarmCui, Paxson, Weaver Page 20 The Main Honeyfarm Located at LBNL in ESNet's machine room –Designed around HP DL360 G4 1u, dual processor servers Currently: –1 server as "head unit" Previous head was a DL380, but suffered a catastrophic motherboard failure –7 servers running ESX for honeypots Near term expansion (next couple of weeks) –Convert one ESX server into raw Linux for processing acme.com email Attach 3 TB disk array for tertiary storage –Add 6 more 1u servers –Add a redundant switch –Increase the disk space on the existing servers Generous support from: –ESNet: Network connectivity and rackspace –Hewlett Packard: Equipment –Microsoft: OS and software liscences –VMWare: VMWare liscences

21. The ICSI HoneyfarmCui, Paxson, Weaver Page 21 Possibility: The "Run This" Wormholes We also want small, easy to use endpoints: –Distributed secrets –Endpoints in LANs –Nonblacklistable endpoints for crawlers Our plan is to create a "Run This" endpoint in Click –Creates a new MAC address derived from the host's MAC Obtain DHCP lease Open GRE tunnel to the specified honeyfarm –All traffic is forwarded through the tunnel –Outgoing traffic is strongly policed by the "Run This" module: Limited fanout No contacting local addresses ?What to do about LAN broadcast packets? Goal is an easy to use and trustable endpoint –Which does not trust the honeyfarm.