Printed 2017/02/23 11:43PM

Isolating SQL Server from other systems


In a recent explanation about the RSA breach, Rick Wanner wrote on the Internet Storm Center (ISC) Diary:

The traditional paradigm of a well protected perimeter with a soft inside should be dead.  There are just too many ways to circumvent the perimeter, spear phishing being just one.

He then goes on to say:

Many have been advocating for years moving the prevention and detection closer to the data.  There are a lot of approaches that can be used here, but in my mind it begins with segregating servers from the desktop LAN and controlling access to these protected enclaves as thoroughly or better as we do our perimeters today.  It means classifying your data and installing protection and detection technologies appropriate to the sensitivity of the data.

This goes along with what I said in my SQL Connections SQL Server security presentation. The majority of users who need to access SQL Server only need to be able to connect to two things:

Otherwise, they don't need to touch SQL Server. Therefore, if we can isolate SQL Server better via the following mechanisms, the less likely it will be breached:

There are some servers/worsktations that a SQL Server will need to connect to beyond these ports if it is on the domain:

A diagram to describe this type of network security was this one:

Most infections start at user workstations. So it only makes sense to block off traditional attack vectors by firewalling off access to only what's necessary. Yes, this is harder. But it doesn't have to be a lot harder. For instance, if you can't decide the exact subset of user workstations that need access, or if it is too costly to do (based on the estimated cost for an exposure), then simply block off the client VLANs such that they can only connect to SQL Server on the ports listed above. This prevents worms that might attack via NetBIOS, scans that use pings (ICMP) to try and recon for juicy targets, etc. There are just too many ways to get inside a firewall and launch an attack from there. Therefore, what we're needing is additional barriers within the internal network, but not barriers that prevent reasonable access.

Copyright © 2002-2017 Redgate. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.