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

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 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 IaaS cloud outgoing attack edge firewall

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 VM compromised apache postfix portscan e-mail edge firewall 10.0.0.1 deny 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 portscanner edge firewall 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 sender information inside VMs by using VM introspection xFilter detects and stops outgoing attacks with sender information VM VMM xFilter introspection portscanner deny packets from portscanner

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 process struct task_struct { : }; struct task_struct { : }; struct inet_sock { : }; struct inet_sock { : }; type information 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 pid 1234 uid 501 deny ip * port * vm 1 pid 1235 uid 501 :... pid:1234pid:1235 deny ip * port * vm 1 pid * uid 501... uid:501

9. Challenge How does xFilter reduce the overhead of VM introspection? In Xen, domain 0 handles outgoing 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 filter introspect

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 files_struct fdtablefile socket inet_sock 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 VM introspection Detector Detects outgoing attacks netfrontnetback VMDomain 0 process inspector detectorcore VMM driver xFilter OS introspect

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 task_struct inet_sock pid: 1234 uid: 501 deny... pid 1234 uid 501 daddr: x.x.x.x dport: 80 rule packet header daddr: x.x.x.x dport: 80 task_struct 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 allow ip x.x.x.x port 80 vm 1 sport 10000 decision cache packets SYN FIN... xFilter VM1 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 xFilter attacker packets portscan introspection VM

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 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) server CPU: Athlon 64 3500+ Memory: 2 GB NIC: Gigabit Ethernet client

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 nmap VM ssh SSH xFilter VMM deny... pid 16532 uid 501 deny... pid * uid 501

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/process83 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 apache VM xFilter VMM request response client server

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