Security Through Obscurity | Hacker News Reader

Security Through Obscurity

throwingfire.com

43 pointsthirsteh60 comments

While I mostly agree that the cries of "zomg security through obscurity" that one mostly sees on the internet these days come from people who are really just parroting a catch phrase, one shouldn't forget that the industry came upon that aversion honestly. Mostly, it seems, the bad old days of raw security through obscurity are behind us. Examples like custom protocols substituting for authentication, proprietary encoding substituting for encryption, etc.

So it seems quite possible that those who might mock running ssh on a nonstandard port or omitting a service version might never have seen actual pure examples of the practice. Perhaps in some years "defense in depth" will have become such a saying that people relying solely on not having bugs in their application will get bullied in a similar way.

Exploits don't care about version banners. You know what cares about version banners? Nessus. If blinding your own security scanners makes you feel better, go ahead, I guess.

Browser exploit packs absolutely care about version numbers. It's how they determine what if any exploits to push to a client. Nessus, on the other hand, will never look at a user-agent string. So while you're probably correct for one class of threats and targets (targeted and enterprise servers) I wouldn't agree at all that the world is as black and white as you're claiming.

Are we talking about modifying your browser binary to defeat memory disclosure exploits? I didn't think we were talking about that.

It certainly seems in scope to me if we're talking about version identifiers, and it (along with several other examples) are clear situations where changing an identifier string could definitely lead to an automated attack that would succeed never being tried.

And you don't need to modify any binaries: The easiest way to change something like that is in a transparent proxy, but ie also supports changing via the registry, opera and firefox via about:config, etc.

What's an example of a serverside vulnerability that cares about version banners?

What vulnerability depends on a specific version banner? Surely you're not insisting that the actual bug be predicated on the fact that one version prints instead of another.

A server intrusion work flow that involves a version banner? Saint on /24 -> choose exploit & target based on results. I understand you've said either this isn't worth the tradeoffs or 0days aren't getting mass exploited this way, but it is hard to believe you really disagree that intrusions happen in this fashion.

That's how security consultants break into machines. If you're arguing that someone with a very recent SSH remote is going to use Saint to scope out a target, no; doubt it.

> it seems quite possible that those who might mock running ssh on a nonstandard port

Running sshd on a nonstandard port is not a security measure, it keeps your logs cleaner and saves you a few cycles.

Ok, see, that's a good reason to run SSH on a nonstandard port. Thank you.

"Having critical services (e.g. SSH) on non-standard ports"

I routinely do this. Not because I think it will enhance security, but because it will reduce the tsunami of braindead bruteforce attacks on my machines, and the associated resource consumption.

One night I woke up because my bedside MacMini (which I use for watching movies and listening to podcasts) spooled up its fan and was making a vacuum cleaner sound, something that I didn't experience before with this machine. With sleepy squinted eyes, I inspected the output of 'top' and saw SSH consuming 100% CPU or something. I switched off SSH in the System Preferences and the MacMini returned back to normal; and I went back to sleep. Next morning I moved the SSH service to another port (in the router) and haven't experienced this again.

My FreeBSD home server was bashed by a multitude of foreign clients, all trying to break in on port 22. The /var/log/auth.log showed hundreds of thousands of breakin attempts. When I reconfigured sshd to listen on another port, this dramatically dropped to almost zero.

There is no evidence that the SHA-512 cryptographic hash algorithm is breakable by any modern machinery, so why are we keeping password hashes secret?

Yes, but we're still working out the theoretical underpinnings of hash algorithms.

http://domino.research.ibm.com/comm/research_projects.nsf/pa...

Also, if one looks at past performance, it seems like it's only a matter of time before a hash algorithm is broken in some way.

http://en.wikipedia.org/wiki/Cryptographic_hash_function#Cry...

There is nothing wrong with obscurity, provided that 1) you don't use it as a replacement for standard security and 2) it doesn't interfere with the operation and auditing of your standard security.

Reversing hashes, even thoroughly broken ones, is still quite impractical - it's collision attacks that you have to watch out for.

Of course, you don't break password hashes by reversing the hash, you break password hashes by just trying (variations on) dictionary words until one matches the hash. For that purpose, SHA-256 is not a good choice, since it's too fast - use PBKDF2/bcrypt.

Reversing a hash is impossible, so a collision is "reversing" it. All that really matters is that you've got something that the auth system will think is the right password.

You're confusing a collision (find any x, y such that f(x) = f(y)) and a second preimage attack (find any x such that f(x) = y for some particular y). The latter is much more difficult, but the former can still be used - see "rogue CA".

His analogy to exposing password hashes doesn't really work.

The primary reason you don't expose password hashes isn't that someone will break the hashing algorithm. It's that users come up with crappy passwords, and exposing the hashes would let an attacker do a brute-force search on the likely password space.

His other points are pretty good, though.

Good point. Let's say, for the sake of argument, that each of them have their own salt :)

Any reasonable password algorithm will have a unique salt for each password (well, a random long salt; you're highly unlikely to have collisions). Dictionary attacks still work.

Right. The analogy isn't bulletproof, but in conclusion it's pretty dumb to share information that could conceivably be used to extract some information or otherwise get an advantage when there's no reason to.

You can't use SHA-512 by itself as a secure password hash. SHA-512 is plutonium. You need the reactor to do anything but kill yourself with it.

None of those "obscurity" measures do anything meaningful to improve your security. People just do them to make themselves feel less powerless.

So how do you quantify "less likely to be h@xxored by some script kiddy's scripts" versus "actually able to resist a focused penetration test"?

Are you saying the zero-day exploit "todo list" isn't a valid concern? Mathematically, perhaps there is no difference because the focused penetration attempt overwhelms the equation, but if I'm just "some IP" on the Internet, isn't the less knowledge about me better?

It is very similar to the "secret military facility". The security of the facility is determined by what would stop somebody who knows about you, but you reduce the number of times that is tested through the "secret" (obscure) part of the base.

I have no idea what you're talking about. Nobody with OpenSSH zero-day is feeding it through an Internet-wide scanner.

The point is the scanner keeps track of versions: 148.65.45.123 is using SSH x.y. When a zero-day hits for a particular version, they are able to look at the list previously generated to see immediately where they can put a back door.

If you don't advertise your ssh (eg change ports) or your version, you aren't on that zero day list. Your system isn't more secure, but your are less likely to be hacked.

So, that's the scenario. The above has reduced your chances of being hacked without actually increasing how secure your systems actually are.

And then the question: how do you account for that in assessing the cost/value benefits associated with security? I really am curious about this, because there is a cost to the above, so any value should be included in the calculation of whether it is worth it. How do you calculate the value of not being on that list?

Security plus obscurity probably does beat obscurity (as long as you're not trying to rely on scanners to find the vulnerabilities in your own network), but the people asserting this are almost always doing something horribly wrong (e.g. using SHA-256 for passwords, like this guy is doing). Even if this is not the case, moving your SSHD to a high port is unlikely to be as effective as just switching to public-key crypto, which doesn't end up taking more time. Etc.

In short, you're right in theory, but in practice obscurity is pretty much never the right answer.

> None of those "obscurity" measures do anything meaningful to improve your security

That's just not true. Consider a practical analogy: the access ID badges that many companies issue to their employees. Most of the time, these badges do not include information identifying the company other than a simple postal address. This isn't a strong security mechanism by a long shot, but does serve to make it more difficult to use a lost card. Often, more difficult is all it takes to make a casual attacker lose interest in the target.

Hiding version information is a lot like that. Which is more useful to an attacker: "ApacheTomcat 6.0.25" or "BigCompanyServer"? Sure, a sophisticated and dedicated attacker could identify the software you are running (often down to a version number), but that takes time. The time that takes is time taken away from the rest of the attack, and possibly enough of a timesink to deter some attackers.

I don't think anybody sensible is claiming that "hide your server version" is as important as "don't run a known-buggy version", but there is no doubt that both of these things have value.

In 1995 when you were breaking into a server, you maybe telnetted to port 25 and checked out whether they were running Sendmail 8.6.9 or Sendmail 6.6.12, so you could decide whether you were going to try a character quoting bug or a buffer overflow.

Nowaways, you just run your ruby script and wait for the connectback shell. You might not even care if they're running a server on port 80. Either the exploit works or it doesn't; who cares why it doesn't?

Hiding version numbers does nothing at all to meaningfully improve your security. Exploits don't care about version banners. They don't not try the attack if they see the wrong version.

The author kind of mentions this but not explicitly. When you want to use obscurity always make sure it is layered on top of security. In other words, if you are hiding some piece of information that you think helps in security, always make sure that it is still secure even if you do not hide it. So go ahead and obscure your SSH ports, but make sure you are using the latest version.

The problem with being complacent about obscurity is that sooner than later people think that obscurity implies security and fail to ensure that their systems are secure underneath the layer of obscurity. Then the system is only secure so long as what you've obscured is obscure. That is dangerous and must be avoided.

This is a pet peeve of mine as well. Obscurity in your crypto scheme or your SSH server's source code is obviously bad, but applying that phrase to changing an SSH port fundamentally misunderstands what the slogan means.

I agree. Changing your SSH port number isn't even obscurity. It's obvious which port you've bound it to. Nonstandard SSH port numbers are just security through idiosyncrasy.

It's obvious which port you've bound it to.

Can you can do it in less time than testing all ports until you find it? (an average of 2^15 connections?).

Also if you run it on port 22 and someone tries 22 then that will not trigger any port-scan-detectors. If you run it on port N and they are scanning all ports, you can block them before they find SSH.

It is obscurity, it's making finding/confirming SSH 1/65535 instead of 1/1.

All your comments here are of the nature "Everyone's an idiot. Ignore the explanations and arguments raised in the article they're just wrong. Trust me."

There's this person you are thinking of who is actually vulnerable to something an SSH scanner is looking for. What I'd like to know is, what is that person reasonably going to do when his portscan detector goes off? Why didn't he do it a month ago instead of waiting?

I hope my comments here are of the nature of "My mind is boggling as to why smart people think these measures are anything but laetrile." Also: do you think I'm just making it up? Don't be passive-aggressive. If you think I'm full of it on this topic, just say so.

> There's this person you are thinking of who is actually vulnerable to something an SSH scanner is looking for.

The point is that if a vulnerability gets discovered in future, he doesn't want to be on a list of "servers that are now vulnerable".

When he hears about the exploit, he'll fix it. But if the bad guys hear about it first, not being on that list is useful obscurity.

> If you think I'm full of it on this topic, just say so.

You're probably not full of it, but it's hard to extract much value from your comments.

Once every ~4-6 years or so someone will find a vulnerability in OpenSSH. When that happens, the list of vulnerable servers is "everyone running SSH". Maybe there's some attacker that is keeping a database of every SSH server on the Internet, but I doubt it.

I don't think it's hard to extract value from my comments. I think you don't want the value that's in my comment, because that value is "you are spending time and energy doing something that isn't providing the security benefit you think it is", and that's not fun to hear.

You don't think an attacker would hold on to the results of scanning for SSH servers? They just scan for days then throw it all away?

I had absolutely no idea what you were trying to say with your first reply to me. It's only by digging through lots of your other replies that I got the hint that it may be an attempt at sarcasm, but I'm still not sure. You are not supporting your assertions, or even making your assertions clear.

Yes. They scan for days and throw away all the results that aren't "machine I can log into".

If a company with a large and complex web property, e.g. Microsoft.com or Google.com, asked you if it mattered whether they allow DNS AXFR, what would your answer be?

Nobody enables AXFR. AXFR isn't a default. I wouldn't advise someone to override that default.

If one of my clients then asked me, "because I don't enable AXFR, is wide-open-dev-machine.customer.com safer?", I would say "no, it is not".

So you agree that disabling AXFR, if AXFR is enabled, is a good idea?

Could you explain why you think wide-open-dev-machine.customer.com is NOT safer without AXFR (assuming it blocks robots, and the web server only serves the site for "wide-open-dev-machine.customer.com")?

I'm just trying to understand how it could not be considered beneficial in any way, however much (which is what you're claiming).

I don't have to think about this much because nobody has AXFR enabled. If you had AXFR enabled, I would in fact tell you to turn it off. It isn't an operational win (unlike SSH on port 22), so what possible reason could there be for enabling it?

wide-open-dev-machine isn't safer because there's a whole variety of ways to learn about it without AXFR.

For what it's worth, I would not flag a customer for running SSH on port 22; I would certainly flag a customer for having port 22 exposed where it didn't need to be; for most SaaS/ASP-type companies, I'd flag them for having more than one SSH port exposed, and I'd recommend that they invest in a VPN instead of exposed SSH.

I think there are far more nameservers allowing AXFR than you think. Write a little app that attempts a zone transfer for the top 1000 of the Alexa list (http://s3.amazonaws.com/alexa-static/top-1m.csv.zip) and see for yourself. (Note to anyone reading: Please don't try this before you've checked if it's legal in your state/country or not.)

Could you explain how you would learn about wide-open-dev-machine as simply as by using AXFR in your scenario (you aren't on the network, so no *casting).

Edit: "so what possible reason could there be for enabling it?" is eerily similar to my message :)

Here's your answer:

    imageshack.com
    about.com
    ehow.com
    sparkstudios.com 
    yfrog.com
    liveinternet.ru
    pgmediaserve.com
    wikimedia.com
    adfly.com
    thefreedictionary.com
    amung.us
    btjunkie.com
    bluehost.com
    drtuber.com
    ero-advertising.com
    autohome.com.cn
    exblog.jp
    inetglobal.com
    milliyet.com.tr
    imagebam.com
    naukri.com
    bigpoint.com
    altervista.com
    hypergames.com
    gsmarena.com
    excite.co.jp
    admagnet.com
    macrumors.com
    linkbucks.com
    cracked.com
    traidnt.com
    radikal.ru
    paper.li
    eluniversal.com.mx
    wiktionary.org
    indianrail.gov.in
    docin.com
    123rf.com
    perezhilton.com
    mangafox.com
    hostmonster.com
    myfreecams.com
    giveawayoftheday.com
    ultimate-guitar.com
    itpro1.nikkeibp.co.jp
    pantip.com
    hawaaworld.com
    120ask.com

4.8%. That's more than I would have thought, but it's still a small number: 95.2% of the Alexa 1000 keep AXFR disabled. Also: someone should tell some of these people not to do this.

Indeed. Keep in mind it's the top, so these are the people you really expect to keep something like that hidden. I promise you the stats are much worse further down the list, or if you do the same, but for a specific country's TLD.

> When that happens, the list of vulnerable servers is "everyone running SSH".

Agreed, but in between "bad guys discover vulnerability" and "he fixes vulnerability", can't he reduce the chance that he will be attacked by having SSH on a different port? It won't stop someone who's targeting him, but it might keep him off the radar of someone who's just looking for easy targets. From another post:

> "32,000" sounds like a large number on a message board, but write an evented port scanner† and see how big that number really is.

So is your claim that anyone looking for vulnerable SSH servers will scan every port they can on a given IP, rather than just looking at port 22 and moving on?

> I don't think it's hard to extract value from my comments.

With respect, you are not the best judge of this. (I personally don't administer a server; if anything, I want you to be correct because that will save me effort if I ever do.) When I read your posts, I learn your opinion, but I often can't work out why you hold that opinion.

Possibly you just write your posts under assumptions that seem obvious to you, but not to others.

One assumption I may have that needs to be stated: OpenSSH vulnerabilities are infrequent, bordering on rare. The discovery of a remote auth bypass or remote code exec flaw in OpenSSH is a big deal; a "drop everything and block all access to port 22" deal.

Another assumption: the gap between the rumor of an OpenSSH remote and the time it hits "people so dumb as to burn the exploit on a scanner" is large; probably weeks, possibly months.

Another assumption: anyone running OpenSSH has turned off the dumb stuff, like password authentication. If you are using passwords to log into SSH servers, you have problems port numbers can't fix.

The only attacker SSH-on-port-51122 defends against is the one so far back in line for SSH exploits that she'll stick it on the business end of an Internet-wide scanner. That vulnerability is worth many tens of thousands of dollars. Nobody that has it in the window between announce and "public downloadable exploit" is scanning with it.

Finally, you really should only have one machine exposed to SSH, if that. If you have to manage 50 servers, set up 1 bastion server and relay through it.

Auto-ban the source of the portscanning, and limit what the now-known-hostile source IP can do next.

This person is probably doing nothing more than an automated nightly security update. Someone running an exploit against SSH which may work is bad, someone unable to run an exploit against SSH because they didn't find it before being blocked by an intrusion detection system is better.

And, because it wasn't scanning a month ago.

They are of that "lol, dumbasses" nature. That's annoying and unhelpful. The submission is an article where the author explains some specific thoughts on some specific potential security measures, your replies are of the nature "lol no; ha ha nope; wrong again". I don't claim your view is wrong, but neither are you giving any of us mere mortals anything more to go on than trusting your reputation.

Great, "SHA-512 is plutonium", that's gonna help me what ... be afraid of it? "None of these security measures do anything to improve security"? Well that's literally not true, so are you merely claiming that they do to little to be worth it? Or what?

"People do things they think are heplful but which aren't helpful so we feel less powerless"? No, we do them because we think they help. That's just an ad-hom.

Changing the SSH port to a random one makes a scan to find it 32,000 times more effort, on average. The author claims that makes it too expensive for people to scan for. You claim it's "obvious" where you put it so it doesn't help. Well it isn't obvious where you put it. It just isn't. You do have to scan for it.

1. Your comments seems premised on the notion that OpenSSH vulnerabilities are routine. They are not routine. They are not hard to keep up with. And if you do not keep up with them, nothing you do is going to protect your server. I am reading tea leaves to arrive at this conclusion about your mindset, yes, but it's still worth pointing out.

2. Blocking sources is a silly way to defend against a server. Anyone who is actually using SSH exploits to break into servers has lots of sources. Meanwhile: anything a scanner is looking for, you're not vulnerable to; if you were, you're already owned. All blocking the source does is make you feel btter.

3. Yes, you should be afraid of using SHA-512. Yes, that is the point of that comment.

4. "32,000" sounds like a large number on a message board, but write an evented port scanner† and see how big that number really is.

† Programming Challenge Level: 3 (Casual Comment On Hacker News - http://news.ycombinator.com/item?id=2317547)*.

The point of a lot of the techniques he mentions is not obscurity, but avoiding being "low hanging fruit" for non-targeted attacks
For example, running ssh on an alt port = less likely to be picked up in a scan = less likely to appear in one of those lists of attack targets.
It's the old two guys being chased by a bear joke where one stops to put on shoes, so that he can outrun the other. In non-targeted attack situations little "obscurity" enhancements may mean the difference between being attacked and being skipped over.

OT, but: all security has obscurity and you can't have one without the other: Do you salt your password hashes and hide [obscure] the salt? Do you not share [obscure] your private key? Good security severely restricts the amount of info that need to be obscured; it doesn't mean you can leave behind obscurity.
At the same time, being secure doesn't mean you should be wantonly non-obscure. Even if you are using SHA-512, there's just no good reason to expose crucial hashes.

The salt is a public value. It isn't a key; it's a randomizing nonce. Its sole purpose is to transform one hash (SHA-256 or whatever) into thousands or millions of hashes.
Of course, if you're using an algorithm that demands that you decide what to do with a salt, you're rearranging deck chairs on the titanic anyways.

Hmm... I didn't say the salt was a key (since hashes are one-way that would be silly, right?). I was referring to using a salt to enhance security on stored passwords and, in that case, I don't think that a salt is a nonce since it's used repeatedly (in either per-account or per-application usage) to produce the hash value to match the stored password hash. In this case, it's certainly not a public value.
Of course, if you're using an algorithm that demands that you decide what to do with a salt, you're rearranging deck chairs on the titanic anyways.
I'll bite: how do you store passwords securely?

You do not use a salt "repeatedly". The salt needs to be unique per hash. Maybe you should stop offering advice on this topic.

http://en.wikipedia.org/wiki/Salt_(cryptography)
In a typical usage for password authentication, the salt is stored along with the output of the one-way function, sometimes along with the number of iterations to be used in generating the output (for key stretching). Salt is closely related to the concept of nonce.
Two important bits there: salt != nonce (closely related); salt is typically stored for future usage (e.g. repetition) (I quoted the iteration bit, but am not referring to that in my usage of "repetition").
Edit: replying here since the thread is too deep. You've got a couple of issues there: you haven't answered my question about storing passwords; you've committed the "appeal to ridicule" fallacy.
Further: I don't doubt you know more about this than do I, but I'd love for you to educate me rather than ridicule me. I assume your consulting clients receive better treatment?

At least 51% of interested Wikipedians also do not completely understand the concept of a "salt".

To store a password securely, you use a hashing algorithm that isn't designed to be fast, i.e. bcrypt. Please read: http://codahale.com/how-to-safely-store-a-password/.
Giving advice and in general debating about a specialized topic like crypto is a touchy business. With specialized topics in general, those without deep domain knowledge typically get things wrong. And in a topic like crypto, wrong advice can have significant negative consequences for those that follow it. The reason why Thomas is taking you to task on this one is that your original post talks about secret salts. That's a big red flag that there is a lack of understanding of underlying, fundamental security principles.

I agree with @stcredzero , the password hash thing is nonsense.
If you expose the hashes to allow other people to authenticate your users, which I think the author suggests, 3rd party sites can simply cache the password the user provides for crunching and have BAM stolen their password.

It was a kind of tongue-in-cheek comment to demonstrate the irony of "exposing it doesn't matter". I should probably have been more clear that I wasn't actually serious.

@pmylund:
Great post! I'm sure that you have been inspired by this comment http://news.ycombinator.com/item?id=2564263
No Disqus on your blog. Why not?

Lots of people seem to forget to configure their firewalls. Nobody should be allowed to connect on your ssh port, except from your office. On the road a lot? VPN into the office THEN connect to ssh.

Isn't a good password just a really obscure combination of characters?

all security i've seen depends on the obscurity of passwords. There is no difference, except in how easily things are spread and cached and logged (i.e. the only reason to not put passwords in URL query strings)

Reply on news.ycombinator.com