41–50 of 59 posts
OpenVPN with tls-auth switched on is a pretty robust front door. If you combine that with enforced key only auth for ssh, ensure all internal machines run their own firewall and logically split different bits of your internal network off in to their own subnets you've got a fairly secure foundation to build upon. Another easy win is switching internal services over to TLS/SSL only (where it makes sense/is possible to do so).
Earlier quoted context omitted.
I've been doing this sysadmin thing for a long, long time, and have built some large, high profile platforms,[1][2] and I can tell you that few things have made me happier than port knocking. Yes, it is a password with a tiny number of "bits". But nobody suggested using only port knocking, so that's not significant. Yes, if my attacker is sharing the exact same NAT'd IP as me then they have a window to attack ... my…
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?…
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.
Jump boxes are a good idea. A better idea, if you're in AWS, is to use a VPC and just VPN into your environment; the VPN terminator in the VPC serves the same purpose as a jump box. If OpenVPN scares you, you can still do layer-4 filtering to minimize the impact of losing the OpenVPN server (ie, to get it to "no worse than if we hadn't used VPCs in the first place). "Single-packet authentication" is, I think, silly,…
I agree. I usually use simple port knocking for that purpose. Surely you can agree that "no ports listening" is a better circumstance than "tcp/22 open to the world, with key-based-auth only"?
A VPN is redundant (and requires special client), whereas port knocking to open a port for ssh (that only supports key-based auth) is a simple matter of a few "nc -w 1" lines in a script before you ssh...
EDIT: Saw your posts below. You presuppose that such OpenSSH-zero-day holding attackers are specifically targeting you, which is not invalid; however a spray-and-pray quickly after public release is much more probable in a lot of cases.
Earlier quoted context omitted.
Yes, an AES-CTR transformation would be more secure than any port knocking variety such as SPA, at the cost of being more complicated. But the point in port knocking is not its intrinsic security, which is not worth to talk about: its point is actually the obscurity it adds to some other secure access method such as SSH, and its ease of implementation and usage. With it you get much shorter and less noisy logs to mon…
You're not thinking the threat model through. If you're not concerned about the kinds of serious, dedicated attackers who have OpenSSH zero-day, you're fine leaving properly-configured OpenSSH exposed. If you are concerned about those attackers, port knocking is barely a speed bump. I also dispute that a plugboard proxy is "more complicated" than "cryptographic port knocking".
I'm not aware of any available plugboard proxy solution, so it would have the added complication of hacking it together. That's what I meant. And there are diminishing returns there: a non-criptographic port knocking scheme with a few packets could be good enough as a camouflage in many cases. But I still find it to be a time saver in the more general case (not APT). I think having cleaner logs is worth using this simple trick then.
Rather than provide an untested and possibly subpar experience of our site, may we suggest downloading one of these fine browsers? (We think you'll find your overall experience of the Web will improve if you do.)
Jump boxes are a good idea. A better idea, if you're in AWS, is to use a VPC and just VPN into your environment; the VPN terminator in the VPC serves the same purpose as a jump box. If OpenVPN scares you, you can still do layer-4 filtering to minimize the impact of losing the OpenVPN server (ie, to get it to "no worse than if we hadn't used VPCs in the first place). "Single-packet authentication" is, I think, silly,…
(tls-auth doesn't protect you from vulnerabilities in the OpenVPN data protocol, but that's a lot simpler.)
Earlier quoted context omitted.
Bastion hosts are generally a bad idea. There is not a single implementation of a bastion host that doesn't have significant security holes. This is doubly true if you want to do proper group based access control. Most notable of these issues is the nature of either needing SSH agent forwarding enabled or storing a copy of the private keys on the bastion host (please don't do that). There are ofcourse ways of dealing…
To a one, every medium- and large- sized application deployment I've tested that failed to set up VPC (or something like it) has fallen to some stupid oversight on some stupid backend, support, or dev machine. Don't rely on individual host hardening for security; you'll fail.
I only said bastion hosts are bad and generally decrease overall security because it's almost impossible to craft one that doesn't create more security holes than it closes.
Earlier quoted context omitted.
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?…
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.
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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).
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.