Live data from Hacker News

Security by obscurity is underrated

utkusen.com

401–410 of 530 posts

Re: Security by obscurity is underrated

#401

Earlier quoted context omitted.

Using a non-standard SSH port is a bad example because nmap can see through that deception in a few seconds. Any attacker who is looking for more than just the lowest of low-hanging fruit will not be even slightly deterred. A better example would be a port-knocking arrangement that hides sshd except from systems that probe a sequence of ports in a specific way. This is very much security by obscurity, because it's tr…

> Using a non-standard SSH port is a bad example because nmap can see through that deception in a few seconds. Compared to milliseconds. Do yourself the favor and open one sshd on port 22 vs one on a port >10000, then compare logs after a month. The 22 one will have thousands of attempts; the other one hardly tens if even any. The 99% level we're defending against here is root:123456 or pi:raspberry on port 22. Which…

> The 22 one will have thousands of attempts

The range in the figures is surprising. I leave everything on port 22, except at home where due to NAT one system is on port 21.

On these systems, since 1 September:

  lastb | grep Sep\  | wc -l

  160,000 requests  (academic IP range 1),
  120,000 requests  (academic IP range 2),
    1,500 requests¹ (academic IP range 3),
    1,700 requests² (academic IP range 3),
  180,000 requests³ (academic IP range 3, just the next IP),
   80,000 requests  (home broadband),
   14,000 requests  (home broadband ­— port 21),
    5,000 requests  (different home broadband, IPv4 port)
        0 requests  (           ,,     ,,      IPv6 port)
¹²³ is odd. All three run webservers, ² also runs a mailserver, yet they have sequential IP addresses.

I don't bother with port knocking or non-standard ports to ensure I have access from everywhere, to avoid additional configuration, and because I don't really see the point when an SSH key is required (password access is disabled).

Re: Security by obscurity is underrated

#403
post #342
post #273

Earlier quoted context omitted.

Here's a counter-example (I said else-where in this thread): Imagine a 0day for SSH drops tomorrow. Almost immediately script kiddies all over the world will be trying to take over everything running on port 22. I'll also point out that we're generally talking about different threat vectors here, so it's good to lay them out. I don't think obscurity helps against a persistent threat probing your network, it helps aga…

>Imagine a 0day for SSH drops tomorrow. Almost immediately script kiddies all over the world will be trying to take over everything running on port 22. But how much of a threat is this? Who's going to drop a ssh 0day with PoC for script kiddies to use? If it's a bad guy he's going to sell it on the black market for $$$. If it's a bad guy he's going to responsibly disclose. >You're right that these events could happen…

It makes the logs less noisy. And with much less noisy logs it is easier to notice if something undesirable is happening. Also from my experience this 50% is more like 99%.

Re: Security by obscurity is underrated

#405

Earlier quoted context omitted.

It doesn't add enough to compensate for its costs, which are commensurate with those of VPNs, which provide drastically more return on the investment. But VPNs don't have a cheering section, because they're so obviously useful that nobody has any incentive to make that banal observation. "Port knocking" is idiosyncratic and widely looked down on by security engineering teams, so there's a contrarian impulse that make…

I'm struggling to walk away with a crystallized view of why port-knocking is bad, though. I do agree, nobody should be going to sleep at night, relying solely on obscurity as their source of protection. But these commenters are offering it as an additional layer of indirection. They're not touting it as _the_ solution, full stop. At the most basic level, would you refute the claim that port knocking or alternate port…

There's several components to this.

Foremost, there is an opportunity cost to setting it up. The time you spend setting up port knocking could be spent setting up another form of security. I believe it is a sound argument to say that a VPN provides more security at a similar level effort. No public SSH means an attack cannot know SSH is running on the server from a port scan because it simply isn't listening. It allows you to reduce the attack surface - you can add more and more servers that you need to SSH into, but you are only allowing public access via your VPN - so you have fewer potential ingress points, and can ratchet up your security and auditing commensurately. And if your VPN concentrator is owned, you should have been setting things up so that they did not implicitly trust someone just because they were on the VPN, so you still have all of your usual measures of security in place.

In that case, there's just not much point. You could also enable port knocking, but I don't think it provides much benefit.

That brings us to the next part. Port knocking is a "weird" thing. It's idiosyncratic and not standardly used. Documenting it and understanding it is additional overhead, and it's something you have to manage and worry about on every server that's using it. Additionally, both standard and SPA implementations are vulnerable to man in the middle attacks, though most SPA based implementations will require an active MITM in that blocks the initial packet rather than just replaying a knock sequence. So extra complexity, less secure, and an oddity on the network that you have to have documented and explain to new team members, etc.

If you're a single person managing a single server, well, honestly you're probably fine just turning off password auth. And you can feel free to do port knocking and whatever else. It probably doesn't matter.

Re: Security by obscurity is underrated

#407

Earlier quoted context omitted.

I'm not sure I necessarily understand your argument, so my apologies if I'm off here. In scenario 1, you do not gate access via VPN. Things are accessible via the public internet. In scenario 2, you do gate access via VPN. Things are not accessible via the public internet. Someone compromises the VPN. They now have as much access as if there was no VPN and things were accessible to the public internet. In scenario 2,…

In the setups I've seen, once you've connected through VPN you're essentially on the LAN. If you compromise the SSH server, then you're also essentially on the LAN. Yes with the VPN you still have to compromise the server running the SSH service if that's the machine you want access to, but inside the LAN you now have a much greater attack surface. Of course if the setup is VPN -> firewall -> SSH to make sure only th…

But without the VPN, you're already the equivalent of on the LAN because all of these services are exposed to the public internet.

In the discussion we're having, we're going from a setup where there is no equivalent to a private network because everything is public, to having a private network that only allows you access to the things that were previously public.

Re: Security by obscurity is underrated

#408
post #111

Earlier quoted context omitted.

> This has it completely backwards. Security through obscurity's goal is not to signal predators, it's the opposite. The goal is to obscure, to hide. The "signal" is there is nothing here (or nothing here worth your time). Most of the usages of "security through obscurity" that I've seen dissected and decried haven't been in the sense that something was being hidden, but rather that something was being confused. For…

“Security through obscurity” means something like e.g. “uses a bespoke unpublished crypto algorithm, in the hopes that nobody has put in the effort to exploit it yet.” Usually this is a poor choice vs. going with the published industry standard, because crypto is hard to get right, and people rolling their own implementations usually screw it up, making life much easier for dedicated attackers than trying to attack s…

Banking Software uses all sorts of security through obscurity. Infact Unisys used to make custom 48bit CPUs for their clearpath OS to make targeting the hardware very difficult without inside knowledge of the chip architecture.

Re: Security by obscurity is underrated

#409

risk = probability * severity Security by obscurity is bad regardless of other controls because it does little to reduce probability of attack and nothing for severity. It is only barely helpful at reducing the probability of attack because it is ineffective against various forms of automated footprinting. That is just the attacker. Security controls impact everybody though. Not only does it make the problem obscure…

Ehh the majority of companies practice security by obscurity as an extra layer. There's the idea in security that an attacker knowing your algorithm/practices shouldn't mean anything yet you rarely see companies detail the security measures they take on internal systems because we know keeping this secret has no downside.

Popularity does not validate stupidity.

Security policies at most companies are often generic and not secret. Reporting chains for emergency remediation and asset identification are secret because those identities are potential attack vectors. Information sensitivity of that nature means it must be protected from disclosure and not that it should otherwise be hidden. The key phrase for sensitivity management is: need to know.

Re: Security by obscurity is underrated

#410
post #247
post #27

There's something to the idea of rehabilitating "obscurity", or at least recognizing that "cost" is part of threat models, and you can raise costs for particular attack vectors by degrees instead of "to infinity". But SSH is a terrible example, because the cost to the defender of simply not having SSH vulnerabilities is the same, or even less, than the cost of obfuscating it with nonstandard ports, "port knocking", o…

>But SSH is a terrible example, because the cost to the defender of simply not having SSH vulnerabilities is the same, or even less, than the cost of obfuscating it with nonstandard ports, "port knocking", or fail2ban, which are all silly ideas. This just shows how ignorant you (and most) are on the topic of port knocking. SPA port knocking is cryptographically secure and does not suffer from replay attacks. Similarl…

>This just shows how ignorant you (and most) are on the topic of port knocking.

You, uh, do know who you're replying to, right? https://sockpuppet.org/me/ if not - I don't mention this to go "lol he must be right because of who he is", but calling a well respected security researcher with plenty of real world street cred ignorant is a bit much.

>SPA port knocking is cryptographically secure and does not suffer from replay attacks.

SPA port knocking doesn't suffer from passive replay attacks, but it does suffer from block and replay attacks. An active MITM can still get you.

His suggestion hasn't been "if you care about security just don't do port knocking", his suggestion has been "if you care about security just throw up a VPN it'll be more secure and just as much work"

Post reply on HN