stepping stone tracing and ids evaluation n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Stepping Stone Tracing and IDS Evaluation PowerPoint Presentation
Download Presentation
Stepping Stone Tracing and IDS Evaluation

Loading in 2 Seconds...

play fullscreen
1 / 50

Stepping Stone Tracing and IDS Evaluation - PowerPoint PPT Presentation


  • 145 Views
  • Uploaded on

Stepping Stone Tracing and IDS Evaluation. S. Felix Wu Computer Science Department University of California, Davis. Tracing vs. Anonymity. Packet-Level Layer-3 Tracing iTrace Application-Layer Tracing Botnet Stepping Stone Chains of Evil… (across inter-domain). Attack Chain. LLNL. NYU.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Stepping Stone Tracing and IDS Evaluation' - charis


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
stepping stone tracing and ids evaluation

Stepping Stone Tracing and IDS Evaluation

S. Felix Wu

Computer Science Department

University of California, Davis

tracing vs anonymity
Tracing vs. Anonymity
  • Packet-Level Layer-3 Tracing
    • iTrace
  • Application-Layer Tracing
    • Botnet
    • Stepping Stone
    • Chains of Evil… (across inter-domain)

ecs236

attack chain
Attack Chain

LLNL

NYU

UCDavis

XP

UCSD

Linux

ecs236

simple trusted 3rdpty proxy
Simple Trusted 3rdPty Proxy
  • Secure Relay Service

Proxy

Target

Sender

Encryption

Decryption

Decryption & Mapping

Mapping and Encryption

Receive

Reply

ecs236

slide5
Mix

Mix

Real vs dummy messages!!

ecs236

a network of mixers
A Network of Mixers

target

Mix

Mix

Mix

Mix

Mix

Mix

sender

Mix

Mix

Mix

ecs236

multi layer encryption
Multi-Layer Encryption
  • E(PK[1], Mix2, E(PK[2], Mix3,E(PK[3], Target, Message))).

ENC-PK-Mix1

ENC-PK-Mix2

ENC-PK-Mix3

Mix2,

Mix3,

Target, Message

ecs236

slide8

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.

ecs236

malicious onion bombing
Malicious Onion Bombing

LLNL

NYU

UCDavis

XP

UCSD

Mix, Onion R., Babel, Crowd, LPWA

E.g., Anonymous WEB Access

Linux

ecs236

connection correlation

Linux

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)

???

ecs236

active tracing
Active Tracing
  • Active Tracing
    • changing the “traffic pattern” by selective delaying and dropping
    • detecting “changes” on the other observation point

an incoming

connection

a domain

with stepping

stones.

a set of outgoing

connections

ecs236

dropping for sscp tracing
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

ecs236

artificial traffic
Artificial Traffic

Do we have a packet to send?

Scheduler

a pseudo random traffic generation process

ecs236

limitations
Limitations
  • RAID’2004 Impossibility Results
  • Multiplexing and De-multiplexing

ecs236

suit itrace
SUIT/iTrace

Dynamic

Horizontal

Separation

Anonymous

Communication

IDS

ecs236

tie traceable information exchange

OS Kernel

CPU & Memory

Host-based

TIETraceable Information Exchange

Network

Process

I/O

Process

Process

File Sys.

Information

Router

ecs236

information tracing
Information Tracing
  • Understand how information is being propagated, combined, modified…

Tracing

Without

Modifying

OS kernel or

applications

MINOS

Bochs

ecs236

tie analysis
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?

ecs236

slide20

OS Kernel

CPU & Memory

Information

Router

Network

Process

I/O

Process

Process

File Sys.

MINOS

TIE Analysis

Information visualization interface

ecs236

deter emist
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.

ecs236

experimental evaluation
Experimental Evaluation
  • Simulation/Emulation/Test-bed

ecs236

slide23

Emulab/DETER Experimental Network

Cluster of N nearly identical experimental nodes, interconnected dynamically into arbitrary topologies using VLAN switch.

Pool of N processors

160

PC

PC

PC

Switch Control Interface

N x 4 @1000bT

Data ports

Programmable Patch Panel (VLAN switch)

the fidelity issue
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

ecs236

data collection
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

DHS-Predict

ecs236

slide28
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

ecs236

slide29
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

ecs236

tcpopera design goals
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.

ecs236

tcptransform high level model

config

TCPtransform High-Level Model

New

TCPdump

file

Original

TCPdump

file

TCPopera

ecs236

tcpopera phase 1 requirements
TCPopera Phase 1 Requirements
  • Percentage total packet loss.
  • Percentage total packet delay
  • Percentage data packet loss.
  • Percentage ACK packet loss.
  • Percentage data packet delay.
  • Percentage ACK packet delay.
  • Amount of delay
  • Packet loss occurring on sending, receiving, or both sending and receiving sides.
  • Packet delay occurring on sending, receiving, or both sending and receiving sides.

tcp_prof

198.206.5.211

ecs236

tcpopera phase 1 design

Sender

Receiver

Data

ACK

Data

Time

ACK

TCPopera Phase 1 Design
  • What do I mean by dependency?

ecs236

tcpopera phase 1 design1

Sender

Receiver

Data

ACK

Data

Time

ACK

TCPopera Phase 1 Design
  • Another example

ecs236

tcpopera architecture
TCPopera Architecture

TCP/IP traffic

Parameters

Packet

Injection

Thread

Trace

Records

Trace

Analysis

Flow

Threads

TCP timer

Thread

Packet

Capturing

Thread

Network

Configuration

ARP

Emulation

IP Flow Preprocessing

Interactive Flow Replaying

ecs236

tcpopera major components
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

ecs236

tcpopera major components cont d
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

ecs236

config file example
“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

ecs236

tcpopera example
TCPopera Example

DROPPED

10: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 transmission

10:08:06.134362 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]

RETRANSMISSION

10:08:07.824361 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: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]

ecs236

slide41

# 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 Interface

var DEFAULTROUTER_IPV4 172.16.0.254

var 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.100

var SYNC_SERVER_PORT 9999

# locations for output files

output DEBUG_FILE ../output/opera.debug

output FLOW_FILE ../output/opera.flow

output LOG_FILE ../output/opera.log

output DROP_FILE ../output/opera.drop

output 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

ecs236

slide42

# 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.0.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 Interface

var DEFAULTROUTER_IPV4 172.16.0.254

var 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.100

var SYNC_SERVER_PORT 9999

# locations for output files

output DEBUG_FILE ../output/opera.debug

output FLOW_FILE ../output/opera.flow

output LOG_FILE ../output/opera.log

output DROP_FILE ../output/opera.drop

output 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

ecs236

slide43

# 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 Interface

var DEFAULTROUTER_IPV4 172.16.0.254

var 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.100

var SYNC_SERVER_PORT 9999

# locations for output files

output DEBUG_FILE ../output/opera.debug

output FLOW_FILE ../output/opera.flow

output LOG_FILE ../output/opera.log

output DROP_FILE ../output/opera.drop

output 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

ecs236

slide44

# 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 Interface

var DEFAULTROUTER_IPV4 172.16.0.254

var 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.100

var SYNC_SERVER_PORT 9999

# locations for output files

output DEBUG_FILE ../output/opera.debug

output FLOW_FILE ../output/opera.flow

output LOG_FILE ../output/opera.log

output DROP_FILE ../output/opera.drop

output 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

ecs236

tcpopera validation
TCPopera Validation

Snort (stream4)

Internal

TCPopera node

BSD Firewall (ipfw)

External

TCPopera node

Dummynet

LAN

  • 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

ecs236

tcpopera traffic reproduction
TCPopera traffic reproduction
  • DARPA IDEVAL99 (first 12 hours of 03/29/99)

ecs236

tcpopera traffic reproduction1
TCPopera Traffic reproduction
  • Traffic volume comparison (every minute)

IP Bytes

TCP Bytes

ecs236

tcpopera traffic reproduction3
TCPopera Traffic Reproduction

Input

Connections

C1

C2

C3

C4

C5

time

Replayed

Connections

C1 (packet drop)

C2

C3

C4

C5

ecs236

tcpopera validation snort evaluation
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

ecs236