So I have my website set up, call it www.mywebsite.com. I have my Traffic Manager set up so that www.mywebsite.com points to mytrafficmanager.trafficmanager.com.
The Traffic Manager then points to my two on-premise web front-ends web1.mywebsite.com and web2.mywebsite.com. It also has an endpoint of a Azure Web App.
It is set up to do a Priority fail over: web1, then if that fails to web2, and if they are both down, to fail over to the Azure Web App.
My question is this: If I get a DDoS attack on www.mywebsite.com, what would happen? Would the on-premise servers go down, and then it would fail over to the Azure Web App (which is set up to scale appropriately to hopefully mitigate a DDoS attack). Or would it not be able to route the traffic properly?
See MSDN forum topic for answer: https://social.msdn.microsoft.com/Forums/en-US/92733178-f305-4994-b954-67da945f40a7/azure-traffic-manager-and-ddos-attacks?forum=WAVirtualMachinesVirtualNetwork
Related
I basically have an API that is going to be used with a web app and a mobile app. I don't want the API to publically available, where should I deploy it then? is there a way without using AWS? Thanks, Nav :)
There are multiple ways of doing this. This is a sensitive topic, as this is an opinion-based field.
However, I will try to answer below - and challange your way of approaching this.
It really depends on your 'operational' skills, funds, need for security, deadline(s) etc.
Basically you need to make an endpoint available on the www, without everybody being able to connect.
You could either:
Deploy a virtual machine or web app. in Azure/AWS/GCP/... and whitelist the IP's you need to connect from.
Rent a VPS from any provider, and deploy your application here - Again, whitelisting. (Edit: Not phones, since this IP changes constantly. A proxy can be implemented here (potential bottleneck), or any authentication mechanism like OAuth, JWT, Certificates etc. can be implemented either on the ingress controller (e.g. NGINX) or the application itself.)
Deploy the application on your Home-PC, order a static IP to your home and make a forwarded port and set up security on your premise (not recommended, and raises and bunch of other headaches)
Get in touch with a company that hosts web applications (Can be quite expensive)
Based on the limited information provided in your question, there is a ton of options, nice-2-haves and factors that comes in to play when choosing the setup that suits your needs.
You should also consider; VPN usage, Backup/disaster recovery, data leaks, redundancy, the need for future deploys, how you would access your environment in six months....
I hope this answered your question, but also raised a few for you to answer yourself.
Finally, I'd recommend you looking for inspiration here.
EDIT:
Question:
Whitelisting mobile IP's.
VPS selected.
Answer:
This becomes quite a task when mobile phones tend to change IP's frequently.
Since you are looking further into the VPS setup, you are more in control of the setup and can choose to look into OAuth and JWT.
Links:
OAuth - https://oauth.net/getting-started/ https://developer.okta.com/blog/2019/01/22/oauth-api-keys-arent-safe-in-mobile-apps
NGINX JWT - https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-jwt-authentication/
So - At the end of the day, you can make your app use a proxy (potential bottleneck) and whitelist this IP, or make the endpoint open (any -> 443) and implement an authentication mechanism like the ones mentioned above.
Consider implementing a DMZ zone for incoming traffic from the web.
https://en.wikipedia.org/wiki/DMZ_(computing)
and put your application behind this zone, making sure that the only the DMZ zone is facing the internet, and the server hosting your application is talking to the server in the DMZ.
Again, this is quite a big topic and is hard to simplify to a stackoverflow post.
If you are hosting the app on AWS you have a couple of options.
API Gateway now supports private endpoints. These endpoints can not be called via the public internet. That means if your app is hosted on AWS only the internal services of the app can call the end point. i.e. front end to database etc. I've used this method for internal micro services such as placing in house app data onto kinesis streams.
Alternatively, if you don't want to use API Gateway you have lots of options. Most of which would involve you creating rest APIs from where ever you plan on hosting your code. This could be on the server it's self or some sort of container.
API Gateway Private Endpoint Reference:
https://aws.amazon.com/blogs/compute/introducing-amazon-api-gateway-private-endpoints/
We have an appservice hosting some odata api's in Azure. We are running an instance in Central US and another in East US 2. We have a Traffic Manager profile set up so a single url is balanced between the two instances. There is an intermittent issue, is there a way to hit a specific server as the endpoint to test them?
If you want to hit a specific server, you can directly access the instance with each instance domain name. Since Azure Traffic Manager works based on DNS, you can verify Traffic Manager settings using the tools like nslookup or dig to resolve DNS names. To effectively test a performance traffic routing method, you must have clients located in different parts of the world.
About the performance, please note that
The only performance impact that Traffic Manager can have on your
website is the initial DNS lookup.
Traffic does NOT flow through Traffic Manager. Once the DNS lookup
completes, the client has an IP address for an instance of your web
site. The client connects directly to that address and does not pass
through Traffic Manager. The Traffic Manager policy you choose has no
influence on the DNS performance. However, a Performance
routing-method can negatively impact the application experience. For
example, if your policy redirects traffic from North America to an
instance hosted in Asia, the network latency for those sessions may be
a performance issue.
You may set the DNS TTL value low so that changes propagate quickly (for example, 30 seconds).
In addition, there are sample tools to measure DNS performance.
To troubleshoot a probe failure, you need a tool that shows the HTTP status code return from the probe URL. There are many tools available that show you the raw HTTP response.
Fiddler
curl
wget
Also, you can use the Network tab of the F12 Debugging Tools in Internet Explorer to view the HTTP responses.
Hope this information could help you.
As per the Traffic Manager FAQs in the unlikely event of an outage of an entire Azure region, Traffic Manager is expected to continue to function normally.
Can someone please confirm if during an Azure worldwide outage, Azure Traffic Manager is expected to function normally or not?
Traffic manager is not a regional deployment. It is a service which spans across data centers. In case of any regional outages, your Traffic manager still continues to work but the endpoint which you have added might fail as it is a regional deployment.
Currently I'm hosting a client application written in AngularJS on Google Cloud Storage using the configuration described here.
I like this configuration because it acts as a CDN and we don't have to use a dedicated machine to host the frontend files.
The problem is that Google Cloud doesn't support HTTPS for custom domain names, and we want to improve our security standards serving at least the login page on an https domain.
¿Is there anyway we can keep the static files hosted on Google Cloud/some other CDN for fast serving and use an https domain?
Update
For anyone interested, we finally migrated all our CDN with HTTPS requirements to Amazon S3 + CloudFront and it works like a charm.
While Google Cloud Storage does support HTTPS, it does not support HTTPS for custom domain names.
Although you've found a solution not connected with your original question, I'm answering in case someone gets here with the same question like I did.
Google Firebase link is an excellent way to serve websites (and apps) as it is automatically through SSL (https) and Google Edge servers (effectively CDN function). And https will work using your own domain name. You can push your site from your local machine (Node.js needed) or from GitHub, Gitlab, etc. using continuous integration/deploy.
There is a generous free trial plan to try it first, then a reasonable monthly rate to pay as you go as your usage grows. plans
Wondering if we can share session data between two servers (running different code) behind an Nginx reverse proxy.
To be precise, we have a legacy app in PHP running on an apache server. We are updating some functionality and hosting only that functionality on a separate server (nginx). Both apps update the same DB.
nginX uses load balancing/ reverse proxy URL rewritting techniques to decide which server to send the client to based on the URL path they use.
So, a person can add items to his virtual basket (held in session) on
the new server application.
He then decides to edit his personal information which is on the other server (Legacy).
Nginx uses it's reverse proxy/load balancing magic to decide which server to send the person to based on where an app is available.
The question is, how can a session created on one app server be available to another app server aswell? is it possible to setup the reverse proxy to store all session data and how. Please point me to the right direction of you can help with google links aswell.
your question has several possible answers. It all depends on the way the application is designed.
A possible scenario would be to keep session information on a database shared among different web heads. In this way the client, once authenticated will retrieve its "session status" regardless which server he is accessing in the final servers cluster backend.
Again, this depends very much on the way the application is/has been designed.
I think there is very little magic you can do on an old legacy application just by configuring the reverse proxy engine.
In the end, sessions are handled by the application server and not the proxy frontend.