2
XBLOG Disitributed 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 defence mechanisms are placed at the perimeter of the network... INTRACLOUD DDOS DETECTION AND MITIGATION USING SDN Konstantin Agouros, Xantaro Solution Architect Xantaro Deutschland +49 (0)40 413498-0 Xantaro UK +44 (0)20 3178 2768 www.xantaro.net HOWEVER THERE IS A SECOND SIDE TO THIS STORY Cloud providers’ infrastructure is often leveraged to stage the attack. (Virtual) machines in cloud data centres 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 defence mechanisms to recognise and/or mitigate are deployed at the perimeter the attack that stays in the cloud is not recognised 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 base-lining to detect “normal” traffic can be used to trigger alarms if a significant deviation is recognised. 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 centre 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 up-loadable shell script is run. 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 recognises when an attack has stopped the mitigation is automatically lifted. THE 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 (e.g. 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. 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. Fig.1 Fig.2 For further information please contact Xantaro’s Solution Architects

INTRACLOUD DDOS DETECTION AND MITIGATION USING SDN … · DDoS Defender product offers a ‘Shell Script’ mitigation method where if a DDoS is detected an up-loadable shell script

  • Upload
    others

  • View
    7

  • Download
    0

Embed Size (px)

Citation preview

Page 1: INTRACLOUD DDOS DETECTION AND MITIGATION USING SDN … · DDoS Defender product offers a ‘Shell Script’ mitigation method where if a DDoS is detected an up-loadable shell script

XBLOGDisitributed 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 defence mechanisms are placed at the perimeter of the network...

INTRACLOUD DDOS DETECTION AND MITIGATION USING SDNKonstantin Agouros, Xantaro Solution Architect

Xantaro Deutschland+49 (0)40 413498-0

Xantaro UK+44 (0)20 3178 2768

www.xantaro.net

HOWEVER THERE IS A SECOND SIDE TO THIS STORYCloud providers’ infrastructure is often leveraged to stage the attack. (Virtual) machines in cloud data centres 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 defence mechanisms to recognise and/or mitigate are deployed at the perimeter the attack that stays in the cloud is not recognised until the service of the victim fails.

NETFLOW FOR DETECTIONModern 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 base-lining to detect “normal” traffic can be used to trigger alarms if a significant deviation is recognised.

GENERAL MITIGATIONThere 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 centre 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 RESCUEFor 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 up-loadable shell script is run. 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 recognises when an attack has stopped the mitigation is automatically lifted.

THE TECHNICAL DETAILSTo 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 (e.g. 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.

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.

Fig.1

Fig.2

For further information please contact Xantaro’s Solution Architects

Page 2: INTRACLOUD DDOS DETECTION AND MITIGATION USING SDN … · DDoS Defender product offers a ‘Shell Script’ mitigation method where if a DDoS is detected an up-loadable shell script

XBLOGA Distributed Denial of Service (DDoS) attack is an attempt to make an online service unavailable by overwhelming it with traffic from multiple sources. Across the globe DDoS attack size, frequency and complexity is on the rise. At the same time, businesses have never been more connected and dependent on the availability of websites and online services. Many customer types are at risk, Governments, Broadcasters, Service Providers & Enterprises. DDoS is a problem that’s getting worse.

INTRACLOUD DDOS DETECTION AND MITIGATION USING SDNKonstantin Agouros, Xantaro Solution Architect

Xantaro Deutschland+49 (0)40 413498-0

Xantaro UK+44 (0)20 3178 2768

www.xantaro.net

Fig.1