SQLServerCentral Editorial

Misconfiguration is a Problem

,

Once upon a time I worked on an OS/2 server, supporting a SQL Server application that had a few issues. The server crashed every half hour or so, and most of my "effort" was spent rebooting the physical machine in a particularly cold data center. I decided to look deeper into the inner workings of the database instance and eventually connected through the default "probe" account and "probe" password to access related systems, finding some mis-configurations and problems with our server. It didn't eliminate my babysitting, but it reduced the number of times we had to reboot the server every day. 

I've connected with "system" and "manager" on Oracle systems, "root" and "" on MySQL, "admin" and "admin" on many routers and other network devices and a few more well known combinations. Usually this was because I had the need to get something done quickly and using defaults allowed me to do my job. However it was disconcerting to be able to access supposedly secure systems using defaults. 

There was a problem with the HHS servers earlier this year and a few were breached because of the misconfiguration of a server. A test server with default values was attacked, and malware installed. Supposedly no personal information was released, but it's disconcerting that the defaults were still in use. I was very happy when SQL Server stopped allowing blank sa passwords (and even an active sa account) in setup, where people far too often click "next", "next", "next" without thinking. I dislike having defaults built into software, but even more I dislike administrators leaving them active, on any server.

There's one great quote in the article that says "I would assume that the test servers are configured in a way that reflects the production environment." Changes are that the HHS was protected precisely because configuration is usually so bad that dev and test servers are likely configured nothing like production. It's not the I think production servers are better, or more securely, configured. It's more likely that standards or procedures aren't in place to ensure that environments are configured the same.

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating