Let's shortly remind what is a DoS attack (thanks to wikipedia);

In computing, a denial-of-service (DoS) or distributed denial-of-service (DDoS) attack is an attempt to make a machine or network resource unavailable to its intended users.

A distributed denial-of-service attacks are sent by two or more people, or bots, and denial-of-service attacks are sent by one person or system. As of 2014, the frequency of recognized DDoS attacks had reached an average rate of 28 per hour.1


One common method of attack involves saturating the target mechanism with external communications requests, so much so that it cannot respond to legitimate traffic, or responds so slowly as to be rendered essentially unavailable. Such attacks usually lead to a server overload. 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.

In 2015, we know that large scale attacks involve harmful code delivered to a subhost and then to engage an army of bots (software application that runs automated tasks over the Internet) creating short a multiple of request every second to an IP (business motivation) or a range of IP (political / military motivation).

Provided by courtesy of Cisco
Provided by courtesy of Cisco

So, In general a (Distributed) Denial of Service attack will not provide you with much information directly. However, there are a few scenarios where information could be gleaned as a result of a DoS. The following are a few examples, but this is not at all exhaustive:

  • A load balancer may divulge internal subnet information or leak internal machine names in situations where backing systems are offline.
    This will help attacker to acquire infrastructure implementation by mapping the target network(s) and nodes. This information may certainly be useful to prepare other attack far more elaborated.
  • A DoS that shuts down the database first may cause an application reveal the database engine type, connection username, or internal IP address via an error message.
    As the previous this is clearly a very useful data collecting operation to plan with different techniques and more dangerous weapons the next attack.
  • A poorly implemented API could result in a "fail-open" scenario--DoS'ing a Single Sign On server may give an attacker the ability to log in unauthenticated, or with local credentials.
    DoS will give enough information and will allow to test web-based software, API's, Database scheme, etc. Any breach will be exploited and this one will allow the attacker to get access and control of accounts and believe me they will aim for Admin, Super-User or Supervisors account (and this is why I urge any of my colleague to use non-descriptive username or groupname).
  • In Advanced Persistent Threat scenarios, DoS'ing detection infrastructure may allow an attacker to remain undetected during other information-gathering stages.
  • Similarly, DoS'ing the admin interface of a firewall could hinder network administration's incident response efforts.
  • In an extreme case, DoS against a key-revocation service could allow an attacker to continue to use revoked, or known-compromised credentials.


Clearly DoS can be a simple overloading attack (as explained at first) but it may be used as screen smoke to do and prepare a second phase.
To reduce the risk I implemented a trimester reviewed (and revised) protocol I can resume in simple point:

  1. Decent password, username, groupname and permission scheme
  2. Monitoring and advanced alert tools (notification for control on time basis)
  3. API and Web-based software should be reviewed before being web accessible
  4. Third party component should be known and Security/Patch/Upgrade notification should be received by the IT Admin of the concerned node
  5. Tools/method to control traffic (and stop part of incoming) should be at hand in case of emergency
  6. Use DoS protect server/NOC based like ARBOR Services that will help:
    Based System Out-of-Band that its ability to effectively detect DDoS attacks from many sources, and is not exposed to DDoS attacks her.
    Ability to cope with extremely high traffic volumes.
    Identifying and dealing with a variety of attacks like Bandwidth-consuming attacks, Connection-layer exhaustion attacks and VoIP or DNS attacks that target specific applications.

I forgot the first rule... Know your enemy so keep reading and learn.