Kenichi Kourai (Kyushu Institute of Technology)Takeshi Azumi (Tokyo Institute of Technology)Shigeru Chiba (Tokyo University)

A Self-protection Mechanism against Stepping-stone Attacks for IaaS clouds

Stepping-stone Attacks via IaaS IaaS clouds are emerging

They provide VMs to users Some of the VMs have vulnerabilities

Stepping-stone attacks via VMs are a new threat Outside attackers compromise VMs in IaaS They mount attacks to outside hosts

e.g., portscans and DoS attacks

VM

IaaS cloudattack

attack

Active Response

Self-protection is indispensable for IaaS providers Not only users but also providers are

responsible to attacks against the outside On attack detection, IaaS stops outgoing

attacks at edge firewalls Stopping incoming attacks is ideal but not

always possible Typically, packet filtering based on source IP

addresses is usedVM

IaaS cloud

outgoingattack

edgefirewall

Towards Pinpoint Active Response Active response should stop only outgoing

attacks Usually, only a part of the system is

compromised The other part is protected by process- and

user-based protection IaaS providers can give users the time to fix

problems However, packet filtering based on source

IP addresses blocks all outgoing packets

VMcompromised

apache

postfix

portscan

e-mailedge

firewall 10.0.0.1

deny 10.0.0.1

Filtering at Edge Firewalls

Pinpoint active response is difficult at edge firewalls even if more packet information are used Destination IP address

Too many rules for attacks against many hosts Destination port

Most well-known ports blocked for portscans Source port

Too pinpoint for short-lived connectionsVM

portscanner

edgefirewall

postfixsourcedestination

xFilter

A VMM-level packet filter for pinpoint active response The VMM can intercept all packets from VMs It can obtain sender information inside VMs by

using VM introspection xFilter detects and stops outgoing attacks

with sender informationVM

VMMxFilter

introspection

portscanner

deny packets from

portscanner

VM Introspection [Garfinkel et al. NDSS 2003]

A technique for inspecting data used by OSes in VMs through analysis of the VM's memory based on

internal structures of OSes e.g., using type and symbol information

In principle, the VMM is not aware of the internals of VMs

It simply allocates memory to VMs xFilter finds a sender process that owns

the socket used for sending a target packet

VM

processstruct task_struct { :};

struct inet_sock { :};

type information

introspect sockets?

Automatic Rule Generation

xFilter automatically generates filtering rules when detecting outgoing attacks It adds deny rules with sender's process/user

IDs It merges process-level rules into one user-

level rule Process-level rules are often too pinpoint User-level rules can prevent successive similar

attacks

deny ip * port * vm 1 pid 1234 uid 501deny ip * port * vm 1 pid 1235 uid 501 :

...

pid:1234pid:1235

deny ip * port * vm 1 pid * uid 501

...

uid:501

Challenge

How does xFilter reduce the overhead of VM introspection?

In Xen, domain 0 handlesoutgoing packets Domain 0 is natural for

running packet filters But VM introspection is

too heavyweight

Xen VMM

netfront

netback

VM(Domain U)Domain 0

process

driver

OS

network

filterintrospect

VM Introspection in Domain 0

Domain 0 must map memory pages of a VM to access them by issuing a hypercall to the VMM

It must access page tables as well as kernel objects Virtual-to-physical address translation is

necessary Mapping 4 pages for one translation

task_struct task_struct task_struct task_struct

files_struct

fdtable file socket inet_sock

page tablesDomain 0 VM

System Architecture of xFilter

xFilter performs only VM introspection in the VMM The VMM can access the VM's memory directly

Components Core

Filters packets Inspector

Performs VMintrospection

Detector Detects outgoing

attacks

netfront

netback

VMDomain 0

process

inspector

detector

core

VMM

driver

xFilter

OS

introspect

Optimized Sender Traversal

xFilter examines only sockets owned by processes whose pid/uid match rules Among such sockets, it examines the existence

of a sending socket Naive approach

Finds a sending socket by traversing all Examines rules with the sender's pid/uid

task_struct

inet_sock

pid: 1234uid: 501

deny ... pid 1234 uid 501

daddr: x.x.x.xdport: 80

rule

packet header

daddr: x.x.x.xdport: 80

task_struct task_struct

inet_sock inet_sock

Decision Cache

The decision cache stores the filtering decisions for reuse Packets in the same TCP connection hit xFilter can perform filtering without VM

introspection Cache management

Cache a decision for a SYN packet Remove it in a FIN or RST packet

allow ip x.x.x.x port 80 vm 1 sport 10000

decision cache

packetsSYN

FIN...

xFilter

VM1

x.x.x.x:80

Two-phase Attack Detection

The detector has two phases to reduce overheads under no attack Detection phase

Detects attacks with only packet headers Switches to the inspection phase if detecting an

attack Inspection phase

Identifies attackers with VM introspection Generates a new filtering rule

xFilterattacker

packetsportscan

introspection

VM

Experiments

We conducted experiments to confirm whether only outgoing attacks were stopped how effective our optimizations were

We have developed a portscan detector The detector detects a portscan if packets are

sent to many ports at an excessive rate

CPU: Core i7 860Memory: 8 GB (1 GB for DomU)NIC: Gigabit EthernetVMM: Xen 3.4.2OS: Linux 2.6.18 (PV)

server

CPU: Athlon 64 3500+Memory: 2 GBNIC: Gigabit Ethernet

client

Stopping Portscans

We attempted portscans from a VM to outside hosts Using one or many nmap processes TCP scans against several hosts

xFilter could detect portscans and stop successive portscans It generated filtering rules and merged them

into one We could still establish SSH connections to the

outside

nmap VMssh

SSH

xFilter VMM

deny ... pid 16532 uid 501

deny ... pid * uid 501

Effect of VM Introspection in the VMM We measured the time for inspecting

kernel objects from the VMM small enough more than 3000 times faster than in domain 0

0 200 400 600 800 10000

20

40

60

80

100

# of processes

tim

e (

us)

0 200 400 600 800 10000

20

40

60

80

100

# of sockets

tim

e (

us)31 ns/process 83 ns/socket

Measuring Web Performance

We examined the impact of xFilter to web performance ApacheBench sent requests for 50 KB files to

the Apache web server The baseline is the performance without xFilter

apache

VM

xFilter

VMM

request

responseclient

server

Effect of Optimized Sender Traversal We measured web performance when

xFilter had a rule that never matched 58% improvement in 500 processes

19% degradation from the baseline

0 200 400 600 800 10000

200400600800

10001200

baseline opt no-opt

# of processes

thro

ug

hp

ut

(req

/s)

0 200 400 600 800 10000

1

2

3

4

baseline optno-opt

# of processes

resp

on

se t

ime (

ms)

Effect of the Decision Cache (1/2) We measured web performance for various

numbers of target processes 14% improvement in 500 processes

7% degradation from the baseline

0 200 400 600 800 10000

400

800

1200

baseline w/ cachew/o cache

# of processes

thro

ug

hp

ut

(req

/s)

0 200 400 600 800 10000.0

0.5

1.0

1.5

2.0

baseline w/ cachew/o cache

# of processes

resp

on

se t

ime (

ms)

Effect of the Decision Cache (2/2) We measured web performance for various

numbers of target sockets 63% improvement in 500 sockets

13% degradation from the baseline

0 200 400 600 800 10000

500

1000

1500

baseline w/ cachew/o cache

# of sockets

thro

ug

hp

ut

(req

/s)

0 200 400 600 800 10000

1

2

3

baseline w/ cachew/o cache

# of sockets

resp

on

se t

ime (

ms)

Effect of Two-phase Attack Detection We measured performance degradation

due to attack detection Detection phase: 1% Inspection phase: 16% in 500 sockets

0 200 400 600 800 10000

400

800

1200

baseline detectioninspection

# of sockets

thro

ug

hp

ut

(req

/s)

0 200 400 600 800 10000.0

0.5

1.0

1.5

baseline detectioninspection

# of sockets

resp

on

se t

ime (

ms)

Related Work

VMwall [Srivastava et al. RAID 2008] Similar to xFilter VM introspection is performed in domain 0

Only an optimization similar to our decision cache

Using whitelist-based rules Personal firewalls

Firewalls inside VMs e.g., iptables and ipfw

Supporting packet filtering based on senders Under the control of VM users

Amazon EC2 security groups Inbound firewall probably in domain 0

Conclusion

We proposed xFilter, a self-protection mechanism against stepping-stone attacks in IaaS xFilter stops only outgoing attacks

Using sender information obtained by VM introspection

We made xFilter practical by four optimizations VM introspection in the VMM (3000x) Optimized sender traversal (58%) Decision cache (63%) Two-phase attack detection (15%)

Future work Packet filtering at edge firewalls with VM

introspection in source hosts