Inside Defense

Intracloud

The scenarios described so far always have an outside and an inside; the detection and filtering methods described only work at the external borders of a network. If attackers misuse parts of your own infrastructure, the only way to tell is by examining the outbound traffic; however, not all solutions do this.

Under certain circumstances the situation can be more complex for operators of cloud environments. Many virtual machines (VMs) managed by customers themselves do not always have the latest patches for an infrastructure as a service (IaaS) offering. This makes them vulnerable and potential sources of a DDoS attack (e.g., via NTP reflection attacks).

For DDoS attackers, systems with fast connections in a data center are gems, because, unlike private connections, they are backed by an ADSL line with high bandwidth, meaning you need less compromised systems for an effective attack.

Therefore, attackers will conceivably look for their victims in the same cloud. The attacking machine and the victim's VM might even run on the same host. In this case, although customers can no longer reach the service, none of the external network devices (routers or switches) measure an increase in network load. The anomaly is only noticeable when you look at the virtual infrastructure. So what do you need for security?

Virtual is Better

Fortunately, virtual switches such as Open vSwitch (OvS) [5] in the environment of KVM, Xen, or OpenStack – but also the distributed switches from VMware – give you an option for exporting NetFlow data. If you want an Open vSwitch named testswitch to send flow data to the IP address 10.1.1.1: 3000, you would use the command:

ovs-vsctl -- set Bridge testswitch  netflow=@nf -- --id=@nf create NetFlow targets=\"10.1.1.1:3000\" active-timeout=30

If a framework such as OpenStack is used to manage many VMs on many hosts, this function unfortunately is not integrated, so you would have to enter it manually on the individual compute nodes.

VMware splits the configuration into two parts. In the network settings, the network administrator configures a NetFlow collector for each distributed vSwitch (Figure 2). For each distributed port group, you then decide whether or not you want to send (Figure 3).

Figure 2: VMware's NetFlow settings on the distributed vSwitch.

Figure 3: The port groups are configured separately in VMware.

SDN

In the case of Open vSwitch, the virtual switch will, if necessary, block the attack packets. Open vSwitch supports the OpenFlow protocol (see the "OpenFlow" box), which can drop packets on the basis of certain criteria. At the command line, you can generate filters with the ovs-ofctl tool. The following example drops all packages in the direction of IP address 10.1.1.2 and on the UDP destination port 1234:

ovs-ofctl add-flow testswitch ip,nw_dst=10.1.1.2,udp,udp_dst=1234,actions=drop

As a highlight, if you operate in SDN environments, you do not need to log in individually to each device. Rather, a central point in the network takes over control. The controller manages the flows from a single source and distributes them to all relevant devices, and as the admin, you have more or less a bird's-eye view.