I'm planning on provisioning a web server and database server in a server farm environment. They will be in the same network but not in the same domain, both windows server 2008 and the database server is sql server 2008. My question being, what is the best way to secure data in transport between the servers? I've looked into IPSEC and SSL but not sure how to go about implementing either.
As you mentioned, IPSEC is your best bet for SQL traffic (port 1433), and SSL for web traffic (port 443).
IPSEC can be enabled through Group Policy in Active Directory.
My knowledge of IPSEC is limited but I believe that the encrypted traffic is put into a tunnel, which then travels through a different port.
When IPSEC is then turned on, traffic over port 1433 can then be blocked either through an ACL or a Firewall, thus ensuring your SQL traffic is completely secure.
If you have the ability to configure Group Policy yourself you may find this link useful.
http://www.petri.co.il/configuring_ipsec_policies_through_gpo.htm
Related
How do I make connection to an AWS hosted database, and pull or query data into a local or Azure hosted SQL server DB? Can I be directed to the right place or resource?
Thanks.
There's nothing special about the fact that they're in AWS or Azure VMs. For this to work, you need TCP/IP connectivity from your client to the server, and you need port 1433 to not be blocked along the way.
The VM in AWS or Azure needs to have an externally visible IP address, or you need to be connecting via a VPN to the internal network of the cloud-hosted system. The operating system on that VM that's hosting SQL Server needs to have a firewall rule that allows port 1433 inbound.
Once you can do that, you can then just set up a Linked Server on your end, that refers to the SQL Server at the other end. That will allow you to query the tables on the server via 4 part names i.e. linkedservername.databasename.schemaname.tablename.
If you have SQL Server with the same collation at both ends, also ensure you set "collation compatible" on the linked server configuration. (It can make a huge performance difference)
I have an Azure VPN client that I use for connecting to a web server using RDP and to an Azure SQL Server instance using SSMS. The problem is, I cannot connect to both at the same time.
When I go to the Networking properties of the VPN connection, then select the properties of TCP/IPv4, if I select "Use default gateway on remote network", I am able to connect to RDP, but not SQL Server. If "Use default gateway on remote network" is not selected, I am able to connect to SQL Server, but not RDP.
What can I do to be able to connect to both at the same time?
As far as I know. By default, once a successful VPN connection creates, the highest priority entry will be added automatically in the local machine route table. When you select Use default gateway on remote network, data that can not be sent on the local network is forwarded to the dial-up network when you are connected to a local network and a dial-up network simultaneously. The local network prefers to select a VPN connection route. The connection to a local network is disconnected automatically by default. So you could RDP to the web server via the private VPN connection in the dial-up network. You could not access the Azure SQL server since the traffic from the dial-up network is not allowed in the firewall of Azure SQL server firewall. In this scenario, you could check if the outgoing traffic to the Internet from your dial-up network is blocking.
When you un-select Use default gateway on remote network, usually default gateway of the PPP adaptor will be empty. In this scenario, you cannot connect to resources on the remote network because you have disabled the Use Default Gateway on Remote Network setting in the VPN TCP/IP configuration. You could add routes for the desired VPN subnets. Refer to this paragraph Configuring Split Tunnel for Windows
You could use route print on the local machine to check the route entry. Compare the route table in the two situations. More details you could get from this DOC.
It sounds to me like you need to configure a service endpoint on your vnet to allow traffic to route through to your Azure SQL database.
https://learn.microsoft.com/en-us/azure/sql-database/sql-database-vnet-service-endpoint-rule-overview
Try the link above for help configuring it.
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.
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.
I need to transfer data daily from SQL Server (2008) to SQL Server (2005). One of the servers is located at our web host so the data will be transferred over the Internet. On the same network I would use SSIS to transfer the data, but over the Internet this is not a secure option. Is there a secure way of achieving this?
You can use SSL with SQL Server (2000/2005 Instructions / 2008 Instructions) and then force protocol encryption on the connection between both machines. You don't have to use a purchased SSL certificate either, you can use Windows Server Certificate Services to generate one - however if you do so then the CRL must be on a machine that both servers can connect to. An easy way to do this is install Certificate Services on a stand alone machine, perhaps just a VM and the configure it to embed a public DNS name for it's CRL. This doesn't have to be a machine running Certificate Services, just something you own and can upload to. Then you can generate the certificates and publish the CRL and tada, all done.
You will need to ensure the service account SQL is running as has access to the private key of the certificate it is using.
Generally it isn't recommended to have your SQL Servers exposed to the Internet, although that may be out of your control in this case. In your position I would investigate developing some separate Web Services that would perform the transfer of the data. These can then be secured using a variety of methods, such as SSL and WS-Security and other custom user permissions. If that isn't possible then blowdart's answer seems like the way to go.
You can use Service Broker:
Built into SLQ Server engine itself, no need for external process to drive communication.
Compatible protocol SQL 2005 and SQL 2008 communicate over Service Broker out-of-the box.
No need to expose either server to the internet. Through Message Forwarding you can expose
just a SQL Express, with no data on it, to the internet to act as a gateway that lets messages into the back end target.
Communication is encrypted.
Speed, the sample in the link shows how you can exchange over 5000 1k payload messages per second between commodity machines.
Unlike SSIS or replication Service Broker is a general communication framework so it won't provide support to extract the changes and to apply the changes, with conflict resolution and the like. You would have to code that part yourself.