Obscure codes, cyphers, and crypto systems have repeatedly fallen to attack regardless of the obscurity of their vulnerabilities. Historically, security through obscurity has been a very feeble reed on which to rely in matters cryptographic. Claude Shannon, the father of modern cryptography (and of much else), rephrased it as "The enemy knows the system". It is, from the original French, "The security of a cypher resides entirely in the key". In cryptography, the reverse of security by obscurity is Kerckhoffs' principle from the late 1880s, which states that system designers should assume that the entire design of a security system is known to all attackers, with the exception of cryptographic key secrets. However, the house owner believes that the location of the key is not known to the public, and a burglar is unlikely to find it. The theoretical security vulnerability is that anybody could break into the house by unlocking the door using the spare key. A system relying on security through obscurity may have theoretical or actual security vulnerabilities, but its owners or designers believe that the flaws are not known, and that attackers are unlikely to find them.įor example, if somebody stores a spare key under the doormat in case they are locked out of the house, then they are relying on security through obscurity. Me, I’m going to go eat my lunch in the pool.Security through obscurity Security through obscurity or security by obscurity is a controversial principle in security engineering, which attempts to use secrecy to ensure security. So, instead of repeating the mantra of how security by obscurity doesn’t work, learn to think for yourself. Why not rename the root account, create an unprivileged bogus root account in its place and see what happens to your security exposure risk? It won’t increase. Ask if renaming the root account could possibly hurt their system and they’ll say no (after a little thought). Mention renaming the root account and you’ll get stares. Recommend that they change default RPC program numbers, which many malicious scripts depend on, and you’ll get imagined stories of all the things it will break. Unix/Linux administrators seem even more resistant to changing defaults than Windows admins. Hackers could find the second SQL server honeypot (the SQL password is blank on the second box, by the way), but so far, the simple port change is doing a fine job of obscuring its location. The latter has never had a single SQL probe on port 1435 in more than a year from either automated malware or hackers. The first gets attacked hundreds of times a day. ![]() Two of them are SQL server honeypots one runs on port 1434, the other runs on 1435. Here's where security by obscurity can work, and it’s only one of hundreds of examples I could give you: I run almost a dozen honeypots attached to the Internet. You can modify the default ports during a new install and simply update a registry entry for existing clients and servers. The easiest solution of the three is to move your SQL ports to some other TCP/IP, maybe 43143 or the like. And VPNs can be one of the most difficult things to establish between multiple points. Keeping patches up-to-date can be hard in a large enterprise, especially when trying to thoroughly test a mission-critical application. It's not easy to fix all of those problems. Third, your SQL servers were running on the default port of 1434. Second, you connected your SQL to the dangerous world of the Internet without a protective VPN. First, your SQL box was unpatched, even though the patch had been out for more than half a year. If you got compromised by Slammer, it meant you did three things wrong. Think of how security by obscurity could have helped avoid the SQL Slammer worm. Hackers can do SID enumeration, but most of them don’t. The reality, however, is that most attacks are automated and none of them have ever done SID enumeration. ![]() Security experts will respond that in the Windows world, the Administrator account can always be easily identified by its well known SID (security identifier) number of 500, and that’s true. The Exchange Administrator account shouldn’t be called ExchangeAdmin and your tape backup service account should not be called Tapebackup. Why give malicious hackers and automated malware a leg up on your environment?įor example, Windows administrators should rename their Administrator account to something less than obvious, such as PeterC. ![]() The idea is that if something doesn’t have to be installed to the worldwide known default name or location, don’t do it. * Rename configuration files to nondefault names, if possible. * Install high-risk software (such as Internet-facing Web servers) to nondefault directories. * Run server services on non-default ports whenever possible.
0 Comments
Leave a Reply. |