Towards Defeating the Crossfire Attack using SDN
Dimitrios Gkounis, Vasileios Kotronis, Xenofontas Dimitropoulos
aa r X i v : . [ c s . N I] D ec Towards Defeating the
Crossfire
Attack using SDN
Dimitrios Gkounis
FORTH, Greece [email protected] Vasileios Kotronis
ETH Zurich, Switzerland [email protected] XenofontasDimitropoulos
FORTH, Greece [email protected]
ABSTRACT
In this work, we propose online traffic engineering as a novelapproach to detect and mitigate an emerging class of stealthyDenial of Service (DoS) link-flooding attacks. Our approachexploits the Software Defined Networking (SDN) paradigm,which renders the management of network traffic more flex-ible through centralised flow-level control and monitoring.We implement a full prototype of our solution on an em-ulated SDN environment using OpenFlow to interface withthe network devices. We further discuss useful insights gainedfrom our preliminary experiments as well as a number ofopen research questions which constitute work in progress.
1. INTRODUCTION
Some of the most powerful DoS attacks ever, such asthe attack against Spamhaus which reached 400 Gbit/s [3],have been observed during the last two years. Moreover,new types of DoS link-flooding attacks have been re-cently proposed; these attacks are extremely difficult tomitigate and could potentially take entire countries offthe Internet [8, 11]. The
Crossfire [8] attack in particu-lar: i ) uses legitimate rather than spoofed source IP ad-dresses to send traffic; these addresses are much harderto filter, ii ) sends legitimate packets to publicly accessi-ble servers, and iii ) transmits low-bandwidth flows fromeach bot individually; these “under-the-radar” flows thencumulatively flood certain links in the network.In this work, we introduce a novel approach to de-tect Crossfire bots under adverse DoS conditions. Thekey idea is to repeatedly change how traffic is routedand to monitor sources that persistently react to re-routing for the purpose of attacking a specific target. Ifcertain sources are recorded several times in links thatare DoS’ed they are considered suspicious and are fil-tered. Therefore, our approach effectively increases thecost for executing
Crossfire . Traditionally, traffic engi-neering is used solely for the purpose of load-balancingDoS attacks. We use online traffic engineering bothto detect stealthy bots and to balance the load. Ourapproach benefits from the following SDN principles: i ) centralised visibility and control for fast traffic engi-neering, and ii ) flow-level reactive traffic management.
2. METHODOLOGY
Attacker Model:
The goal of the
Crossfire [8] at-tack is to cut-off Internet connectivity towards a specificgeographic area, the
Target Area . Around the targetarea, there are public servers, the
Decoy Servers , andnetwork links, the
Target Links , which lead to both thetarget area and the decoy servers. The attacker firstconstructs a map of the links (the link-map ) in andaround the target area. Then, he floods certain targetlinks sending traffic only to the decoy servers. This waythe flood cannot be directly observed in the target area,but it still isolates this area from the rest of the network.For this purpose, the attacker finds the target links thatare used most along the bot-to-decoy server and bot-to-target area paths and he coordinates his bots to attackthem. Finally, the attacker monitors the network routesand reacts to changes (which are possible defender’s ac-tions) by setting up the attack again, i.e., updating thelink-map and recalculating the target links.
Defender Model:
The goal of the defender is tokeep the network running without any severe conges-tion and to find and rate-limit malicious traffic sources.Therefore, the defender: i ) monitors traffic load onhis network and detects DoS’ed links that are severelycongested, ii ) balances traffic load by rerouting traf-fic destined to different destinations (including the tar-get area, decoy servers, etc), without knowing the at-tacker’s classification, and iii ) records sources observedin DoS’ed links to detect suspicious recurring sources. Attacker - Defender Interplay:
Malicious
Cross-fire bots will change their decoy server selection in casethe rerouting has diverted their load from the targetedlink(s), as shown in the example of Figure 1. Therefore,the same bots will “return to the crime-scene” and bepresent in another DoS event. The defender records thesources that appear in DoS’ed links. In addition, herecords sources that he re-routes “away” of such linksfor load balancing. Sources that are pushed away, butreturn to future DoS’ed links (by selecting a new de-coy server) are particularly suspicious. Thus after eachattacker-defender interaction, malicious sources becomemore identifiable. Sources that surpass a threshold of1 DoS
Target Link Legitimate trafficRerouted legitimate trafficAttack trafficRerouted attack traffic
Crossfire Attack Defender Rerouting Attacker Reaction
DoS
Decoy ServersTarget Area
Figure 1: Attacker - Defender interplay: 1) Attacker floods target link, 2) Defender reroutes trafficdestined to decoy server 2 to mitigate the attack, 3) Attacker updates selected decoy servers sendingmore traffic to decoy server 1. Traffic sources returning to the target link are deemed suspicious. suspiciousness can be rate-limited. In contrast, benignflash-crowd load does not re-adjust to routing changes,but it uses the same popular destination(s) as before.A key challenge for the defender is that he has noinformation about how the network nodes are mappedto the target area and the decoy servers. Therefore, hecan select different re-routing strategies to optimise thedetection phase: e.g., using random destinations or pre-ferring servers that occupy homogeneous bandwidth onthe congested links. The former strategy is simpler butmight need more rounds to lead to detection. The latterstrategy is a crude way of “approximating” the decoyserver groups, since the attacker generally distributestraffic to those evenly for load-balancing.
Parameter Space:
In our model, the attacker andthe defender are continuously engaged into two co-depe-ndent loops consisting of the following steps: 1) cen-tralised flow monitoring [4]; 2) consolidation of mea-surement data and decision for next action; 3) networkcontrol and bot orchestration. The interactions betweenthe two players determine if and when one of them hasan advantage. Numerous parameters can influence theoutcome, namely: i ) network topology and link capac-ities, ii ) attack flow rate per bot, iii ) bot and flow as-signment strategy for attacker, iv ) link-map and link-bandwidth measurement intervals for both the attackerand the defender, v ) rerouting strategy for the defender, vi ) DoS’ed link detection approach and thresholds, and vii ) suspiciousness threshold for rate-limiting decisions. Proof-of-Concept Implementation:
To better un-derstand the parameter space and the parameterizationtrade-offs, we have implemented a full prototype of theattacker and the defender on the Mininet emulation en-vironment [9]. Emulated bots periodically use tracer-oute towards the target area and the decoy servers tobuild and maintain the link-map. They flood the targetlinks using low-bandwidth HTTP GET requests to thedecoy servers. On the defender’s side, we use the POXOpenFlow controller [2] for prototyping our online traf-fic engineering approach. We also employ OpenFlow [1]capabilities for network monitoring, in order to have a unified management solution. More implementation de-tails of our emulation setup can be found in [7].
Preliminary Results and Insights:
We evaluatethe feasibility of our approach using a custom topologyas described in [7]. Early results show that our SDN-based solution reacts in comparable time scales (someseconds) as the attack setup stage. Since the attackerneeds approx. equal time to identify and react to de-fender’s re-routing and counter-measures, the attack iseffective for ∼
50% of the total time. Moreover, a keyinsight is that links that are DoS’ed in parallel needto be handled in batches to avoid routing oscillationsduring mitigation; this mandates a tunable delay inthe defender’s action loop. We further note that theOpenFlow-based control functions run in sub-secondtimes; monitoring is the dominant time component.
3. SUMMARY AND OPEN QUESTIONS
In this work, we proposed using dynamic traffic en-gineering in a novel way to detect and counter the par-ticularly stealthy
Crossfire attack. In contrast to theCoDef [10] approach which assumes a collaborative en-vironment, we assume a hostile setup. The approachraises a number of research questions: i ) What is thetrade-off between detection accuracy, topology and traf-fic characteristics, and re-routing strategy? How canwe re-route traffic to accelerate detection and minimisefalse positives? ii ) What is the trade-off between rerout-ing costs (including possible instabilities) and DoS costs? iii ) What are the temporal aspects of the attacker anddefender control loops and their dependencies on dif-ferent parameters? iv ) How to extend the mitigationmethodology to the inter-domain level involving sup-port from upstream providers, who run the algorithm“as-a-Service”? v ) How to scale up source recording us-ing bloom filters and/or prefix aggregation? Other fu-ture research topics include understanding the interplaybetween fast rerouting and TCP congestion control [6],as well as the interaction with classic routing policies [5].Lastly, we are interested in the game-theoretic mod-elling of the interaction between the players.2 . REFERENCES [1] OpenFlow Switch Specification. http://archive.openflow.org/documents/openflow-spec-v1.0.0.pdf .[2] POX. .[3] The DDoS That Almost Broke The Internet. http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet .[4] Athreya, A. P., Wang, X., Kim, Y. S., Tian,Y., and Tague, P.
Resistance Is Not Futile:Detecting DDoS Attacks without PacketInspection. In
Information Security Applications .Springer, 2014, pp. 174–188.[5]
Caesar, M., and Rexford, J.
BGP routingpolicies in ISP networks.
Network, IEEE 19 , 6(2005), 5–11.[6]
Gao, R., Blair, D., Dovrolis, C., Morrow,M., and Zegura, E.
Interactions of intelligentroute control with TCP congestion control. In
NETWORKING 2007. Ad Hoc and SensorNetworks, Wireless Networks, Next GenerationInternet . Springer, 2007, pp. 1014–1025. [7]
Gkounis, D.
Cross-domain DoS link-floodingattack detection and mitigation using SDNprinciples. Master’s thesis, ETH Zurich, 2014.[8]
Kang, M. S., Lee, S. B., and Gligor, V. D.
The crossfire attack. In
Security and Privacy(SP), 2013 IEEE Symposium on (2013), IEEE,pp. 127–141.[9]
Lantz, B., Heller, B., and McKeown, N.
Anetwork in a laptop: rapid prototyping forsoftware-defined networks. In
Proceedings of the9th ACM SIGCOMM Workshop on Hot Topics inNetworks (2010), ACM, p. 19.[10]
Lee, S. B., Kang, M. S., and Gligor, V. D.
CoDef: Collaborative Defense Against Large-scaleLink-flooding Attacks. In
Proceedings of the NinthACM Conference on Emerging NetworkingExperiments and Technologies (2013), CoNEXT’13.[11]
Studer, A., and Perrig, A.
The CoremeltAttack. In