I am setting up a system that runs on Azure but needs to access an on-premises SQL Server. I've built it out as detailed in this article. This calls for me opening port 1433 to the world which looks like a serious security problem. Is there any way to open that port and still have it secure (I know that I can have complex user ids and passwords and everything, but is there a better way to secure SQL Server)
The connection between your on-premises DB and Windows Azure Connect will be secure by default via the IPSEC protocol
"Windows Azure Connect uses industry-standard end-to-end IPSEC
protocol to establish secure connections between on-premise machines
and roles in the cloud. Unlike a traditional Virtual Private Network
(VPN), which establishes secure connectivity at gateway level, Windows
Azure Connect offers more granular control by establishing secure
connections at a machine and role level."
http://blogs.msdn.com/b/usisvde/archive/2012/03/14/windows-azure-security-best-practices-part-6-how-azure-services-extends-your-app-security.aspx
Your DB won't be publicly available, only VM's on the Azure Connect will be able to see it.
Your traditional firewall and on-premises security policies and procedures will still hide your DB in your Enterprise Environment, all you are doing is giving Windows Azure VM (Roles) the ability to see it.
I saw the comment discussion on #user728584's answer about opening port 1433. Port 1433 has nothing to do with Azure Connect, which is essentially a VPN tunnel between on-prem boxes and a collection of Windows Azure role instances. Azure Connect requires an agent to be installed on any on-prem server you're adding to the Connect Group and doesn't require an inbound port to be opened. In your case, you'd add the agent to your SQL Server box, which would then be part of the connect group and accessible directly from your Windows Azure Role instances (for the roles you add to the group). The Connect Agent then establishes the tunnel.
The Connect Agent has a special key baked in, generated for you, making it unique. But even if someone somehow obtained the installer for your specific Connect Agent, it wouldn't help at all, as you still need to add that node to the Connect Group. So, this is a secure setup.
Related
I am unable to connect my RDS SQL Server instance from my AWS EC2 instance.
I have installed SQL Server Management Studio on my AWS EC2 Windows Server 2019 instance.
I am neither able to ping my RDS endpoint from that machine nor able to connect using SSMS. In the security group inbound rules for RDS I have entered IP of my EC2 instance under all traffic option, also tried using SQL Server option in security inbound rules.
There's two key questions that are relevant here: 1) is the connectivity allowed in AWS, and 2) is the connectivity allowed by the host/applications on the individual instances.
For 1, you need visibility into the networking aspect of your cloud. I use Batfish's virtual traceroute in your environment. There's an free and open source project (https://batfish.org) or you can try a free trial of the enterprise offering (https://www.intentionet.com/trial).
After you validate that the traffic is allowed in AWS (no Network ACLs or security groups are misconfigured, vpc peerings / routing tables are correct, etc.) you should move on to verifying application config on the actual hosts.
(Disclaimer: I work on Batfish and Batfish Enterprise).
What you need to do is:
The security group that you have attached to the RDS instance you need to add a rule for the inbound section of the security group to be SQL Server and have the source of that rule be the same name as the security group, this is called a self referencing security group rule. Then go to the EC2 instance and attach that same security group to the instance. This will solve the Security Group potential problem.
The other piece you need to check is if the EC2 instance is in a different subnet than the RDS SQL Server you need to make sure the Network Access Control List (NACL) will allow the inbound/outbound traffic of SQL between the subnets.
I created a sql database in the azure (PAAS) and trying to connect using SSMS 2017.
Unfortunately, I do not have admin rights to my machine. considering this, Can you please let me know what are my options in connecting to azure sql db?
Here is the error I am seeing.
Since your company network has port 1433 blocked, you can try the following. Most companies have a free WIFI for guests or visitors, use that WIFI to connect to your company using a VPN client like FortiClient, Citrix Workspace or SonicWall NetExtender. While connected to your company network with these clients you may still be able to connect to Azure SQL Database.
Make sure Windows Firewall or other security software do not have port 1433 blocked also.
I have my api running on Azure and it is working perfect if it is connected to Azure SQL database.
I want this api to use my local database i.e on-premises database. I made my database to accept connection from remote and also enabled TCP/IP in wf.msc and also created an inbound rule for 1433. Is there anything i had to do to make this work? I tried to use the following connection string in azure :
ASP.Net core 2.0 web api written in C# hosted on azure and trying to access the sqlserver database on the Virtual Machine.
I tried as mentioned in the following to create hybrid connection but the status keeps saying 'Not Connected'
https://learn.microsoft.com/en-us/azure/app-service/app-service-hybrid-connections
Server=tcp:<mycomputername>,1433;Initial Catalog=MyDb;Persist Security Info=False;User ID=userid;Password=pwd;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
If your On-Prem SQL VM is behind firewall, you need to allow inbound from Azure. Usually you poke a hole in your On-Prem firewall and allow inbound from your Azure (source) to your On-Prem SQL server (Destination) on a particular port.
We are building a client solution that will be hosted on servers in a data-centre. It consists of several servers all related to providing the client solution. There is no internal network to protect but for some reason our UAT environment has the notion of a DMZ in the server diagram.
We have an IIS box which will have a public IP. Then we have two servers DB(Sql Server) and APP that are only on the internal lan with no public IPs. You can only RDP to these servers via VPN. Our IIS server needs sql access so port 1433 is open from IIS box(DMZ) to the sql server. We are also opening several ports from the IIS server to the APP server which hosts WCF services.
My understanding was that a DMZ was meant to protect internal private networks and that these networks should not be accessible from the DMZ but we are now opening up ports to both our APP and DB servers so they are accessible from the DMZ. In the end most of our servers are accessible from the IIS server via certain ports.
We originally wanted to setup our SQL server for AD authentication only but since our IIS server is in the DMZ and has no AD access we will be forced to enable mixed mode authentication in SQL server. This might be another security issue in it's own since we are now forced to store passwords somewhere on the IIS server to be able to auth against sql server.
Are we not perhaps missing the idea of a DMZ?
So with a system where you have a DMZ, there is also a firewall involved.
So your system should look like this I think:
SQL-server hosting internal data
Other servers needed for the company
---- firewall ----
SQL-server hosting data for web solution
AD-server (if needed)
Web-server
FTP-server (could be on the web server also)
With this setup you don't expose company-sensitive database to the outside world and you also don't open up a port in the firewall making it possible for attackers to (maybe) get access to the internal database which has company sensitive data...
Just my suggestion based on the information provided.
So I have a server, being hosted by an external hosting provider. To work on the server, I just need to remote connect with an IP address, a username, and password. When I remote connect, I can open SQL Server Management Studio and work on the databases. I use:
Server Name: (local)
Authentication: Windows Authentication
Username: SERVER\Administrator (Administrator is the username to remote connect)
I would like to connect to the server databases from SQL Server on my local machine. I obviously can't use (local) as the Server Name, and I can't use Windows Authentication.
I'm terrible with configuring things like this, and I really don't even know what to search for. Do I need to set up something in SQL Server on my server? Or can I use the credentials for the server to connect?
You probably won't be able to do this as the firewall will block the port that SQL Server communicates over. The hosting provider probably won't allow this traffic over their firewall as it's a big security risk.
Essentially you're stuck with the remote desktop.
The other possibility is a VPN arrangement or SSH tunneling. See if your provider can support an IPSEC VPN. If you can set up a VPN then you should be able to connect to the server that way.
There are going to be two issues.
The ports will need to be open on the remote server to connect from your machine to the server
When using Windows Authentication, there will need to be a trust relationship between SERVER and the authentication domain for the account running SSMS on the local machine
You can get around 2 by making a SQL Server account in the server (if you have rights to do that) and logging in as a SQL Server user instead of relying on a domain controller for authentication.
1 is not as easy to get around without some kind of VPN or other tunnel. Once you set up a SQL Server user, just try to connect to the machine by IP address instead of (local).