In essence, only allow requests/responses to/from Azure Front Door. There are different options, however, I'm having trouble finding details on implementation and best practices. I think the proper solution would be to create a Virtual Network to use to integrate the two services.
One nuance exists, the Web Apps have staging slots that may require a different solution since they use Azure Active Directory to prevent public access to pre-production.
I found a little more insight here, but still found it a bit confusing.
It seems that if I have a custom domain with subdomains with Front Door, there should be an easy way to prevent direct access to the backend addresses of the Web Apps and only allow through the custom DNS and Front Door.
This was helpful, however, I'm still getting 403 from the Front Door, so I must be missing something in how to configure.
Middleware? This also was helpful, but seems to indicate it can only be accomplished by middleware and I'm running Node/Express not .NET Core. Is it true, it can only be accomplished through middleware code?
This also mentions the same details.
What is missing? How to configuration this across different application stacks.
The documentation is inaccurate when it states
< To lock down your application to accept traffic only from your specific Front Door, you will need to set up IP ACLs for your backend and then restrict the traffic on your backend to the specific value of the header 'X-Azure-FDID' sent by Front Door. These steps are detailed out as below:
It requires either setting up IP ACLs for your backend or implementing middleware code to conditionally match on your specific header value for 'X-Azure-FDID'. Both may not be required, the documentation is unclear.
I think you DO need both IP ACLs and checking the 'X-Azure-FDID' header. (I wish it was not needed...). If you only use IP restriction, your back-end is still open for all Front Doors around the globe, also those of other Azure Customers. And if you use only the check on the 'X-Azure-FDID' header, you are open for attackers trying to guess the header with brute force. Only the combination of IP ACL and checking the header will protect your back-end, because then you can be sure that the 'X-Azure-FDID' header was indeed added by a real Front Door service, and not spoofed.
See also this post, where it's explained clearly.
Related
I would like your feedback and opinion about using { FrontDoor + Appservices + Authentication + restrict access to FD only }
I do confirm I can set up all of this thanks to all contribution/ forums / blog found on the net. I can use my custom domain which request AD authentication and I am correctly redirect to my appservices (in browser: I see my custom domain name and never see any *.azurefdnet or *azurewebsites.net as expected).
The only problem is that I needed to use a custom domain to make it works. For production purpose it is acceptable to have a custom domain but for dev or test I wonder if we can do it without custom domain by simply keeping original address like *.azurefd.net and *.azurewebsites.net
I struggle to make it works without custom domain. I keep getting “too many redirection” message or ‘403 sites blocked’.
Does anyone success to do it ? My general configuration looks like
My backend is linked with my appservices
Details of my backend is:
I think my problem is with BackendHostHeader but not sure. When i used custom domain for my production it works. But remind i do not want to use custom domain for dev and test.
My route looks like
And finally my appservices is secure to allow frontdoor only
When my user goes to stackoverflo.azurefd.net they get AD authentication which is good but just after i get redirection to xxx.azurewebsites.net with 403 forbidden (which looks normal because of restriction to FD only).
I tried to change the backend host header by replacing by FD value but in this case i get a error with loop redirection.
Is it a feasible scenario without custom domain ?
Regards
PS: i configured Azure ADApp to allow reply url to my FD like stackoverflo.azurefd.net/.auth/login/aad/callback
Yes, you can Restrict the access to website without using Custom Domain.
Goto the Application you want to restrict the access in Azure Portal and select the Networking from left Pane, now click on Access Restrictions.
For complete information you can go through this Microsoft Documentation.
I just wonder whether CloudFlare (or others) manages this or not and if it manages how. The situation can be explained with a simple example. Think of a corporation in which there are 1000s of users. These users have the same IP (different internal IPs of course but external IP will be the same since it's a corporation..) and these users try to access the same site which is protected by CloudFlare. Will CloudFlare treat these users as the same users or not? How does DDos prevention tools manage this situation?
I would manage it as writing unique cookies for different users (kind of session_id) and look for this cookie value. Since it will be different for all of the users behind company network, there would be no problem..
Edit: That cookie solution is the way I'll go as a solution for my problem (if security vendors don't manage it..) and I didn't write it as the ideal solution for security vendors (that would be so arrogant:) )
I realize that mac addresses or machine ids aren't transferred over the internet, however, I would like to lock down our subscription-based website security so that only specific computers can register and have access to its resources.
Large organizations will subscribe to our service and will undoubtedly have more than one ip for their organization. As well, we'd like to give the ability for their qualified employees to access the website on devices outside of their physical organization (for road-trip presentations, etc.).
Is there a sure-fire way to achieve this end (beyond the username/password assigned to each account)? If not, what would be the most effective approach?
Instead of restricting access via IP, you want to use something that's actually secure.
Username and password over an HTTPS connection should at least be unsniffable, but you might want to look in to client SSL certificates. They can be configured in Apache or other web server software. If username/password authentication is not enough, this is the next (and perhaps final) step up.
UPDATE:
That said, what many application providers will do is provide a method for subscribers to implement an ACL for their accounts. You can even force people to consider their ACL before allowing them to access your services. Think of it this way:
An account is set up in your system allowing login from anywhere. Upon creation, the ACL is UNSET.
User logs in and is immediately directed to an ACL setup page, where they must provide either an IP address or range or subnet associated with their account. You can be clever and pre-populate things with their existing IP address or subnet, perhaps even looking things up at ARIN to see if their IP is in a network assigned to the company name on their account.
Once the ACL is set (or they have, despite your warnings, confirmed that they want to keep their ACL open), they can access your services.
If they try log in from elsewhere, they (and you) are notified via email (or SMS or whatever) of an attempted breach.
If they no longer have access to their ACL-listed IPs (i.e. IP renumbering due to a new upstream Internet provider and bad planning), they can call your phone support who will validate them by other means. FAX confirmation perhaps, because that's SO secure...
A user-managed ACL is not a "sure-fire" way, but it may be sufficiently effective for your needs, and it will certainly instill a sense in your customers that you have their best interests at heart.
There is no sure-fire way. That's in the nature of networks. You accept data from a remote machine and you have to trust it at least to some extend.
Take the simple username/password approach. If the usename and the passwords match, you have to trust, that they where entered by the person that the username and password was intended for. This does not fundamentally change if you require more data to be send by the client.
So i'm in the middle of defining the architecture for an application I've been waiting to start and have hit a bit of a bump. I 'm having a bit of a hard time figuring out how to handle multi-tenancy in conjunction with Top-Level domains.
Here's the gist of what I am trying to accomplish:
Users can come to the site and register for an account, when they register they can set up the application to use their own registered domain name. I'm not handling registrations (but do provide good instructions on how to register and point the domain for most Domain Registration companies) just the application end of it.
What I am having a hard time figuring out is how sites like Wordpress.com and Typepad handle the multi-tenancy at the application level.
So say a request comes in for www.test.com/ it reaches my multi-tenancy application but how do I serve the correct site? do I pull the headers from the request and serve a site based on that.
For instance if you were using Apache as your web server for your application, there's no way you would be adding virtual host config to apache every time a person registered for the application with a custom domain. So they have to be handling it programmatically but I can't seem to find any resources that are clear about how to handle the multi-tenancy of top-level domains at the application level.
General idea is not that difficult. When request gets to your application you have to parse url and get some tenantID from that. Similar question in asp.net mvc 3 was asked on question. You'll find my answer there with solution in our application. On sites like wp or similar i believe that proxy is adding some http header data to request so the application layer already gets tenantID.
When running Sharepoint (WSS 3.0) with Windows Authentication (NTLM), external users must supply their usernames in the form of DOMAIN\username. This makes sense, because you could have multiple domains, trusts between them, etc. However in my case, I only have one domain, and I want my users to be able to logon with their pure username only. Is there any way to configure Sharepoint with a default logon-Domain to get this to work?
Changing the authentication to basic or forms is not an option for me.
That's a windows/IIS issue rather than something specific to sharepoint.
You can find a more detailed explanation at http://forums.iis.net/t/1151401.aspx but basically it's impossible due to the the design of integrated authentication - the client has to know the domain before the server is contacted.
The closest you get to a default domain is local logins on the server - potentially a solution if users are truly external.
Realize that some browsers can be configured to automatically provide NTLM credentials. For example, IE can do this. I believe by default it will for sites in the Local Intranet and maybe even for Trusted sites (if not, you can change it so it will).
There is software out there for pushing these settings (policies) out to users if their computer is a part of your domain.