DDoS protection in the cloud

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:

OpenFlow

The Open Networking Foundation [6] developed the OpenFlow protocol for controlling traffic flow on network devices. A flow definition instructs a device that supports this standard to run a list of specified actions for certain packages. This works much like firewall rules, but more immediately. Filters sort by IP, IPv6, or MAC addresses; VLAN ID; multiprotocol label-switching (MPLS) and Internet control message protocol (ICMP) fields; or TCP, UDP, and SCTP ports. OpenFlow also supports other Layer 2 protocols.

In the scope of possibilities, OpenFlow drops packets, forwards them to one or more interfaces, sends them to the controller, which then triggers more actions after a deeper analysis, or rewrites values in the packet header. It supports redirection of packages to a different VLAN or the insertion of MPLS labels. In addition to these two options, meters are used to deploy bandwidth controls as actions. You can even reference complete action groups as a single action to avoid having to work through a list of actions each time. More specifically, OpenFlow can replace the destination IP and destination MAC packages within the action group and then forward them through a specific port.

OpenFlow stores flow definitions in a table. Each flow has a specific priority. In addition to the matching filter criteria, it defines when a flow should be used. Newer OpenFlow implementations and versions support multiple tables. A go-to action lets you to jump to the next table to manipulate packages for further processing.

The OpenFlow protocol comes in several editions. The current version is 1.5 (standard). Version 1.3 is still quite common, as is 1.0. They differ mainly in terms of filter support and actions. The support for multiple tables was introduced in version 1.3.

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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs



Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>
	</a>

<hr>		    
			</div>
		    		</div>

		<div class=