Upload
lilith
View
79
Download
0
Tags:
Embed Size (px)
DESCRIPTION
A Self-protection Mechanism against Stepping-stone Attacks for IaaS clouds. Kenichi Kourai (Kyushu Institute of Technology) Takeshi Azumi (Tokyo Institute of Technology) Shigeru Chiba (Tokyo University). Stepping-stone Attacks via IaaS. IaaS clouds are emerging - PowerPoint PPT Presentation
Citation preview
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