SOA Security and Denial of Service Attacks

SOA Security and Denial of Service Attacks

An approach to SOA security must consider one of the most difficult security problems faced by IT, the Denial of Service attack. This section will describe the current state of Denial of Service attack prevention and mitigation, and then outline how to apply this to securing an SOA. It will illustrate how SOA Security needs to encompass Web Services security techniques in addition to the existing security infrastructure of an enterprise to provide a comprehensive solution. An aspect oriented approach to SOA allows independent development of security and Quality of Service (Qos) aspects of an enterprise IT architecture, leaving business process aspects of the architecture to be developed and deployed on an independent basis as long as a simple set of standards are followed across the enterprise.

A Denial of Service (DOS) attack is intended to block the availability of a computing resource from the legitimate users of that resource. Common targets of this type of attack include web servers that have a high profile. The goal of the attack is to make Internet usage of the target web pages impossible. This type of attack is a computer crime and violates the Internet Architecture Board’s Internet proper use policy.

Two types of Denial of Service attack are generally encountered: One type of Denial of Service attack attempts to cause the target system to consume resources at a level that prevents users from accessing the service provided by the system. Another type of Denial of Service attack attempts to prevent communication between the users and the target system. A Denial of Service attack can also be a component of a larger attack strategy.

Examples of Denial of Service attacks include: attempts to prevent access to a system by sending more requests than the system can handle, attempts to prevent access to a system by flooding the network that the system is hosted on, attempts to block access to a service for a particular user and attempts to eliminate service to a specific system.

Denial of Service attacks can be directed at a number of specific devices or networks. Attacks can target routers, web servers, web services, mail servers or Domain Name System (DNS) servers. Three basic kinds of Denial of Service attacks are: causing a system to consume resources, including memory, network bandwidth, CPU time or disk space, disrupting a system’s configuration such as routing information, or disrupting the physical network that a service depends upon.

Symptoms of a Denial of Service attack include the unavailability of either any Web site or a particular Web site, slow network performance, and an increased level of spam E-mails.

The SYN Flood Denial of Service Attack

The SYN Flood attack floods a network with TCP/SYN packets, generally using forged sender addresses. What happens is that when one of these packets is received by the target system, it is handled as a connection request, causing the server to create a half-open connection. The target server sends back a TCP/SYN-ACK packet and waits for the corresponding TCP/ACK packet that would normally come back from the sender address. The resulting half-open connections will each consume an amount of resources on the target server, eventually reaching the server’s capacity for connection requests and preventing new users from successfully accessing the target system.

A TCP/IP connection is the most common Internet connection. The normal sequence of events is that a client system will send a TCP/SYN packet, indicating that the client system would like to connect to the server. The server sends back a TCP/SYN-ACK packet as its response, indicating to the client system that it may connect, and reserves a memory space for the client’s connection. The client then responds with a TCP/ACK packet specifying the details of the connection. In a SYN flood the client’s address is usually forged. The TCP/SYN-ACK response packet from the target server will be sent to a system that did not issue the original TCP/SYN request, and consequently the system whose address was forged will simply ignore the TCP/SYN-ACK packet, or it will go to a non-existent server. The resulting dead connection will consume resources on the target server. If enough of these requests are made for connections that are never completed, legitimate users are blocked from accessing the target system.

Other types of attack include the LAND attack, the ICMP Flood attack, the UDP Flood attack, Teardrop attacks and Application Level Flood attacks.. The LAND attack is a variation on the SYN Flood attack where the forged source address of the TCP/SYN packet is the address of the target system. This results in the target system responding to itself, and can cause the system to crash. The ICMP Flood attack, also called a ping flood, ping of death or smurf attack, is another variation of a flooding Denial of Service attack. This attack takes advantage of a misconfiguration of network devices that can allow packets to be sent to all systems on the network, using the network’s broadcast address. This type of network, when used in this type of attack, is referred to as a smurf amplifier. The attacker sends a large number of IP packets that have the source address of the target system. In order to prevent this type of attack, a Smurf Amplifier Registry is used to filter network traffic. A ping flood attack is accomplished by sending the target system a large number of ping packets. Blocking access to ping to the Internet is generally used to combat this type of attack. In a UDP Flood attack, also referred to as a Fraggle attack, the attacker floods the target system by sending a large amount of UDP echo traffic to IP broadcast addresses, using forged source addresses. It is very similar to the smurf attack.
In a Teardrop attack, an attacker sends IP fragments that have overlapping payloads to the target machine. This takes advantage of a bug in the TCP/IP code that reassembles IP fragements that results in a crash of the target system’s operating system. Versions of Windows up to Windows NT and Linux up to 2.0.32 and 2.1.63 are vulnerable to this type of Denial of Service attack. Application Level Floods take advantage of exploits including buffer overflow to consume resources on the target system, and are normally mitigated in an SOA by the application of WS-Security and OS level security design patterns and security patterns or best practices.

One may legitimately wonder what how SOA is any different than previous architectures in respect to Denial of Service attacks. Existing firewalls and intrusion detection devices are successully being used to block Denial of Service attacks launched from a single attacking system. It is in the realm of Distributed Denial of Service attacks that we will begin to see how an SOA approach can be combined with the approaches being developed to combat Distributed Denial of Service attacks and provide an integrated defense.

Distributed Denial of Service Attacks

A Distributed Denial of Service attack uses a botnet to launch a Denial of Service attack from multiple attack clients. If these attackers are compromised systems themselves, they are referred to as zombies. This type of attack prevents the simple blocking of an attacker’s IP address in the firewall that protects the target system as a solution.

A pulsing zombie attack is a Distributed Denial of Service attack that uses zombies to degrade system performance, on a recurring basis making it difficult to identify the set of source IP addresses that are controlled by the attacker and distinguish them from the IP addresses of legitimate users. If the set of source IP addresses of the attacking systems can be identified then the firwall protecting the target system can be used to block requests from that set of IP addresses.

Mitigation of Distributed Denial of Service Attacks

There are several main approaches to Distributed Denial of Service prevention. They are reactive approaches that operate after clients have attempted to access systems, and proactive approaches, requiring clients to perform actions before connecting to the target system.

Reactive approaches to Distributed Denial of Service include pushback, traceback and filtering.

The pushback approach uses routers to limit the amount of traffic flow from a set of client IP addresses sharing some particular property, such as the subnet address. The filtering is then pushed upstream in the direction of the source of the traffic, eliminating the impact of the traffic on downstream systems. Difficulties of this approach are the problem of identifying attack traffic, cooperation between ISPs and the fact that it requires routers to change state in order to accomplish the pushback of the traffic filtering.

The traceback approach focuses on the identification of the origins of the attack. Variants include traceback based on the Probabilistic Packet Marking Scheme and Hash-Based Traceback. The goal is to differentiate between attack traffic and legitimate traffic by generating attack signatures. This approach will not work if the attack traffic is coming from genuine source addresses or if the attack traffic is statistically similar to legitimate traffic. Traceback approaches also have scalability issues. The Probabilistic Packet Marking Scheme involves the probabilistic marking of each packet with partial path information. If a significant amount of traffic is received from the same source IP the attack target system will be able to reconstruct the path to the source from the collected set of partial path information. Hash-based traceback uses a packet digest store in the form of a Bloom filter at each router. The attack path can then be reconstructed by checking neighboring routers with attack packets.

Filtering approaches include Secure Overlay Services, Distributed Packet Filtering, the Pi Marking Scheme, and the Stateless Internet Flow Filter. Mayday is an approach using the Secure Overlay Services (SOS) architecture to defend against Denial of Service attacks in a proactive manner. Distributed Packet Filtering (DPF) takes advantage of BGP routing information to detect spoofed IP addresses in client traffic. The Pi marking scheme is another approach of detecting spoofed IP addresses. The Stateless Internet Flow Filter (SIFF) approach allows a target system to block traffic flows from specific sources without requiring the network to store per-flow state information, and provides a defense against bandwidth flooding attacks. Both Pi and SIFF require the ability to distinguish between legitimate traffic and attack traffic.

The critical problem facing reactive approaches is the difficult task of differentiating legitimate user traffic from attack traffic. Because of the difficulty of this task, reactive approaches result in non-zero false positive rates, blocking legitimate users from accessing systems, which results in an unintended Denial of Service attack on those users. For many applications this is an unacceptable situation. An SOA approach allows the insertion of gateway services between clients and services that deliberately introduce properties of the underlying IP packets that enable the unequivocal differentiation of legitimate user traffic, without allowing attackers to take advantage of this by intercepting and analyzing a sample of legitimate traffic flow. An attacker following this approach would result in a detectable change in the probability distribution of legitimate user traffic and allow the identification of which subset of identification properties had been compromised. The gateway services could then be dynamically updated with new security policies that would block access from attack traffic. One approach to this would be to distribute to clients a set of message attribute values to select on a random basis for each connection request. If the traffic is all from legitimate users then the message attribute values will arrive in a Poisson probability distribution. If an attacker intercepts one or more clients then the traffic’s distribution will be affected, thereby detecting the attack and triggering secure distribution of a new set of attribute values to the clients.

The Client Puzzle is the main proactive approach to Distributed Denial of Service attack prevention. A Client Puzzle requires the client system to perform an action that consumes a significant amount of client resources, balancing the field between the server’s resources and the resources of client systems that are requesting connections. Client puzzles can require the client system to perform a task, or perform the user to perform an action, such as solving an application-layer graphic Turing test (GTT).

These approaches can be used within the commonly used perimeter defense paradigm as part of the perimeter defense. However, within an SOA, an approach to defend against Distributed Denial of Service attacks is needed at every service gateway device or service in case the perimeter defense is penetrated or the attack is from an insider. An SOA approach using a security infrastructure composed of interoperable security services and devices, including routers and firewalls, could allow this approach to be done at the enterprise level. The advantage to this would mean, if an attacker failed in a Denial of Service attack against one enterprise IT asset, and switched the attack to another asset, the attack against the new asset would be already mitigated.

As traffic levels increase, clients are required to solve more and more difficult puzzles in order to obtain connections, allowing the server to require the clients to consume resources at a great enough level to prevent them from overwhelming the target system.

While Client Puzzles are viewed as a promising technique to prevent Denial of Service attacks that are aimed at consuming resources, the approach must be enhanced to be effective against Denial of Service attacks that employ a flood of messages to make network bandwidth unusable by legitimate users. Mahimkar et. al. present an approach that moves the generation of client puzzles to a distributed puzzle distribution layer. Their approach also uses distributed monitoring to have an enterprise view of the traffic statistics and distributed filtering to filter traffic based on client solutions to the puzzles. It would be natural in an SOA to implement all of these components of the Denial of Service prevention as services themselves managed from a central security administration point.

In an SOA context, service monitoring would allow corrective action if this balance were to become upset. For example, if an attacker launched an attack that depended on the capability of defeating the GTTs being sent the by target system back to the clients, the target system could dynamically start deploying GTTs of a more difficult class that were reserved in advance. The same approach could be used for client puzzles that consume client system resources. An attacker might defeat the existing set of client puzzles by caching the answers or exploiting a weakness. This could be detected by noticing the client returning the correct answer quicker than expected. The gateway security service could dynamically deploy a more difficult class of client puzzles, or begin deploying GTT client puzzles in order to defeat the attack. Afandi et. al. present a policy-based architecture that could be used for dynamic deployment of Client Puzzles and GTTs. Wohlsteder et. al. present an example of a security policy allowing a client to express preferences for using Client Puzzles, authentication, or both in order to access a service.

In the process of analyzing the how the current state of the art in Denial of Service prevention can be applied in an SOA context, an interesting pattern can be seen to be emerging. At the same time that security policies and enforcement is being abstracted away from the applications, the network infrastructure is getting more sophisticated and one can see a merging of intelligent network components and security services into an integrated set of security services in an SOA. The value of an SOA approach in dealing with one of the most difficult security challenges faced today is also becoming clear.