stepping stone tracing and ids evaluation

Stepping Stone Tracing and IDS

Evaluation

S. Felix Wu

Computer Science Department

University of California, Davis

03/15/2006 ecs236 2

Tracing vs. Anonymity

• Packet-Level Layer-3 Tracing– iTrace

• Application-Layer Tracing– Botnet– Stepping Stone– Chains of Evil… (across inter-domain)

03/15/2006 ecs236 3

Attack Chain

NYU

LLNL

UCDavis

UCSD

XP

Linux

03/15/2006 ecs236 4

Simple Trusted 3rdPty Proxy

• Secure Relay Service

Sender Proxy Target

Encryption

Decryption

Decryption & Mapping

Mapping and Encryption

Receive

Reply

03/15/2006 ecs236 5

Mix

Mix

Real vs dummy messages!!

03/15/2006 ecs236 6

A Network of Mixers

Mix

Mix

Mix

Mix

Mix

Mix

Mix

Mix

Mix

sender

target

03/15/2006 ecs236 7

Multi-Layer Encryption

• E(PK[1], Mix2, E(PK[2], Mix3, E(PK[3], Target, Message))).

Target, MessageMix3,Mix2,

ENC-PK-Mix1

ENC-PK-Mix2ENC-PK-Mix3

03/15/2006 ecs236 8

Reply

• Mix3, E(PK[3], Mix2, E(PK[2], Mix1, E(PK[1], Sender))), E(PK[SKey], Reply).

• Only the Target can open the sender’s reply path.

• Only the Sender knows about SKey.

03/15/2006 ecs236 9

Malicious Onion Bombing

NYU

LLNL

UCDavis

UCSD

XP

Linux

Mix, Onion R., Babel, Crowd, LPWAE.g., Anonymous WEB Access

03/15/2006 ecs236 10

Connection Correlation

• We can not trust the “stepping stones” themselves.

• Given an “outgoing” connection, whether we can find the correlating “incoming” connection.– Currently assuming 1-1 channel mapping (no

multiplexing)

Linux

???

03/15/2006 ecs236 11

Stepping Stones with Multiplexing

LinuxLinuxLinux

noise

03/15/2006 ecs236 12

Active Tracing

• Active Tracing– changing the “traffic pattern” by selective

delaying and dropping– detecting “changes” on the other observation

point

a domainwith steppingstones.

an incomingconnection

a set of outgoingconnections

03/15/2006 ecs236 13

Dropping for SSCP-Tracing

• SSCP (Stepping Stone Connection Pairs)– attacker observes only a few connections– correlation gateway sees “all” the connections

• drop enough just for the gateway to distinguish the dropped/watermarked connection

• Challenges:– dropping ==> delay– attacker’s artificial noise

03/15/2006 ecs236 14

Artificial Traffic

a pseudo random traffic generation process

Do we have a packet to send?

Scheduler

03/15/2006 ecs236 15

Limitations

• RAID’2004 Impossibility Results

• Multiplexing and De-multiplexing

03/15/2006 ecs236 16

SUIT/iTrace

IDS

DynamicHorizontalSeparation

AnonymousCommunication

03/15/2006 ecs236 17

TIETraceable Information Exchange

OS Kernel

CPU & Memory

Process

Process

Process

Network

I/O

File Sys.

InformationRouter

03/15/2006 ecs236 18

Information Tracing

• Understand how information is being propagated, combined, modified…

MINOS

Bochs

TracingWithoutModifyingOS kernel orapplications

03/15/2006 ecs236 19

TIE Analysis

• Correlation between network and OS/CA information– We will know precisely how the connection

chains are propagated, even if both encrypted/decrypted and multiplexed.

• How to “redirect” a stepping stone into a MINOS-based environment?

03/15/2006 ecs236 20

OS Kernel

CPU & Memory

Process

Process

Process

Network

I/O

File Sys.

InformationRouter

MINOS

Information visualization interface

03/15/2006 ecs236 21

DETER/EMIST

• “…to provide the scientific knowledge required to enable the development of solutions to cyber security problems of national importance…”, especially at large-scale.

• Through the creation of an experimental infrastructure network -- networks, tools, methodologies, and supporting processes -- to support national-scale experimentation on research and advanced development of security technologies.

03/15/2006 ecs236 22

Experimental Evaluation

• Simulation/Emulation/Test-bed

PC 160

N x 4 @1000bTData ports

PC PC

Programmable Patch Panel (VLAN switch)

Switch Control Interface

Emulab/DETER Experimental Emulab/DETER Experimental

NetworkNetwork

Cluster of N nearly identical experimental

nodes, interconnected dynamically into arbitrary

topologies using VLAN switch.

Pool of N processors

03/15/2006 ecs236 24

03/15/2006 ecs236 25

PC

Internet

160 PowerController

'Boss' Server

User Acct & Data logging

N x 4 @1000bTData ports

N @100bTControl ports

‘User’ Server

PC PC

…

Control Network VLAN

User

ControlDB

Node Serial Line Server

Power Serial Line Server

Web/DB/SNMP,switch mgmt

Userfiles

Ethernet Bridge with Firewall

Programmable Patch Panel (VLAN switch)

'Gatekeeper'

DETER TestbedSchematic

03/15/2006 ecs236 26

The Fidelity Issue

– Would ideally like:– Large and realistic topologies– Diverse, realistic nodes and links.– Realistic active traffic

• But: – Fidelity is expensive– Large-scale fidelity may be unnecessary for

(maybe even contrary to) good science

03/15/2006 ecs236 27

Data Collection

• Classes of data that are interesting, people want collected, and seem reasonable to collect– Netflow

– Packet traces – headers and full packet (context dependent)

– Critical infrastructure – BGP and DNS data

– Topology data

– IDS / firewall logs

– Performance data

– Network management data (i.e., SNMP)

– VoIP (1400 IP-phone network)

– Blackhole Monitor traffic

03/15/2006 ecs236 28

• Limitation of conventional trace replay tools– Not capable of stateful emulation of TCP connections

– Inconsistent data/control packets generation• E.g. generation of ghost packets

– No good for in-line device testing such as NIPS testing

• Live security test environments require– Realistic test traffic and packet contents

– more interactive traffic replay approach

03/15/2006 ecs236 29

• Trace-based traffic replaying– Easy to implement and mimic system behaviors– Real traffic, sufficient diversities– Hard to adjust trace for various test conditions

• Assuming the test condition is the same as the time at the trace was recorded

• Analytic-model based traffic generation– Easy to control/adjust traffic generation models– Statistically identical to traffic models.– Hard to support trace contents for security test

environments

03/15/2006 ecs236 30

Property-Oriented Analysis

03/15/2006 ecs236 31

TCPopera Design Goals

• No ghost packet generation– Stateful TCP connection replaying

• Traffic model support– TCP connection parameters– IP flow parameters, e.g. Dummynet

• Environment transformation– IP Address Remapping– ARP emulation (spoofing)

• Inter-connection dependencies– Flow dependencies over IP, e.g. Stepping Stone Connection– Application-specific inter-connection dependencies

• FTP, HTTP, P2P, etc.

03/15/2006 ecs236 32

TCPtransform High-Level Model

OriginalTCPdump

file

NewTCPdump

file

config

TCPopera

03/15/2006 ecs236 33

TCPopera Phase 1 Requirements

tcp_prof1. Percentage total packet loss.2. Percentage total packet delay 3. Percentage data packet loss.4. Percentage ACK packet loss.5. Percentage data packet delay.6. Percentage ACK packet delay.7. Amount of delay 8. Packet loss occurring on

sending, receiving, or both sending and receiving sides.

9. Packet delay occurring on sending, receiving, or both sending and receiving sides.

198.206.5.211

03/15/2006 ecs236 34

TCPopera Phase 1 Design

• What do I mean by dependency?

Sender Receiver

Time

Data

ACK

Data

ACK

03/15/2006 ecs236 35

TCPopera Phase 1 Design

• Another example

Sender Receiver

Time

Data

ACK

Data

ACK

03/15/2006 ecs236 36

TCPopera Architecture

TraceRecord

s

TraceAnalysis

TCP/IP traffic

Parameters

NetworkConfiguratio

n

FlowThreads

TCP timerThread

PacketInjectionThread

PacketCapturing

Thread

ARPEmulation

IP Flow Preprocessing Interactive Flow Replaying

03/15/2006 ecs236 37

TCPOpera Major Components

• IP Flow Preprocess– Preparing IP flows

– Extraction of TCP connection and IP flow parameters• RTT, transmission rate, packet loss rate, path MTU

– Address remapping, ARP emulation

• IP Flow process– Creating a POSIX thread for each IP flow

– TCP control block emulation

• Traffic Models– TCP parameters for the initiation of TCP control blocks

– Gap-based packet loss model

03/15/2006 ecs236 38

TCPopera Major Components (Cont’d)• TCP Functions

– Based on BSD4.4-Lite release (1994) - TCP Reno– 8 TCP timers – Timeout & Retransmission

• RTT measurement

– Fast Retransmit & Fast Recovery– Flow & Congestion Control

• TCPopera Timer– Slow timer (500ms)– Fast timer (200ms)

• Packet Injection/Packet Capturing– Libnet and Pcap– IP/TCP checksum recalculation if a packet is modified

03/15/2006 ecs236 39

“Config file” Example

SETDROP ALL 192.186.0.2 25

SETDROP DACK 192.186.0.3 25

SETDROP DATA 192.186.0.3 50

SETRETRANSMIT 192.186.0.2 3

SETRETRANSMIT 192.186.0.3 2

SETINITTIMEOUT 192.186.0.2 1.3

03/15/2006 ecs236 40

TCPopera Example

DROPPED10:08:01.644364 nupte.cs.ucdavis.edu.32780 > 192.186.0.3.telnet: P 5:6(1) ack 6 win

5840 <nop,nop,timestamp 69960 240133055> (DF) [tos 0x10]

10:08:01.644474 192.186.0.3.telnet > nupte.cs.ucdavis.edu.32780: P 6:7(1) ack 6 win 5792 <nop,nop,timestamp 240133066 69960> (DF) [tos 0x10]

TCPopera generates:

1st transmission10:08:06.134362 nupte.cs.ucdavis.edu.32780 > 192.186.0.3.telnet: P 5:6(1) ack 6 win


RETRANSMISSION10:08:07.824361 nupte.cs.ucdavis.edu.32780 > 192.186.0.3.telnet: P 5:6(1) ack 6 win


10:08:07.824471 192.186.0.3.telnet > nupte.cs.ucdavis.edu.32780: P 6:7(1) ack 6 win 5792 <nop,nop,timestamp 240133066 69960> (DF) [tos 0x10]

03/15/2006 ecs236 41

# You can specify it explicitly as: #var HOME_NET 20.20.0.0/16# var HOME_NET [10.1.1.0/24,192.168.1.0/24,192.168.1.0/16]

# Set up the external variable to specify this TCPopera node # covers all other hosts other than HOME_NET.

# var EXTERNAL_NET on

# Configure the replay mode.# TCPopera supports three different replay mode.

var REPLAY_MODE INTERACTIVE_REPLAY#var REPLAY_MODE CLIENT_EMULATION#var REPLAY_MODE SERVER_EMULATION

# If the replay_mode is CLIENT_EMULATION, the following # variable stores the server list that the client should be # connected to.# var CE_SERVER_LIST ./ce_server.config

# Configure your defaultrouter in your testbed.

# Trusted Interfacevar DEFAULTROUTER_IPV4 172.16.0.254var DEFAULTROUTER_MAC 00:90:27:32:23:29

# External Interface# var DEFAULTROUTER_IPV4 192.168.0.254# var DEFAULTROUTER_MAC 00:04:5A:72:46:53

# Configure node type for the synchronization # var SYNC_SERVER_FLAG on

# Configure your synchronization server IP address and port# number TCPopera will use this information to synchronize the # replaying information.var SYNC_SERVER_ADDR 30.30.1.100var SYNC_SERVER_PORT 9999

# locations for output filesoutput DEBUG_FILE ../output/opera.debugoutput FLOW_FILE ../output/opera.flowoutput LOG_FILE ../output/opera.logoutput DROP_FILE ../output/opera.dropoutput STAT_FILE ../output/opera.stat

# Include the address remapping file.# This line will read remap file and change the IP addresses in a # trace file to new IP addresses as specified in the remap file.

config remap ./config/remap.config

# If you want to use the general packet loss rate configuration,# uncomment the following variables.# var PL_RATE 0.001# var PLR_INDEX 1.0# var PLR_SCALE 2.0

# Otherwise, include the drop rate file.# config drop_rate ../config_files/drop_rate.config

# Include the TCP/IP parameter configuration file

# Include flow_parameter ./config/flow.config

03/15/2006 ecs236 42



















03/15/2006 ecs236 43



















03/15/2006 ecs236 44



















03/15/2006 ecs236 45

TCPopera Validation

LAN

ExternalTCPopera node

Dummynet

InternalTCPopera node

Snort (stream4)

BSD Firewall (ipfw)

• TCPopera nodes– 2 GHz Intel Pentium 4, 768MB RAM– Internal: Redhat 8 (2.4.18), External: Redhat 9 (2.4.20)

• Network Emulator– 455MHz Pentium II Celeron, 256MB RAM– FreeBSD5.0, IPFW (with Dummynet)

• Snort 2.3– 3.2 GHz Intel Pentium 4 Processor, 512MB– Slackware 10.0 (2.4.26)– All Snort rules are enabled including the Stream4 analysis

03/15/2006 ecs236 46

TCPopera traffic reproduction

Category Input traceTCPopera

No loss 1% loss

IPPackets 1,502,584 1,552,882 1,531,388

Bytes 234,434,486 234,991,187 232,145,926

TCPPackets 1,225,905 1,276,195 1,254,762

Bytes 194,927,209 195,483,762 192,647,088

UDPPackets 276,286 276,294 276,234

Bytes 39,474,602 39,495,286 39,466,797

ICMPPackets 393 393 392

Bytes 32,675 32,139 32,041

TCP connections replayed 18,138 18,138 18,043

TCP connections completed 14,974 14,971 14,796

DARPA IDEVAL99 (first 12 hours of 03/29/99)

03/15/2006 ecs236 47

TCPopera Traffic reproduction

• Traffic volume comparison (every minute)

IP Bytes

TCP Bytes

03/15/2006 ecs236 48

TCPopera Traffic Reproduction

• Inter-connection time

03/15/2006 ecs236 49

TCPopera Traffic Reproduction

C1 C2 C3 C4 C5

C1 (packet drop) C2 C3 C4 C5

time

InputConnections

ReplayedConnections

03/15/2006 ecs236 50

TCPopera validation (Snort Evaluation)

• ITRI Dataset– Collected for 30 minutes from a host within

140.96.114.0/24 segment in Taiwan– Major applications: HTTP, P2P (eDonkey), FTP

Signature

No. of alerts

Input trace

TCPopera

No-loss 1% loss 3% loss

ICMP Destination/Port Unreachable 5 5 5 5

ICMP Destination/Host Unreachable 2 2 2 2

ICMP Destination Unreachable

Fragmentation needed but DF bit is set1 1 1 1

P2P eDonkey Transfer 3 3 3 3

(stream4) Possible retransmission detection 38 212 200 181

(stream4) WINDOW violation detection 488 3 1 4

Total 537 226 212 196

stepping stone tracing and ids evaluation

Documents