SQL Server Telemetry

  • Steve Jones - SSC Editor - Tuesday, April 18, 2017 8:20 AM

    Sean Redmond - Tuesday, April 18, 2017 3:01 AM

    Are they? Really?
    Or could it be that an order has come down from on high in Microsoft that metadata is the new gold rush and that whatever can be collected must be collected.

    What I don't really understand is why so many SQL Servers have Internet access. These servers should only be accessed internally or by their application servers. The idea that so many SQL Server installations are exposed to the Internet sends a shiver down my spine. Are you who is charged with the well-being of your DB-server up to speed with cybersecurity or do you hope that a virus-scanner and a religious devotion to updates and patches will keep it safe?

    Re: the first part, I think mostly they are. Most developers look for ways to improve things and want to collect data with only good intentions. There are certainly other groups, such as sales and marketing, that start to turn things a different direction.

    Re: Internet access. Most firewalls and systems allow  access out, meaning they  allow connections initiated inside the firewall to go outside to any address not blocked. It's only connections coming in that are blocked. That's the default way most systems are configured.

    But, the problem is that the telemetry connection (at least currently,) *IS* an outgoing connection to a presumably non-blocked address (anyone want to bet MS is using something.microsoft.com for the endpoint?)  So, most firewalls won't be blocking this connection.

  • We are required to block this "data" at the firewall due to the nature of our business. "nuff said."

    As for Microsoft, they currently seem to be more trustworthy than most of their competitors, but I've been using their products since the early '80s and still remain skeptical due to decades of experience. 
    I've caught 2 zero day exploits on my home Windows machines which resulting me in banishing Windows to hygienic VMs and running more secure host OSes. I do run a Windows Phone since Android is riddled with security holes and I have no fondness for Apple.

  • jasona.work - Tuesday, April 18, 2017 9:37 AM

    But, the problem is that the telemetry connection (at least currently,) *IS* an outgoing connection to a presumably non-blocked address (anyone want to bet MS is using something.microsoft.com for the endpoint?)  So, most firewalls won't be blocking this connection.

    Problem? May or may not be, but it's not necessarily the case or a sign that too many servers have Internet access. Until more admins learn to script and manage their work through non-browser access, I suspect this won't change.

  • If you run a DB server in the cloud then it needs internet access of some sort.  Microsoft make a big song and dance about the cloud therefore cloud access is required.

    I can remember life pre-Microsoft and consequently have never understood the rabid anti-Microsoft sentiment.  Compare SQLBits with the Oracle equivalent.  Where's the equivalent of SQLServerCentral?  Was there an equivalent of Codeplex for non-opensource vendors?

    It would be interesting to see who contributes most to open-source projects.  If you have to run enterprise versions of open-source software you soon find the costs are no cheaper than proprietary equivalents so if is some form of commercial purism that drives the dislike then it is misplaced.

    In terms of honest and honourable intent I'm sure Microsoft perceive themselves to be operating in that manner. Other people may have a different perception.  History teaches us that an event has many different interpretations depending on the viewpoint of the observer

  • Steve Jones - SSC Editor - Tuesday, April 18, 2017 9:51 AM

    jasona.work - Tuesday, April 18, 2017 9:37 AM

    But, the problem is that the telemetry connection (at least currently,) *IS* an outgoing connection to a presumably non-blocked address (anyone want to bet MS is using something.microsoft.com for the endpoint?)  So, most firewalls won't be blocking this connection.

    Problem? May or may not be, but it's not necessarily the case or a sign that too many servers have Internet access. Until more admins learn to script and manage their work through non-browser access, I suspect this won't change.

    Yes, it would depend on the business requirements if it were a problem or not.
    For my home servers, if I weren't too lazy to set up a SUS host, I'd probably banish them from the Internet, it's fairly straight-forward to do.
    Step 1, remove the gateway IP from the network config (least secure method though)
    Step 2, block out- and in-bound traffic to the server IPs at the firewall (even better if you can block by MAC, but my firewall doesn't do that)
    Step 3, Group Policy to block execution of IE on the servers (and Chrome and Firefox and Safari and Opera)
    Now, would that be 100% Internet blocked?  Probably not, I'm sure there's holes in my process you can drive a truck through.  But, for a home network, it'd likely be a good start.

    For a business, you can start by black-holing certain web addresses, in addition to some of the steps above (you may need to keep the gateway if you've got multiple subnets or VPN remote users.)

    One thing I'm seeing at work (not on my servers, thankfully) is more and more server applications that require a web browser to configure, LOCALLY, in order to access the web configuration interface to be accessible from client PCs.  Which, if you lock down IE on the servers (prevent it from running,) means you can't configure the application...

  • jasona.work - Tuesday, April 18, 2017 10:57 AM

    One thing I'm seeing at work (not on my servers, thankfully) is more and more server applications that require a web browser to configure, LOCALLY, in order to access the web configuration interface to be accessible from client PCs.  Which, if you lock down IE on the servers (prevent it from running,) means you can't configure the application...

    Sign of the times. Configuring an HTML5 app to handle things for a local service is way, way quicker than building a thick client. Get used to it.

Viewing 6 posts - 16 through 20 (of 20 total)

You must be logged in to reply to this topic. Login to reply