I'm using SSMS to connect to Azure DB from my laptop. I have provided my laptop IP address in "Set server firewall". However, each time when connecting from SSMS it's considering my public IP address, instead of laptop IP.
My questions are:
why is it not considering my Laptop IP?
How safe is it to configure a public IP address in Azure's "set server firewall"? Will not it possible someone having same public IP can able to connect to Azure DB?
How the Azure DB can be configured so that it should account the request from my laptop IP only?
Azure PaaS service has a public endpoint, so it means that you cannot connect to them from your private IP, you must configure your Azure PaaS with your public IP. There is an option to make a public endpoint as a private endpoint using a private link, vpn point to site, virtual network gateway. Please, have a look at this article for more details.
You can keep security your connection from public IP using Azure PaaS firewall once your connection from your source to azure allows only you public IP, but you have to change this IP in firewall for each time your IP is renewed in case it is dynamic. For the best practice you should consider a private link or a Azure Instance Manager SQL which has more option, but it is more expensive then Azure PaaS SQL.
To help you answer these questions, we first must consider the network topology involved. Your laptop is likely connected to a wireless access point which is connected to a network switch. All traffic on the switch (or series of switches depending on the location you are at) uses a private IP addresses to communicate. These addresses cannot be routed on the public internet. In order for you to access the Azure SQL Database which sits on a different private network then your laptop, it had to travel over the public internet. This means your traffic is going through a series of routers and in order for the connection to correctly route between you and Azure, it needs your public IP address.
It is safe to a certain point. The Azure SQL Server you are connecting too uses SSL/TLS to encrypt the traffic so communication over the public web is encrypted. Your concern for essentially spoofing the public IP is valid which is why it is crucial to make sure you have selected a strong password for the SQL login. Microsoft also deploys a series of edge security services that monitors for attacks on any of their services to ensure the safety of their platform and will flat out block suspected attacks.
If you want to restrict traffic so that only your laptop can be used, now we are introducing a complex but doable architecture. You will need to setup a VNet and VPN Gateway in Azure and connect the two services. You will have to then connect the Azure SQL Database to the VNet you just setup. Once completed, you will need to access the VPN from your laptop which will grant you access to the database. The actual setup isn't trivial as there are many things to take into consideration such as cost, hardware capabilities on your side and security requirements.
At the end of the day, what should drive the "right solution" should be your security requirements. For some, running via a public IP is sufficient, for others they need to access it over a VPN.
To address your comment below, I needed more space so I'm amending the solution.
Anytime you make something publicly accessible over the internet, there is a possibility for someone else to access it. The chances are lowered the more complex you make the password to the resource. If you do not have a static IP address for your internet or someone spoofs your public IP address, there is a chance an attacker will have the ability to connect to the Azure SQL Server. This is where the password complexity comes into play. The stronger the password, the harder/longer it will take to brute force their way in.
If you have time to do the research/learning on this, I'd suggest taking a look at the online training Microsoft has for the Azure Solutions Architect certification. I think it will help you to better understand the intricacies involved with building a solution such as this.
https://learn.microsoft.com/en-us/learn/certifications/azure-solutions-architect
Related
can anyone explain difference between Azure Application Gateway, Virtual Network Gateway, Virtual WAN, ExpressRoute, Arc and Private Link, please?
It seems to me all services are pretty similar helping with connecting either on-prem to Azure, in-Azure to in-Azure or public to Azure.
They're similar in that they all involve network traffic, but that's pretty much where the similarities end.
Application Gateway is a Layer 7 load balancing service with advanced features like SSL termination. It's used to route client requests to your applications.
Virtual Network Gateway is a VPN gateway for point-to-site (user) and site-to-site (office/datacenter) VPN connections to your own Azure VNETs. This would, for example, allow you to RDP into Azure VMs from your on-prem office using their private IPs.
ExpressRoute is similar to site-to-site, however it doesn't use IpSec tunnels, it's a dedicated, unencrypted connection from your location directly into Microsoft's backbone. (i.e. you don't traverse the public internet). There's no encryption and the connection is faster. This is a service you need to work with a 3rd party internet provider to implement.
Virtual WAN is more like a networking hub where there would be many site-to-site, point-to-site, ExpressRoute, etc... connections spanning a wide area (as the name implies). This would be for large enterpise organizations with many on-prem locations.
Arc is a means of adding your on-prem resources into Azure for management. e.g. you have a physical server somewhere and you want to manage it though ARM/portal.
Azure Private Link is a feature of many Azure services (storage, SQL PaaS, etc..) which allows you to create a private DNS record and assign a private IP address on your internal VNETs. This is used when you want to disable all public network access to a resource and only allow access from within your own VNET.
I have barely scratched the surface of the differences here, but suffice it to say, there are many differences. From this page, you can type the service name into the search and get more specific details on the offering. Hope this helps.
https://learn.microsoft.com/en-us/search/?terms=networking%20in%20azure
I am pretty new to Azure, I need to give developers access to our database in Azure. The problem is that each time when they connect to the database, they need to whitelist client IP in the firewall which is practically frustrating.
Can someone help me find the best solution so that they don't need to do this every single time since everyone is using broadband connections they don't have a static IP so it's like practically creating new rules every single time.
It's only possible (as far as I know) with a P2S Vpn connection to a Azure VM, where the Azure VM Vnet has a private endpoint connection to the database server.
See also : https://techcommunity.microsoft.com/t5/azure-sql/connect-to-azure-sql-database-with-point-to-site-connection-and/m-p/1362840
The Problem
I'm trying to understand more about networking, firewalls, and IP ranges to help me solve a few real-life problems. The problem I ran into is that the SQL server I'm connecting to has a firewall which can list individual IP's or IP ranges, but my ISP changes my IP fairly frequently, which means that whitelisting my current IP is a temporary solution and I'll eventually be disconnected.
The Question
If I wanted to stabilize my IP and make it so that it comes from a predetermined range (or even a single static IP), would the best way of doing that be to make a virtual network that I can VPN into that has a specified range of IP's? Or is there any easier solution?
Details
I'm interested in the answer at a broad level, but the specific database I'm connecting to is on Azure. Hence, my thought process would be to create a Virtual Network and and a Virtual Network Gateway, which I would connect to using a standard VPN connection tool like Hamachi or Open VPN. I'm assuming then that I could open up a tool like PGAdmin and connect to the database, because the database would consider the incoming connection to be from the IP range that I've whitelisted and that the Virtual Network sits on. Is this accurate?
As you stated, if there is a public IP range from your on-premise outbound traffic, you just need to whiltelist the IP list on the firewall of Azure SQL database server. It is a simple method.
If you want to block the public endpoint from on-premises machines, you can use private endpoint for Azure SQL database. Read On-premises connectivity over private peering for more details.
With Private Link, customers can enable cross-premises access to the
private endpoint using ExpressRoute, private peering, or VPN
tunneling. Customers can then disable all access via the public
endpoint and not use the IP-based firewall to allow any IP addresses.
On Azure, I have a two-VM set (both classic), whereby my web application resides on one VM, my database on another. Both map to the same DNS and belong to the same Resource Group, but both are acting as standalone cloud services at the moment. Let me explain: currently the web application communicates with the database over the public DNS. However, I need them to be on the same lan, so I can de-risk security and improve latency.
I know for a fact that they're not part of a virtual network because when I try to affix a static private IP to my database VM, I'm shown the following prompt in the portal:
This virtual machine can't be configured with a static private IP
address because it's not deployed in a virtual network.
How should I proceed to fix this misconfiguration and what should my next concrete step be? The website is live, and I don't want to risk service interruption. Ideally, both VMs should be in the same virtual network, and should communicate with eachother via a static internal IP. Please forgive my ignorance. Any help would be greatly appreciated.
I guess i'll be the bearer of bad news. You have to delete both VMs while keeping the VHDs in the storage account, then recreate the VMs (reattaching the disks) in the Virtual Network.
Since these are Classic VMs you can use the old Portal when re-creating them. You'll find the VHDs under "My Disks" in the VM creation workflow.
Alternatively, just restrict the inbound access with an ACL on the database Endpoint. Allow the VIP of the first VM and deny everything else. This is good enough for almost any scenario, since if your Web Server gets compromised it's game over. It makes no difference how they exfiltrate stuff off your database (over a VNET or over VIP).
Here's the relevant documentation page for setting up Endpoint ACLs:
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-classic-setup-endpoints/
I'd like to setup the below infrastructure in Azure. I have one possible solution, but it seems like it makes compromises in security architecture. Is there a better way to do this in Azure than in my compromised workaround?:
VM #1: Role: SQL Server and IIS. Server should have a unique public IP address. The hosted websites will be available through public port 80, and connect to local SQL Server.
VM #2: Role: IIS. Server should have a unique public IP address. The hosted websites will be available through public port 80, and will connect to SQL Server on VM #1.
This has been my experience so far:
No issues setting up VM #1.
With VM #2, I tried building it in the same cloud service as VM #1. When I did that, it was assigned the same public IP address as VM #1. Thus, in this scenario, hosting websites on port 80 on both machines doesn't work.
Next I tried building VM #2 in a different cloud service. This resulted in assignment of a unique public IP address. However, I was unable to obtain connectivity to SQL Server on VM #1.
Things I tried for the above: VM #1 SQL Server set as mixed mode, named SQL account provisioned (and connectivity confirmed locally), SQL configured to allow incoming remote TCP connections, firewall rule opened for incoming connections on TCP port that SQL runs under, but so far have not been able to connect to it from VM #2.
One architecture I believe would work is to open a public port on VM #1 and map that to the private SQL Server port. Then VM #2 could connect using the fully-qualifed public DNS name of VM #1. I believe Azure also would allow connectivity to be constrained to the public IP address of VM #2.
However, this seems less than ideal, because now SQL communication is being routed through a more public route than one would normally design for a data center, and an extra public port has to be opened on VM #1 (even if constrained by IP address, I'd rather not expose that surface area if not necessary). Additionally, sending the SQL Server data over a more public network hypothetically means transport security may need to be considered.
Research indicates connectivity between 2 VMs on different cloud services may not be possible using private ports, although the info I've found so far is not conclusive. So again, is there a better way to do this in Azure?
A single cloud service is a security boundary and the only way into it is through a public (input) endpoint on the unique public VIP of the service. A Virtual Network (VNET) can be used to host multiple cloud services and allow private visibility among them without going through a public endpoint.
A typical model would be to put an IIS website in a PaaS cloud service with a public VIP and the backend SQL Server in an IaaS cloud service with a public VIP but NO public endpoints declared on it. Both these cloud services would be hosted in the same VNET. This allows the front end web role instances access to the backend SQL Server instance over the private VNET. There is a hands-on lab in the Windows Azure Training Kit that describes precisely how to implement this.
In this case I would recommend separating the IIS/SQL Server combination so that the SQL Server box is in an IaaS cloud service with no public endpoint (although it will always have a public VIP). I would also recommend using either a Point-to-Site or Site-to-Site VPN which would allow you to access the VMs without exposing a public RDP endpoint. A point-to-site VPN is developer focused and very easy to configure. A site-to-site VPN is more of an IT thing since it requires configuration of a VPN router such as Cisco, Juniper or Windows Server.