Security RRS feed

  • General discussion

  • This discussion is to ask questions and get answer about the various aspects of service and application security.  Here we can discuss aspects not necessarily related to Authentication and Authorization which is covered in the Active Directory / ACS discussion thread.  Feel free to ask your questions, make suggestions and chat in general. Try to keep things in the right topics though so we can keep things in the right train of thought.
    Thursday, February 28, 2013 1:53 AM

All replies

  • Hi Rocky,

    I'd be interested to know what options are available, technical or financial, for mitigating against a DOS or DDOS attack.

    If my website hosted on Azure was hit with a denial of service, how would I keep it online and how would I limit my costs, assuming that data in/out is included in the charges?



    Thursday, February 28, 2013 5:22 AM
  • Hi Darren

    There are a couple things that help prevent D/DOS attacks on cloud hosted sites. But it depends on the type of DOS. Let me quickly recap the types
    Resource Starvation (CPU, Memory, Network, Disk)
    Crashing the application

    When it comes to CPU, Memory, and Crashing, the mitigations are largely up to the designers and developers of the system to prevent. If a bad guy can submit some kind of data to your system such as malformed strings that can cause the application to spike the CPU, overflow memory, or crash it, they have effectively created a denial of service. So these can really only be mitigated by good design, proper input validation, and proper error handling.  It is important to note that with CPU spikes, the cloud provider themselves will limit you to only the CPU you are paying for. This is to prevent one application from disturbing other applications on the same infrastructure.  Along the same lines, if you accept file uploads, and you only have a finite amount of disk space available to you, a bad guy my try to upload 30 copies of War and Peace in double byte character sets, in which case you'll get disk starvation, and the application will likely fail to process other requests in the best case scenario.

    Some things can be put in place to help with this malicious input such as intrusion detection system. Most cloud providers have some level of monitoring on their networks that examine traffic for known attack patterns. They will likely be squelching the common attacks before they even get into the network, however unknown attack strings, or strings customised to crash your application they cannot prevent. After all, they will never know what is legitimate input to your application and what is not.

    As far as network starvation goes, for a genuine cloud provider, this is very difficult to accomplish. Some cloud providers will limit the bandwidth of incoming traffic depending on the type of service you've purchased. In many cases, such as that of Windows Azure, DDOS attacks are handled through a combination of specialised network equipment and massive network pipes. However, each customer is limited to how much incoming traffic they are allowed based on their subscription levels. This is to prevent one application from taking up 90% of the available bandwidth for the rack.  You can get specialised arrangements for high traffic sites but that is on a case by case basis.

    Now, all that being said, the answer is, you can scale up your applications to handle whatever you determine is a peak load, or to the limit of your budget. Beyond that, several built-in mechanisms in Azure will prevent most of the DDOS type attacks. However, specialised DOS attacks aimed at your application to cause CPU, Disk, or Memory starvation (and hence crash the application) it would be impossible for Azure to defend you against because it would require specialised knowledge of your code. To prevent the latter category of attacks, I would recommend implementing a Secure Development Lifecycle, implementing Threat Modelling, Code Review, and Penetration testing to ensure your application is as robust as it can be.

    Hopefully that answered your question. If not, feel free to clarify and I'll try to provide more information.

    Thursday, February 28, 2013 11:40 AM
  • Thanks Rocky, that answers my question.
    Thursday, February 28, 2013 1:24 PM