kenichi kourai (kyushu institute of technology) takeshi azumi (tokyo institute of technology)...
TRANSCRIPT
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