Hi there,
first of all I want to provide the solution to this Issue in form of a feature request:
Please add those VPN tun0 rules as default into your iptables (for the non-considered regular user like me and others):
iptables -F
iptables -A INPUT -i tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i tun0 -j DROP
These rules will filter only the tun0 interface in case an OpenVPN connection is established to a VPN provider (remote Server, which is not in your control) for overcoming geo-blocking or for IP anonymization etc. So only requested data will get to you (IPTV and scraping media coverarts will all work with that). All local connections (lcdproc, yatse, webserver, samba) will remain untouched by this.
[hr]
Now here's the long shot of the story as explanation why this is a concern of massive consequences:
As nowadays many LibreELEC users consume not only local content, but also streaming content, they might use one of a lot of VPN Providers on the market to overcome geo-blocking or simply to mask their own IP Address to be anonymous during media scraping like Coverarts etc.
Because of the demand to use VPN connections on LibreELEC, LibreELEC team reincluded OpenVPN and the user zomboided developed a mighty and very awesome addon VPN Manager for OpenVPN as well as lrusak provided his own one before. So the demand got heard
The Problem with LibreELEC is that it was not meant to be used outside of the own LAN, thus no iptables rules are set as default and there is also no GUI for that or any addon that could provide you this. But fortunately iptables is integrated, so anybody can add his own rules, if he knows that they are mandatory on his setup. So this issue potentially exposes your entire local area network to the internet.
BUT here's the massive security issue with some VPN Providers in combination with LibreELECs default setup:
I can speak for my VPN Provider "PureVPN": PureVPN and probably many other VPN services assign an external IP to my/your LibreELEC device whenever you connect to one of their servers. The shocking point here is:
Knowing this IP, everybody is able to access your LibreELEC system and bypassing the routers firewall as well as all its closed ports. This is an unbelievably massive security issue, because all ports are open (including SSH 22)!
Obviously this is exactly how a VPN connection is working and why it was invented originally: People wanted an encrypted connection from workplaces or from vacation to their Network at home. So far so good, but the use case of overcoming geo-blocking or using VPNs to anonymize your own IP is differnt here: You are paying for a tunnel, of which you have only control on your own side (LAN), but not of the other side (VPN Providers remote Servers). That means that a mean employee at your VPN Provider sees the IP assigned to you upon establishing the connection and gets access to your LibreELEC machine, and in an extreme situation to your whole LAN, although you have set up a quite secure Router-Firewall and NAT (everything gets bypassed).
I was naive and didn't ever consider that a big VPN-Provider like PureVPN (and some others are doing the same) assign not shared IPs upon established VPN connection, but real 1:1 for every single VPN tunnel. I thought that it would be like NAT: Every unrequested connection coming from outside will be simply rejected. But that's not the case. PureVPN and some other providers simply route every single connection from outside to your client. So whenever you are surfing or streaming or so through their tunnel, every content provider or website logs your PureVPN IP, which points directly to your machine bypassing your router. They can simply type in this IP into a browser and access your Webserver at Port 8080, or access through SSH.
Comparison: If using a private VPN connection for connecting the home network to the working place network (vice versa), then you know the other side and have probably control of the server at the other end, also there might be a software firewall which does its part to security (Windows firewall doesn't help you, if established an OpenVPN tunnel). But here you don't know what is on the other side and you certainly don't want to be accessed without asking while you simply use netflix USA from Europe or so.
And this is the frightening result of it:
- Establish a OpenVPN connection with PureVPN
- determine your external VPN IP: curl ifconfig.co --> Lets say you get this IP: 136.0.5.198
- Everybody can SSH into your system now, just knowing your IP: 136.0.5.198:22 with root/libreelec (provided you have SSH activated with password)
- Everybody can access your webserver at 136.0.5.198:8080, if you don't have set a password for it (default: not set). Even with password, it won't be hard for an attacker to breach it, I think.
- You can be pinged with ping 136.0.5.198
- This way everybody could also access your Samba shares and simply everything that is connected to your local network. Even if the routers firewall secures everything, the VPN tunnels from some of those VPN services, are really dangerous for not so well informed people like me and many others. Anybody on the other side simply needs to guess or to read the IP and then they can get directly into your network no matter what router security configuration you have.
- As this is a VPN tunnel IP, it passes through my WAN router and bypasses also all the closed ports of it
The worst thing in case of LibreELEC is that the SSH user/pass are hardcoded: root/libereelec, so anybody who has SSH activated and did not deactivate the password, is accessable due to this shit of some VPN providers from all over the world with root/libreelec.
The thing is that I was concerned about security before using VPNs for this purpose. And whenever you search for "VPN+security", it tells you that it is kind of safe. Even if I search now for keywords with the current knowledge, it is nowhere mentioned, that those services don't close all ports in your direction by default. So a normal user like I am, would simply assume that only connections established by me will cause inbound traffic. Just like it is if you are using a Windows computer with a browser: The Firewall or routers NAT will block everything that I did not request by typing it in into the URL bar.
And anyways... I can't even think of any use case where somebody would like to have opened ports in his direction from remote servers, where he is not sitting (if the other side is not his own LAN).
So.. What I want to say is: VPN Providers like PureVPN, IPVanish, PIA are nowadays (especially on MediaCenters like LibreELEC) not to be seen as a regular VPN tunnel, which is commonly known for secure connections between workplaces and your homenetwork. After discovering this issue, I had the explanation why I had suddenly about 15000 infected files (by an ancient trojan) on my external harddrive some months ago, which is always connected to my Odroid C2, and no other system at home had this infection.
Using another VPN Provider named PIA is also kind of strange: Mostly you land on a foreign computer (noticed because ssh user/pass didn't work). So it is also similar to PureVPN, except the IP is kind of random to many computers (real NAT would reject those access attempts).
Quick workaround for those who encounter the same or who can successful access their webserver via External-VPN-IP:8080 :
- create an autostart.sh in: storage/.config/autostart.sh
- with this content:
- make it executable: chmod +x storage/.config/autostart.sh
- Reboot the system and check whether the new rules are set in SSH: iptables -L
- Then try again to ping your computer or accress ssh via port 22. It should time out.
Sorry for the long post :/. But I already brang this topic up in the german kodinerds forum and many users tried to explain me that this is what VPN is for... but they didn't want to understand that this geo-unblocking usecase is a different matter in terms of VPN usage. And then some other users tested it and found out that they have the same issue with their VPN Providers and didn't notice that their network was exposed the whole time because of this.