I’ve been giving an encryption talk over the last year, focusing on educating DBAs on the various features and capabilities available in SQL Server. One of the things I note in the talk is that SHA1 is not considered secure. You should avoid SHA or SHA1 if you are using SQL Server 2012. If you’re on an earlier version, you don’t have a choice.
Hopefully we’ll have more choices in the future. NIST has selected an SHA-3 algorithm as a new standard. This should provide more security, though there will be some time before we find out if there are any problems or potential attacks against this algorithm.
How can you put any server on the Internet without a firewall? Even most home routers enable a NAT router and basic firewall these days, not allowing connections in by default. In the last 5-6 years, the technology has been widely available, even to uninformed home users, to not deploy any system on the Internet without protection.
So how do these servers get out there? Are these development systems? Are people opening 1433 so they can test an application or access their remote SQL Servers? That’s what I suspect. Many developers I know are optimists and they don’t expect people to be pinging their servers or accessing their systems in any way other than how it’s designed.
We’ve been hacked here at SQLServerCentral.com a few times over the years with SQL Injection techniques, but never to my knowledge with an attack directly against our SQL Server. For a long time we did have our SQL Server exposed, but not on 1433. It was on a high, random port that was unused by any other service and we had strong passwords on accounts. It was a convenience service, we had login tracking, and I never saw an unexpected attempt in our logs.
However if you run a corporate SQL Server and need to stick servers outside your firm’s firewall in some type of DMZ, at least close off port 1433 to anonymous access. Go spend the $100 out of your pocket for a small router that can at least protect your servers with basic NAT and prevent traffic from getting directly to your database server. It might not be the best solution, but it’s better than nothing.
There’s no excuse these days for putting a server out on the Internet without at least basic NAT protection. Some type of router or firewall should protect every server, and probably every computer, and only allow those services that are really needed. For most servers, this is port 80 and nothing else. Allowing access to SQL Server, RPCs, or any other port that’s not meant for anonymous access, is really stupid.
And if you can’t figure out a way to securely make your service available to partners or customers, then you should hire someone that can. There are plenty of networking professionals out there that can help you set things up correctly.
Know your limits, ask for help, and don’t jeopardize your company’s security because of ignorance, pride, or laziness.
Steve Jones
The Voice of the DBA
The podcast feeds are now available atsqlservercentral.podshow.comto get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted. You can get feeds from there.
Today’s podcast features music by Wakamojo, the Kansas band featuring our very own Adam Angelini, DBA from the heartland and SQLServerCentral.com community member.
I really appreciate and value feedback on the podcasts. Let us know what you like, don’t like, or even send in ideas for the show. If you’d like to comment, post something here. The boss will be sure to read it.
As an FYI, if you want to host or participate, contact Adam Machanic.
Horrifying
The thing that first comes to mind for me is my first job in Denver. I had interviewed with a small financial services firm looking for a DBA. We thought it was a good fit and I came out to start work in early 1999. Fortunately my wife stayed back in Virginia to sell our house and I was alone since I ended up working a lot.
The first surprise I had when I arrived for work was that not only was I responsible for the databases (v6.5), but that I was also going to manage the network administrator. He wasn’t that experienced and needed some guidance because we were experiencing daily problems.
The second surprise was that all of our applications used the sa account. We had 3 or 4 standalone workstations devoted to loading pricing and position information every morning from clients, all using SA. We also had a web application and a thick client application (VB6) that allowed clients to authenticate with a name and password (stored in plain text) in the database, but the connection to SQL Server as with sa.
However the most horrifying thing was that all developers used the “sa” account to connect to our database servers, in development, QA, and production, with the same password.
A scary situation.
The daily issues actually helped here. I started to tackle our problems, requiring the developers to fix the applications one by one, using a normal user account. It required months just to convince our management that stability was compromised by developers making changes in production, but we were able to change the sa password in all environments and make it different. We then started to require applications to use difference accounts, and a year later, we had ad least provided more stability by removing the “quick fixes” made in production.
All sorts of poor practices at that job, and when I left after almost two years, there were still numerous issues.
Are security services like this going to be outsourced in the future?
Security is becoming more of an issue for many companies. Increased regulation, more scrutiny from the media, and customers that are more concerned about their data handling and privacy are forcing companies to spend more resources to ensure better security. However building secure systems takes skill and experience, something many companies lack. Acquiring those skills can be hard, and I think as an industry, we do not disperse information on secure coding well. If we could get developers and administrators to read about security with the same level of interest they show in the iPhone 5 v the Galaxy S3 v the Lumia 920 debate, perhaps things would be different.
One vendor is betting that companies will look to outsource security needs. Webroot has moved to a hosted service, confident that customers will move to the new service for its ease of implementation and arguably better protection. By controlling the software themselves, and updating it as quickly as possible to meet new threats, Webroot can do a much better job of ensuring security than most companies can by managing the service themselves.
That’s an interesting idea, and it’s similar to the idea of threat detection that Bruce Schneier wrote about a decade ago. This doesn’t solve application issues, but it can improve security for threats that attack your network. That’s if the vendor actually does their job correctly.
There are any number of issues with this model, but as more companies get comfortable with the idea of renting services and platforms, moving to the “cloud”, I can see this idea growing. For us in the data world, this means that we have another group to interface with, potentially audit to ensure they are not violating any data protection. As far as your actions if you find issues? That can be complicated, but it certainly will require that your communication skills are strong.
The Voice of the DBA Podcasts
We normally publish three versions of the podcast each day for you to enjoy. Today there is no podcast due to Steve being ill. Hope to have the podcasts return tomorrow.
