Active Response Mechanism for IaaS Cloud Security
Stepping-stone attacks in IaaS clouds pose a new threat where attackers compromise vulnerable VMs to launch attacks against external hosts. This research explores the necessity of self-protection mechanisms for IaaS providers, emphasizing active response to detect and stop outgoing attacks at edge firewalls. The proposed xFilter at the VMM level enables pinpoint active response by intercepting all packets from VMs and obtaining sender information to prevent potential threats effectively.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
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 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 attack IaaS cloud 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 used VM outgoing attack edge firewall IaaS cloud
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 deny 10.0.0.1 VM portscan compromised apache e-mail postfix edge firewall 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 connections VM edge firewall portscanner postfix source destination
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 information portscanner VM deny packets from portscanner introspection xFilter VMM
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 type information process sockets ? struct task_struct { : }; struct inet_sock { : }; introspect
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 501 deny ip * port * vm 1 pid 1235 uid 501 : deny ip * port * vm 1 pid * uid 501 ... ... pid:1234 pid:1235 uid:501
Challenge How does xFilter reduce the overhead of VM introspection? VM Domain 0 (Domain U) In Xen, domain 0 handles outgoing packets Domain 0 is natural for running packet filters But VM introspection is too heavyweight process netfront netback driver filter OS introspect Xen VMM network
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 inet_sock socket fdtable file page tables Domain 0 VM
System Architecture of xFilter xFilter performs only VM introspection in the VMM The VMM can access the VM's memory directly Domain 0 VM Components Core Filters packets Inspector Performs VM introspection Detector Detects outgoing attacks process driver netback netfront detector core OS introspect inspector VMM xFilter
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 packet header task_struct task_struct pid: 1234 uid: 501 task_struct daddr: x.x.x.x dport: 80 rule inet_sock daddr: x.x.x.x dport: 80 deny ... pid 1234 uid 501 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 decision cache packets allow ip x.x.x.x port 80 vm 1 sport 10000 VM1 ... FIN SYN xFilter 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 VM packets portscan attacker xFilter introspection
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 server client CPU: Core i7 860 Memory: 8 GB (1 GB for DomU) NIC: Gigabit Ethernet VMM: Xen 3.4.2 OS: Linux 2.6.18 (PV) CPU: Athlon 64 3500+ Memory: 2 GB NIC: Gigabit Ethernet
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 VM nmap ssh deny ... pid 16532 uid 501 SSH deny ... pid * uid 501 VMM xFilter
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 100 100 80 80 31 ns/process 83 ns/socket time (us) time (us) 60 60 40 40 20 20 0 0 0 200 400 600 800 1000 0 500 1000 # of processes # of sockets
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 VM apache request client response xFilter server VMM
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 baseline opt no-opt baseline opt no-opt 1200 4 response time (ms) throughput (req/s) 1000 3 800 600 2 400 1 200 0 0 0 500 1000 0 500 1000 # of processes # of processes
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 baseline w/ cache w/o cache baseline w/ cache w/o cache 1200 2.0 response time (ms) throughput (req/s) 1000 1.5 800 600 1.0 400 0.5 200 0 0.0 0 500 1000 0 500 1000 # of processes # of processes
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 baseline w/ cache w/o cache baseline w/ cache w/o cache 1200 3 response time (ms) throughput (req/s) 1000 2.5 800 2 600 1.5 400 1 200 0.5 0 0 0 200 400 # of sockets 600 800 1000 0 200 400 # of sockets 600 800 1000
Effect of Two-phase Attack Detection We measured performance degradation due to attack detection Detection phase: 1% Inspection phase: 16% in 500 sockets baseline detection inspection baseline detection inspection 1200 1.5 response time (ms) throughput (req/s) 1000 800 1.0 600 400 0.5 200 0 0.0 0 200 400 # of sockets 600 800 1000 0 200 400 # of sockets 600 800 1000
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
