Anyone who has launched
sshd on an Internet-facing server has had the same experience: within a matter of hours or even minutes, the server is receiving hundreds of failed-login attempts per minute. This continues night and day.
In my opinion, the fundamental problems with
ssh are twofold:
- Most damningly, it is "a shell." The fact that it encrypts its network traffic is immaterial: it presents the dreaded prompt:
- It reveals its presence to anyone who does a port-scan.
But there
is an alternative:
OpenVPN with digital certificates and tls-auth security.
As I describe in my blog post
How to Build a Dwarvish Door With OpenVPN, it is possible to create an outer portal into your system that not only cannot be penetrated, it cannot be
detected!
When the
tls-auth feature is used, the OpenVPN server requires that supplicants show possession of a particular digital certificate, on their
first exchange with the server. If they do not, OpenVPN silently
drops the packet: it does not respond at all. Thus, to a port scan and to a "script kiddie," it simply isn't there.
Someone who
does possess the first-level certificate does receive a response, and the
only response that should be accepted is: a unique, one-of-a-kind, individually issued (usually, "self-signed")
certificate: up to 4,096 bits of pure-random information.
(N-E-V-E-R(!!) settle for "Pre-Shared-Keys (PSKs) == Passwords!") Falsification or "brute forcing" of such a thing is impossible, and each recognized certificate is unique. Thus, they can be
revoked individually. (For "road warriors," the certificates can also be encrypted such that a password is required to unlock it.)
It is reasonable that authorized users should be subject to further challenges -- user names and passwords,
ssh certificates, and so on -- once they have successfully passed through the OpenVPN portal. But, by placing this "undetectable bastion" as your outer-ring defense, you leave 100% of the script-kiddies out in the cold. Your servers (
sshd and otherwise ...) should "listen"
only to the virtual-tunnel provided by OpenVPN, so that in order to reach any of them you must first have passed through the tunnel.
(Also: you should constantly "port scan" your own systems to be certain that
"no ports appear to be open.")
Is it "hard to do?" Frankly,
no. OpenVPN uses the same "TLS" cryptographic protocol that is used by
https: web sites. It includes the "EasyRSA" toolkit that, as the name implies, makes the necessary operations very "easy."
Try it, and "enjoy the blissful
silence." Your server logs simply
don't have any(!) "failed login attempts" to report ... period. The script-kiddies never make it that far. And, they never will.
... and yet, your
authorized users, each of whom you know by the unique certificates that each one bears, can pass through the gantlet with ease. Once the "tunnel" is connected, they can access network resources as though they
were "local." You don't have to worry about their traffic passing through the Internet without encryption if they "do the wrong thing" or "fail to do the right thing." The seemingly-effortless simplicity with which they gain access stands in direct contrast to the
impossibility that faces everyone(!) else in the world.
This, in my opinion, is "encryption as it
should be."
- Authorized users are not inconvenienced.
- Access is tied to the possession of "a unique thing," not "a (not-so) secret," and each-and-every thing is tied to a single authorized possessor of that particular thing.
- The scenario can be centrally managed.
- Access can be revoked at will, without impacting any other authorized user.
- Unauthorized users face an impenetrable (and, invisible) barricade that they cannot penetrate. ("The door is shut.")