1 / 24

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

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

lilith
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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)

  2. 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

  3. 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

  4. 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

  5. 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

  6. xFilter • A VMM-level packet filter for pinpoint active response • The VMM can intercept all packets from VMs • It can obtain senderinformation inside VMs by using VM introspection • xFilter detects and stops outgoing attacks with sender information portscanner VM deny packets from portscanner introspection xFilter VMM

  7. 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 structtask_struct { : }; structinet_sock { : }; introspect sockets

  8. 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 pid1234uid 501 deny ip * port * vm 1 pid1235uid 501 : deny ip * port * vm 1 pid*uid 501 ... ... pid:1234 pid:1235 uid:501

  9. Challenge • How does xFilter reduce the overhead of VM introspection? • In Xen, domain 0 handlesoutgoing packets • Domain 0 is natural forrunning packet filters • But VM introspection istoo heavyweight VM (Domain U) Domain 0 process netfront netback driver filter OS introspect Xen VMM network

  10. 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

  11. 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 outgoingattacks Domain 0 VM process driver netback netfront detector core OS introspect inspector VMM xFilter

  12. 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 task_struct pid: 1234 uid: 501 daddr: x.x.x.x dport: 80 rule inet_sock daddr: x.x.x.x dport: 80 deny ... pid1234uid501 inet_sock inet_sock

  13. 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 ipx.x.x.x port 80 vm 1 sport 10000 VM1 ... FIN SYN xFilter x.x.x.x:80

  14. 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

  15. 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

  16. 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

  17. 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 31 ns/process 83 ns/socket

  18. 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

  19. 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

  20. 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

  21. 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

  22. Effect of Two-phase Attack Detection • We measured performance degradation due to attack detection • Detection phase: 1% • Inspection phase: 16% in 500 sockets

  23. 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

  24. 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

More Related