(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:

(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.)

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?)

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...

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.

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.

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.

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).

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.

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 itDo destroy ca.plain.key after you're sure you can sign new keys with the encrypted ca.key and your passphrase.

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.

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

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.

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

Hi ondoho,

I will try to give answers to your post #

Yes, just follow the howtos on OpenVPN official documentation, and you will end up with an infrastructure relying on your self-signed CA.

Generally, you do not need any additional hardware, providing that you already have computers that can access Internet, and and at least one that is permanently connected to and reachable from Internet. It is on that particular computer that you will base your CA, and have it acts as the OpenVPN server. The others will run as OpenVPN clients.

Thanks for the link, and the basic strategy recommendation!

It looks to me like OpenVPN is a commercial product and that to have 9 simultaneous connections would require purchasing it. That's a deal killer for my home network already. So, perhaps Openswan could be a good alternative?

This strategy also seems like a single point of failure, which I do not like. Currently, my main server is a Debian computer serving as my router and nfs server (among other things). I have all of its functionality, including IP address, ssh keys, etc, duplicated on a replacement server. In case my main server fails, I physically swap in my replacement server and I'm up and running again. It's not an instant failover, but it's good enough for my purposes and relatively simple to maintain.

Setting up a drop in replacement server with OpenVPN seems problematic. Maybe not with Openswan?

I don't know...it seems like a lot of complication and effort for dubious benefits. I find it pretty easy to set up and maintain using ssh to log in from one computer to another on my home network. I honestly don't see any benefit there. Bluntly, I'm going to keep on using ssh to log into other computers in my home network even if I also set up some sort of VPN thing. My biggest security concern is that I'm using simplistic IP level security for nfs shares of my nfs root computers.

If there's a straightforward way to encrypt all traffic between all of my home computers initiated within the initrd environment, then great! Otherwise...I'm not sure.

Openswan might be more my speed, and it seems like it might be straightforward to set up since I'd be using it strictly within a simple LAN (so, no filtering or NAT to worry about).

http://www.enterprisenetworkingplane...-Your-Mind.htm

In my case, the router's shared subnet would be the entire internet, while each client's shared subnet would be only a dummy interface's ip address (different from the actual physical NIC's LAN address). It seems pretty straightforward for my computers which boot off of a local drive. I'm not sure whether the potential benefits are worthwhile in my usage case...but I can't gauge that before figuring out basically what I'm looking at.

This whole "one or the other" question is silly. When I need to connect to a production server, I set up a VPN to that network, and then log in using SSH. They are not choices, they are tools that complement one another.

According to https://openvpn.net/index.php/terms-of-use.html
It seems that they also sell something called "OpenVPN Access Server" which is proprietary. https://openvpn.net/index.php/access.../overview.html

That's running an encrypted SSH session inside an already encrypted VPN tunnel. I hear my laptop groaning (and it's not even turned on!) at the mention of running every packet twice through the encryption engine. SSH on a nonstandard port and with password authentication disallowed works fine for me. I get one or two hits per month from probes on that port, and those typically send some fragment of HTTP and disconnect immediately when the SSH server replies.

I do keep a VPN service running at home and connect through it as my default route when I'm away and using my laptop at some random WiFi hotspot. It works great for that.

I'm not talking open source vs proprietary, I'm talking freeware vs commercial. But I was just looking at the provided link and it's FAQ etc. That may have led me down the wrong path.

Okay, so I've decided to just leap in with one of my Debian Stable machines with:

I don't really know what I'm looking at exactly and how to get started (it would be nice to be able to search for openvpn without seeing hits about the OpenVPN Access Server or whatever also). But I figure I could start off experimenting with using the Network-Manager applet GUI (between computers which have network-manager, obviously)...then if I figure out a good potential use for it I can practice doing it via command line.

Or...ugh. Okay, I don't really care about using the network-manager GUI. I mean, I might use it for a laptop I'd be using on the go. But I'd rather do this stuff via command line and text config files etc. It's just easier for me to set up and maintain my computers that way...shake and bake with command line/copy/paste, rather than configuring junk manually via GUI like a windows monkey.

And I've rethought my overall strategy a bit. I figure all computers might as well access the Internet the normal way. As such, every shared "subnet" is actually just localhost. So, my main server/router keeps the same basic DHCP server and routing functionality it currently has, but it no longer accepts any connections to ssh or nfs on its physical network interfaces. It looks like the default is to share only localhost anyway, which suits my use case fine:

https://openvpn.net/index.php/open-s...ion/howto.html

So, this is getting more clear in my mind. Basic internet connectivity and LAN functionality remains the same, but I tighten up ssh and nfs so they only accept connections from within the VPN. My client computers auto-connect to the server via openvpn, which allows the clients to connect to the server's nfs shares and ssh access. I think that by default, I will need to ssh into the server and then from there ssh to other clients (I am okay with this). Generally, the clients will not be able to see each other.

...hmm. Okay, I will need to set things up so that the clients can directly see other clients. I use synergy to have the mouse/keyboard of one computer control many computers...

In any case, I just do not see any way around still using ssh. I will definitely still use ssh to give myself a remote command line interface. It works, and it works well, and I see no sensible way in which openvpn or any other VPN solution is a replacement for ssh. But I've got a lot of other stuff which I wouldn't mind tightening up...

I don't use gooey-tools to manage OpenVPN, so I can't speak to that. ("Real programmers don't need no stinkin' GUI ...") ;) ;)

But, basically, yes: you only expose OpenVPN to the outside world. You have no port-forwarding other than a UDP (not TCP/IP ...) port of your choosing. You specifically firewall-away any attempt to reach the outside world directly.

Now, your OpenVPN server will expose a virtual IP-address, on its software-produced utunX device ... (you are using OpenVPN in tunnel, not bridge mode) ... for itself: it should be 10.8.0.1. And you arrange for your sshd and so-on to "listen" only to that port for incoming connection requests. It does not listen to the outside world, and, even if it accidentally did, your home router will not "port-forward" anything for them to hear.

Every directly-connected external user will be assigned some IP-address on the 10.8.0.x subnet, and this is how the host communicates with them. (It's a configurable option whether you want the various clients to see and to be able to communicate with one another.)

So, your sshd, and anything else on your internal network that you wish to expose to your clients (via push route and a corresponding client-side pull ...), will be accessible only by first establishing a connection through your secret door.

:eek: If you are using a GUI, it is extremely important that you do n-o-t succumb to the temptation of "pre-shared keys == PSKs == passwords!" :eek: You must arrange things so that each and every authorized client has a uniquely-generated, one-of-a-kind, digital certificate, as does the server itself, and that it accepts no other form of identification. (If you use PSKs, you've basically thrown all of the possible goodness of any VPN right out the window ...)

Since I have never used the Gnome tool, I cannot speak for what it does.

However – in my blog, here, I do address OpenVPN in is several different ways, and "setting up the necessary files in the old-fashioned way" in this case just might be easier.

All crypto tools are engineered(!) to be obtuse, since they presume that you are Eve, not Alice or Bob. You will :banghead: against their very-deliberate obstacles – and I am a card-carrying testament to that fact(!) :) – but, really, only for a very little time.

If I firewall away any attempt to reach the outside world directly, how do I reach the outside world? This seems bizarre to me. For example, I regularly browse the internet. I also access Debian's software repositories to keep my computers up to date. I'm supposed to firewall away all this stuff? Why? To what benefit?

I looked through all four blog posts, and none of them seem to give any instructions on how to set this up, or link to instructions on how to set this up. This does not seem very helpful.

It sounds like you expect people to figure it out for themselves how to set it up, and that this is a feature rather than a flaw.

But I don't see it that way. I think that security depends upon giving adequate guidance on how to set things up without making mistakes. Those mistakes are an obvious risk for making security mistakes.

There are detailed straightforward instructions for how to set up ssh securely. I am quite happy with my passphrase protected key based ssh set on a custom port.

I am satisfied with the internet-facing security on my main server/router (straightforward iptables based security with only the custom ssh port and my web server ports open on the internet side). My interest in VPN is possibly tightening things up on the inside of my home LAN. It's not the "outside world" I'm so much concerned about. I'm more concerned about the various non-Debian devices within my LAN (such as Android phones).

The more obvious solution is something someone suggested earlier - set things up so that the WiFi access point is "outside" the trusted zone. Or set up a restricted guest WiFi. But these approaches make it difficult to make specific exceptions for various things, such as an Android app which lets the phone act as a remote control/keyboard/mouse via WiFi.

(Note that it's really hard to do nfs through an ssh tunnel because it likes to use a wide swathe of random ports. This is why it looks promising to me to have a solution which encrypts/routes all ports.)

+1

Security software which nobody can use does not provide security.


Sshfs?

I have found sshfs to be rather brittle compared to nfs. It's great for a short term connection, but it does not seem suitable for a long term connection.

I don't know how stable a VPN connection is for permanent connections, but I'd think it's pretty good since that's a common use case. And even if it goes down, it will be possible to reconnect it and the relevant nfs mounts will have simply sat around waiting for the connection to return. My experience with sshfs is that it's very sensitive to any sort of connection breakage.

That is not what a VPN is for, nor will it serve that purpose well. What you want is your WIFI network on a different subnet from your wired network, and consider it a DMZ with access to the internet but NO access into your internal wired network. If you have a WIFI only network device (printer?) you may have to add a SECURE wifi subnet and hard-code the IP (or make a reservation) for that device.

I have one rented VPS (at $7.99 month) which serves as OpenVPN server.

My regular home network has a Linux box which acts as internet router and OpenVPN router. That Linux box is connected to the VPN server.

I have a number of measurement/logging computers remotely installed (RasPi's) which are all connected to the OpenVPN server.

In my alternate home I also have a Linux box set up as OpenVPN gateway, and it is connected to the OpenVPN server.

On (all) my laptops I directly connect to the OpenVPN server.

The result:
I can transparently access any host on my both home networks from any other host.
I can access all the remote computers and laptops from wherever I am and the other way around.
Both home networks are behind the ISP router but I never need to deal with the ISP external IP address.
I have "no idea" how the network or firewall is configured for the remote measurement computers but I still can access them
The databases used by the remote measurement computers can only be accessed from the VPN. Which is easy for security measurement.
All in all, everything talks to each other like it is on the local LAN.

Routing of LANs through gateways is a bit tricky to find out. OpenVPN provides good HowTo's and it works.

There is just one security risk. The remote measurement computers could be stolen or unauthorized being accessed. Once a host is physically accessible its security is compromised and that host IS connected to the VPN and all the LANs. Now I don't store my private keys on those remote hosts, and on most hosts I have disabled password access. But I could have forgotten one. In any case, all hosts have their own key pair so I can easily withdraw a key on the OpenVPN server if I suspect something.

OpenVPN is FOSS, so license issues are none. And AFAIK using the self-generated certificates is secure. I need only to trust myself, hence I do not need a paid certificate.

jlinkels

I already have IP level security to handle my wifi connected laptops etc, and they do use static ip addresses. But I'm not sure what you mean by a "SECURE" wifi subnet.

Anyway, the more I think about it, the more tractable it seems. If I set up my two on-the-go laptops for VPN access, I might as well use the VPN access for when they're connected by WiFi also. Simpler that way, and more elegant. And if I do that, then why not set up all of my client computers that way? Okay, this is probably more trouble than it's worth for my nfs root computers, but I could actually convert all of them to RAMBOOT (loading a tarball from local drive rather).

Its not obvious how to set up VPN the "right" way, though, so I'm sitting on the idea and just thinking about it for now. I don't want to register anything with a third party as far as signing goes. And doing searches for getting started with OpenVPN are polluted with their commercial product. It's not obvious how to separate out that stuff for a newcomer. I dunno...maybe OpenSwan would be better. But I'm concerned that OpenSwan might be harder for me to access on-the-road.

In VPN parlance, "subnets" commonly refer to "remote subnets" ... portions of the internal network of a set of distant computers to which you have a secure connection, thereby allowing you to route traffic to and from them as though they were directly connected using some other kind of browser.

WiFi networks should be regarded as insecure since, basically, anyone can drive by your house and in a few minute's time figure out what your WPA2 password is. (And, in addition, you often go to a coffee-shop where, perhaps unbeknownst to you, everyone else in that shop is "on your local network" for the duration!) However, if your computers use other means to securely identify one another for sharing purposes, and do not allow a stranger to do anything, VPN within that network might be unnecessary. It's up to you.

No argument except with this: That part is not true. A "subnet" is a portion of the address space that may be addressed and routed differently than other parts of the network. It may be local or remote.

As an example, I use a full class C local and network (10.10.255.0/24, a subnet of the entire 10.* class A, itself a subnet of the larger ipv4 network space. From that I subnet 10.10.255.128/25 subnet for WIFI and use the lower 10.10.255.0/25 for direct wired network. There is no traffic allowed between these two local subnets, with one exception: a static route that allows all devices on both networks to reach my network printer.

This is entirely true, but VPN is engineered to act as a secure router (or bridge), implemented in software. You could implement a third subnet on your network, which is located somewhere else and reached through the Internet, and with VPN you would know with whom you were communicating, and you would (if you do it right) also know that no one else on the planet can discover the link (in order to try to log on to it), let alone penetrate it.

I think I'm giving up on OpenVPN after reading many different guides on getting started with it. Too many different ideas on how to secure it, too complex, too many different places to make mistakes and have stumbling blocks. For on-the-road access, I'm more comfortable with the simple and limited ssh on custom port. Even if someone gets the key file, the passphrase still protects it, and it's only for a single non-root user.

For internal use within my LAN, it seems OpenSwan may be easier to set up. Fits on one page:

https://wiki.debian.org/HowTo/openswan

(Obviously, I'll use "systemctl restart ipsec" rather than the init.d script.)

Since I'll be using this strictly for computer-to-computer access within a shared LAN, I'll need to set up dummy interfaces rather than "real" subnets, but this seems simple enough.

Sadly that has been my experience also. I've set up (simple) LAMP servers with HTTPS and use SSH with keys but just can't find a straightforward guide for getting OpenSSH running.

"So, is that why your servers spend X% of their time fighting-off Y,000 'unauthorized access attempts' per hour," until one of their dictionary-bots finally, by pure brute-force tactics, manages to penetrate your system and install a root-kit?" :tisk:

Even though (Open)VPN documentation is not the best, in my blog, right here, I have sincerely attempted to share the :banghead: product of :banghead: my experiences :banghead:, and I am happy to write more installments.

I found that there are basically two obstacles to the adoption of VPN, among users who are accustomed to SSH:

1. The notion that a VPN serves the role of a network appliance, either a "router" or (much less commonly) a "switch." Frankly, many users have never encountered a network which involved the use of a router other than their "internet router," and have never :banghead: dealt with "round-trip TCP/IP routing issues" of any kind.
2. The process of creating and then setting-up a TLS "self-signing CA" and then issuing certificates under it. (And subsequently managing those certificates.)

"Real-world" encryption technologies are all about "Alice and Bob, and Eve." (And they never(!) assume that "Eve" can actually "successfully pretend to be Alice, such that Bob cannot tell the difference," merely(!) by "Saying the Magic Word!™") :eek: Therefore, they do require a certain amount of patience. Until you get "the entire(!) incantation" just right, the door will not open. And, quite by design, it will strive to give you "not one single miserable hint" what you (presumed to be "Eve!") did wrong.

However, if you persevere, just one time, you will be rewarded with ... silence. With security logs that are ... empty.

P.S.: I will be more than happy to write new articles in my blog, here. :)

Like I noted before, I looked at your four blog articles, and none of them describe how to set this up.

I'm actually a bit puzzled that you don't already have some sort of documentation of what to do. I have set up various things on my main server, and I have instructions for myself on how to do it all over again. These instructions aren't entirely readable for others, but I include enough detail for myself to replicate what I've done. I've done so several times, because I like to have a drop-in replacement server and I also like to occasionally do a fresh reinstall (about once every Debian Stable release).

I mean, look at my blog. All 8 of my blog posts are detailed instructions on how to do something. Do you think that's only for the benefit of others? Nope, I'm sure the person who refers to them the most is myself. So, not only do I say why you'd want to do X, I also describe how to actually do X. It helps others, sure, but it also helps myself.

My point is - if I had to build a replacement server and install/set up from scratch, I could and it would be done in one night's work thanks to the instructions I maintain for myself.

So why don't you have your own instructions, even if only for your own use? Are you confident that you could replicate your VPN server quickly after a fresh linux install? If not, why not?

I personally wouldn't be comfortable with anything I couldn't set up over again in a straightforward way. When I set up a new server, I don't expect to bang my head against a wall. I expect to follow my notes and for it to work.

Note that you don't need to make a blog post that's more "user friendly" than an info dump. Sometimes, your notes consist of little more than fragments of configuration files and copy/paste commands to enter. It may not be the easiest thing for others to comprehend, but you can just post an info dump and then maybe modify it later with explanations. A lot of times, just seeing raw config file fragments can be more helpful than a wordy description of what to do in the abstract. (My own blog posts combine wordy descriptions with config files/script fragments.)

As for security logs - as others have already noted, this just isn't a problem with ssh on a custom port. Custom ports for ssh just don't get hit often, and even if they did it doesn't matter with password authentication turned off.

A VPN server is much harder to set up than an SSH server. IMHO, there's no comparison between the two in that regard. You will have to don your learning hat to get the most functionality/security out of VPN if you don't already know how to configure it. Same goes for SSH, but the learning hat is much smaller.

Saying "always use UDP for VPN" is entirely too simplistic. I agree that most of the time, for most users, UDP is the way to go. However there are times when TCP will offer more functionality (breaking through restrictive firewalls), or (paradoxically) better performance (when faced with large scale packet loss or rearrangement of packet order).

Next up, you have to decide it you want a TUN or a TAP VPN setup. TUN is also called "a routed VPN" and TAP is called "a bridged VPN". Bridging is easier to set up and comprehend, but routed gives you more fine-tuned control. e.g., You can easily firewall stuff with a routed VPN - not so easy in a bridged one (you can't use iptables for something that is bridged, you have to go to a lower level). So your choice between TAP/TUN will depend on the level of access you want to grant and the amount of trust you have in your VPN users. You can assign VPN users specific IP addresses based on their cert. So when "Fred" comes in, you know it is him for sure, you give him a specific IP address that does not vary, and thus you can control what he can access via iptables rules (on a routed VPN). "Bob" then comes in, has a totally different IP address assigned to him, and you can give him completely different access to things than you gave to "Fred".

VPN is more powerful and flexible than SSH. But with that power and flexibility comes quite a bit of added complexity. And the more you want to up the security, the more complex it gets as well. login/password is the least secure, but the easiest to set up. Next, in the SSH world, comes pubkey authentication. Much better than login/password. But not as good as certificates. Certificate authentication is the standard in VPN (although you can set authentication in other ways). I consider pubkey the standard for SSH in my installations, but many would argue that login/password is the standard in their installations. You can use certificates in SSH. I am not up-to-date in OpenSSL vs. certs. It used to be that OpenSSL (opensource, free) didn't support them, but maybe they do now. I remember having to use Tectia SSH (commercial, paid) to enable client cert authentication years ago for a specific installation at work.

SSH is much easier to test than VPN. Assuming you are sitting at home and all your devices are on the same LAN, you can't bring up a VPN for testing (well you can, but it won't work reliably, probably not at all). This is because packet routings get very confused deciding to send packets directly over the LAN, or over the LAN via the VPN. SSH does not have this constraint, and you can easily test it with all devices on the same LAN.

Conclusion: There is no one answer to VPN vs. SSH. No one answer to UDP vs. TCP. No one answer to TUN vs. TAP. No one answer to login/password vs. pubkey vs. certificate authentication. Every situation has a different balance of ease vs. complexity and ease vs. security. Put on your learning hat and do some research before making a decision.

FWIW - at home, I run VPN on my router. Two instances. One is TUN/UDP, the other is TAP/TCP. Remotely I can connect either way, depending on the situation. But since I only implicitly trust myself, other users of my VPN (limited family members) are all TUN/UDP only. While they are trustworthy, I'm not so sure about the other environments that connect in, thus their actual devices could be compromised. My family VPN users are very tightly firewalled. By default they can't connect to anything, zero network activity allowed, unless I explicitly grant a specific access to each of them, on an individual basis. My router runs OpenVPN. There is a GUI for administering it. But I do not use that. I use good old manual config files that I set up from scratch. I do not trust the GUI configuration to do what I want to do. You never really know what those little GUI checkboxs actually do down in the bowels of the OpenVPN configuration. Some are obvious, others are not.

Also, I run SSH on my home router. Pubkey only. Very tightly configured. I am the only user allowed in. While SSH/pubkey is weaker than VPN/certificate, the way I have it configured it is strong enough for my personal needs, which is what matters.

Also, iptables on my router. Again, manually configured - not with the GUI checkboxes provided in the user interface.

Although you have seen that I agree with you that a VPN makes life much easier, just wondering. I do need SSH access to my servers for maintenance and setup. Even if they are on a VPN, I must have SSH open. Is an additional requirement to deny SSH from any subnet except the VPN?

jlinkels

Doesn't apply to SSH with keys.

There are three basic problems with this:

1. Everyone in the Known Universe knows that "ssh" is there, and therefore they will do so.
2. It is actually quite difficult to prevent "ssh" from falling-back to a password prompt.
3. Even when an "ssh tunnel" is successfully established, you must take special precautions to ensure that your traffic is actually passing through it.

Without ... obviously :rolleyes: ... "over-simplifying this matter," the VPN approach to security has compelling advantages because "it's just there." :)

• When you use VPN to connect your private network to another private network, you can basically forget that there is "an Internet" in the way.
• When you use VPN to connect to your private network from the outside, you can basically forget that you are "remote."
• When digital certificates and tls-auth are used, "unauthorized access attempts" become impossible.

"ssh" operates at a level above "the TCP/IP stack," while "VPN" operates within it.

Are you saying that "PasswordAuthentication no" in the sshd_config file is not sufficient?

Do what?

If you rephrase as "it's easy to neglect to forbid password login" I would agree, and it is a real drawback (default is not secure).

I think most people use ssh as a shell, so this is not much of an issue. That is, ssh isn't meant to be a replacement for VPN.

Lock it down with more than just "PasswordAuthentication no". The following is not a complete sshd config, it just touches on security related stuff. Also, some of the settings are not used because other settings negate their need. But it doesn't hurt to set them anyway.

I don't think it's difficult to instruct SSHD to not prompt for passwords. Pretty simple really - just say "no" to the things you don't want and "yes" to the things you do want.

I've spent a fair bit of time playing with virtual machines with various ports open to the internet and it's my experience that if SSH isn't on port 22 that cuts down script kiddies to practically zero*. As to brute force -- if they brute force the private key or my Pi then they've probably wasted a lot of computing power for virtually none. Sure, it's possible but unlikely.


*Less security through obscurity than log management.

The tricky bit is figuring out which things you want. Or that you need to say "no" or "yes" to things in the first place.

It's the same likelihood as brute forcing the VPN certificate.

Still the question: if I need to have SSH access to the hosts which are part of the VPN how do I prevent the above mentioned break-in-attempts. IPtables to allow only traffic from the VPN subnet?

jlinkels

Forgive me, but I still do not see a real point here. VPN (as a networking access technique/concept) and SSH (as a terminal session client) are both excellent concepts that apply to different problems. They are versatile, and SSH CAN be applied to some of the same issues as a VPN, but that does not make it the right answer. VPN is a network concept, while SSH is a client/server session concept.

Any problem that is entirely local that a VPN can solve, can be better solved by smart networking (routing, firewalls, etc.) and should not require VPN software. VPN is an elegant solution to remote network access, and not really appropriate to other uses.

OpenVPN, as a specific VPN application, is very powerful and somewhat complex and designed for network and system administrators.
OpenSSH, as a specific SSH application (server and client), is easier because the server side is intended for system administrators and network administration skills are not as critical. The OpenSSH client applications are intended for normal users, and have useful defaults that are simple enough for any normal user. (And more advanced options for those who are more skilled.)

OpenSSH has, in recent versions, some significant VPN features tacked on. These make host-to-host VPN sessions very easy to do in that tool. Host to remote network (routing through a remote host) solutions are possible, but hardly as secure or stable as when using a proper VPN.

Several messages here make it very clear that there is a learning curve involved in advanced use of either one. It is worth climbing that curve IF you have a good case for that learning, and it is worth the effort if you really want to know.

Arguing that one is better than the other is like arguing the advantages of motorcycles over boats. It depends upon the environment (How wet is YOUR highway?) and where/how you need to use them.

I recommend you search for fail2ban on duckduckgo or google. It provides automated blocking (we assume iptables is available) that is adequate to block those dictionary or brute force attacks by detecting and acting on the activity.

This does not mean I approve the use of SSH for secure network communications where a VPN would be more appropriate, but if that is your limit then making it more secure is only reasonable.

Indeed, i-f you are using only digital certificates for SSH, "brute forcing" of those certificates is impossible. But, SSH has the very annoying characteristic that it will continue to "ratchet down" to lesser and lesser authentication alternatives, accepting the least secure ("passwords") alternative that it has been told to allow.

Furthermore, if an intruder can "slip" a new certificate into the authorized-keys file, he can grant access to himself with a fairly-low probability of actually being detected. All he needs to do is to penetrate the system once, and hope that you're not paying attention.

And, in any case, it's all happening on top of the network stack, and processes which wish to use it e.g. for "tunneling" must do so explicitly. Whereas, VPN operates as a router or a switch, and it normally communicates using UDP. Therefore, I-f you are using one-of-a-kind certificates, not "PSKs" == "passwords"(!), for authentication, you are rewarded with an unobtrusive secure link to a remote system, which both parties can identify with certainty, and which is simply "the route" to that subnet. Any and all traffic bound to/from those IPs will pass through the tunnel, automagically.

It literally is a "Virtual Private Network." :)

If the connection is secured with both digital certificates and tls-auth, not only penetration but even detection of the link becomes ... impossible. And yet, authorized users can open a new connection in less than ten seconds and thereafter "simply communicate," as though the resources were directly attached using boxes and wires instead of passing through an insecure public network.

As already noted, it is very easy to set up /etc/ssh/sshd_config to lock everyone out except for one user which is only allowed to log in via key (encrypted with pass phrase).

In contrast, it seems that setting up a VPN with the exact right security is NOT so easy. And you're not making it any easier.

Eh, you mean the intruder "just" needs root access once. With root access, there are a zillion different ways to insert a back door without messing with any configuration file. For example, unless you block outgoing web requests (the typical method by which a linux distribution will download security updates), it'll be possible for a compromised executable to reach out with a reverse ssh.

Which, honestly, I am more comfortable with when it comes to on-the-road access. You're assuming the client computer is never compromised, but what are the chances? Physical security on a laptop is typically going to be less robust. If I accidentally leave my laptop unlocked for a minute while distracted or something? It takes only a few seconds to plug in a USB device and run a script kiddie script. It's not root level access, but regular user level access is plenty to start banging around a VPN connected network for any internal vulnerabilities.

I like the fact that when I'm on the road, the only connection back home is a narrow straw - just ssh for text console login and sshfs for file transfers, with only the access level of a single specified regular user to a single machine. The way ssh works, it's not so easy to piggyback on an ssh connection to try and root around for vulnerabilities in the connected computer (much less the LAN connected to it). A script kiddie script could still potentially do a lot of damage, but it's not so easy to cover its tracks when it only has regular user level access.