Automated Attack Mitigation Frameworks

The “Event Monitoring Enabling Responses to Anomalous Live Disturbances” (EMERALD) project dates back to 1997 [110, 111]. It consists of a distributed intrusion detection and response system. The goal of EMERALD was the surveillance of larger networks, such as enterprise networks, the detection and tracking of malicious and anomalous activity, and the triggering of appropriate countermeasures. The main component of EMERALD is a modular service monitor. Each monitor is responsible for the surveillance of a small part of the protected systems, networks and services. This approach reduces the amount of information a single monitor has to process as well as the complexity of the processing itself since the monitor applies only those detection methods appropriate for the monitored target. The collected information from the monitors is merged into a target-specific event stream that is analysed using both signature-based and anomaly detection methods in signature engines and profiler engines respectively. Signature engines and profiler engines report the analysis results to the resolver. The resolver decides on countermeasures according to the response policy. Therefore, it may correlate the local results with additional results received from other EMERALD monitors. Furthermore the resolver can disseminate local results to other monitors. The exchange of

2. DDOS ATTACKS AND DEFENCES

analysis results between monitors is based on a subscription-based communication scheme: A monitor that wants to receive results from another monitor subscribes to the other monitor as a client to a server. Thereby, the client may specify the information it is interested in. EMERALD is not open- source and not adapted for the detection and mitigation of DDoS attacks (since the first DDoS attacks occurred only a few years after). However, the general architecture and concept of distributed monitors and subscription-based result dissemination is suitable for future DDoS detection systems.

COSSACK is a distributed intrusion detection and response system [112]. It consists of several subsystems, called watchdogs, which are located at the edge networks of the Internet. The watchdogs near the victim detect that an attack is in progress by observing a preponderance of attack traffic towards the target. The intrusion detection system is then instructed by the watchdogs to compile source address information and attack signature data. The attack notification is then multicasted to other watchdogs in the network indicating the attack source addresses. In order to be efficient, COSSACK watchdogs have to be widely deployed at many edge networks of the Internet. In addition, based on the detection of the preponderance of traffic to indicate an attack, only flooding attacks can be detected. COSSACK also disseminates the source addresses of the attack packets within the attack notification and rely on the fact that the source addresses are not spoofed. If the addresses are spoofed and filtering is used as a response to drop packets based on these source addresses, self DoS may be inflicted.

DiDDeM is a distributed DoS detection and traceback system [113]. The goal of the system is to provide early detection and response to DDoS attacks. The system integrates a set of cooperative domains. Each domain comprises a single command and control (C2_{) server and a set of}

prefilters/traffic monitors. The C2 server manages the prefilters and responds to the attacks detected and reported by the prefilters. The occurrence of an attack is detected using congestion detection algorithms. Once the attack is detected, a sample of the attack packets (part of a large flow of traffic toward the same destination) is analysed to derive the attack packets’ signature. The information of the attack can then be propagated towards the source of the attack through communications between the C2 _{servers and further detection by prefilters in the adjacent domains detecting matches of packets with}

the attack signature, thus achieving traceback. Packets matching the attack signature can then be blocked nearer to the sources to stop the attack. However, DiDDeM requires wide spread deployment in the Internet to be effective. In addition, it assumes that the attack packets contain matching characteristics and are distinguishable from legitimate packets. If the attacker launches an attack with

2.2 DDoS Defences

attack packets having different contents or with seemingly legitimate traffic, it would be very difficult for an attack signature to be derived.

SNORT is an open source network intrusion prevention and detection system [114]. It is a knowledge-based system which relies on previously defined rule sets. SNORT consists of five main base components, which are the sniffer, the packet decode engine, the pre-processor, the detection engine and the output engine. The sniffer is responsible for the packet capturing from the network interface. It makes use of the libpcap library. The packet decode engine fills in the internal data structures by decoding the sniffed packets. The pre-processor handles the packet data after the packets are classified and decoded. Packets are passed to pre-processor plugins to perform further processing if they match certain criteria set out by the plugins (for example, portscan plugins). These pre- processor plugins are able to outperform simple rule or signature-based detection by running arbitrary complex checks on the packets to reassemble fragmented packets, detect portscans, etc. After the pre- processor plugins have handled the packets, they are passed on to the detection engine. The detection engine dispatches the work to detection plugins that can inspect both the packet header and payload for suspicious signatures. More complex operations needed for signature-based detection, such as regular expression matching, are performed here. The output engine provides several output plugins for different logging mechanisms for writing alerts and logs. For example, there are plugins for storing logs in a database or alerting an administrator through a syslog entry. SNORT’s detection primarily relies on attack packets matching known signatures within its database. Therefore, an outdated signature database would affect the reliability of the entire system. However, SNORT does have an important plugin which supports DDOS attack detection. This is the SPADE (Statistical Packet Anomaly Detection Engine) module which provides anomaly detection for SNORT. For example, if the network is running a web server, the normal traffic will be from a large range of external IP addresses to a single address on TCP port 80. If an internal DNS server is running, the expected traffic will be to and from port 53 UDP and TCP from machines within the same network. The SPADE module profiles normal traffic by maintaining probability tables that contain information regarding the number of occurrences of different kinds of packets over time on the network (for example, probability of a packet to the DNS server on port 53 is 10%, whereas probability of a packet to the DNS server on port 80 is 0.1%). However, this method only detects attack traffic targeting ports that are not running particular services. For flooding attacks with seemingly legitimate packets targeting open ports, the detection would not work.

2. DDOS ATTACKS AND DEFENCES

Prelude is a hybrid intrusion detection system [115-117]. It enables all available security applications, be they open-source or proprietary, to report to a centralized system. Prelude IDS consists of three functional components: sensors, managers, and countermeasure agents. Both network-based and host-based sensors are supported. They report security relevant information and intrusion detection alerts to the managers. Prelude is a centralized system with one Prelude manager at the top of a hierarchy of lower level managers. Managers at lower levels primarily act as relays that aggregate the information received from associated sensors and forward it to the top-level manager. Countermeasure agents are used to enforce active responses. In the architecture, countermeasure agents are controlled by direct communication between sensors and agents. Prelude uses the Intrusion Detection Message Exchange Format (IDMEF) for the exchange and storage of intrusion detection information [118]. A Prelude manager receives IDMEF messages from the associated sensors and processes them for further reporting, logging, and output purposes. However, Prelude relies on knowledge-based detection only, that is, it does not make use of anomaly detection methods. The development of active response mechanisms in Prelude only concentrates on blocking attack flows by dynamically updating firewall rules [119]. Another envisaged method is the rerouting of malicious traffic.