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 attacksVM

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 packetsVM

compromisedapache

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

portscannerdeny 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

VMprocessstruct

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

attacksdeny 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 heavyweightXen VMM

netfront

netback

VM(Domain U)Domain 0

process

driver

OS

network

filter introspect

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: 80rule

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)

serverCPU: 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

outsidenmap 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

20406080

100

# of processes

tim

e (u

s)

0 200 400 600 800 10000

20406080

100

# of sockets

time

(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

apacheVM

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

ughp

ut (r

eq/s

)

0 200 400 600 800 100001234

baseline optno-opt

# of processesresp

onse

tim

e (m

s)

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

ughp

ut (r

eq/s

)

0 200 400 600 800 10000.0 0.5 1.0 1.5 2.0

baseline w/ cachew/o cache

# of processesresp

onse

tim

e (m

s)

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

ughp

ut (r

eq/s

)

0 200 400 600 800 10000

1

2

3

baseline w/ cachew/o cache

# of socketsresp

onse

tim

e (m

s)

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

ughp

ut (r

eq/s

)

0 200 400 600 800 10000.0

0.5

1.0

1.5

baseline detectioninspection

# of socketsresp

onse

tim

e (m

s)

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