Securing Your Instances

  • GeorgeCopeland - Friday, January 13, 2017 10:19 AM

    djackson 22568 - Friday, January 13, 2017 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.

    Your comment applies mainly to encryption, which is a far sight more complex than obfuscation. Renaming the port is a technique, not obfuscation.

    No, my comment was about trying to secure something by hiding it.  Encryption is not at all what I am talking about, I can't even imagine how one would "hide" via encryption.

    A real world example is those who share a folder, but make it a hidden share, yet give the EVERYONE group full control on the security tab.  I have seen some people "share" to everyone, but lock down security.  MS recommendations are to share it to those who need it, and to lock down security as well.  If all you do is leave the directory wide open, and add a $ sign to the share name, nobody can easily see it, but that doesn't prevent access.  Especially when talking about vendor software, a vendor that shares a folder as part of implementation will tend to use the same share name across customers, so once you know what it is, you can use it everywhere.

    Where it can be confusing is when you do something like rename the Administrator account.  That is obscurity and not real useful if you set the password to "password".  On the other hand, renaming it and using a secure password is useful.  Just a secure password is useful.  Why do I view this different than changing a port?  Because a port scanner can be run on a different machine and elicit all of your SQL Servers, a simple program cab be written to scan every port and then determine what is running on that port.  In order to get a list of account names, you first must access the box.  Essentially, without the account name, you are going to have to try random account names, and then random passwords for each one.

    Changing a port has no security value.

    Dave

  • A few years back there was a discussion about Honeypot servers. The basic concept is that you setup a marginally secure server for the sole purpose of baiting hackers who are randomly scanning your network. For example, you can have an instance of Express edition listening on ports 1433 and 1434 with an enticingly named database like [CustomerPayments] or [HRDataMart] and tables loaded with convincing looking mockup data. http://www.sqlservercentral.com/Forums/Topic1453316-263-1.aspx

    What would be cool is if the FBI were to setup special honeypot credit card numbers which raise a red flag when someone attempts to use it. These special credit card numbers and fake identities could then be seeded into the databases of retailers who volunteer to participate in the sting operation.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • I'll disagree.

    Port scanners can be blocked, especially simple ones. Are there targeted, distributed scanners that use lots of IPs over time? Sure, but those aren't necessarily what many vandals or random attacks use. There are also scripts and viruses written that look for specific ports, and specific users or passwords. If you had the browser disabled, and renamed sa, even if the password were blank, many scripts would fail since they look to log in with SA. Other scripts might try common passwords.

    Hiding the instance doesn't prevent every attack, nor is it supposed to. No security system prevents every attack. That doesn't mean small changes don't provide some security.

    Likening this to making a hidden share and allowing everyone access doesn't make sense. There is still some security here, and if you don't have a browser and limit port scans, you can prevent brute force attacks, and potentially DOS attacks.

  • I am intrigued by the idea of a honeypot on standard ports. I guess my caution would be know what you are doing. An insecure honeypot can give an attacker control of your network.

  • No, my comment was about trying to secure something by hiding it.  Encryption is not at all what I am talking about, I can't even imagine how one would "hide" via encryption.

    Its a common theme that security by obscurity often means hiding the encryption algorithm as well as the encryption key with the intent that the attacker will not be able to decrypt due to not knowing the encryption algorithm. Often this is accompanied by use of an obscure, seldom used, or even proprietary encryption algorithm that hasn't been vetted by reasonably meaningful cryptanalysis, so the use of poor (and correspondingly obscure) encryption algorithms might be more easily cracked then better more public (and therefore vetted) algorithms.

    Note here that the poorly vetted and correspondingly obscure algorithms TAKE THE PLACE OF better, more public (and thus less obscure) algorithms, whereas changing the port IS IN ADDITION to the usual security put in place, so despite your assertion, it cannot REDUCE security unless it encourages lapses in the other areas charged to the folks securing the installation.

  • patrickmcginnis59 10839 - Friday, January 13, 2017 2:03 PM

    No, my comment was about trying to secure something by hiding it.  Encryption is not at all what I am talking about, I can't even imagine how one would "hide" via encryption.

    Its a common theme that security by obscurity often means hiding the encryption algorithm as well as the encryption key with the intent that the attacker will not be able to decrypt due to not knowing the encryption algorithm. Often this is accompanied by use of an obscure, seldom used, or even proprietary encryption algorithm that hasn't been vetted by reasonably meaningful cryptanalysis, so the use of poor (and correspondingly obscure) encryption algorithms might be more easily cracked then better more public (and therefore vetted) algorithms.

    Note here that the poorly vetted and correspondingly obscure algorithms TAKE THE PLACE OF better, more public (and thus less obscure) algorithms, whereas changing the port IS IN ADDITION to the usual security put in place, so despite your assertion, it cannot REDUCE security unless it encourages lapses in the other areas charged to the folks securing the installation.

    Thanks.  I had never heard of that.  Sounds like a very dumb thing to do.  "Hmm, nobody uses the encryption standards from 1950, let's use those!"

    And I did not mean to imply that it would reduce security.  Just that it doesn't actually benefit security.  While some may disagree, hence probably why Steve is asking for our opinions, that is my view.

    Dave

  • I see that 3DES is now regarded as crackable

  • David.Poole - Friday, January 13, 2017 2:38 PM

    I see that 3DES is now regarded as crackable

    Beginning with SQL Server 2016, all algorithms other than AES_128, AES_192, and AES_256 are deprecated.
    https://msdn.microsoft.com/en-us/library/ms345262.aspx

  • GeorgeCopeland - Friday, January 13, 2017 2:47 PM

    David.Poole - Friday, January 13, 2017 2:38 PM

    I see that 3DES is now regarded as crackable

    Beginning with SQL Server 2016, all algorithms other than AES_128, AES_192, and AES_256 are deprecated.
    https://msdn.microsoft.com/en-us/library/ms345262.aspx

    More evidence that an annual review, at the very least, of security standards needs to be applied.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Yes, the service account used for the honeypot server should be local no admin minimal priv, the mssql account left open to the public should itself be nothing more than data reader. Really, the honeypot should be running within a walled off VM with only the illusion that it's part of a larger corp intranet.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric M Russell - Saturday, January 14, 2017 8:18 AM

    Yes, the service account used for the honeypot server should be local no admin minimal priv, the mssql account left open to the public should itself be nothing more than data reader. Really, the honeypot should be running within a walled off VM with only the illusion that it's part of a larger corp intranet.

    Exactly. I am pretty sure that any viable honeypot requires elaborate design. I can't think of a reason to go through this exercise unless you intend to do something to the attackers that you catch. Earlier in this thread someone mentioned feeding attackers with a poison credit card list.

    I know a Windows security admin who is in the standard port camp. What he does with attackers is he tries to take over their workstations. I have actually seen him on the phone with an attacker, the attacker begging him to give his computer back. Reverse ransomware.

    I suppose you could set up your honeypot as a fire and forget thing, just let anyone in it do what they will. I don't see the use in this. Just change the port from standard and be done.

  • GeorgeCopeland - Saturday, January 14, 2017 3:21 PM

    Eric M Russell - Saturday, January 14, 2017 8:18 AM

    Yes, the service account used for the honeypot server should be local no admin minimal priv, the mssql account left open to the public should itself be nothing more than data reader. Really, the honeypot should be running within a walled off VM with only the illusion that it's part of a larger corp intranet.

    Exactly. I am pretty sure that any viable honeypot requires elaborate design. I can't think of a reason to go through this exercise unless you intend to do something to the attackers that you catch. Earlier in this thread someone mentioned feeding attackers with a poison credit card list.

    I know a Windows security admin who is in the standard port camp. What he does with attackers is he tries to take over their workstations. I have actually seen him on the phone with an attacker, the attacker begging him to give his computer back. Reverse ransomware.

    I suppose you could set up your honeypot as a fire and forget thing, just let anyone in it do what they will. I don't see the use in this. Just change the port from standard and be done.

    So, a honeypot is basically like a tripwire; a first line of defense that alerts you that someone is creeping into your network using something other than the predefined port, and perhaps also buys you some time before they move on to the real target. If a connection is made to the honeypot on port 1433, whether from an internal or external source, and someone starts poking around in the "TopSecret" database, then that's a positive signal that you're not dealing is a passive port scan but rather it's a live hacker or a bored IT employee up to no good. A lot can be learned about the hacker by profiling what specific accounts and queries they're attempting to use.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric M Russell - Wednesday, January 18, 2017 12:54 PM

    GeorgeCopeland - Saturday, January 14, 2017 3:21 PM

    Eric M Russell - Saturday, January 14, 2017 8:18 AM

    Yes, the service account used for the honeypot server should be local no admin minimal priv, the mssql account left open to the public should itself be nothing more than data reader. Really, the honeypot should be running within a walled off VM with only the illusion that it's part of a larger corp intranet.

    Exactly. I am pretty sure that any viable honeypot requires elaborate design. I can't think of a reason to go through this exercise unless you intend to do something to the attackers that you catch. Earlier in this thread someone mentioned feeding attackers with a poison credit card list.

    I know a Windows security admin who is in the standard port camp. What he does with attackers is he tries to take over their workstations. I have actually seen him on the phone with an attacker, the attacker begging him to give his computer back. Reverse ransomware.

    I suppose you could set up your honeypot as a fire and forget thing, just let anyone in it do what they will. I don't see the use in this. Just change the port from standard and be done.

    So, a honeypot is basically like a tripwire; a first line of defense that alerts you that someone is creeping into your network using something other than the predefined port, and perhaps also buys you some time before they move on to the real target. If a connection is made to the honeypot on port 1433, whether from an internal or external source, and someone starts poking around in the "TopSecret" database, then that's a positive signal that you're not dealing is a passive port scan but rather it's a live hacker or a bored IT employee up to no good. A lot can be learned about the hacker by profiling what specific accounts and queries they're attempting to use.

    You have to be careful about honeypots in the U.S. The use of them could be considered entrapment. ISTR reading a news article some years back about a court case where the hacker in question was basically saying it was entrapment, but I can't find the link now nor can I find end result of that court case.

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

  • Brandie Tarvin - Thursday, January 19, 2017 4:28 AM

    Eric M Russell - Wednesday, January 18, 2017 12:54 PM

    GeorgeCopeland - Saturday, January 14, 2017 3:21 PM

    Eric M Russell - Saturday, January 14, 2017 8:18 AM

    Yes, the service account used for the honeypot server should be local no admin minimal priv, the mssql account left open to the public should itself be nothing more than data reader. Really, the honeypot should be running within a walled off VM with only the illusion that it's part of a larger corp intranet.

    Exactly. I am pretty sure that any viable honeypot requires elaborate design. I can't think of a reason to go through this exercise unless you intend to do something to the attackers that you catch. Earlier in this thread someone mentioned feeding attackers with a poison credit card list.

    I know a Windows security admin who is in the standard port camp. What he does with attackers is he tries to take over their workstations. I have actually seen him on the phone with an attacker, the attacker begging him to give his computer back. Reverse ransomware.

    I suppose you could set up your honeypot as a fire and forget thing, just let anyone in it do what they will. I don't see the use in this. Just change the port from standard and be done.

    So, a honeypot is basically like a tripwire; a first line of defense that alerts you that someone is creeping into your network using something other than the predefined port, and perhaps also buys you some time before they move on to the real target. If a connection is made to the honeypot on port 1433, whether from an internal or external source, and someone starts poking around in the "TopSecret" database, then that's a positive signal that you're not dealing is a passive port scan but rather it's a live hacker or a bored IT employee up to no good. A lot can be learned about the hacker by profiling what specific accounts and queries they're attempting to use.

    You have to be careful about honeypots in the U.S. The use of them could be considered entrapment. ISTR reading a news article some years back about a court case where the hacker in question was basically saying it was entrapment, but I can't find the link now nor can I find end result of that court case.

    [The accepted standard legal definition of entrapment as stated by Justice Roberts in 1932 in Sorrells vs. United States]

    “Entrapment is the conception and planning of an offense by an officer, and his procurement of its commission by one who would not have perpetrated it except for the trickery, persuasion, or fraud of the officers.†

    https://www.researchgate.net/publication/3955168_Internet_honeypots_protection_or_entrapment

    I don't see a honeypot server as conceptually the same thing as, for example, leaving a laptop sitting on a park bench for the express purpose of enticing someone to spontaneously steal. A hacker won't discover the honeypot unless they are port scanning a network and employing other specialized techniques in the first place, so there is premeditated intent to commit a crime. In any event, an organization implementing a honeypot may be more interested in detecting attempted breaches and analyzing attempts for informational purposes rather than bringing the hackers to justice in court.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • I always advise my fellow technologists to avoid providing advice in areas where they have no expertise, especially the law.

Viewing 15 posts - 16 through 30 (of 38 total)

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