January 12, 2017 at 10:35 pm
Comments posted to this topic are about the item Securing Your Instances
January 12, 2017 at 11:12 pm
Steve Jones - SSC Editor - Thursday, January 12, 2017 10:35 PMComments posted to this topic are about the item Securing Your Instances
I agree with your article, Steve. We started changing ports for SQL servers many years ago, just because we hosted multiple servers behind one external IP address, back when getting additional IP addresses from the provider was expensive. Later, we decided that there was no reason to ever have a SQL Server on the default address, at least for external connections. Since we build the EXE that accesses the server, it's pretty easy for us to add the port number. Users don't see it. Maybe it doesn't add much in the way of obscurity/security, but it certainly doesn't hurt.
Student of SQL and Golf, Master of Neither
January 13, 2017 at 12:20 am
Back in the 1980s car theft was rife in the UK and insurance costs rocketed.
There used to be all sorts of crook locks on the market. The ones that worked were expensive and implementing them took time, effort and practice. You certainly wouldn't win any "1st off the line at Le Mans" prizes with one on.
The vast majority of crook locks were useless, however, when faced with a car with a crook lock vs one without most toerags chose the one without. It deterred the bored.
The problem was that someone more determined could easily disable the lock. The definition of a good lock was one that could keep people out for 60seconds!
I think those locks did more harm than good because criminals knew they were a small inconvenience but those of us buying them didn't.
Being able to change the port number on SQL Server differs from those crook locks only in that changing the port number allows multiple instances to use different ports. My concern is that people would be lulled into a false sense of security by such a tactic
January 13, 2017 at 1:00 am
Would it be possible to install my real instance e.g. at myserver port 9999 and a second instance with empty databases uses the same name at port 1433 that links to a honeypot? As far I know you can't install two instances with the same name (or two main instances) on a server, so you would have to play around with routing settings to redirect all traffic from myserver:1433 to the honeypot-server...
God is real, unless declared integer.
January 13, 2017 at 1:11 am
I suggest that installig as a named instance (compared to the default instance) does much of this automatically. And if within a network the port is randomised each SQL restart. Generally to get through firewalls you'll need to fix the port. I agree its not much, but can add to other things like good firewalls.
January 13, 2017 at 2:23 am
David.Poole - Friday, January 13, 2017 12:20 AMBack in the 1980s car theft was rife in the UK and insurance costs rocketed.There used to be all sorts of crook locks on the market. The ones that worked were expensive and implementing them took time, effort and practice. You certainly wouldn't win any "1st off the line at Le Mans" prizes with one on.
The vast majority of crook locks were useless, however, when faced with a car with a crook lock vs one without most toerags chose the one without. It deterred the bored.
The problem was that someone more determined could easily disable the lock. The definition of a good lock was one that could keep people out for 60seconds!
I think those locks did more harm than good because criminals knew they were a small inconvenience but those of us buying them didn't.
Being able to change the port number on SQL Server differs from those crook locks only in that changing the port number allows multiple instances to use different ports. My concern is that people would be lulled into a false sense of security by such a tactic
I particularly like the crooklock analogy. Not only for the reason you stated, but also as it raises the issue of inconvenience as security - not only were crooklocks a poor security measure; they were inconvenient for the car driver. The solution, of course, was that the car manufacturers took responsibility and developed the sophisticated key and immobiliser systems we now have, which are far more secure than crooklocks and, even better, completely transparent to the end user.
Good security is not inconvenient; it is transparent. I think this is something often lost sight of by security professionals, who in their zeal to lock everything down often forget that the systems they try to protect have users who are trying to meet business needs, often under extreme time pressures.
January 13, 2017 at 2:46 am
Interestingly written. There is no security in obscurity however, as the article author notes, obscurity can slow down or deter more casual attacks. One would hope that if you're careful enough with connection credentials in that they are complicated enough that they cannot be guessed or rainbow attacked and they aren't recorded anywhere in plain text or weakly hashed, that modern versions of MS-SQL server are pretty safe from attacks. From my observations the most common MS-SQL related security failures are basic procedural ones:
As for locking down an SQL server, a firewall is your friend. If you have an applicition with a database then should any other system even be able to connect to this database? Lock the incoming SQL port to the address of the application that needs it and you've significantly reduced the attack space against your SQL server. You may find that you have to add a few authorised systems but even locking down connections to, for example, four authorised systems is considerably more secure than allowing connections from any system on the network.
If you're feelling particularly security concious it's an easy matter to lock down an MS-SQL server down behind an independent fireall allowing very limited connections in and out. For example to accept incoming SQL connections from only authorised systems, incoming RDP from authorised management systems only and to allow only outgoing WSUS connections to a specific network address and MS-LAN connections to the addresses of the servers running MS-Domain Control functions. Things tend to get a little more complicated when you have to add monitoring software connections and AV updates but nothing that can't be worked around as long as there are local servers to handle the updates.
January 13, 2017 at 7:05 am
This comes at an interesting time for me. I'm reading the CISSP (Certified Information Systems Security Professional) exam book*. In chapter 1, there is a blurb that goes:
To have viable accountability, you must be able to support your security in a court of law. If you are unable to legally support your security efforts, then you will be unlikely to be able to hold a human accountable for actions linked to a user account.
It goes on to say:
The point of security is to keep bad things from happening while supporting the occurrence of good things. When bad things do happen, organizations often desire assistance from law enforcement and the legal system for compensation. To obtain legal restitution, you must demonstrate a crime was committed, that the suspect committed that crime, and that you took reasonable efforts to prevent the crime. This means your organization's security needs to be legally defensible... Ultimately, this requires a complete security solution that has strong multifactor authentication techniques, solid authorization mechanisms, and impeccable auditing systems...
Basically, the upshot of this whole thing is "if you don't try hard enough to secure your stuff, then no one is going to help you out when the eventual security breach happens." And it's not wrong. Look at how many companies are getting blamed and sued for breaches of their data (Target, Yahoo, etc.) because they left one door open or weren't paying enough attention. Should we obscure our ports? Absolutely. It may not stop anything, but it will help the company prove (when the breach happens) that we did everything in our power to make it more difficult for anyone to actually access the servers. And that alone might be enough to hold the hackers accountable in a court of law, even if it doesn't stop them in the first place.
*(ISC)2 Official Study Guide - CISSP Certified Information Systems Security Professional Official Study Guide, Seventh Edition, James Michael Stewart, Mike Chapple, Darril Gibson, Sybex, 2015.
January 13, 2017 at 7:06 am
RP1966 - Friday, January 13, 2017 2:23 AMDavid.Poole - Friday, January 13, 2017 12:20 AMBack in the 1980s car theft was rife in the UK and insurance costs rocketed.There used to be all sorts of crook locks on the market. The ones that worked were expensive and implementing them took time, effort and practice. You certainly wouldn't win any "1st off the line at Le Mans" prizes with one on.
The vast majority of crook locks were useless, however, when faced with a car with a crook lock vs one without most toerags chose the one without. It deterred the bored.
The problem was that someone more determined could easily disable the lock. The definition of a good lock was one that could keep people out for 60seconds!
I think those locks did more harm than good because criminals knew they were a small inconvenience but those of us buying them didn't.
Being able to change the port number on SQL Server differs from those crook locks only in that changing the port number allows multiple instances to use different ports. My concern is that people would be lulled into a false sense of security by such a tactic
I particularly like the crooklock analogy. Not only for the reason you stated, but also as it raises the issue of inconvenience as security - not only were crooklocks a poor security measure; they were inconvenient for the car driver. The solution, of course, was that the car manufacturers took responsibility and developed the sophisticated key and immobiliser systems we now have, which are far more secure than crooklocks and, even better, completely transparent to the end user.
Good security is not inconvenient; it is transparent. I think this is something often lost sight of by security professionals, who in their zeal to lock everything down often forget that the systems they try to protect have users who are trying to meet business needs, often under extreme time pressures.
These are really good points, and I'll add that if your "security" measures are really just nuisances to users than the users themselves will find ways to bypass most of them, doing a would be attackers work for them. For example long, complex password requirements end up causing users to leave their passwords somewhere on a sticky note for reference.
January 13, 2017 at 7:17 am
Wow, great comments. I would go either way depending on what the local expert wants. If that person is me, I change the port. Most attacks are looking for defaults. This one change sends them away.
January 13, 2017 at 7:31 am
Brandie Tarvin - Friday, January 13, 2017 7:05 AM...Should we obscure our ports? Absolutely. It may not stop anything, but it will help the company prove (when the breach happens) that we did everything in our power to make it more difficult for anyone to actually access the servers. And that alone might be enough to hold the hackers accountable in a court of law, even if it doesn't stop them in the first place...
It does highlight that the hacker could not have just accidentally downloaded and run a script. It must have been an attack.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
January 13, 2017 at 8:13 am
I always change the port, the instance name and the name of the sa account. I also create a bogus sa account. Although each of these only adds a little to security, the other thing to consider is the ability to identify actual attacks. Since each of these steps requires a certain amount of effort to overcome, an analysis of behavior helps identify a pattern of malicious behavior (or a serious need for remedial training).
There are no facts, only interpretations.
Friedrich Nietzsche
January 13, 2017 at 9:28 am
I'm for anything that would help keep the data secure.
January 13, 2017 at 10:08 am
I have heard this from our security team, and also seen it from security experts in the industry:
"Security by obscurity is not security at all."
Changing a port has less than zero value in preventing unauthorized access.
Dave
January 13, 2017 at 10:19 am
djackson 22568 - Friday, January 13, 2017 10:08 AMI have heard this from our security team, and also seen it from security experts in the industry:"Security by obscurity is not security at all."
Changing a port has less than zero value in preventing unauthorized access.
Your comment applies mainly to encryption, which is a far sight more complex than obfuscation. Renaming the port is a technique, not obfuscation.
Viewing 15 posts - 1 through 15 (of 38 total)
You must be logged in to reply to this topic. Login to reply