Containing and Tracking Botnets Angelos D. Keromytis Columbia University.

Containing and Tracking Botnets

Angelos D. Keromytis

Columbia University

Prevention and Attribution

• Consent-based networking (i.e., network capabilities)– Explore the expensive-but-expressive end of

the design spectrum– GRA: Mansoor Alicherry

• Identify ultimate source of C&C traffic (botmaster)– Adopt technique we developed in attacking

anonymity networks– GRA: Sambuddho Chakravarty

February 2010 Project Review Meeting 2

Expressive Capabilities

• Network capabilities proposed as a decentralized (management) and distributed (enforcement) containment mechanism

• Typical designs try to minimize space and processing overhead

• We are exploring opposite side of spectrum: expressive but expensive capabilities– What is the limit of capabilities?– Can they be managed?– Can we gain flexibility with minimal overhead?

February 2010 Project Review Meeting 3

Example environment: MANETs

February 2010 Project Review Meeting 4

Our Approach

• Policy enforcement framework– Capability: Access rules and bandwidth constraints

represented using capabilities– Deny-by-default: Every packet in the network needs to

have an associated capability– Distributed Enforcement: All the intermediate nodes

enforce the capability policy

• Unauthorized traffic dropped closer to the source– Protects end-host resources and network bandwidth

February 2010 Project Review Meeting 5

Network Capabilities

• Access control and bandwidth limitation represented using capability– Identity of the principal– Identity of the destination– Type of service and bandwidth– Expiration date– Issuer & Signature

• Policy tokens– Issued by the administrator

• Network capability– Issued by the receiving node– Contains policy authorizing it to issue

February 2010 Project Review Meeting 6

Policy Token Example

serial: 130745owner: unit01.nj.army.mil (public key)destination: *.nj.army.milservice: httpsbandwidth: 50kbpsexpiration: 2010-12-31 23:59:59issuer: captain.nj.army.milsignature: sig-rsa 23455656767543566678

February 2010 Project Review Meeting 7

Network Capability Example

serial: 1567owner: unit01.nj.army.mil (public key)destination: unit02.nj.army.milbandwidth: 150kbpsexpiration: 2009:10:21 13:05:35issuer: unit02.nj.army.milcomment: Policy allowing the receiverto issue this capability.signature: sig-rsa 238769789789898

February 2010 Project Review Meeting 8

Protocol• Capability associated with each communication

session– Transaction identifier and signature

• Capability Establishment– Source node informs the intermediate nodes about

transaction identifier, capability and key for signature• Smaller keys used for per packet signature|

• Sender– Adds transaction id, sequence number and signature to

the packet• Intermediate nodes and Receiver

– Verifies the packet (probabilistically) for signature and bandwidth

February 2010 Project Review Meeting 9

System Architecture

February 2010 Project Review Meeting 10

Evaluation Methodology

• Simulations using GloMoSim– Extend GloMoSim for new architecture– Add support for packet processing delays

• Input Parameters– Conducting experiments in stand alone settings (Pentium-4

3.20GHz CPU, 1GB RAM)

• Traffic– CBR, FTP

• From simple (line) to complex (grid, random) topology– With mobility

February 2010 Project Review Meeting 11

Parameters of Interest

• Latency of packets– Time taken for a packet to travel from a source

to destination– First packet latency, Average latency

• Throughput• Packet Delivery Ratio (PDR)

February 2010 Project Review Meeting 12

Latency of first packet

• Capability establishment, database lookup, signature verification, larger header (36B)

• Overhead (35.8 mS, 41.6 mS, 60.9 mS) – About 20.5%

• Line topology (node distance =

200 m)

• CBR 512 B

February 2010 Project Review Meeting 13

Future Directions

• Proceeding with implementation and performance evaluation on wireless testbed

• Evaluation of usability aspects– Token issuance– Revocation– Disconnected operation

• Explore multi-party consent– Capabilities can incorporate hierarchy,

thresholds, and other schemes authorizing 3rd parties to control aspects of the communication

February 2010 Project Review Meeting 14

Attribution

• Can we identify the node that originates commands?– botmaster may use proxies– botnet may be inherently decentralized (P2P)– we don’t have presence in all routers and links– C&C traffic may be encrypted

• Insight: remote sensing of a link’s available bandwidth, combined with induced oscillations of specific types of botnet traffic, can allow us to track where such traffic goes

February 2010 Project Review Meeting 15

Emulating a Global Eavesdropper

• Induce traffic fluctuations on botnet traffic that is ultimately intended for the botmaster– e.g., information harvesting– not all botnets may allow this– may require capture or emulation of bots– need large amounts of such traffic

• may be detected

• Trace the effects of those fluctuations by measuring available bandwidth on remote links– need a lot of bandwidth, and a network map

February 2010 Project Review Meeting 16

Bandwidth Estimation

• Send pair of “back-to-back” packets to destination

• Pair “spreads” in time; we call this dispersion

BW = (Packet Length * 8) / (dispersion) (measured in bps)

• Packet train method: send multiple back-to-back packets– fewer errors (equivalent to multiple

independent* trials)

February 2010 Project Review Meeting 17

LinkWidth

• Tool that emulates TCP Westwood sender to measure available bandwidth and throughput– TCP-Westwood uses bandwidth estimation

every RTT seconds to adjust the TCP slow start threshold whenever congestion is detected

• Generates TCP RST packets “sandwiched” between TCP SYN packets– TCP SYNs go to closed ports, eliciting TCP

RST+ACK responses• If TCP SYNs are filtered, we resort to ICMP

February 2010 Project Review Meeting 18

Remote Bandwidth Sensing

• Use LinkWidth against routers to measure the available bandwidth on the links from probe host to that router– need static topology map

• Induce severe traffic fluctuations on traffic whose ultimate destination we want to identify– traffic volume must be mostly preserved

• Trace back fluctuations on available bandwidth, one link at a time

February 2010 Project Review Meeting 19

Experimental Testbed

February 2010 Project Review Meeting 20

Preliminary Experimental Results

• Test for accuracy: 10Mbps link shared by up to 3 HTTP sessions (each at 500 Kbps)

• Test for convergence: increase traffic from 200Kbps to 1.4Mbps in less than 2 minutes

February 2010 Project Review Meeting 21

Probing Nodes in TOR

February 2010 Project Review Meeting 22

Future Directions

• Automate process; currently, requires human operator

• Improve sensitivity and reduce FPs• Considerably more evaluation

– currently working on DETER topologies– also experimenting on TOR

February 2010 Project Review Meeting 23

Outreach and Education

• Integrated material on bots into COMS W4180 course• 1 invited talk (beyond conference talks)

• Working with Symantec to determine modus operandi of rogue AV sites (and why users trust them)– Preliminary results published in the October 2009

Interim Symantec Threat Report (ISTR)

"Gone Rogue: An Analysis of Rogue Security Software Campaigns" Marc Cova, Corrado Leita, Olivier Thonnard, Marc Dacier, and Angelos D. Keromytis. In Proceedings (electronic) of the 5th European Conference on Computer Network Defense (EC2ND). November 2009, Milan, Italy. (Invited paper)

February 2010 24Project Review Meeting

Backup slides

February 2010 Project Review Meeting 25

Input Parameters

• Radio range = 377m, link bandwidth = 2 Mbps, 802.11 MAC

• Packet processing time = 0.01 mS (equavalent to 100Mbps for 128 B packets)

• Database: insertion = 0.01 mS, lookup = 0.005 mS

• 1024 bit RSA for capability– Signature 3.159 mS, verification 0.140 mS

• 256 bit for packet signature– Signature 0.168 mS, Verification 0.0275 mS

February 2010 Project Review Meeting 26

Average Latency

• Database lookup, signature verification, larger header (36B)• Overhead (0.6 mS, 1.2 mS, 1.6 mS) – About 8%

• Line topology

• CBR 512 B, 100 mS, 1000 pkts

February 2010 Project Review Meeting 27

Throughput (CBR)

• Throughput overhead: 2% lower for our scheme

• Line topology

• CBR 1400 B, 1 mS

February 2010 Project Review Meeting 28

Throughput (FTP)

• Throughput overhead: 5.3% lower for our scheme

• Line topology

• 10 FTP files

February 2010 Project Review Meeting 29

Route Change

• Original Drops: 108mS worth of traffic• Our scheme: 155mS

• Line topology

• CBR 512 B, 1000 pkts

• Path length: 3

• Route change at 0.5 S

February 2010 Project Review Meeting 30

Mobility on Grid

• PDR overhead: 1.6% (50mS), 9.14(25mS) lower for our scheme

• Random topology: 50 nodes,

1200x1200m grid

• CBR 256 B

• 5 pairs of traffic

• Random way point mobility

February 2010 Project Review Meeting 31