VPN (gigantisches) Sicherheitsproblem: Jeder kann mein OpenELEC/LibreELEC anpingen und zugreifen (SSH)

Goil vielen Dank!
Ich habe nur einen Port geöffnet und weitergeleitet.
Laut http://www.dnstools.ch/port-scanner.html
Sind alle Ports dicht.

Da scheint man bei purevpn aber viel für sein Geld zu bekommen.

Wenn die jedem VPN-Kunden tatsächlich ne eigene ipv4 IP zuweisen und alle Ports direkt zum Kunden weitergeleitet werden.

Sicherheitstechnisch ist das für unerfahrene Kunden natürlich eine Katastrophe!!!
Wobei sich der mögliche Schaden auf nem Kodi Media-center wohl noch im Rahmen hält.

Arm sind allerdings die dran welche diesen VPN dann sogar im Router eingerichtet haben, das öffnet ja Tür und Tor für die ganz fiesen Jungs. Da ist es ja easy möglich den ganzen Router zu kapern.

Dieser VPN scheint sehr nützlich zu sein, wenn man viele Server-Dienste trotz einer dyn IP im Internet anbieten möchte.

Ein Router ist normalerweise eh schon direkt mit dem Internet verbunden und entsprechend abgesichert. Die Anzahl der Router auf denen ein SSH-Server läuft und der Admin-Account mit (unveränderlichen) Standardzugangsdaten zugänglich ist, hält sich hoffentlich in Grenzen.
Ich sehe nicht, wieso der VPN da plötzlich "Tür und Tor für die ganz fiesen Jungs" öffnen sollte.

Das sind die Leute die denken sie verstehen was von den ganzen "Sicherheitskram". Die installieren dann auch gleich 3 Virenscanner parallel. Ist ja viel sicherer!
VPN und einfache Routingregeln im Router ist mit der richtigen Verschlüsselung vollkommen ausreichend.

ansonsten DMZ aktivieren und gut ist

VPN:
Hat 4. Funktionen
1. Sicherheit. (Ich Nutze einen Seriösen VPN Anbieter, in Hotells. Da in Hotels nie weiß wer mithört
2. Länder Schutz Mechanismen aushebeln
3. Anonymisieren
4. Länder Schutz Mechanismen umgehen (z.b. den Content Filter in England)

Zu 3) Vieleicht noch was. Da dies bei dem Provider nicht gegeben ist

Anonymisierung funtkioniert so 100 Leute Wählen sich bei dem VPN anbieter ein. der VPn anbieter Routet alle über die Selbe IP nach außen. Logt aber selber nicht.

Ein Beobbachter nennen wir ihn mal NSA sieht dan nur was 100 Leute für zugriffe gemacht haben können aber nicht mehr genau sagen wer welchen zugriff gemacht haben. damit ist eine Anomisierung gegeben. Je mehr ein Dienst genutzt wird desto Anonymer ist man. Setzt er Vorraus das er nicht logt. Das ist auch ein versprechen auf das man sich verlassen muss.
HAt also viel mit Vertrauen zu tun

Ich habe einen Provider dem ich vetraue. Aber der Kostet auch Geld

Zitat von eminga

Ein Router ist normalerweise eh schon direkt mit dem Internet verbunden und entsprechend abgesichert. Die Anzahl der Router auf denen ein SSH-Server läuft und der Admin-Account mit (unveränderlichen) Standardzugangsdaten zugänglich ist, hält sich hoffentlich in Grenzen.
Ich sehe nicht, wieso der VPN da plötzlich "Tür und Tor für die ganz fiesen Jungs" öffnen sollte.

Wenn du das denkst ist dir noch nicht ganz klar was der vpn auf dem router bewirkt

Zitat von PVR-Fucker

Wenn du das denkst ist dir noch nicht ganz klar was der vpn auf dem router bewirkt

kommt stark auf den router an. Für meinen ist "VPN" z.b. schlicht ein zusätzliches WAN-Interface, für das halt noch FW-Rules and (policy)routing erstellt werden wollen, bevor es überhaupt genutzt wird.

Zitat von PVR-Fucker

Wenn du das denkst ist dir noch nicht ganz klar was der vpn auf dem router bewirkt

Na dann warte ich gespannt auf deine Ausführungen wie ein fieser Junge ganz einfach meinen Router kapern kann, wenn er die IP-Adresse kennt, die mir mein VPN-Anbieter zugewiesen hat.

Und wie @MaxRink schon sagt, behandeln "Consumer"-Router (Fritz!Box und Konsorten) solche VPN-Verbindungen in der Regel einfach wie ein WAN-Interface. Dass man sich beispielsweise mit einem Cisco-Router oder einem Router auf dem OpenWRT läuft selbst drum kümmern muss, das sicher zu konfigurieren (v.a. zum Schutz vor dem VPN-Anbieter, egal ob man nun eine private oder öffentliche IPv4-Adresse bekommt), ist hoffentlich jedem klar, der damit arbeitet.

Wenn die Fritzboxen tun Interfaces inzwischen als WAN Interface behandeln und nicht mehr als vertrauenwürdiges netzwerk a la LAN, ist das schonmal sehr gut.

Dann ist das vpn in der Tat auch in diesem speziellen Fall wie bei purevpn schonmal solide abgesichert.

Aber sehr sehr viele andere Router im billig Segment unter 200€ und auch alte Fritzboxen die keine Firmware Updates mehr erhalten handhaben das häufig ganz anders.

Und bei den WRT Routern muss man wie du ja schon sagtest die Rules selbst erstellen.
Diese sind nicht immer ganz trivial und bei umfangreichen Configs schleichen sich dort schnell Fehler ein, welche Angriffsfläche bieten können.

Aber mit Sicherheit ist die Mehrheit der Router (keine aktuelle Fritzbox oder ein WRT Router) und diese sind auf diesem Weg leider sehr anfällig, da die vpns dort noch als vertrauenswürdige Netzwerke gelten.

*verteilt ganz viele Aluhüte*
if you don't know how to use vpn don't use VPN.

Zitat von infinity

Gut, schließe mich deiner Aussage an, und halte nun meine Klappe
Also, ich habe nun folgende iptables Regeln erstellt mit Hilfe der von CvH genannten Seite:

(192.168.0.0/16 heißt, dass alle IP's von 192.168.x.x gehen. Wenn man einschränken möchte, dann vielleicht auch 192.168.178.0/24 oder 192.168.1.0/24" machen. Dann wären Alle IP's mit 192.168.178.0x erlaubt)

Bash: autostart.sh

#!/bin/sh


# Flush old rules, old custom tables
iptables --flush
iptables --delete-chain


# Set default policies for all three default chains
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT


# Enable free use of loopback interfaces
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT ! -i lo -d 127.0.0.0/8 -j DROP


# All TCP sessions should begin with SYN
iptables -A INPUT -p tcp ! --syn -m state --state NEW -s 192.168.0.0/16 -j DROP


# Accept inbound TCP packets
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -s 192.168.0.0/16 -j ACCEPT


# Allow inbound access to Samba shares
iptables -A INPUT -p udp -m udp --dport 137 -s 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 138 -s 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 139 -s 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 445 -s 192.168.0.0/16 -j ACCEPT


# Allow Kodi Webserver access through port 8080 from local network
iptables -A INPUT -p tcp --dport 8080 -s 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -p tcp --dport 8080 -s 127.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 8080 -j DROP


# Yatse EventServer (Cursor Steuerung usw): https://yatse.tv/redmine/projects/yatse/knowledgebase/articles/26
#UDP 9777
iptables -A INPUT -s 192.168.0.0/16 -m state --state NEW -p udp --dport 9777 -j ACCEPT


# Reject all other inbound - default deny unless explicitly allowed policy:
# This rule disrupts Yatse controls and Samba
iptables -A INPUT -j DROP

Alles anzeigen

Erfahrung damit:

• Im LAN: SMB share funzt
• Im LAN: Yatse funzt samt Webserver (Port 8080)
• Im LAN: SSH geht (Port 22)
• Von außen: SSH geht nicht
• Von außen: Webserver IP:8080 geht nicht
• Ping geht in Zeitüberschreitung auf
• Youtube funzt (von Yatse gesendet)
• IPTV funzt über VPN
• Portscanner http://www.dnstools.ch/port-scanner.html sagt, dass die gescannten Ports alle geschlossen sind
• NFS shares? Keine Ahnung, hab keine
• LCDproc geht. Also mein I2C LCD zeigt alles an, obwohl LCDproc auch über die Netzwerksnittstelle mit XBMC/KODI kommuniziert (glaube die # Enable free use of loopback interfacesiptables -A INPUT -i lo -j ACCEPT Regel erlaubt dies

Falls man sich versehentlich aus SSH ausgesperrt haben sollte, dann einfach in der GUI mit der Fernbedienung auf den Dateimanager gehen in .config Ordner und die autostart.sh beliebig umbenennen (Kontextmenü) und neustarten. Dann werden die Regeln beim nächsten Start nicht geladen und SSH geht wieder.

EDIT:
Hat jemand eine Idee wie man bei OE/LE die iptables loggen lassen kann? Also dass ich irgendwo nachsehen kann welche Zugriffe geblockt wurden? Ich glaube Syslog ist dafür eigentlich zuständig, aber das gibt es ja glaub ich in OpenELEC/LibreELEC nicht?

Falls dein LAN als sicher anzusehen ist, sollten vermutlich deutlich weniger rules reichen in OE/LE.

iptables -F
iptables -A INPUT -i tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i tun0 -j DROP

Wie man iptables Zugriffe im OE/LE [definition='1','0']log[/definition] anzeigt würd ich auch gern wissen.

Mir ging es nur um den Fall, dass der VPN-Client des Routers selbst benutzt wird. Wenn ich richtig informiert bin, unterstützt die Fritz!Box allerdings nur reines IPSec.

Wenn der VPN-Client auf einem Gerät in deinem LAN läuft, beispielsweise wie im Eingangspost auf einem Raspi, kann ein Router prinzipiell nichts weiter machen als die Pakete weiterzuleiten.
Kurze (vereinfachte) Erläuterung warum: Nehmen wir den SSH-Client auf deinem Raspi als Beispiel. Der kann unter Nutzung von TCP auf Port 22 erreicht werden. Das heißt, wer eine SSH-Verbindung aufbaut, schickt TCP-Pakete mit Zielport 22 und erhält TCP-Pakete mit Quellport 22. TCP-Pakete alleine bringen noch nicht viel, damit es auch beim gewünschten Host ankommt, braucht es noch IP-Pakete. In denen stehen die IP-Adressen von Sender und Empfänger (und noch ein paar andere Sachen) und das TCP-Paket wird als "Payload" hinten dran gehängt.
Das ganze funktioniert dann innerhalb des Heimnetzes ganz wunderbar, ist von außerhalb aber nicht erreichbar, da der Raspi eine private IP-Adresse hat. Wollte man das ganze von außerhalb erreichbar machen, müsste man im Router "Port Forwarding" konfigurieren. Dann könnte man von außen den Router kontaktieren, der schaut dann in das TCP-Paket hinein und sieht Zielport 22, ändert die Ziel-IP-Adresse auf die private IP-Adresse des Raspis und leitet das Paket weiter.
Läuft auf dem Raspi ein VPN-Client gibt es einen bedeutenden Unterschied: Die Pakete, die zwischen VPN-Client und VPN-Server ausgetauscht werden sind verschlüsselt. Verschickt der Raspi ein Paket über das Interface, das der VPN-Client angelegt hat, landen die Pakete erst mal beim VPN-Client. Der nimmt dann das ganze IP-Paket, verschlüsselt es und packt es in ein neues IP-Paket mit Ziel-Adresse VPN-Server. Dieses neue IP-Paket wird dann über das physische Interface gesendet. Sobald es beim VPN-Server angekommen ist, entschlüsselt er das eigentliche IP-Paket und versendet es an die Ziel-IP-Adresse. Analog in der Gegenrichtung.
Dein Heimrouter bekommt bei der ganzen Geschichte nur die IP-Pakete mit verschlüsselter Payload zu sehen. Er erkennt am Protokoll-Feld des IP-Headers, dass es sich beispielsweise um IPSec-Pakete handelt, die zu einer VPN-Verbindung gehören, und leitet eingehende Pakete an deinen Raspi weiter. Dort kommt das Paket am physischen Interface an, der VPN-Client entschlüsselt das eigentliche IP-Paket und gibt es über das neue virtuelle Interface aus. Erst hier ist also der Inhalt des IP-Pakets erkennbar und wenn es sich um ein TCP-Paket mit Zielport 22 handelt und iptables es nicht filtert, landet es eben beim SSH-Server.

Der Heimrouter hat also keine Chance unerwünschte Pakete zu filtern! Er kennt schlicht den Inhalt nicht.

Auch wenn man vom VPN-Anbieter eine private IP-Adresse zugeteilt bekommt, ist man übrigens nicht viel sicherer unterwegs. Klar, es kann einem nicht jeder Internetnutzer Pakete schicken. Andere Kunden desselben VPN-Anbieters womöglich aber schon und auf jeden Fall der VPN-Anbieter selbst. Und um wieder auf das Beispiel aus dem Eingangspost zurückzukommen: Niemand kann wollen, dass der VPN-Anbieter die Möglichkeit hat, root-Zugriff auf sein Gerät zu erhalten. Und genau das ist der Fall, wenn man einen VPN-Client auf einem Raspberry Pi mit OpenELEC/LibreELEC und aktiviertem SSH-Server (mit Default-Logindaten) ohne angepasste iptables-Regeln am laufen hat.

Deshalb gilt: Ein Gerät auf dem ein VPN-Client läuft, ist IMMER so zu behandeln als wäre es direkt mit dem Internet verbunden und entsprechend abzusichern.

Noch kurz zu den iptables-Regeln (ohne einer ausführlicheren Antwort von @Tuxino zu sehr vorgreifen zu wollen): Diese Regeln bewirken, dass am VPN-Interface ankommende Pakete grundsätzlich verworfen werden. Ausgenommen davon sind nur Pakete, die zu einer bestehenden Verbindung gehören.
Beispiel: Will jemand eine Verbindung zu deinem SSH-Server aufbauen, wird das Paket verworfen.
Baust du selbst eine Verbindung auf, beispielsweise indem du eine Internetseite aufrufst, wird das Antwortpaket nicht verworfen, da es zu einer bestehenden Verbindung gehört.
Wohlgemerkt gilt das ganze nur für das VPN-Interface, Pakete die an einem anderen (physischen) Interface ankommen, sind davon nicht betroffen, es ist also weiterhin möglich den SSH-Server über das Heimnetz zu erreichen.

Zitat von eminga

Noch kurz zu den iptables-Regeln (ohne einer ausführlicheren Antwort von @Tuxino zu sehr vorgreifen zu wollen): Diese Regeln bewirken, dass am VPN-Interface ankommende Pakete grundsätzlich verworfen werden. Ausgenommen davon sind nur Pakete, die zu einer bestehenden Verbindung gehören.
Beispiel: Will jemand eine Verbindung zu deinem SSH-Server aufbauen, wird das Paket verworfen.
Baust du selbst eine Verbindung auf, beispielsweise indem du eine Internetseite aufrufst, wird das Antwortpaket nicht verworfen, da es zu einer bestehenden Verbindung gehört.
Wohlgemerkt gilt das ganze nur für das VPN-Interface, Pakete die an einem anderen (physischen) Interface ankommen, sind davon nicht betroffen, es ist also weiterhin möglich den SSH-Server über das Heimnetz zu erreichen.

Trifft ziemlich genau zu.
Alles was dein tun0 Interface erreicht wird verworfen, lediglich wenn du selbst über das tun0 Interface die Verbindung von deinem OE/LE System startest/aufbaust dürfen für diesen Zweck auch wieder zurückkommende Pakete dieser Instanz durchgelassen werden.

An den Interfaces lo,eth0,wlan0 würde alles weiterhin ungefiltert passieren, das reduziert im Idealfall die CPU-Last, da die Firewall hier nicht reagiert.