If we have some spherical application in vacuum hosted on Microsoft Azure, that we would like to protect against DDoS attack with minimum economic impact and maximum reliability then:
Is it useful to organize reverse proxy like squid or nginx as a
protection level against DDoS?
If true - does it make sense to deploy reverse proxy on Azure or as
dedicated server?
If we deploy proxy on Azure, should/can it be multiinstantinated and if
not, won't it become a bottleneck?
If false - what measures can be appplied to effective respond on
ddos attack real time, except scaling out by throwing more instances
to keep up with traffic surge and relying on Azure's Load Balancer?
The Microsoft Datacenters that host Windows Azure already have protections for items such as DDoS attacks. That said, it is still up to you to monitor your application for unexpected and potentially invalid spikes in traffic and to react accordingly. This can be scaling up your capacity to handle the load using multiple service instances, or by submitted support tickets to have the invalid traffic blocked by MSFT's datacenter protections.
Related
I understand that Azure Web Apps as a PaaS offering are inherently more secure than if hosting on your own VM ... but does that mean a firewall solution is not required at all?
Azure offers a few solutions, but anything acting as a firewall seems expensive - so we are wondering if we can just do without one.
Not required as long as you are secured login for sensitive data and enabled CORN rules. For other protections you can definitely add to your subscription like firewall and DDoS protection.
It is not required; however, depending on the type of application you are building it is greatly encouraged, if not required by specific industries.
Depending on your architecture and/or approach and if cost is a concern I'd recommend Azure FrontDoor w/ Web Application Firewall (WAF) enabled. This will cover additional security for your application at a reasonable cost as well as potentially server as a Traffic/Manager Load balancer.
I am creating a standard multi-tenant site that has the following structure:
example.com
tenant1.example.com
tenant2.example.com
The hosting is Azure web apps. Tenants are generated dynamically (there could be many) and the site includes real-time components, so utilises Azure SignalR. The site will have a wildcard SSL/TLS certificate to enable the subdomain structure.
Rather than going direct to the app service in one region, I'd like to put a load balancer in front of this and route traffic to regional clusters, or maybe even isolated instances for larger clients. It would also be good to have the DDOS protection that comes in-built with these things.
Azure Front Door was my first investigation, this can handle wildcard certificates but doesn't support SignalR.
Application Gateway was my next investigation, this can handle SignalR, but doesn't support wilcard certificates.
In terms of DDOS attacks, it seems we can enable a form of protection directly on the web apps. However, to me, this seems like it would throttle an attack rather than provide (low-cost) protection, as I believe a load balancer would.
How can I load balance this situation please?
I have a Django based web application hosted on Azure provisioned virtual machines (Ubuntu OS). My application recently experienced a DDoS attack and we were helpless against it.
The problem is that once traffic hits the server - even if it's blocked at a firewall or throttled in my webserver - the traffic is already consuming my network bandwidth. I can do nothing about it. This needs to be blocked "upstream", in the routing gear servicing my server.
Is there any DDoS protection Azure can offer me? Or at the very least, make recommendations as to how I might deploy my application so that it's more resistant to these attacks? Please advise.
Current, Azure provides DDOS protection at the network level, but not at the application level. So, if you are receiving a bunch of ACK requests, for example, this should be blocked by the platform itself.
For app level DDOS protection, you need to consider an upstream provider such as Incapsula or Silverline. Integrating them is quite easy. See https://www.incapsula.com/blog/how-to-add-incapsula-to-your-microsoft-azure-instance.html for an example.
Essentially, you will setup Incapsula and configure it with the DNS label of the web app (something.azurewebsites.net). Your DNS (www.domain.com) will then point to the incapsula service and they will handle the rest.
Please note that separating the DDOS from the service still allows for an attack against the service itself (ie: if someone hits something.azurewebsites.net then Incapsula will not protect this traffic).
Hope that helps!
First: Azure allows for IP-whitelisting (or blacklisting), so you can add malicious IP addresses to your block-list on incoming traffic (port 80/443 for instance). And you can modify IP addresses / ranges programmatically. This should prevent traffic from hitting your web app. Note: This is specific to Azure Virtual Machines, which you're using.
Second: Azure provides the Azure Security Center, which is designed to detect such things as DoS attacks, intrusion attacks, etc. Not that it solves your problem, but it can be used for alerting you to issues.
Using incapsula will be the right answer for you , since incapsula hides your origin ip and mitigate the attack before it even reached Azure.
in addition it provides CDN and cache which helped us save on bandwidth costs on AWS and make our application work faster.
I have my website (abc.azurewebsites.net) hosted to Azure Web Apps using Visual Studio.
Now after 1 month I am facing problems with traffic management. My CPU is always 90 - 95% as the number of requests is too high.
Does anyone know how to add Traffic Management in this web app without changing the domain abc.azurewebsites.net? Is it hard coded in my application?
I thought of changing the web app to a Virtual Machine but now as it's already deployed I am scared of domain loss.
When you Scale your Web App you add instances of your current pricing tier and Azure deploys your Web App package to each of them.
There's a Load Balancer over all your instances, so, traffic is automatically load balanced between them. You shouldn't need a Virtual Machine for this and you don't need to configure any extra Traffic Manager.
I can vouch that my company is using Azure Web Apps to manage more than 1000 concurrent users making thousands of requests with just 2-3 instances. It all depends on what your application does and what other resources does it access too, if you implemented or not a caching strategy and what kind of data storage you are using.
High CPU does not always mean high traffic, it's a mix of CPU and Http Queue Length that gives you an idea of how well your instances are handling traffic.
Your solution might implementing a group of things:
Performance tweak your application
Add caching strategies (distributed cache like Azure Redis is a good option)
Increase Web App instances by configuring Auto-Scaling based on HTTP Queue Length / CPU.
You should not have to change your domain to autoscale a Web App, but you may have to change your pricing tier. Scaling to multiple instance is available at Basic pricing tier, and autoscaling starts at Standard tier. Custom domains are allowed at these levels but you don't have to change your domain if you don't want to.
Here is the overview of scaling a web app https://azure.microsoft.com/en-us/documentation/articles/web-sites-scale/
Adding a Virtual Machine (VM) is very costly as compared to adding instance. On top of it, Redundancy (recommended) for the VMs, adding NIC etc will blow up the cost. Maintenance is another challenge. PAAS (webApp etc) is always a better option than IAAS.
Serverless offerings like Azure Functions can also be thought of. They support http trigger and scale up really well.
We integrate with a third-party service where we can run queries which is right now secured using HTTPS encryption and username/password. We send our queries from a service running on the Windows Azure cloud.
The third-party provider wants to migrate towards better security and they have asked us to either
Setup a VPN - which is problematic because for we'd need to use Azure Connect and they'd have to install the client endpoint service on their part.
Provide some IP address where the queries will come from so they can filter out anyone else at the firewall level - which is problematic because AFAIK you cannot fix the IP addresses of the Windows Azure Compute nodes.
Suggest another secure alternative - the only thing I could think of is to set up the VPN with them on a non-Azure server and then tunnel the requests through using Azure Connect - which is obviously extra work for us and also defeats the point of hosting the service on a cloud if it depends on a non-cloud service.
Any ideas?
Can they install the Azure Connect endpoint on another server on their DMZ network? i.e. not the actual server which hosts their service?
Can we somehow provide them with static IPs for incoming queries?
Any other solution that is scalable?
Thanks
If I understand the scenario correctly, your Azure service is a client to a 3rd party service. This scenario may be solved through the use of the Windows Azure AppFabric Service Bus. You would need to install a proxy app in the 3rd party's datacenter that would be responsible for establishing the connection to the service bus. The connection comes from inside the 3rd party's datacenter, so no new incoming holes in the firewall. The connection can handle WCF connections with all its security strengths, and users can be authenticated with ACS.
Here is a starting point: http://msdn.microsoft.com/en-us/library/ee732537.aspx
There is a hands on lab in the Windows Azure Platform Training Kit that explains most of the details that you'll need.
IMHO, HTTPS is already very good; and I don't exactly see how a VPN would make the system any more secure. In particular, VPN is no silver bullet, if your VM is compromised then the VPN connection is compromised too (same for HTTPS). On the other hand, the IP restriction would indeed reduce the attack surface.
Then, using a server outside the cloud is a poor idea indeed. Not only it defeats most of the benefits of the cloud (been there, done that and suffered a lot), but also it also makes the whole thing less secure with more complexity and more attack surface.
Windows Azure does not provide anything that look like a static IP at this point. In our experience, IP addresses for a given service change once in a while even if the service is only upgraded (and never deleted). Static IP addresses have been an important feature request for a long time, Microsoft will probably provide it at some point, but it might still take many months.