That is the knock against OpenVPN, it can be quite complicated to set up. Because it retains tons of backward compatibility for very old things. But it supports almost any option you could think of. Just have a glance at it’s man page to get a sense of what Rich and I are talking about.
This is one of the main reasons many people (including myself) are now using WireGuard:
It’s much simpler to set up
Good crypto model: uses latest ciphers, etc. (see also Protocol page at WireGuard)
Even Linus had favorable things to say about it (and you know how often that happens) XD
I know I mentioned it further up thread, but I feel it’s a good enough solution that it bears repeating. Just have a look around their website, and do a little research and you will find lots of people talking about it nowadays.
Unfortunately, until Wireguard undergoes a thorough third party audit I’m not sure I can recommended it. It looks very promising but it’s not been proven to be secure yet. It’s miles ahead of where it was when this thread first started but I’d still rate it as beta software at best. And in some places (e.g. FreeBSD) it’s not even to that level.
Good points. And I am aware of some of the criticisms, which mostly seem to revolve around the fact that Wireguard is the new kid on the block. It has not had nearly as long a history as OpenVPN, for instance.
Third party audits certainly are one of the fundamental things you look for in terms of security. I am sure they will get one eventually (actually I am a bit surprised they haven’t already). But in the meantime, it cannot be worse than nothing (which is what the OP was apparently doing). So keep that in mind.
For me, reducing the attack surface by an order of magnitude (also good fundamental security practice by the way) was enough to convince me. Well, that and the information presented at Wireguard’s website (which is quite a lot and good info, white papers, etc.). Jettisoning a lot of legacy cruft and being able to start with a clean sheet design allows you a lot of flexibility in implementing a solution, and results in a much smaller and more maintainable code base, now and going forward.
At the end of the day, it is up to each of us to read and make our own informed decisions. But there is a lot to know about crypto, so @rlkoshak advice is sound if you are not sure. Use whichever one you personally feel comfortable with.
I’m also using Wireguard since ~ August, it was quite simple to configure, even my wife’s iPad now has remote access to our LAN (and she likes it… )
Before I changed my router OS to opnsense I used IPSec (certificate based) with great success, but it was a nightmare to configure in first place (I used ipfire 2), and I wasn’t able to succeed with opnsense and eventually gave up.
Now with Wireguard, it was only a few clicks here and there some additional downloads as there is no native client yet (for no OS at all…) but that’s it.
Start the client, click to activate, done.
Instant access (which is: ‘WHAT? ALREADY ONLINE??? Can’t be secure if connection is established that fast…!’ )
You could also get a NAS and set up openVPN with that. That will get you back to your home LAN as if you were there. I am using a Synology NAS, and openVPN on that is a super easy job.
One thing- i see many openHAB systems with open port 8080 in the world, with no password or something else. Please close them or use vpns etc. I know its easier but thats an open door for everyone. Its your home and not for the whole world!
Security by obscurity… there is absolutely no reason to change the ports to non standard ports, if the implementation is correct, no matter if using openVPN, IPSec, Wireguard, ssh, … there are simple tools to scan all ports.
A valid way to add additional security is to use port knocking or another control channel (so there is no open Port at all until sending a valid “open the port” message)
Hello Udo,
you are right. But the normal user, use the standard ports with “normal” configuration. If you scan all ports, than you know your target, directly one ip. You know what are you looking for. The scan of iot things or something else, are knocking for the standard ports, its faster. The whole scan of every port of every ip, thats not easy. If someone search a victim, he search es standard ports, after that, it will be “dirty”. And you say, “simple tools”, of all ips? If you had a super Computer, or a lot of time, yes. .
Its only a tip, and its our opinion because the most incidents are over the standard ports🤔.
And when you use knockd for example, than you can use also ipfire, both of them.
It doesn’t really adds much security, but it does reduce some inconvenience. If you are running ssh on port 22, you can expect a failed login attempt a couple times a minute. If you are in a non-standard port you will be invisible to most of the automated attack bots. So you don’t have to have your system processing all these weak ass attacks that will never succeed but still consume your resources if you use a non-standard port.
For this reason it is considered a best practice where available.
Port knocking is challenging to set up and is vulnerable to some TOCTU to attacks. It’s probably more secure if properly set up than not having it, but I’m not sure it’s worth it for the average home user.
It’s been awhile since I’ve checked, but I think Shodan can identify services even when not running on stressed ports. Many attackers don’t even need to do a scan any more. They just search.
If you are using a service that isn’t so easily identifiable through a standard scan or your port is only open some of the time, it can reduce the likelihood of ending up in one of the Shodan like databases. But it only reduces the likelihood, not eliminates it.
Unless someone is targeting you as an individual, no one does port scans any more. There is no need to. They do a search on a service like Shodan for "all the ips with port 22 open. Then they set up their bot to attack all those ips.
They don’t approach an attack by saying “let’s see what vulnerabilities Kim’s computer has.” They say “I know that lots of people put their router with ssh enabled on the internet with a default password, let’s try the default password we know on all of them and maybe we’ll get lucky.” In other words, they have an exploit against a vulnerability so they go looking for machines that are likely to have that vulnerability which they can do using a simple search. If you use a non-default port.
They aren’t going to bother trying against those who run on a different port because they wouldn’t have done something stupid like not changing the default password.
Like I said, using a non-default port doesn’t make you more secure, but the lazy attackers with the automated bots won’t bother trying against the not-default ports so you don’t need to spend your CPU and network cycles processing failed login attempts.
I’m not so sure. I suppose if you select the Revers Proxy option to install in oepnhabian-config that it might be a good idea to set up Fail2Ban. But Fail2Ban is only useful if you are directly exposing your openHABian to the Internet or some other “dangerous” network, which I believe, or at least hope, is not something that OH recommends or officially supports.
IPTABLES already is installed but it is probably left open. This one has a bit more of a trade off involved. On the one hand you reduce the attack surface the RPi is exposed to by closing any unused open ports. On the other hand, I don’t think there are any open ports on a standard openHABian install that would not be exposed anyway. If your host based firewall is exposing all the ports you have open anyway, it’s not really doing anything. And to what end would the other ports be blocked? Since the only supported deployment is on a protected network, the risk of attack is very low.
And it doesn’t come at no cost. Users routinely install software on their openHABian servers all the time and if the ports are locked down, this software won’t work and they will be coming back here for help.
If you are willing to take it upon yourself to expose your openHABian to a dangerous network, they even if openHABian did these things, you would still be required to do additional lock down and continuous monitoring of the machine.
But I suspect if someone were to submit a PR that implements these things it would be accepted.
I’m indeed running openHAB behind a nginx reverse proxy and only allow external access to 3 ports (ssh, http, https). The ports are blocked at the dynamic DNS provider side as well as at my ISP.
Well, with that option, you’re also offered to setup a trusted SSL certificate for HTTPS if you have a have a domain name (it will also ask if you want to password protect this instance). This would normally imply that you intend to remotely connect to openHAB via the internet right? Fail2Ban sounds like a good idea in that case.
Indeed, that’s how I did this. I configured a hardened TLS access, deactivating all weak ciphers and generating a hard key for the domain name. The certificate is managed with LetsEncrypt. Next barrier is HTTP authentication.
)
some additional downloads as there is no native client yet (for no OS at all…) but that’s it.
there is absolutely no reason to change the ports to non standard ports, if the implementation is correct, no matter if using openVPN, IPSec, Wireguard, ssh, … there are simple tools to scan all ports.