4 ms·

He's right that "security by obscurity" isn't the entire story -- it's more like a mnemonic device for the more complex idea that: 1. In the real world, securi

by bcoates 13y ago

He's right that "security by obscurity" isn't the entire story -- it's more like a mnemonic device for the more complex idea that: 1. In the real world, security resources aren't free. 2. Security decisions are made by users. 3. Humans will engage in risk compensation [1] 4. Setting policy doesn't change people's brains, it just tells them what to do. 5. It doesn't matter what you intend, it matters what users actually do. The upshot of this is that any security policy that is highly visible and highly inconvenient will reduce your security, and has to have a substantial benefit to justify its cost. You can say "I'll do stupid port reassignment tricks, and I'll also mandate that passwords are forbidden, and require that private keys be managed properly" but at three in the morning when the whatever is overdue and not working what you're gonna get is: I'll just do password auth with root:root, nobody ever hits port 24601 anyway. Besides, look at this page [2], using a strange port makes me invisible like the Predator and makes me four thousand times more secure! I really want to believe this so I do. Also, subverting scanners is an anti-security move, not a pro-security one. Scanners are a helpful tool to identify what the hell is running on your network. Your security efforts have to find every hole, the bad guys only have to find one. Don't put yourself at an even bigger disadvantage by making your systems harder to analyze. [1] http://en.wikipedia.org/wiki/Risk_compensation http://en.wikipedia.org/wiki/Risk_compensation [2] http://www.danielmiessler.com/blog/security-and-obscurity-does-changing-your-ssh-port-lower-your-risk http://www.danielmiessler.com/blog/security-and-obscurity-do...

telephonetemp 13y ago
I agree with the sentiment of your post, however, I'm not sure if for the kind of user who would put a root:root shell on port 24601 the alternative in the absence of the article [2] wouldn't be putting the same shell on port 22. The former at least has a better chance to stay uncompromised until somebody comes in to fix it. Edit: I also wonder if a passwordless root Telnet would last longer. :-)
INTPenis 13y ago
I think you're making some assumptions about people in your argument. This is really very simple, security is a multi layered thing and security by obscurity is never a good layer by itself but part of a larger "onion" it can be helpful. Bottom line, good security always takes discipline because humans are the last line of defense. There is no one button solution and anyone in security should know this so the argument shouldn't even be present about that point. Changing the SSH port towards the internet is a very pragmatic solution to spam in your logs. I know people will mention fail2ban but I'd rather not have a log parser running day and night on every internet facing server when I can just change the port and get rid of all that spam Forever. (I have yet to encounter one robot that can dynamically scan for SSH ports and use anything else than 22). Also, in my personal opinion, using a high port like 24601 is insecure because if your SSH daemon ever crashes then an unprivileged user on your system can listen on that high port and receive your precious connections. So personally I always use an alternative ssh port under 1024.
- marcosdumay 13y ago
  > security by obscurity is never a good layer by itself but part of a larger "onion" it can be helpful. That's ok. Just don't pretend that you are getting anything worthwhile from that policy. All you get is a 10 bit door, added (not multiplied - so, it does not increase your overall security) to whatever security you already had. In computer security, people normally consider anything with less than 64 bits worthless. A 10 protection can be brute-forced by hand. As humans work, changing that port is a clear indicator of an admin that didn't care about avoiding the less secure modes of SSH. If you are looking for obscurity, I'd consider a non-standard port (and concern about bots) to be a huge flag announcing "This system is exploitable".
  - mscarborough 13y ago
    > I'd consider a non-standard port (and concern about bots) to be a huge flag announcing "This system is exploitable". Every system is exploitable. How is changing a port indicative of someone who did nothing else to secure their shell access? I keep all mine on 22, but have been considering moving it just to keep the logs a little more sane for when I actually have to read them to find something.
- uiri 13y ago
  It really isn't difficult to write such a robot, it just involves a port scan before actually probing. Using bash, something like: nmap $host | grep -i open | cut -d '/' -f 1 | xargs -I {} ./sshscan.sh $host {} Where the contents of sshscan.sh is something like: #!/bin/bash nc $1 $2 | grep -i ssh if [ $? -eq 0 ]; then # ssh probing stuff here fi

by bcoates 13y ago

telephonetemp 13y ago

I agree with the sentiment of your post, however, I'm not sure if for the kind of user who would put a root:root shell on port 24601 the alternative in the absence of the article [2] wouldn't be putting the same shell on port 22. The former at least has a better chance to stay uncompromised until somebody comes in to fix it. Edit: I also wonder if a passwordless root Telnet would last longer. :-)

INTPenis 13y ago

I think you're making some assumptions about people in your argument. This is really very simple, security is a multi layered thing and security by obscurity is never a good layer by itself but part of a larger "onion" it can be helpful. Bottom line, good security always takes discipline because humans are the last line of defense. There is no one button solution and anyone in security should know this so the argument shouldn't even be present about that point. Changing the SSH port towards the internet is a very pragmatic solution to spam in your logs. I know people will mention fail2ban but I'd rather not have a log parser running day and night on every internet facing server when I can just change the port and get rid of all that spam Forever. (I have yet to encounter one robot that can dynamically scan for SSH ports and use anything else than 22). Also, in my personal opinion, using a high port like 24601 is insecure because if your SSH daemon ever crashes then an unprivileged user on your system can listen on that high port and receive your precious connections. So personally I always use an alternative ssh port under 1024.

marcosdumay 13y ago
> security by obscurity is never a good layer by itself but part of a larger "onion" it can be helpful. That's ok. Just don't pretend that you are getting anything worthwhile from that policy. All you get is a 10 bit door, added (not multiplied - so, it does not increase your overall security) to whatever security you already had. In computer security, people normally consider anything with less than 64 bits worthless. A 10 protection can be brute-forced by hand. As humans work, changing that port is a clear indicator of an admin that didn't care about avoiding the less secure modes of SSH. If you are looking for obscurity, I'd consider a non-standard port (and concern about bots) to be a huge flag announcing "This system is exploitable".
- mscarborough 13y ago
  > I'd consider a non-standard port (and concern about bots) to be a huge flag announcing "This system is exploitable". Every system is exploitable. How is changing a port indicative of someone who did nothing else to secure their shell access? I keep all mine on 22, but have been considering moving it just to keep the logs a little more sane for when I actually have to read them to find something.
uiri 13y ago
It really isn't difficult to write such a robot, it just involves a port scan before actually probing. Using bash, something like: nmap $host | grep -i open | cut -d '/' -f 1 | xargs -I {} ./sshscan.sh $host {} Where the contents of sshscan.sh is something like: #!/bin/bash nc $1 $2 | grep -i ssh if [ $? -eq 0 ]; then # ssh probing stuff here fi