Denial of Service: Difference between revisions
No edit summary |
|||
(3 intermediate revisions by the same user not shown) | |||
Line 10: | Line 10: | ||
== DoS on communication links == |
== DoS on communication links == |
||
*flooding with mails (mail bombs, spam) |
*flooding with mails (mail bombs, spam) |
||
*overloading of the internet connection (Attackers have to generate more network packets or distribute them more quickly than the receiver can process. Only destination address and checksum of the packets must be correct. Bundling the bandwidth of many attackers easily overpowers the target’s bandwidth.) |
*overloading of the internet connection (Attackers have to generate more network packets or distribute them more quickly than the receiver can process. Only destination address and checksum of the packets must be correct, in order to not being rejected instantly. Bundling the bandwidth of many attackers easily overpowers the target’s bandwidth.) |
||
== DoS on network layer == |
== DoS on network layer == |
||
Line 17: | Line 16: | ||
*exploit wrong or inefficient implementations |
*exploit wrong or inefficient implementations |
||
*SYN flood attack: According to the three way handshake for establishing a connection, the receiver of the first SYN signal has to send a SYN response, which in turn must be answered by the sender. Thus the connection is established. Attacking systems send the first SYN signal to the target. It adds each connection to its list of half-opened connections and sends a SYN response. Since packets get lost sometimes it will not delete a connection when no response is received after a certain amount of time, but try again to send the second SYN signal. When the table is filled up, no more connections can be allowed. Now regular users of the service won’t be able to access it. |
*SYN flood attack: According to the three way handshake for establishing a connection, the receiver of the first SYN signal has to send a SYN response, which in turn must be answered by the sender. Thus the connection is established. Attacking systems send the first SYN signal to the target. It adds each connection to its list of half-opened connections and sends a SYN response. Since packets get lost sometimes it will not delete a connection when no response is received after a certain amount of time, but try again to send the second SYN signal. When the table is filled up, no more connections can be allowed. Now regular users of the service won’t be able to access it. |
||
[[Image:Smurf_attack_amplifier.png|thumb|right|smurf attack using a router as amplifier]] |
|||
*smurf attack: The ICMP echo request is a transport layer message used for tools like “ping”. Upon receiving an echo request, a client is expected to send an echo response. The attacker sends an ICMP echo request to the router of a network that is misconfigured and routes. The router acts as amplifier for the request. Without it the attacker would have to use much more clients in order to raise an equivalent number of echoes. The router translates the request into a broadcast which is sent to the clients of the network behind the router. Each client now in turn sends an echo response to the target, since the source address was manipulated to hold the target’s address. By doing so either the target or the router itself gets overloaded. |
*smurf attack: The ICMP echo request is a transport layer message used for tools like “ping”. Upon receiving an echo request, a client is expected to send an echo response. The attacker sends an ICMP echo request to the router of a network that is misconfigured and routes. The router acts as amplifier for the request. Without it the attacker would have to use much more clients in order to raise an equivalent number of echoes. The router translates the request into a broadcast which is sent to the clients of the network behind the router. Each client now in turn sends an echo response to the target, since the source address was manipulated to hold the target’s address. By doing so either the target or the router itself gets overloaded. |
||
== DoS on application layer == |
== DoS on application layer == |
||
Line 35: | Line 34: | ||
== Defence and counter measures == |
== Defence and counter measures == |
||
Since DoS attacks aim on overusing a service, there is no perfect solution. Doing nothing will let the attack block the regular clients from using the service. Blocking the access, so as to block the attack, will also deny the service to the clients. |
Since DoS attacks aim on overusing a service, there is '''no perfect solution'''. Doing nothing will let the attack block the regular clients from using the service. Blocking the access, so as to block the attack, will also deny the service to the clients. |
||
Though there are some other measures against DoS attacks, most of them try to just block some addresses or even specific address spaces. By doing so the attacked service restricts itself partially to the public, acting for the intention of the attacker. |
Though there are some other measures against DoS attacks, most of them try to just block some addresses or even specific address spaces. By doing so the attacked service restricts itself partially to the public, acting for the intention of the attacker. |
||
Usually when being attacked using DoS, one might want to observe all inbound packets and try to find some characteristics. Then all packets that match those characteristics should be discarded completely. This results maybe in rejecting some regular users, but can keep the system "alive" and thus accessible to most regular users. |
Usually when being attacked using DoS, one might want to '''observe all inbound packets''' and try to find some characteristics. Then all packets that match those characteristics should be discarded completely. This results maybe in rejecting some regular users, but can keep the system "alive" and thus accessible to most regular users. |
||
Characteristics might be a special range from where the packets originate, a special TCP sequence number, or even some characteristics that are immanent in normal packets but absent in random packets. |
|||
Characteristics might be a special ... |
|||
⚫ | |||
Some sources also consider the following measures: |
|||
⚫ | |||
*Trying to track the source of the attack down and block it directly. But that greatly depends on ISP cooperation on international basis, on the possibility of tracing back the connections, and so on. |
|||
*Increase memory and network capacity, which is expensive. Supply of more capacity also needs time which is often rare. |
|||
*Create a list of regular users that frequentially visit the service. When having a DoS attack deny all IPs/users that are not listed. |
|||
*Filter unused address spaces (as listed in BGP4 routing tables), because sometimes faked packets show an IP from that space. |
|||
Regarding these actions a arms race seems inevitable. |
|||
But even in a perfect scenario, where no server has errors, all systems are safe and every user authenticated, there still will be DoS attacks, because '''a service being accessible to the public, also can be abused by the public'''. |
But even in a perfect scenario, where no server has errors, all systems are safe and every user authenticated, there still will be DoS attacks, because '''a service being accessible to the public, also can be abused by the public'''. |
Latest revision as of 19:29, 14 November 2004
A Denial of Service attack (abbr. DoS) tries to block or restrict a certain resource or service (typically available on the internet). This aim can be achieved by various means.
- overloading of the internet connection
- using up resources needed for the service (e.g. memory, CPU capacity, …)
- destruction of files essential to the service
- shutdown of system processes
- any other action leading to the restriction of the service
Those services aimed at, are typically available on the internet. But from the general meaning of "denial of service", also blocking any services that are available to the public (e.g. a computer in a library) can be titled "Denial of Service".
DoS on communication links
- flooding with mails (mail bombs, spam)
- overloading of the internet connection (Attackers have to generate more network packets or distribute them more quickly than the receiver can process. Only destination address and checksum of the packets must be correct, in order to not being rejected instantly. Bundling the bandwidth of many attackers easily overpowers the target’s bandwidth.)
DoS on network layer
- exploit wrong or inefficient implementations
- SYN flood attack: According to the three way handshake for establishing a connection, the receiver of the first SYN signal has to send a SYN response, which in turn must be answered by the sender. Thus the connection is established. Attacking systems send the first SYN signal to the target. It adds each connection to its list of half-opened connections and sends a SYN response. Since packets get lost sometimes it will not delete a connection when no response is received after a certain amount of time, but try again to send the second SYN signal. When the table is filled up, no more connections can be allowed. Now regular users of the service won’t be able to access it.
- smurf attack: The ICMP echo request is a transport layer message used for tools like “ping”. Upon receiving an echo request, a client is expected to send an echo response. The attacker sends an ICMP echo request to the router of a network that is misconfigured and routes. The router acts as amplifier for the request. Without it the attacker would have to use much more clients in order to raise an equivalent number of echoes. The router translates the request into a broadcast which is sent to the clients of the network behind the router. Each client now in turn sends an echo response to the target, since the source address was manipulated to hold the target’s address. By doing so either the target or the router itself gets overloaded.
DoS on application layer
- Flood process table or overload CPU and other resources.
- Spam via mail.
DoS through other actions
- fork bomb: Fills process table, but requires possibility of executing code (main(){ for(;;)fork();}).
- consume memory resources: Mass mailers, spam or even worms like “Love Letter”. Everytime a Visual Basic script gets shown or opened it replicates and sends itself to every addressee in the global address book.
- delete files: Delete those files needed by services in order to restrict them. The “Love Bug” worm deleted all .bat, .com, .exe, .dll and .sys files on windows systems.
- shutdown system
- fear: When the “I Love You” virus raged through the net, some companies cut their networks deliberately from the internet, so as to not being infected. Of course they weren’t accessible to the public, resulting in a denial of their services.
Defence and counter measures
Since DoS attacks aim on overusing a service, there is no perfect solution. Doing nothing will let the attack block the regular clients from using the service. Blocking the access, so as to block the attack, will also deny the service to the clients. Though there are some other measures against DoS attacks, most of them try to just block some addresses or even specific address spaces. By doing so the attacked service restricts itself partially to the public, acting for the intention of the attacker.
Usually when being attacked using DoS, one might want to observe all inbound packets and try to find some characteristics. Then all packets that match those characteristics should be discarded completely. This results maybe in rejecting some regular users, but can keep the system "alive" and thus accessible to most regular users. Characteristics might be a special range from where the packets originate, a special TCP sequence number, or even some characteristics that are immanent in normal packets but absent in random packets.
Attacked companies with no interest in outside users having access to their network services may consider completely changing the current IP number without updating of common DNS servers for the time being.
Some sources also consider the following measures:
- Trying to track the source of the attack down and block it directly. But that greatly depends on ISP cooperation on international basis, on the possibility of tracing back the connections, and so on.
- Increase memory and network capacity, which is expensive. Supply of more capacity also needs time which is often rare.
- Create a list of regular users that frequentially visit the service. When having a DoS attack deny all IPs/users that are not listed.
- Filter unused address spaces (as listed in BGP4 routing tables), because sometimes faked packets show an IP from that space.
Regarding these actions a arms race seems inevitable. But even in a perfect scenario, where no server has errors, all systems are safe and every user authenticated, there still will be DoS attacks, because a service being accessible to the public, also can be abused by the public.