By Konstantin Agouros, Solution Architect Security Technologies at Xantaro in Germany.
Distributed Denial of Service (DDoS) attacks are a common threat on the Internet. The main threat for an entity is an attack from the outside. In most cases the attackers flood the victim's network with packets or request that either consume all the available bandwidth or exhaust resources like state tables or memory and CPU.
As a result most detection and defense mechanisms are placed at the perimeter of the network. Figure 1 depicts a typical set up for DDoS defense.
Fig. 1: DDoS Defence common set up.
However there is a second side to this story. Cloud providers' infrastructure is often leveraged to stage the attack. (Virtual) machines in cloud data centers do have a high speed connection to the internet and thus are a perfect attack tool to flood the victim's network. The systems in the cloud that are vulnerable to be used to stage a DDoS attack can also be used to stage an attack in the same cloud with a much higher impact as the connections are running with LAN speed.
As all defense mechanisms to recognize and/or mitigate are deployed at the perimeter the attack that stays in the cloud is not recognized until the service of the victim fails.
Netflow for Detection
Modern cloud infrastructures use virtual switches to connect the VMs to each other and the outside world. VMWare's vSphere infrastructure uses distributed vswitches, OpenStack uses Open vSwitch in its default installation. Both support the NetFlow protocol to send information about flows passing through the virtual switch to a flow receiver. A flow describes one particular connection e.g IP address 1.2.3.4 talking to 2.3.4.5 using tcp with source port 54332 and destination port 80. Also the number of packets and bytes are count. As DDoS attacks usually consist of lots of packets and or bytes, NetFlow data can be used to recognize them. Statistical analysis of this data shows anomalies if a DDoS is staged against or from the cloud. Software like Flowmon's DDoS defender or Arbor's Peakflow SP can be fed with the data and after some baselining to detect "normal" traffic can be used to trigger alarms if a signficant deviation is recognized.
General mitigation
There are various solutions in place to mitigate the attack. As in many cases the victim's uplink is so slow that it easily flooded a method is needed that tells the router on the other side of the slow uplink to divert the attacking traffic. This can happen by null routing (e.g. discard the packets for the destination) or using BGP Flowspec to give firewall like rules to the routers that might even propagate a bit through the provider's network. Another popular way is to route all the traffic for the victim through a so called scrubbing center that intelligently filters the traffic and then sends only clean traffic in the direction of the victim. However for the intra cloud case these methods are not feasible. In some cases the traffic from the attacking to the victim VMs does not even pass a router. If the providers' cloud is used to attack an outside destination the mostly destination based mitigations also don't work.
SDN to the Rescue
For the OpenStack use case Xantaro devised a solution with the support of Flowmon. Flowmon's DDoS Defender product offers a 'Shell Script' mitigation method where if a DDoS is detected an uploaded shell script is triggered. Xantaro combined the detection technology of Flowmon with the industry leading SDN controller OpenDaylight to push a mitigation filter onto the switch(es) that detected the attack. As Flowmon also recognizes when an attack has stopped the mitigation is automatically lifted.
Technical Details
To implement the detection the particular virtual switch where data shall be collected must be configured to use the Flowmon machine as NetFlow collector. This can be achieved with the following command:
ovs-vsctl -- set Bridge flow-bridge netflow=@nf -- --id=@nf
create netflow targets=\"flowmonserver:3000\" active-timeout=10
Next in the DDoS defender application a network segment for the network where the VMs are located must be defined. Also a learning period must be defined and traffic must be collected for the configured time. For real life deployments one or two weeks of collecting data should be used. DDoS defender then allows for a relative deviation of traffic (eg 300% more than normal) to trigger an alert. In the alert definition shell script can be chosen and a script can be uploaded. In the alert definition the admin can define, when the alert triggers. To have sufficient information for the alert to be precise the option 'Run when attack is detected and attack characteristics are collected' needs to be selected. Also the 'Run when attack is ended' needs to be selected so the script is run, when the attack has ended to lift the mitigation. If the script is run it gets a dataset describing the attack. This data contains the destination IPs, ports and protocols. Also source IPs are included. This information can be used by the script to determine a filter for the mitigation. In comes the next player: OpenDayLight. OpenDayLight is the industry leading SDN controller. It uses a REST API on the north bound interface. On the south bound interface a number of protocols are available. Among them are OpenFlow (the de facto standard for SDN control connections) but also routing protocols like BGP. Open vSwitch is one of the most complete OpenFlow implementations available on the market. To glue everything together the script developed by Xantaro takes the information from the DDoS alert, analysis it and uses OpenDayLight's REST API to push a flow onto the virtual switch that blocks the attacking traffic. Figure 2 gives an overview over the architecture.
Fig. 2: Solution architecture.
This method contains the attack as far inside the cloud as possible and prevents the traffic from spreading outside the compute node if the VM is used to attack.
You can’t protect, what you can’t see! Get the insight with Flowmon. Try out the Flowmon Live Demo or download free Flowmon TRIAL and stay in touch for further information on our products!
