We have an App Service running in Azure that hosts a website. We've recently had a security review on the web site and one of the items found was that the end point below was exposed.
https://<appName>.azurewebsites.net:8172/msdeploy.axd
The recommendation is that this end point should be blocked and using a whitelist to allow limited access (e.g. the build machine that deploys to Azure). How do I block this end point?
After discussions with Microsoft support it appears that port 8172 is enabled for backwards compatibility with old versions of MsDeploy. This port is being phased out and will be open sometimes and not other times.
The fix was for us to create a new resource group, app service plan and app services multiple times until we ended up a server that had the port closed. This was frustrating but ultimately it did resolve the issue.
You could use IP level limitation in the Azure App Service access restrictions to allow limited IP addresses or VNet access to your app service. In this case, it will work on all the applications in your app service.
For some specific endpoint access control, perhaps, you need to control it with access authorization in your application code. Read Tutorial: Authenticate and authorize users end-to-end in Azure App Service and Managing access to apps.
Alternatively, you select to use Application Gateway integration with service endpoints. In this case, you only want the front end to be accessible to your end-users. The back-end should be locked down so it is only callable from the front-end. Also the front end subnet support NSG, you could restrict the end-users with IP and port to access your front end, meanwhile, it will limit access to your endpoint. See Securing Back-end App Service Web Apps with VNets and Service Endpoints for more details.
Hope this helps you.
Related
I have an Azure Web App and an Azure SQL Server, both in the same subscription. Both of them are connected to the same VNet Subnet as shown in the below snapshots. The SQL Server is configured not to Allow Azure Resources and Services to access the server, as it should only permit access from either the connected subnet or a set of IP rules.
Unfortunately, the SQL Server is actively refusing any connection from the web app stating that the web app IP is not allowed to access the server.
The interesting thing is that I have the exact same configuration working on another subscription.
What could I be missing?
Snapshots:
1- Here you can see the web application connected to the "webapps" subnet
2- And here you can see the SQL Server connected to the same subnet
3- And that's the error I get
TLDR
The configuration is correct, but an app service restart may be required.
VNET Integration
The configuration of using a virtual network to connect a web app to a SQL database is correct: if the web app is connected to the same subnet/vnet which is allowed in the database's ACLs, and the Microsoft.Sql service endpoint is enabled on the subnet, the web app is able to communicate to the database. This is the whole reason for service endpoints: you do not need to configure with IP allowances on the database.
As to why the configuration still resulted in an error, it could be the order in which the resources were configured. We were experiencing the exact same setup and issue (which is what let me to this question)!
We connected our web app to the subnet/vnet but had not enabled the service endpoint on the subnet. We then added/allowed the subnet/vnet as an ACL in the database, during which we were prompted to enable the Microsoft.Sql service endpoint (we did). However, even after waiting ~20 minutes, we were still seeing the same connection issue.
However, once we restarted the app service, the issue went away and the web app could connect to the SQL database.
I suspect the issue is due to enabling the subnet's service endpoint after the app service was connected to the subnet. The app service must need a restart to refresh the app service's vnet config/routing.
Configuration NOT needed
Contrary to other answers, you do not need to configure firewall IP allowances nor enable access to Azure services and resources. In fact, there are downsides to both approaches:
Enabling access to Azure services and resources allows any Azure-based resource to connect to your database, which includes resources not owned by you. From doc:
This option configures the firewall to allow all connections from Azure, including connections from the subscriptions of other customers.
Unless you're using an App Service Environment (which is significantly more expensive than normal App Service plans), your web app's outbound IP addresses are neither static nor specific to your application. From doc:
Azure App Service is a multi-tenant service, except for App Service Environments. Apps that are not in an App Service environment (not in the Isolated tier) share network infrastructure with other apps. As a result, the inbound and outbound IP addresses of an app can be different, and can even change in certain situations.
The second point is further elaborated upon in this Github issue:
IPs are indeed shared with other App Service plans (including other customer's plans) that are deployed into the same shared webspace. The network resources are shared among the plans in a workspace even if the computing instances are dedicated (e.g. in Standard tier). This is inherent to the App Service multi-tenant model. The only way to have a dedicated webspace (i.e. outbound IPs) is to deploy an App Service plan into an App Service Environment (ASE) (i.e. Isolated tier). ASE is the only thing that offers true single-tenency in App Service.
So neither of the above options will truly harden your SQL database if you want to isolate communication from only your web app. If you have resources in the same subnet, using vnet integration is the correct way to solve the problem.
If resources cannot be in the same subnet, the solution is to use Private Endpoints.
Virtual networking in Azure is quite different from how it would work on premises.
I had similar problems in production environment and digging deep, the working solution (meeting security standards and create a secure connection to the database) was to create a private endpoint for SQL access in the virtual network. Then all the calls to the SQL were performed internally (it did not go on the internet), and the databases were denying all public calls.
In your case now, you deactivated the Allow Azure apps to access so when your app is trying to access the SQL the server checks the ip to find out if it is white listed or not. So fast solutions would be one of the following:
Enable Azure Web apps to access SQL
Find all outbound IPs of your web app and register them in you SQL firewall/ security settings.
If you talk about a proper production environment with security regulations I would suggest you go down the more tedious path of private endpoints.
You have to configure the outbound IPs from the app service in the sql fw.
You can find them under properties of your app service. Documentation.
The reason why is that the VNET integration doesn't give your app service an outbound IP in the VNET you configured it in, so the FW you configured doesn't work.
I have working web apps which access storage accounts and KVs. These storage accounts and KVs accept traffic from a particular subnet and the web apps have been configured to integrate with those subnets. I did face an issue where even after integration apps were not able to access these resources. What worked for me was, I changed the App service SKU from Standard to Premium and restarted the app. As you can see, it warns that "Outgoing IPs of your app might change". This is not guaranteed solution but it worked for me.. several times! Not sure about SQL server though. Private endpoint does seem like the way to go but you can give this a try.
I am getting to the point of my project where I am ready to deploy it online with my custom domain via Azure once I make the upgrade from my Free Subscription.
So a little context, I have 1 web app service and 4 api services and each one is hosted in a separate app service such as:
www.sitename.azurewebsites.net
www.sitename-api1.azurewebsites.net
www.sitename-api2.azurewebsites.net
www.sitename-api3.azurewebsites.net
www.sitename-api4.azurewebsites.net
And the above web app communicates to all 4 api's and some api's may or may not talk to another. (Would have loved an application gateway so hopefully I'll be changing this architecture later down the road).
So as I get ready to associate my domain to the services, the web container seems pretty straight forward to me as it just becomes www.sitename.com, but I am a little confused about the api services. The way I am thinking about this is that each api service will be in it's own subdomain, such as:
www.api1.sitename.net
www.api2.sitename.net
www.api3.sitename.net
www.api4.sitename.net
where I believe I can register my SSL and domain to each app service somehow, but this leaves me with a few questions.
Do I host each api in a subdomain using the same domain as the web
app, or is there a different way preferred like where I host them
all on the same domain with different exposed ports per API and web
listening 80/443, or maybe just use the IP address of the api app
service and allow www.sitename.com as the origin for CORS?
I am assuming that since I am associating my SSL cert to the web
service, I will need to do the following on the api services?
Would it be better (and still affordable) if I just had a VNET
associated to the app services and the domain only registered with
the web app?
Any insight into this would be greatly appreciated on how I can establish communication between my app services with my custom domain and SSL as I am fairly new to this part of the stack, but excited about learning!
As I known, on Azure cloud, there are two services can help to manage your APIs deployed on multiple app service containers: API Management and Application Gateway.
The Premium tier of API Management has the feature for multiple custom domain names, please see the offical document Feature-based comparison of the Azure API Management tiers as the figure below.
You can refer to the quick start tutorial of Create a new Azure API Management service instance and other related documents to kown how to.
"Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications." said in the introduce What is Azure Application Gateway?. And as the figure of its architecture below, "With Application Gateway, you can make routing decisions based on additional attributes of an HTTP request, such as URI path or host headers. For example, you can route traffic based on the incoming URL. So if /images is in the incoming URL, you can route traffic to a specific set of servers (known as a pool) configured for images. If /video is in the URL, that traffic is routed to another pool that's optimized for videos."
I recommended to use Azure Application Gateway which be a good choice to manage multiple app services and expose the unified urls of APIs.
I have an existing on-premises web app that I'd like to migrate to Azure, just a basic migration to start with.
The current app is made up of two websites, a publicly facing front end web site and a private SOAP API site that is accessibly only via a VPN connection.
I can happily place the front end in a standard web app, but can't see a cheap way of hosting the SOAP API. I have used Azure Service Environments in the past, but this approach is expensive and a bit much for the early stages of this migration.
Ideally I would just host the SOAP API in an Azure Web Site and put a Gateway infront of it to manage VPN access. But I'm struggling to see if that is supported.
Is there anything else I can do here?
On the App Service hosting the API, have you looked into using the "Networking" blade to configure an IP restriction? This way you could limit access from only the IP address of your front-end.
Additional considerations:
There is no guarantee on a static IP for your front-end so you may need to consider range(s) based on what's in the DC you're app is hosted in (the IP doesn't change often but understand it's allocated from a pool that MS maintains). For this solution, you'd also need to include the IP of any client needing access for development/debug since it wouldn't use a VPN
You could also use a VNet to isolate services on the network and have more control over the configuration. Unfortunately you'd also need to deploy the app into an ASE which will add further costs. As a bonus, this would allow you to use a VPN as explained here: https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-point-to-site-resource-manager-portal
Good luck!
For example, you can create a P2S VPN from the web to Vnet, create another S2S or P2S VPN from on-premise to Vnet. And there can be an NSG associated to the Vnet, so you can manage the VPN access. I think the document Integrate your app with an Azure Virtual Network
could give you an idea. Unfortunately, you'd also need to deploy a VPN.
I have multiple web apps on Azure that I want to put behind an Application Gateway in order to use a single domain name with path routing.
However, my web apps needs to connect to a db outside of Azure. So I wonder what will the IP of the requests from these web apps to the db would be? I hope it will be the gateway public IP so I only have to authorize one IP at my db provider but I don't find any docs to confirm it (or not).
So I wonder what will the IP of the requests from these web apps to
the db would be?
If you want your web apps to connect a database outside Azure, you may need App service Environment. Because the Web Apps need VNet to connect other resources. Also, due to the date base is outside Azure , you need to create VPN gateway to connect it. This connection is between the Web App and the database, not Application Gateway and Database.
So, the IP of requests from those Web Apps is not the IP of Application Gateway, It depends on the VNet in App Service Environment.
This picture explains how this environment works:
I hope it will be the gateway public IP so I only have to authorize
one IP at my db provider but I don't find any docs to confirm it (or
not).
Also, if you still want to use one IP to connect other resources, you can also add Internal Loadbalancer to achieve that.
You can see more details about Integrating your ILB ASE with an Application Gateway to help your deploy resources.
Please let me know if this answer helps.
I would suggest using the Azure Web App's Hybrid connection. This provides a TCP tunnel in a secured fashion between your azure web app and your SQL db. There is a service bus in between and you have to install the relay agent in your network that does the outgoing communication to this service bus.
Hybrid connection diagram
Details are at:
https://learn.microsoft.com/en-us/azure/app-service/app-service-hybrid-connections
The app gateway's public IP address can't be leveraged nor is it necessary to manage connections between Azure Web Apps and databases outside of Azure. The web apps have their own IP addresses.
On another note, my blog post may be useful to understand how the architecture and configuration between app gateway and azure web app.
In a typical 3-Tier web app, you run web servers in public subnet, while app tier lives in private subnet. Is it possible to run similar architecture with Azure Web apps and Api apps?
I guess you can run Asp.NET Core Web App in Azure Web App and Deploy AspNet Core Web Api to Azure Api App, then make Api end point private so only Web app can talk to it? I see options like Google, Facebook et. as auth providers. Is that what you have to do to make API private?
D.
If you want that level of isolation, one (although expensive) option is an App Service Environment (ASE). Link to docs: https://learn.microsoft.com/en-us/azure/app-service-web/app-service-app-service-environment-intro
App Service Environments are ideal for application workloads requiring:
Very high scale
Isolation and secure network access
The public environment where you deploy by default is public. Your endpoints will be accessible to anyone anywhere, and it is up to your app to do the filtering. This can be done, e.g. through static IP address security settings in Web.config. The problem with that is that even then you can't know for sure what IP address your front-end will use for communication. There are multiple possible addresses it may use for outbound traffic, and those are subject to possible change.
You can see an example of IP restrictions here: restricting IP security
Of course you should also have authentication set up on your API. Documentation links:
https://learn.microsoft.com/en-us/azure/app-service/app-service-authentication-overview
https://learn.microsoft.com/en-us/azure/app-service-api/app-service-api-authentication
In line with what #juunas said above and a slight variant is to introduce Azure API Management Gateway in between Azure web app and Azure Api app. In standard tier API Gateway the IP address is fixed and doesn't change and you can use the API Gateway address in Azure API App web.config to whitelist.