LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   (MHO) "Why you should be using VPN, not SSH ..." (https://www.linuxquestions.org/questions/linux-security-4/mho-why-you-should-be-using-vpn-not-ssh-4175617145/)

sundialsvcs 11-07-2017 01:02 PM

(MHO) "Why you should be using VPN, not SSH ..."
 
Anytime you deploy a web-site or any other shared resource to "the web," or to "the cloud," you are immediately confronted with the question of how to provide "back-end" access to it. These are the avenues that are to be used only by a select group of "trusted" accessors – not by the general public.

The "customary" way of doing this, it would seem, is ssh. This is referred-to as a "secure shell," simply because it encrypts the traffic that it sends to its destination. However, I would argue that "it is 'not secure at all,'" very-simply because it presents the same thing to anyone who comes to it:

Quote:

Originally Posted by 'eek!':

login:

:eek:

(Although it is possible to prevent ssh from doing this ... to cause it to demand a digital certificate and to refuse to accept "a password prompt" as an alternative ... this is not easy to do, and is therefore not ordinarily done.)

ssh presents four(!) security vulnerabilities which can be completely avoided through the use of other, equally readily-available, security technologies (VPN ...):
  1. "Scannable 'Ports'": The service exposes itself to external detection, by opening a well-known TCP/IP port.
  2. Lack of Accountability: "Anyone in the world" can attempt to connect.
  3. Hackability: In the end, the service presents a "login: prompt ...
  4. "Special Case" for Authorized "Insiders": Authorized processes "on the inside," who wish to communicate securely with other parties, are always obliged "to do so 'correctly.'" If they fail to do so, their communications might in fact be un-protected ... and they might not know it!

VPN (Virtual Private Network) technologies, on the other hand, offer a decidedly-superior alternative. (The easily-easiest of these is "OpenVPN.")

These technologies undertake to provide you with "a cryptographically-secure [virtual ...] network appliance." A router, or a switch. In both cases, access is provided to "a remote subnet," as any such network appliance would do, and the fact that "the connection is, in fact, securely encrypted" is not evident at all. Thus, individual applications do not need to take any extra steps at all to assure their own security.

VPN technologies also undertake to identify the two communicating parties to one another. One-of-a-kind digital certificates can(!) be used on both sides to ensure that the two parties cannot be talking to a stranger. (Admittedly, these protections can be turned-off, reduced to "PSKs == Pre-Shared Keys == simple passwords.") :cry:

VPNs usually use the UDP protocol (not TCP/IP) to communicate with one another, so there are no "open ports" to scan. (OpenVPN provides additional protections in the form of its tls-auth feature, which causes it to ignore connection requests by supplicants who do not appear to be authorized.)

273 11-07-2017 01:15 PM

I'd love to use a VPN, I've wanted to for a while now, but I haven't yet found a tutorial which actually tells me what I need to do and why and can be followed easily.
I know the basic functions but by the time I get to creating a private and public key for my server (a Pi lying around) and selecting its domain name and public key authority then creating private keys for hosts things seem to break down. I have SSH working with keys but with VPN all I see are references to things my setup doesn't have.
It really is probably me but VPN seems a little too tricky.

sundialsvcs 11-07-2017 07:19 PM

Quote:

Originally Posted by 273 (Post 5777977)
I'd love to use a VPN, I've wanted to for a while now, but I haven't yet found a tutorial which actually tells me what I need to do and why and can be followed easily.
I know the basic functions but by the time I get to creating a private and public key for my server (a Pi lying around) and selecting its domain name and public key authority then creating private keys for hosts things seem to break down. I have SSH working with keys but with VPN all I see are references to things my setup doesn't have.
It really is probably me but VPN seems a little too tricky.

There are two main-line VPN technologies: "Swan" (IPSec), and "OpenVPN." Of the two, I prefer the latter for a number of reasons: especially because it is mostly a user-land process that requires and expects very little from the host operating system.

OpenVPN relies upon the TLS (aka "SSL" ...) stack for its security architecture: the same thing that drives "https:" web sites. The server validates the certificates that are presented by clients, by verifying that they are all (self-)signed by the Certifying Authority (CA) which has been made known to it ... and by verifying that the presented certificate has not been revoked. The very same "EasyRSA" tool-kit that is used with secure web-sites is also used here.

OpenVPN also has "an ace in the hole," in the form of its tls-auth feature, which uses a separate certificate. The server will ignore any supplicant which cannot, in its first connection-request packet, demonstrate that it possesses a copy of this certificate. It simply will not respond to it at all. And, because the UDP protocol is being used (not TCP/IP), "a server which does not respond cannot be detected." Thus, "the one-and-only doorway into your system," in addition to being stoutly protected, becomes "a secret door."

Authorized users, bearing the proper non-revoked credentials, pass swiftly and surely through the double-gantlet ... and you know every one of them by name. No one else can even find(!) it.

Meanwhile, these users can be certain that they are, in fact, communicating with the intended host, and that all of their communications are secure, even though they need give no further special thought to security. The resources of the remote subnet simply appear to be local, as though no layer of encryption existed at all.

"It's just as painless, and yet, just as secure, as the communications that you are right now(!) having with LQ!" (Did you notice the padlock on the URL-line of your browser window?)

ondoho 11-08-2017 12:40 AM

please enlighten me:
is this VPN technology possible to implement without a third party - usually a paid-for vpn service?
or how could one implement that on their own network, with or without additional hardware?

273 11-08-2017 12:47 AM

Quote:

Originally Posted by ondoho (Post 5778111)
please enlighten me:
is this VPN technology possible to implement without a third party - usually a paid-for vpn service?
or how could one implement that on their own network, with or without additional hardware?

This has been part of my issue, the technology is set up as though one is using or maintaining a certification authority which to a single-instance home user is a lot to mess with.
With SSH I just generate a public key on each client I want to connect with, drop it in a directory on the host then connect using the key while on a trusted network to accept the server certificate and it's done.
I've spent ages generating certificates and key pairs for OpenVPN then copying across what I think the tutorial* is telling me I need only to find that when I try to connect Network Manager is telling me "No VPN Found".

*I type "the tutorial" but, of course, I mean at least 5 since I've followed the process 3 times using 3 initial starting tutorials only to find that they're out of date and I need to start referring to others to find the latest location of the config files I need to copy over or the correct script to invoke and so on...

tshikose 11-08-2017 01:24 AM

Hi,

While I mostly agree with the OP that OpenVPN is "better" than SSH, I must also say that I just use both with no complain so far.
On the official OpenVPN web site one can find good howtos that I used to got me started.

sundialsvcs 11-08-2017 07:47 AM

VPN technology provides for secure communication between two subnets. It functions as a software "router" or a "bridge."

Some companies sell access to VPN servers which they host. The idea is that you establish an encrypted connection to them (from your coffee shop hangout, say), and they forward your traffic to the Internet. You can configure your coffee-shop laptop such that everything flows through the VPN tunnel and is thereby securely encrypted.

Because VPN technology uses the UDP protocol, not TCP/IP, there are no "open ports" to scan. Anyone can discover that you're running sshd just by observing the presence of an "open port," and their attack-bots will proceed to make thousands of "unauthorized access attempts." Whereas, if you're using OpenVPN and tls-auth, the server is undetectable. Any attempted connection request packet which does not seem to bear the necessary credentials is simply dropped. The host will not initiate the connection handshake process at all, except with a client which can show that it is very likely to be legitimate.

The fact that the technology operates as a router/bridge also means that the encryption is transparent to its users. The remote subnet is "just there." It just so happens that the connection is secure. All of your software can ignore this fact: they don't have to do anything special to enjoy the benefits of the security. Nor do you need to worry that some traffic will pass through the Internet "in the clear." Furthermore, if digital certificates are used as they properly should be, both the VPN client and the server have positively identified themselves to one another: you can be certain to whom you are speaking.

If someone in the outside world has a legitimate reason to connect to your box from the outside world, you know who that person is. You give that person a one-of-a-kind credential, much like the badge that you swipe or scan to get past the front door at work. Armed with this un-forgeable digital credential, the authorized user passes through the secret door quickly and easily. When that person should no longer have access, you simply revoke that person's "badge."

If you successfully penetrate an ssh barrier, probably the first thing that you do is to coin a certificate and drop it into the target user's .ssh directory, where it most-likely will not be noticed. :eek: VPNs don't store the credentials needed to access an account in that account's home, and they do check the Certifying Authority which must have self-signed the key. It is common practice that any given key may be used to create only one connection at a time.

273 11-08-2017 07:56 AM

Quote:

Originally Posted by tshikose (Post 5778121)
Hi,

While I mostly agree with the OP that OpenVPN is "better" than SSH, I must also say that I just use both with no complain so far.
On the official OpenVPN web site one can find good howtos that I used to got me started.

The key pair example looks interesting but, of course, doesn't implement some technologies which make VPNs more secure.
The whole "certificate authority" concept, to me, needs simplification for us users who just want just to set up a VPN server at honme and connect from a laptop, phone or two.

IsaacKuo 11-08-2017 10:52 AM

Is this something which can be streamlined enough to be used within a home network?

What I mean is - I have a home network, and most of my ssh activity is between computers within this home network. However, this network does indeed have a WiFi access point. So, in particular, there are numerous Android phones and an iPhone which connect to this network via WiFi. I don't 100% trust all those devices (I maybe 98% trust them).

So, is it practical to put all of my linux computers (including my router) in VPN silos? Each computer is in its own subnet consisting of just the localhost. Then they are connected to each other via ???

Let's say I have 10 computers in my home network. Do I need to set up 45 VPN connections to connect each pair of computers to each other?

Is it possible to set up a VPN connection in a customized initrd, for my computers which use nfs root? The idea would be to customize the initrd script just before it attempts to mount / (modify /usr/share/initramfs-tools/scripts/nfs). It does ??? to connect up to the VPN of the nfs file server, at which point the nfs share of / is available (and all access to it encrypted).

273 11-08-2017 11:34 AM

I'm noy sure that's exactly a use case for VPN?
In that situation, provided I could get VPN to work, I would just set all wireless access up as guest access and require VPN to attach to the rest of the network -- assuming that were possible with the equipment present.

Personally, I just want to set u my Pi so that a VPN connection is forwarded to it by my router then allows access to the Pi and another machine or two on the network as well as the ability to connect to the internet from my home connection while elsewhere both for security and things like BBC iPlayer access abroad.

rknichols 11-08-2017 12:39 PM

Quote:

Originally Posted by 273 (Post 5778242)
The key pair example looks interesting but, of course, doesn't implement some technologies which make VPNs more secure.
The whole "certificate authority" concept, to me, needs simplification for us users who just want just to set up a VPN server at honme and connect from a laptop, phone or two.

It's actually pretty easy to set up if you just blindly follow the "easy-rsa 2" steps in that HOWTO. Generating the CA certificate and key is just a single command, "./build-ca". If you're building a "serious" CA (i.e., not just something to be tested and thrown away), you'll need to keep that ca.key file secure. I suggest encrypting it
Code:

mv ca.key ca.plain.key
openssl rsa -aes256 <ca.plain.key >ca.key

Do destroy ca.plain.key after you're sure you can sign new keys with the encrypted ca.key and your passphrase.

sundialsvcs 11-08-2017 06:36 PM

If you want to use VPN within your home network, I would do so by purchasing a router that has OpenVPN (or, failing that, IPSec [Swan]) support, and make sure that it can be used properly, i.e. with certificates not PSKs = Passwords. (Passwords, in any and all forms, are useless.) This is infinitely stronger than WPA2 non-security.

Most phones have support for at least IPSec built-in, and can also support OpenVPN.

The trouble is that most computers and especially phones are set up to be very lazy – indiscriminately connecting to any wireless network that they find within range and spilling-their-guts onto it. Presence "on the same network" very-erroneously is used to imply trust. People unknowingly lose vast amounts of privacy to this. They're also attaching "an Internet of things," and putting eavesdropping(!) devices into their own homes, also with zero actual thought to security.

The role of VPN is to act as a secure router or switch, facilitating secure access to some remote subnet or acting as a secure entry to the network from the outside. When certificates are properly used, the two parties not only communicate securely, but positively identify each other. (The parties to an SSH communication cannot identify each other.)

With tls-auth, the tunnel is invisible, because all unauthorized supplicants are filtered-out. There will be zero "unauthorized access attempts." You can't attack what you can't find, and you'll never brute-force a digital certificate. The server doesn't have to waste time fighting off bogus attempts to connect.

CA-signing is the mechanism by which the two sides actually ensure that the certificates they are using are "authentic." You can't simply coin your own certificate, slip it into a directory that you have access to, and thereby leave some door open for yourself. The certificate is issued by the signing process. But, unlike SSH, it does not have "authorized keys" files: if the presented certificate is signed by the proper CA, and has not been revoked, then it is accepted as valid.

Any SSH "authorized key" can be stolen, directly from the keys-file, and used anywhere by anyone who is in possession of it. Anyone can generate a key and put it there. Any key that "is there" is both trusted – and completely naked.

ntubski 11-08-2017 07:02 PM

Quote:

Originally Posted by sundialsvcs (Post 5778475)
Any SSH "authorized key" can be stolen, directly from the keys-file, and used anywhere by anyone who is in possession of it. Anyone can generate a key and put it there. Any key that "is there" is both trusted – and completely naked.

Um, do you realize that the keys in the "autorized_keys" file are public keys? "Stealing" them makes no sense.

Turbocapitalist 11-08-2017 11:13 PM

Quote:

Originally Posted by IsaacKuo (Post 5778304)
Let's say I have 10 computers in my home network.

You'd set up one with OpenVPN and then connect the other nine to that one.

https://docs.openvpn.net/

Or if you can set up OpenVPN on your router, have all connect to that.

ondoho 11-09-2017 01:58 AM

sundialsvcs delivers the same sermon in ever varying permutations, but fails to answer a simple question.
it's a communication desaster.


All times are GMT -5. The time now is 07:02 PM.