Hacker News Reader

Comment by peterwwillis | Hacker News Reader

Mr. Sysadmin, I have four questions:

1. When was the last time your sshd was hit with a 0day?

2. Why aren't you running grsec to prevent buffer overflows (amongst other things) ?

3. Wouldn't it be easier to DOS your host with excess traffic (like all modern DDOS attacks), rather than find a remote-code-execution buffer overflow 0day and use it solely to starve resources on a bastion host?

4. Why don't you use a VPN? If you used a udp-based VPN nobody would even know the port was open (connectionless) and you could even require a preshared key, which is the more secure equivalent of port knocking.

View on HN

The answer to #1 is "never". That's no reason not to be aware of the threat and to guard against it.

What is the state of grsec on FreeBSD ? I'm not sure...

Answer to #3 is yes.

I don't use a full-blown VPN in a lot of cases because it's a lot of complexity that isn't needed. knockd is extremely simple (look at the source) and simple to use.

---

This is the way all discussions about port knocking go:

"I like port knocking"

"But port knocking is not the christ child that will deliver us from all of the evils of the world!"

No, it's not. It simply adds a small amount of incremental security at almost zero cost. All else being equal, my sshd was visible before, and now it's not.

Why do you encrypt your traffic?

If the port knocking feature exists to "hide" your network service, you're saying the security of your service is based on the idea that nobody can see your traffic.

But if someone could see your traffic, and therefore your connection, and thus the port your service runs on, they could also clearly see the contents of your traffic. So port knocking would be useless, and everyone could see your traffic, and probably be able to do anything they wanted with it.

But since you use port knocking, you clearly believe nobody can see your traffic. So it then follows that you don't need encryption.

So clearly you should be using telnet.

So clearly you should be using telnet.

This is just an absurd statement. You have conflated to completely separate issues.

you're saying the security of your service is based on the idea that nobody can see your traffic.

No, it's because no one can find the service, not see the traffic.

Okay, let me see if this explains it better:

1. Anyone who can see your traffic can see where the service is.

2. We assume anyone can see your traffic because you're using an encrypted connection. (The conversation should have stopped here, but i'll continue anyway...)

3. The only thing port knocking does is obscure your service from port scanning.

4. The equivalent method to preventing someone finding your service via port scanning is changing the port number.

5. Changing the port number prevents all non-direct-attacks from finding your service. (Nobody scans every TCP+UDP port of every IP on the internet for one service, because 563.6 trillion network packet send+recvs takes a long time, which doesn't even factor multiple tries or error retransmissions).

6. A direct attack by a committed attacker will eventually find your network service.

7. Port knocking does not add to security. It partially obscures information, but it does not prevent access, and it operates on faulty assumptions about network security; the information is still there, you just have to look for it differently. It is less reliable than even IP whitelisting.

8. In the real world (and not the "gee I think this sounds more secure" theoretical world) every single other network service you have will be exploited before OpenSSH. So trying to hide OpenSSH while not hiding your other services becomes farcical.

1. Anyone who can see your traffic can see where the service is.

Dude, right there you lost me. 99.99999999% of the internet can't see your traffic. The NSA can. Your ISP can. Random threats on the 'net at large cannot see your traffic.

You are radically misinformed. As a hacker, I have about a dozen ways to see your traffic. We don't encrypt credit card transactions because we're afraid the NSA or your ISP's network admins might pick up your card and buy some sneakers on Amazon.

Ways I can see your traffic:

  * fucking with bgp
  * fucking with routers in general
  * fucking with switch port tables
  * fucking with proxies
  * spoofing
  * sniffing wireless networks
  * sniffing wired networks
  * tapping a cage backbone
  * rooting an isp
  * rooting a dslam
  * rooting pops
  * rooting firewalls
  * rooting endpoints on management ports
  * abusing hosted networks

The single easiest way to view someone's traffic is to use the completely fucked-up retarded configuration of an intermediary router. Do you know how many routers sit between you and your destination? Do you know how many of those have 10-year-old configurations enabled via telnet on publically-routable interfaces with default snmp community strings and 6-character passwords?

Don't assume that just because you aren't aware of a particular attack that it doesn't exist or doesn't apply to you. Hackers are only limited by their creativity.

Please don't trust the network.

Regarding item 4, a VPN solution is considerably more complex and error prone than port knocking plus SSH. What do you do if/when your VPN service fails? I think you would usually have a VPN service AND a port knocked SSH backdoor.

Yes, good security is usually more complex, though error prone I don't think is accurate. What do you do when your SSH or port knocking service fails?

I meant its configuration and maintenance is more error prone. Certificates may expire without renewal, for example. I've seen port knocking work without a flaw for over ten years in a row, and the SSH configuration is shorter and almost never changes (unless it is to change the cipher or the user).

A side-by-side comparison would require side-by-side configuration. And you can totally configure both SSH and a VPN the same way.

Both ssh and a vpn support authenticating with public keys. Both require maintenance on security updates, or to gain new features, or to strengthen ciphers used, or allow a new user access.

You mention certificates. You do not need to use certificates with either, though you can. You do not need to validate certificate expiration with either, though you can. You can also set expiration to some year well past when the technology will even be relevant.

You claim that expiration of a certificate is somehow a flaw, yet it exists as a security feature. If what you want is to be more secure, you would be wise to use this feature, and not discard it as an annoying maintenance task. However, happily, you can easily ignore it with a VPN just as you do with SSH.

Yes, good security is usually more complex

Wow. So, in your mind software that is more complex is more secure. OK, I think I understand the origin of a lot of your comments, then.

We completely and fundamentally disagree.

What do you do when your SSH or port knocking service fails?

That's a complete red herring. What do you do when your firewall fails??

I love this. I absolute hate VPN. It's waaaay too complex and I fear vulnerabilities in that waaay more than other software. So, I'll stick with port knocking. It's much safer, IMO.

Reply on news.ycombinator.com