I have recently replicated my Azure VM using Azure site recovery and performed a test failover. I was disappointed to see the NSG rules, route table not reflected from Source to target. If the network settings aren't reflected from source to target I don't think so it is of use using Site recovery. Am I missing any steps? I have also created "Allow 443 port outbound rule" for source NSG.
How to Create outbound HTTPS (443) rules for the Site Recovery IPs that correspond to the source location: Location-East US, Site Recovery IP address-13.82.88.226, Site Recovery monitoring IP address-104.45.147.24
Site Recovery does not create NSGs as part of the failover operation. It's recommended to create the required Azure NSGs before initiating failover. You can then associate NSGs to failed over VMs automatically during failover, using automation scripts with Site Recovery’s powerful recovery plans. You could get more info about Azure to Azure replication with NSG.
For Azure VM replication, ensure that the NSG rules on the source Azure region allow outbound connectivity.
Like this example NSG configuration. Please note, you need to create an outbound HTTPS (443) rules for the Site Recovery IPs that correspond to the target location in the source NSG, but create an outbound HTTPS (443) rules for the Site Recovery IPs that correspond to the source location in the target NSG.
In this case, you want to create outbound HTTPS (443) rules for the Site Recovery IPs that correspond to the source location: Location-East US, Site Recovery IP address-13.82.88.226, Site Recovery monitoring IP address-104.45.147.24, it will like this:
Related
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.
Azure network manager security configuration “NRMS-ZeroTrust...” created 54 inbound port rules on my Azure VM which closed my active RDP session and blocked all access to SQL Server.
Is anyone else having a similar issue with their Network Manager (preview)? A screen print of my Azure VM Networking and Vnet Network Manager is below although in preview it looks like stackOverflow has blacked out the rule information you need to see.
I have selected “leave preview” but this didn’t remove the rules.
I see the Remove and update Azure Virtual Network Manager Preview components checklist, but I have no idea what “undeploy the security admin configuration deployment” means as there is no link in the doc. Unlike all the other Azure VM Networking Inbound Port Rules, you can't drill into or delete the rules created by the ZeroTrust config. Creating a rule to explicitly allow the IP of my workstation is ignored.
• You can surely ‘undeploy the security admin configuration deployment’ that has been enabled by accessing the NSG (Network Security Group) of your VM. Also, as you stated that the ‘Zero Trust’ configuration deployed has blocked your access to the VM through RDP and to the SQL Server, it is as such blocked because the similar kind of rules have been configured on the Azure Network Manager with regards to the virtual network in which your VM is configured.
• Also, a security admin rule allows you to enforce security policy criteria that match the conditions set. You can only define security administrative rules for resources within the scope of the Azure Virtual Network Manager instance. These security rules have a higher priority than network security group (NSG) rules and will get evaluated before NSG rules. Also note that security admin rules don't change your NSG rules.
Security admin rules can be used to enforce security rules. For example, an administrator can deny all high-risk ports or protocol from the Internet with security admin rules because these security admin rules will be evaluated prior to all NSG rules as that have been done with you.
• Thus, to configure the security admin configuration to modify the Zero trust rules set for the network group of which your virtual network is a member, go to your VM’s NSG --> Under ‘Support + Troubleshooting’, select ‘Effective security rules’, in that check the name of the ‘Associated Azure Network Manager’ and select it, then select the ‘Configurations’ option under ‘Settings’, in that check the security configuration rule collection set and modify the rules or remove them from that collection set and save it. Once done, you should be able to access the VM over RDP and the SQL Server over its ports. In this way, you can modify the ‘Zero Trust’ network configuration rules for a VM.
Please find the below snapshot of the above said settings in my tenant: -
Please note that you need to have ‘Subscription Admin’ permissions to configure and modify the network manager settings. Also, refer to the below article for detailed configuration and deployment of Azure Virtual network Manager: -
https://virtualizationreview.com/articles/2021/11/03/azure-virtual-network-manager.aspx
I have a non-azure, non-Windows, non-microsoft site-to-site tunnel set up between an Azure cloud environment and an on-premise LAN; at the azure end, the proprietary (non-microsoft) S2S host sits behind an Azure load balancer.
The proprietary tunnel is route-based and as such, I'd like to route connections all the way from our on-premise network to various resources in Azure.
e.g.
OnPrem Server -> OnPremFw -> (tunnel) -> CloudFW -> LB -> vNET1 -> vNET2 -> VMtarget
When packets hit the CloudFW, they are being "Hidden NAT'd", so the source IP address is translated from its On-premise IP address to an IP address recognised by Azure as directly associated with an Azure subnet range. In this case, things work as expected.
However, if I turn off the H-NAT, so that packets carry their original on-prem source IP address in to Azure, then no matter what security or routing rules I apply, nothing works.
Is it plausible that Azure is passively dropping these packets, or is silently screening them out, something like address spoofing?
I can't find any Azure documentation confirming this, but the behaviour I am seeing strongly implies this must be the case. Could anyone confirm?
I would like to know if essentially, it isn't possible to use "non-Azure" IP addresses in Azure routing and security configurations.
thanks
The answer to this question is No.
It is possible to use non-Azure-defined IP addresses in Azure route table rules and in Azure nsg rules.
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.
I have question around DLP (data leakage prevention) from a corporate network.
I have a Virtual Machine on a corporate network. The VM can access an Azure SQL DB in the cloud: aaa.database.windows.net through a connection over port 1433.
However, I don't want that same VM to connect to bbb.database.windows.net.
Azure offers no guarantees on the public IP (both servers could appear as the same IP) - what technology can I use on the corporate's perimeter network/firewall to permit access to aaa but disallow access to bbb?
The attack I am concerned about is someone internal to the company querying data out of aaa and inserting it in to bbb. For example, if the one server is ourcorporatedate.database.windows.net and the other is somerandom.database.windows.net the someone internal to the company could take corporate data and write it to some random database.
Thanks
You can use Virtual Network service endpoints and rules. Virtual network rules are one firewall security feature that controls whether your Azure SQL Database or SQL Data Warehouse server accepts communications that are sent from particular subnets in virtual networks. Learn how to use it and benefits/limitations on this documentation.
If database aaa and bbb have the same public IP address. I think there is not a good way to set in the on-premise firewall to permit access to aaa but deny access to bbb. From the same client, the firewall rule will have the same source IP, protocol, port, and destination IP for outbound traffic.
If you want to selectively grant access to just one of the databases in your Azure SQL server, you can only create a database-level rule for the required database. Also, Specify an IP address range for the database firewall rule that is beyond the IP address range specified in the server-level firewall rule, and ensure that the IP address of the client falls in the range specified in the database-level rule. Server level rules allow access to the Azure SQL Server. Which means that the client will have access to all the databases stored on that SQL Server. Refer to this doc.
The current VPN feature in SQL Azure does not directly prevent this (but please look for future updates where this is planned for the service endpoints feature for SQL Azure). However, there are various mitigations you can use to detect or reduce the ability to do this:
You can enable auditing on the aaa database. This can detect all logins and major state changes to the DB. (Detect)
You can reduce the permissions for various kinds of users on the database to the bare minimum and use features which further reduce the size of the data that a customer can copy out of the database at all. This includes row-level security, data masking, always encrypted (which you would lock down to a specific app/user to be able to decrypt sensitive data in the client - other clients without the key just get cypertext), etc.
Use firewall rules (as stated in the other answers) to restrict which clients can connect to the database at all - then you can restrict where they can connect with permissions.
Please note that SQL Azure's logical servers do not generally imply that every customer database in that server has the same IP. Currently there is a knob in service endpoints (docs page is currently down so I can't get you a link atm) to configure whether you go through the per-region gateway or not. If you don't (recommended), you would see the IP of the hosting node and this can change over time. The Service endpoints feature will give VPN users more control for network-level rules going forward, but some of these features have not yet landed in production. I encourage you to mitigate with other steps (above) until that is available to you.