Page 1 of 5 1. Introduction The present document explains about common attack scenarios to computer networks and describes with some examples the following features of the MilsGates: Protection against Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks, Intrusion Prevention System (IPS). 2. DoS/DDoS 2.1 What is DoS/DDoS? Source: Wikipedia, http://en.wikipedia.org/wiki/denial-of-service_attack A denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is an attempt to make a computer resource unavailable to its intended users. Although the means to carry out, motives for, and targets of a DoS attack may vary, it generally consists of the concerted efforts of a person or people to prevent an Internet site or service from functioning efficiently or at all, temporarily or indefinitely. Perpetrators of DoS attacks typically target sites or services hosted on high-profile web servers such as banks, credit card payment gateways, and even root name servers. The term is generally used with regards to computer networks, but is not limited to this field, for example, it is also used in reference to CPU resource management. One common method of attack involves saturating the target (victim) machine with external communications requests, such that it cannot respond to legitimate traffic, or responds so slowly as to be rendered effectively unavailable. In general terms, DoS attacks are implemented by either forcing the targeted computer(s) to reset, or consuming its resources so that it can no longer provide its intended service or obstructing the communication media between the intended users and the victim so that they can no longer communicate adequately. Denial-of-service attacks are considered violations of the IAB's Internet proper use policy, and also violate the acceptable use policies of virtually all Internet service providers. They also commonly constitute violations of the laws of individual nations. 2.2 What is SYN Flooding? A SYN flood is a form of denial-of-service attack in which an attacker sends a succession of SYN requests to a target's system. When a client attempts to start a TCP connection to a server, the client and server exchange a series of messages which normally runs like this:
Page 2 of 5 1. The client requests a connection by sending a SYN (synchronize) message to the server. 2. The server acknowledges this request by sending SYN-ACK back to the client. 3. The client responds with an ACK, and the connection is established. This is called the TCP three-way handshake, and is the foundation for every connection established using the TCP protocol. The SYN flood is a well known type of attack and is generally not effective against modern networks. It works if a server allocates resources after receiving a SYN, but before it has received the ACK. There are two methods, but both involve the server not receiving the ACK. A malicious client can skip sending this last ACK message. Or by spoofing the source IP address in the SYN, it makes the server send the SYN-ACK to the falsified IP address, and thus never receive the ACK. In both cases the server will wait for the acknowledgement for some time, as simple network congestion could also be the cause of the missing ACK. If these half-open connections bind resources on the server, it may be possible to take up all these resources by flooding the server with SYN messages. Once all resources set aside for half-open connections are reserved, no new connections (legitimate or not) can be made, resulting in denial of service. Some systems may malfunction badly or even crash if other operating system functions are starved of resources this way. 2.3 MilsGate DoS/DDoS Protection The MilsGate firewall successfully protects against DoS or DDoS attacks. Below, some examples of the protection mechanisms are given. Accept Policy The MilsGate firewall offers a choice of two different accept policies on a per rule basis which are intended to offer varying levels of protection against TCP SYN flooding attacks. Only upon successful establishment the TCP session is governed directly by the two communicating network entities. Outbound Accept Policy TCP session requests (SYN packets) are immediately forwarded to the target address if the session is allowed by the rule set. The TCP handshake occurs between source and destination. The main characteristic of the outbound policy is that the client will only receive an ACK when the requested server is really up. This is important for many applications such as a browser when it tries to connect to a server with many IP addresses for the same hostname (DNS round robin). The browser tries to connect to the first IP it gets from the DNS server, and, if it is not successful, it tries the next one and so on. Hence, it would be fatal if the firewall sent an ACK to the client even if the server was not reachable because then the browser would never get the chance to try any further IP. If a certain amount of not confirmed SYN requests within a certain period of time are received, the firewall temporarily switches to the Inbound mode (see below). As soon as the connection shows normal behavior again, the firewall switches back to Outbound mode. Inbound Accept Policy TCP session requests (SYN packets) are NOT immediately forwarded to the target address even if the session is allowed by the rule set. The firewall rather establishes a complete TCP
Page 3 of 5 handshake with the requesting source first, assuring that the requestor is authentic (no IP spoofing) and really intends to establish a TCP session. Only after a complete TCP handshake is established, the handshake with the target is caught up and traffic will be forwarded to the target address. Resource Protection Additionally, as safeguard against DoS/DDoS attacks from the internet for instance, the MilsGate allows configuration of two resource limits on a per rule basis to protect against resource exhaustion of the MilsGate (Max. Number of Sessions/Max. Number of Sessions per Source): 3. IPS 3.1 What is IPS? Source: Wikipedia, http://en.wikipedia.org/wiki/intrusion_prevention_system Intrusion Prevention Systems (IPS), also known as Intrusion Detection and Prevention Systems (IDPS), are network security appliances that monitor network and/or system activities for malicious activity. The main functions of Intrusion Prevention Systems are to identify malicious activity, log information about said activity, attempt to block/stop activity, and report activity. Intrusion prevention systems are considered extensions of intrusion detection systems because they both monitor network traffic and/or system activities for malicious activity. The main differences are, unlike intrusion detection systems, intrusion prevention systems are placed inline and are able to actively prevent/block intrusions that are detected. More specifically, IPS can take such actions as sending an alarm, dropping the malicious packets, resetting the connection and/or blocking the traffic from the offending IP address. An IPS can also correct CRC, defragment packet streams, prevent TCP sequencing issues, and clean up unwanted transport and network layer options. 3.2 What are Attack Patterns? Source: Wikipedia, http://en.wikipedia.org/wiki/attack_patterns In computer science, attack patterns are a group of rigorous methods for finding bugs or errors in code related to computer security.
Page 4 of 5 Attack patterns are often used for testing purposes and are very important for ensuring that potential vulnerabilities are prevented. The attack patterns themselves can be used to highlight areas which need to be considered for security hardening in a software application. They also provide, either physically or in reference, the common solution pattern for preventing the attack. Such a practice can be termed defensive coding patterns. Attack patterns define a series of repeatable steps that can be applied to simulate an attack against the security of a system. 3.3 MilsGate Intrusion Prevention System The MilsGate firewall permanently analyses the data stream by applying deep packet inspection allowing the system to reliably distinguish between legitimate and illegitimate traffic. Below, some examples of the MilsGate IPS are given. Content Filter The content filter is used for blocking Internet worms and exploit attacks. A set of predefined filters, which can be referenced by the firewall rule set, is provided with the MilsGate. The possibility of defining custom filters enables the administrator to react to new threats. The MilsGate content filter can detect network based attacks, and protects the network by terminating the offending IP connection. All type of network connections (for example HTTP, SMTP ) that are defined in the referenced service object, are checked for the configured patterns of the content filter to detect attacks. The list of patterns is kept up-to-date by means of software update packages.
Page 5 of 5 Port Protocol Protection Port Protocol Protection addresses a general problem in stateful packet inspection firewall configurations. A firewall rule basically defines a policy for source/destination networks/hosts, the allowed service and the corresponding port. This policy can in general not guarantee that the desired protocol is actually operating on the correct port number. For example, a firewall rule that allows passing of SSH traffic on port 22 can be misused to forward SMTP traffic over port 22. The MilsGate Port Protocol Protection feature makes use of deep packet inspection mechanisms to prohibit the above mentioned issues. This example shows the definition of a Port Protocol Protection Policy for the service SSH to avoid unwanted traffic forwarded by the according firewall rule: Rule Mismatch Policy Usually, a connection request matches a rule as soon as source, service, and destination match. Situations exist in which you might want to ascertain that no rule allows bypassing a configured rule set. Example: Two machines in your LAN have access to a database server on a critical port (for example telnet). You want to make sure that no other rule accidentally allows access for another source than the configured two clients. In this case, select Block on (Source) Mismatch in the Rule Mismatch Policy section of the Advanced Rule Parameters window: