Adaptive Distributed Traffic Control Service for DDoS Attack Mitigation

1. Adaptive Distributed Traffic Control Service for DDoS Attack Mitigation By VIJAY CHAND UYYURU

2. Introduction and Motivation Internet attacks are rising: • Frequency of reported security incidents grows exponentially 1988: 6 incidents  2003: 137‘529 incidents reported by CERT/CC • Organised crime is blackmailing owners of e-commerce web sites („pay or you will go offline“): e.g. casino, ad distribution, sport bet sites • New worms, viruses, trojans, and exploits announced almost daily

3. Introduction and Motivation Why? • More and more computers operated by security unaware users get broadband Internet access • Knowledge and tools for attackers abound • Attackers can use cheap resources (bandwidth, CPU) of thousands of compromised Internet hosts

4. Direct DDoS Attack Attacker Victim V Masters Mi Agents Ai From: Xi (spoofed) To: Master Mi … From: Xi (spoofed) To: Agent Ai … From: Xi (spoofed) To: Victim V … control packet control packet attack packet

5. Reflector DDoS Attack • A new variant of DDoS attacks became known as DDoS “reflector” attack. • This attack form is especially difficult to defense against as the victim is flooded with traffic from ordinary Internet servers that were not even compromised. • Any server that supports a protocol which replies with a packet after it has received a request packet can be misused as a reflector without the need for a server compromise.

6. How DDoS Reflector Attack Works • The agents send their packets with the spoofed address set to the victim’s address to “innocent” servers, which act as reflectors. • The source addresses of the actual attack packets received by the victim are not spoofed. They belong to legitimate uncompromised servers. • Stopping traffic from these sources will also terminate access to Internet services that the victim might reply on.

7. Reflectors Ri Reflector DDoS Attack Note: Reflectors are NOT compromised. They simply answer requests. Attacker Victim V Masters Mi Agents Ai From: Xi (spoofed) To: Master Mi … From: Xi (spoofed) To: Agent Ai … From: Ri To: Victim V … From: V (spoofed) To: Reflector Ri … control packet attack packet control packet attack trigger packet

8. Analysis of Mitigation Mechanisms • There are two basic mitigation mechanisms: • Reactive Mitigation Strategies • Proactive mitigation Strategies

9. Reactive Mitigation Strategies • Reactive schemes often proceed in three phases: • In the first phase, distributed monitoring components try to detect on-going DDoS attacks. • Once an attack is detected, the detector triggers the second phase resulting in the deployment of countermeasures. • In the third phase, when the DDoS attack subsides or stops, countermeasures are relieved or removed.

10. Some Examples of Reactive Strategies • Traceback mechanisms • Internet Indirection Infrastructure • Pushback

11. Traceback mechanisms • Traceback is very valuable in forensics to find the origins and may be the originator of the attack, it deals with neither detecting attacks not deploying any dipositions against ongoing attacks. • Traceback mechanisms play an important role in other reactive mitigation schemes to determine where countermeasures should be deployed and which filtering rules should be applied. • Reactive strategies involving traceback mechanisms, will yield a wrong “attack source”- the reflectors – to be identified and possibly filtered, if DDoS attacks involve reflectors.

12. Internet Indirection Infrastructure(i3) • i3 is implemented as an overlay that is used to route a client’s packets to a trigger and from there to the server. • Due to performance concerns, i3 would only be used if a server were under attack. Otherwise communication could be established directly between the client and server. • To use i3 as a defense mechanisms, IP addresses of the attached servers are assumed to be hidden from the attackers. It remains unclear how server IP addresses can be hidden under attack, when they are known under normal operation.

13. Pushback • Pushback performs monitoring by observing packet drop statistics in individual routers. • Once a link becomes overloaded to a certain degree, the pushback logic, which is co-located with routers, classifies dropped packets according to source addresses. The class of source addresses with the highest dropped packet count is then considered to originate form the attacker. • Filter rules to rate limit packets from the identified source address(es) are automatically installed on the concerned router. Routers on the path towards the source(s) of attack are informed about the detected attacks and install the same rules. In this way, the attack is pushed back and confined. • In many cases, however, an attacked server’s resources are exhausted before its uplink is overloaded.

14. Proactive mitigation Strategies • Proactive strategies intend to reduce the possibility of successful DDoS attacks by taking appropriate provisions prior to attack. Some of the strategies are: • Ingress Filtering • Secure Overlay networks

15. Ingress Filtering • Ingress filtering rejects packets with spoofed source address at the ingress of a network. (e.g. ISP’s backbone) • Attacks involving reflectors with legitimate source addresses, however, are only affected if ingress routing is applied on paths between agents and reflectors. • Performing ingress filtering puts a management burden on ISPs, because they must keep all filtering rules up to date and defective rules will disgruntle their customers.

16. Secure Overlay networks • Secure overlay networks like SOS and Mayday reduce the risk that a DDoS attack severely affects the communication among members of the overlay network to a minimum. • It requires each user of a group wanting to communicate to pre-establish a trust relationship with the other group members. • Keeping malicious users out of an overlay will be a challenge for a large user base.

17. Mitigation Effectiveness • DDoS attacks are so hard to control because of the fact that attack traffic generally contains spoofed source addresses. • In DDoS reflector attacks this is even more complex, because the victim does not receive traffic from the DDoS agents directly, but from legitimate sources without spoofed source addresses. • If source spoofing was impossible, reflector attacks could be prevented. • Also complex traceback mechanisms would not be needed, because the originator could be identified by the source address in those packets.

18. Mitigation Effectiveness • Making source address spoofing impossible requires proactive mechanisms, since measures have to be taken before an attack. • They may be implemented directly in the IP network or as an overlay network. More effective defense strategies are possible within the IP network. • Performing Ingress Filtering, a single router is capable of blocking traffic from a big number of malicious nodes. • ISPs currently lack any incentive to implement proactive mechanisms.

19. Distributed Traffic Control: Concepts and Approach Definition of traffic ownership: A network data packet is „owned“ by the network user who is officially registered to hold either the source or destination IP address or both.  The server operator „owns“ the traffic his server S will finally receive (to: S)  The user of client C „owns“ the traffic sent until it reaches its destination (from : C) Approach:  We extend the network user‘s control over „his traffic“ to the Internet core (and right to the attacker‘s uplink) by a novel distributed Internet traffic control service. to:server S from:client C payload IP packet:

20. Adaptive Device for Traffic Control Idea: Let each IP address owner control his/her Internet traffic Implementation: Adaptive devices to filter/process IP owner’s traffic  Premium service mostly for e-business companies; few packets are rerouted through adaptive device This path only taken by user‘s own packets

21. Deployment of Traffic Control Service ISP … Internet/Backbone Service Provider Incremental deployment:First at border/edge routers of major ISPs, later at most major routers

22. Service Registration

23. Service Deployment

24. Node Architecture

25. Actions for DDoS Attack Mitigation Traffic processing triggered by matching IP packet header fields (source/dest address, ports etc.), payload, timing and link load conditions etc.: • Packet dropping • Payload deletion • Source blacklisting • Traffic rate control • Ingress filtering for owned IP addresses:  Stops DDoS reflector attacks immediately • Reactive and proactive • Filtering close to source of attack traffic • Coordinated Internet wide attack defence IP packet„from: S“  S A Internet   IP packetfrom: S B IP packet„from: S“

26. Ruling Out Misuse of Traffic Control Restrictions on Traffic Control Service prevent misuse: • Traffic Ownership: Acts only on packets owned by network user Others: • Addressing/Routing: No modification of source or destination addresses • Resource Usage: No change of time to live (TTL) • Traffic Amplification: No increase of packet rate and/or size • Traffic Processing: User-defined functionality checked at installation or run time • Prevention of collateral damage • ISPs/BSPs don‘t lose control over their network

27. Other Enabled Traffic Control Services Traceback • Proactively collect packet hashes • Supporting network forensics • Locate origin of spoofed network traffic Automated reaction to traffic anomalies • Suspicious increase in connection attempts from/to server or network • Detection of variations in address and/or port usage and spoofing attempts Network debugging and optimization • Measure link delays, packet loss, quality of service • Optimize content distribution network Network forensics • Traffic sampling at flow-level and/or packet-level for network forensics

28. Conclusions and Outlook • Any chance of success for the Traffic Control Service? • Incrementally deployable • Add-on box • Function may be integrated into future routers • Not necessary to have complete coverage on all routers • Premium (paid) service for large customers (not home users!) • Business incentive for network service providers • Were issue’s of Internet Service Providers respected? • Approach not “scary” for ISPs: Safe, scalable, controllable • Ever changing shape of DDoS attack threat needs adaptive solution • Technology is not disruptive • International patent application filed (PCT/CH2004/000631) • Prototype implementation underway

29. Thank you! Any questions?

30. Apply Data Mining to Defense-in-Depth Network Security System Written by: Huang, Kao, Hun, Jai, Lin Presented by: Terry Griffin

31. Introduction http://www.cert.org/present/cert-overview-trends/

32. Introduction http://www.cert.org/present/cert-overview-trends/

33. Introduction • IDS / IPS • Intrusion Detection / Prevention System • IDS • Packets pass through • Active logging • Signature comparisons • IPS • Alters packet data • Blocks packets (possibly)

34. Introduction • IDS/IPS Types • Misused Detection • Signature based • Identifies patterns of traffic or application data presumed to be malicious • presumed to be able to detect only 'known' attacks • However, sometimes detect new attacks which share characteristics with old attacks, e.g., accessing 'cmd.exe' via a HTTP GET request.

35. Introduction • IDS/IPS Types • Misused Detection • Signature based • Snort currently has 2200+ signatures • Used alone can lead to > false positives

36. Introduction • IDS/IPS Types • Anomaly Detection • notify operators of traffic or application content presumed to be different from 'normal' activity on the network or host • Typically use “self learning” • Require a training phase. • Observes “Normal Flow” • Normal is relative (set by administrator). • Any deviation from normal results in an alert

37. Introduction • This paper attempts to: • Incorporate data mining within an IDS/IPS • Obtain real time Dos Alerts • Decrease number of False Alarms

38. Defense-in-Depth Architecture The Security Architecture is based on 2 concepts / components: • LPS – Local Policy Server • GPS – Global Policy Server

39. Defense-in-Depth Architecture LPS – Local Policy Server • contains a signature database • logs all packets • somewhat of a local IDS/IPS

40. Defense-in-Depth Architecture GPS – Global Policy Server • Receives logs from LPS’s • Monitors/Controls LPS’s • Does the “Real Time” data mining  • Can shut down / throttle the LANs

41. Defense-in-Depth Architecture

42. System Architecture of GPS Consists of 4 components: • Security Information Management (SIM) module • Global Log Server (GLS) • GUI • Global Database

43. System Architecture of GPS • Security Information Management (SIM) module • Does the actual data mining • Details in next section • Global Log Server (GLS) • Manages all logs from the LPS • Must handle multiple parallel incoming connections • Does no mining, just logging

44. System Architecture of GPS • Gui • Well... it’s a GUI • Global Database • Signature database • Created through the logs received from the GLS

45. System Architecture of GPS Sim Module has 4 components • Online Data Miner • classifies records in active database • Rules Tuner • runs the machine learning algorithms • tunes the parameters of rules accordingly • GLS • Policy Dispatcher • Waits for commands from online miner

46. System Architecture of GPS Data mining framework

47. System Implementation and Experiment Results Data flow of online detecting phase is separated into 3 stages: • Loading • all drivers are loaded • classifiers loaded and initialized • Monitoring • endless loop monitoring logged packets for signatures • Event Handling • Alerts LPS’s • Controls / Throttles them if necessary • Author used IDS Snort and IPS NetKeeper as the IDS/IPS backend.

48. System Implementation and Experiment Results Data Collection Results • For 18 days NetKeeper detected 886,764 events. • For 5 days Snort logged 11,070 events This was the data used to test the system.

49. System Implementation and Experiment Results The system was tested with the following 4 combinations of events: • Single type (SYN Flooding, TCP Flooding, UDP Flooding / Smurfing, IP Flooding, ICMP Flooding / Smurfing, IGMP Flooding) • Mix – 2 (TCP-SYN, TCP-IP,TCP-ICMP, TCP-IGMP, TCP-UDP, UDP-IP, UDP-ICMP,UDP-IGMP, IP-SYN, IP-ICMP, IP-IGMP, ICMP-IGMP) • Mix – 3 (TCP-SYN-IP, TCP-SYN-UDP,SYN-UDP-IP, SYN-IP-ICMP, UDP-ICMP-IP) • Mix – 4 (SYN-TCP-ICMP-IP,SYN-TCP-UDP-IP, TCP-UDP-ICMP-IP)

50. System Implementation and Experiment Results Intrusion Detection Results (Detection Rate) 95% detection rate which is “really good” (quote from author)