Is setting firewall rule for SQL Azure server on specific IP address (or range) is favored on setting the 0.0.0.0 firewall “Allow Microsoft Services access to this server” rule in term of security ?
As far as I know 0.0.0.0 allow all access from Azure local IPs (but of course to actually connect to the database the specific server name and login username/password will need to be offered).
Using 0.0.0.0 makes the configuration more easy since there is no need to track the role instances IPs in order to enable SQL Azure server connections but it does open some risks.
I would like to hear you opinion.
Thanks!
The 0.0.0.0 setting is used internally by Microsoft to allow their services to connect to your SQL instance. Of course, in theory your SQL database is open to any Windows Azure machine out there but it's not like the potential connection surface is the entire world.
Firstly,
Allowed Windows Azure Services - Will allow only azure services to access the database.
Secondly,
To be able to access the database server from any other endpoint, you need to add firewall rules to allow those specific IP ranges. If you want to connect from a machine with ip, 132.99.xx.xx you need to add a rule with start IP and end IP as 132.99.xx.xx
It is always a good practice to add the ranges which are necessary, to avoid any chances of attack
Hope this helps!
Related
We have a sql server firewall setup with no IP access and "Allow Azure Services" flag also set to off.
I understand this means no azure services and no external clients will be able to access the sql server and database.
however, when i try Import Database option on sql server, with bacpac stored in azure storage, we get a strange error of an IP that needs to be given access in sql server firewall. The error reads.
Client with IP address 65.52.129.125 is not allowed to access the server.
While our azure infra is in West Europe, there is no mention of what this IP belongs to and what is the purpose of it.
The same error of course also occurs from Infra as a code approach and CI-CD Pipelines. and I think adding an IP without any information is risky.
Has anyone faced this before? or if anyone knows , what is azure database import using underneath for which this IP needs access and will it always be the same?
65.52.129.0 - 65.52.129.255 is an IP address range owned by Microsoft Corporation and located in Netherlands.
Please read the following explanation about why you should enable Azure Services access on the firewall at least while doing export/import operations. When you finish import/export operations, then disable Azure Services access.
"The IP address space used for outbound connections from the Import/Export Service infrastructure to the target logical server is not documented, and is subject to change at any time. Therefore, given that connections to the target Azure SQL Database server are gated by server firewall, the only fully reliable way to ensure that the Import/Export service will be able to connect is to enable the firewall rule that allows access from all Azure services (or, equivalently, from the 0.0.0.0 IP address). Obviously, opening the firewall to a large IP address space is a network security risk. Security conscious organizations will want to mitigate this risk by disabling this firewall rule as soon as the import operation completes successfully..."
Source is here.
If I create a VNet named mySiteToSitevNet and configure it for Site-To-Site connectivity. I create a Virtual Machine assign it to use mySiteToSiteVNet as its network. I Install SQL Server on it.
Do i get Public IP to connect to that SQL Server from my WebApp which does not have VNet associated to it?
If not, how do I make my WebApp connect to that SQL Server and use the database?
There are 2 options:
Since you already have a Sign to Site VPN then you can VPN in from your website's box to enable it to access the SQL and that's the most secure way.
If for some reason you don’t want to VPN in, first you need to figure out why you don’t want to do this. If there’s a really good reason to not VPN in, then continue with setting up direct Internet access to the SQL Server.
To open an endpoint browse to the VM in the Azure portal. Open the properties of the VM in the Azure Portal, then click the “All Settings” option. Then select “Endpoints”. It’ll look something like this.
If you see a “SQL Server” endpoint with 0 ACL Rules then the work is half done (shown above). If there are ACL rules then you should be finished unless you need to add more ACL Rules.
If there is no SQL Server endpoint click the “Add” button at the top of the Endpoints blade. Name the endpoint “SQL Server”, select the protocol TCP, then set the ports to 1433 (or whatever TCP ports you want to use, but 1433 is the default). Select to setup access rules for whoever needs access and block any subnets that don’t need access and then OK back to the VM’s properties.
At this point you can connect to the SQL Server instance through whichever method you’ve setup. If you are using either VPN option you can just connect to the Virtual Machine’s network name. If you are going through the public endpoint (again this is REALLY NOT recommended) you’ll need to connect to the machines full DNS name.
Any VM deployed in a Virtual network can also be exposed through public Internet, so the answer to your question is Yes, it can be given a instance lvel public IP address (https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-instance-level-public-ip/) or port behind the public load balancer (https://azure.microsoft.com/en-us/documentation/services/load-balancer/)
I've a single Web Role Cloud Service instance running the South East Asia, with a SQL Azure Database running in the same region. I am hitting a firewall issue and the connection is blocked unless I add the Cloud Services public virtual IP to the SQL server firewall.
From everything I've read, if the two systems are in the same region, and 'Allowed Windows Azure Services' is enabled (which adds 0.0.0.0 to the firewall), then the two should be able to communicate internally?
I have some concerns about things being routed inappropriately (is data going outside the network / am I being charged for it), and having to reconfigure the firewall should the VIP change.
Is there some other address I am supposed to access the SQL azure instance by (currently hitting blah.database.windows.net)?
Your understanding is correct. If I were you I would open a support ticket with Microsoft; I have heard of this issue before, although I never experienced it myself. This sounds like an issue, so report it and watch your next invoice carefully.
Firstly,
Allowed Windows Azure Services - Will allow only azure services to access the database.
Secondly,
To be able to access the database server from any other endpoint, you need to add firewall rules to allow those specific IP ranges. If you want to connect from a machine with ip, 132.99.xx.xx you need to add a rule with start IP and end IP as 132.99.xx.xx
Hope this helps!
Apparently one must explicitly specify (whitelist) the IP addresses that will be allowed access to a SQL Azure DB. I want, though, to have N-gazillion* users that will access these tables for data specific to them.
delusions of grandeur/megalomania
Will these need to first provide me with their IP address so that I can add it as a valid entry, or is there a programmatic way to do it, or some other workaround?
It would be advisable to have some sort of middle ware access the db and not your clients directly.
However if you want any IP to be able to connect to the db just add this entry to the firewall list:
Azure Portal -> Databases -> Servers -> Configure and add the following rule:
How will your users be accessing the DB, via a Web App (front end) or directly (I assume you won't give users direct access to your DB?), if its via a Web App (presentation layer) then all you need todo is grant access to this IP address of the presentation layer/service layer (and if hosted in Azure its beside it).
SQL DB Azure has two types of access restrictions (more info here) "Windows Azure SQL Database Firewall"
Server-level firewall rules:
Database-level firewall rules
You could either open up all IP address 0.0.0.0 - 255.255.255.255 (not very secure) or come up with more finer grained policies based on the above Database firewall rules.
The only way is to do it is via SQL query. Azure shows only Firewall Server rules to be visible only on the portal but on database level the only way is via SQL.
-- Enable Allconnections.
EXECUTE sp_set_database_firewall_rule N'Allow All', '0.0.0.0', '255.255.255.255';
Login to azure Portal
select your database subscription
click on Tools
Now there is option 'Open in VisualStudio' (click on it)
You can see "Configure Firewall" click on it.
Add you new IP.
Done :)
If you let them talk directly to your database (for example via SSMS) you need to enter their IP (or you can just whitelist the whole range). Usually they will use your database via your own API, then it's not needed to whitelist their IP addresses.
My Azure web role can, using remote desktop, connect with a browser (IE) to google.com and to a DMZ server on our corporate network.
My web role cannot connect via HTTP GET (IE) to a non-DMZ box behind the firewall. My web role cannot ping this box either. My service is hosted in north/central, allegedly all published IP ranges of north/central have been granted access to the target IP by our CorpIT people. They claim they are seeing no traffic via their sniffer from my compute instance IP when I attempt to ping or HTTP GET against the target local IP.
CorpIT wants help from the Microsoft side but we have no Microsoft relationship. I'm convinced this is the outcome of months of slapdash thirdhand firewall rules applied to the target environment in question. What can I do to further elucidate this for CorpIT?
thx in advance!
You can try to run a trace route or get a network trace from the Azure instance and see what you get back from where. You could also create a support case with microsoft:
https://support.microsoft.com/oas/default.aspx?&c1=501&gprid=14928&&st=1&wfxredirect=1&sd=gn
I wouldn't bet on using the IP ranges to make your applications work correctly. Windows Azure already provides you with some services that allow you to solve these types of issues:
Windows Azure Connect: Allows you to create an IPSec secured connection between your servers and your hosted services. This means you won't need to add rules to the firewall for incoming traffic.
Windows Azure Service Bus Relay: Allows you to expose WCF services to the cloud without having to add rules to the firewall for incoming traffic. Choosing this option might add some extra work for you to do, you might need to create a WCF service if you don't already have one and change the code in your Web Role to connect to this WCF Service.