I have an Azure web app which talks to the Azure VMs via Azure Load balancer. The VMs have NSG rules setup. The VMs are also being used by other servers/web apps. How do I prevent someone impersonating the IP and trying to get access to the VMs? Or how do I add another layer of security other than whitelisting the client IPs in the NSG of the VMs?
To secure Azure VMs, please try the following workarounds:
Make use of Azure Bastion, to securely connect to virtual machines from Azure Portal over TLS. If you are using Azure Bastion there is no need to create public IP on the Azure VM.
Try creating DDoS protection plan and enable it to your virtual network. DDoS protection plan is a paid service that offers enhanced DDoS mitigation capabilities.
Make use of Azure Firewall which filters IPs by denying traffic from known malicious IP addresses.
Enable all the above options in your virtual network like below:
Otherwise,
Make use of JIT (just-in-time) VM access that allows only legitimate users to access the VM when necessary by reducing the attack.
Try using VPN gateways which send encrypted traffic between Azure virtual networks. Please note that each virtual network can have only one VPN gateway.
For more information, please refer below links:
How to secure a Windows Server virtual machine in Azure (microsoft.com).
Best practices for defending Azure Virtual Machines - Microsoft Security Blog.
Related
Configuring a VNet-to-VNet connection is the preferred option to easily connect VNets if you need a secure tunnel using IPsec/IKE. In this case the documentation says that traffic between VNets is routed through the Microsoft backbone infrastructure.
According to the documentation, a Site-to-Site connection is also possible:
If you are working with a complicated network configuration, you may prefer to connect your VNets using the Site-to-Site steps, instead the VNet-to-VNet steps. When you use the Site-to-Site steps, you create and configure the local network gateways manually.
In this case we have control over the configuration of the virtual local network address space, but we need expose public IPs. Documentation donĀ“t says nothing about where the traffic goes (azure internal or public internet)
My question is, in this scenario, S2S between VNets, the traffic is routed through azure infrastructure as in the case of VNet-to-VNet or the comunication is done through public internet?
edit
The traffic in an S2S between VNets is routed through Microsoft backbone network. See this doc.
Microsoft Azure offers the richest portfolio of services and
capabilities, allowing customers to quickly and easily build, expand,
and meet networking requirements anywhere. Our family of connectivity
services span virtual network peering between regions, hybrid, and
in-cloud point-to-site and site-to-site architectures as well as
global IP transit scenarios.
Can anyone suggest some solution for this scenario?:
I have two resources deployed in a VNet: Application Gateway and a VM behind application gateway. (Application gateways in subnet1 and VM in subnet2) There's is no public ip associated with Application Gateway (internal app gateway with only private ip). I have automation scripts in storage account in another tenant and I need to be able to download those inside vm using azure cli. With the given architecture, I want to be able to download the scripts in the vm from storage account. Currently, if I run "az login" from VM, nothing happens. I found some help on Azure documentation :https://learn.microsoft.com/en-us/azure/application-gateway/configuration-overview#allow-application-gateway-access-to-a-few-source-ips but it's not helpful.
I have also attached network security group with allows VnetInbound for VM. In while architecture, I cannot use any public ip because of customer requirements and they do not want any connectivity to internet.
Any suggestions?
Thanks in advance!
Since Azure VM does not attach a public IP, the storage account does not directly communicate with your Azure VM over the Internet.
In this scenario, I would like to provide two suggestions:
The one is to use virtual network service endpoints, which allow you to secure Azure Storage accounts to your virtual networks, fully removing public internet access to these resources. You could create service endpoints for Microsoft.Storage in that VM subnet. You VM instance will access the storage account over the Azure backbone network but it has some limitations as below:
The virtual network where the endpoint is configured can be in the
same or different subscription than the Azure service resource. For
more information on permissions required for setting up endpoints and
securing Azure services, see Provisioning.
Virtual networks and Azure service resources can be in the same or
different subscriptions. If the virtual network and Azure service
resources are in different subscriptions, the resources must be under
the same Active Directory (AD) tenant.
Another suggestion is to use private endpoints for Azure Storage. You could create Private endpoint connections for the storage account in a VNet, then peer this VNet with the VNet where your Azure VM create.
For more references, you could get more details and steps on these blogs--https://stefanstranger.github.io/2019/11/03/UsingAzurePrivateLinkForStorageAccounts/
and
https://kvaes.wordpress.com/2019/03/10/hardening-your-azure-storage-account-by-using-service-endpoints/
For the scenario where a firewall/proxy doesn't support IoT Hub's FQDN.
The recommended approach is to script the updating of the firewall's whitelist - not going to happen in our case.
My plan B is to introduce a "gateway" on the IoT Hub side to provide a static IP address, and forward traffic to IoT Hub. I can see a few azure appliances which might serve here:
Azure Application Gateway
Azure Firewall
Azure Load Balancer
Proxy Server on VM
Has somebody been through this? What was your experience, and where did you land?
I have implemented something like this by building an HA proxy solution (based on Squid proxy) on a VM Scale Set with a Load Balancer in front. You can find the full solution here: https://github.com/sebader/azure-samples-collection/tree/master/VmssProxySolution
This one uses an internal LB (private IP) but you can also easily modify this to expose a static, public IP.
I have a Web App (Azure App Service) and I have an Azure SQL Database that this Web App talks to. I have two questions regarding communication between the two.
When connecting from the Web App to the Database (using the connection string), does the communication go out to the internet and then back into Azure or does Azure know to keep the traffic locally in Azure?
I have been looking into V-Net Service Endpoints as a possible way to improve speed of communication between the two. It is said that when connecting from a VM on V-Net with Service Endpoints enabled to a SQL Database, that Azure knows to keep the traffic internal to the Azure network and not go out to the internet, is this the same for Azure App Services?
Is it possible to keep traffic between an App Service and SQL Database internal to Azure? If so, how do I go about doing this? Any guidance on this is greatly appreciated.
It knows to keep it local on the "Azure backbone" (as per Azure doco). It doesn't go out to the public internet
Yes
Yes. It is already internal to the "Azure Backbone"
Having said that.... networks are really complicated.
As I understand it the main benefit of V-Net is that you can define your own network and add things to it like firewalls, security groups, subnets, peering between networks. Also it helps when setting up a hybrid network - i.e. connecting Azure resources to an on-premises network. When you can set up the same kind of structures as on premise, it's easier to 'transparently' make it part of the on-premises network. Lastly (rereading the doco), you can remove any incoming public IP firewall rules. These are "Azure backbone" IP addresses but they are also "public internet" addresses
There may be a performance improvement if the App Service and Azure SQL are on the same V-Net.
Azure SQL service endpoints are a bit mysterious. They "connect" to the VNET but you still need to connect to a public address. They don't actually take a up a local IP adress.
Depending on what you are really doing, you might want to look into private endpoint, which actually assigns a private IP to your Azure SQL.
Yes, communication between Azure App Service and Azure SQL Database is "local" within the Azure Virtual Network and does not go out to the public internet.
I have a set up I would like to implement but just not sure on the details. As you can see in the image below I have a single VPS in the web which I would like to use as a gateway to a number of locally running web servers. Im using the VPN to hide the IP/location of the server farm while maintaining the ability to host locally.
What I am not sure on is the implementation as I have never used a VPN before. My understanding is that I can host the VPN server on the server farm, have the VPS connect to it which will give me another 'local' network interface which I can then use apache to proxy traffic through?
The server farm is basically a small Kubernetes cluster give or take a little.
Is my understanding correct and can you offer any advice on implementaion?
Thanks in advance!
server farm example image
The VPN server should have two network interfaces. The first is the public interface that connects to the Internet and the second is the local interface that connects to the server farm. All the servers in the farm should connect only to the local interface and have the gateway set as the VPN server.
You can use the Reverse Proxy functionality in Apache to route incoming traffic to the appropriate server. See Reverse Proxy Guide