Ich habe mein Setup mal beschrieben... vielleicht hilft Dir das als Anregung weiter. Es ist aber nicht als Copy/Paste-Tutorial gedacht, sondern befasst sich auch intensiv mit Hintergrund-Wissen... was man meiner Meinung nach als Admin seines privaten Netzwerkes mit offenen Zugängen vom Internet wissen sollte.freckles hat geschrieben:16.06.2020 12:05:25eine gute Idee mit dem OpenVPN. Werde ich mir einmal ansehen.
OpenVPN ist nicht (un)sicherer als SSH. Beides verwendet gleich starke Verschlüsselung.TomL hat geschrieben:16.06.2020 11:31:52Wenn Du allerdings maximale Zugangs-Sicherheit haben möchtest, verwende OpenVPN.
Dafür brauchst du aber den offenen, allseits beaknnten OpenVPN-Port.Dann braucht es keinen offenen SSH-Port
Da bin ich anderer Meinung... allerdings darf man dabei auch nicht die Relevanz für typische Laienuser übersehen ... möglicherweise spielt das letztlich vor der restlichen Datenschutz-Situation eines Anwenders auch keine Rolle mehr. Die Frage ist, ob Du als SSH-Anwender beim Aushandeln eines Schlüssels erkennen kannst, ob ETSI/ETLS irgendwie auf der Strecke zugrunde gelegt wurde.... insbesondere, wenn man sich an prinzipiell unsicheren Netzen anmelden möchte. Bei OpenVPN ist das ausgeschlossen.MSfree hat geschrieben:16.06.2020 12:21:10OpenVPN ist nicht (un)sicherer als SSH. Beides verwendet gleich starke Verschlüsselung.
Nein, brauchst Du nicht, ich rate ebenso wie von Port 22 auch von Port 1194 ab.Dafür brauchst du aber den offenen, allseits beaknnten OpenVPN-Port.
Das ist aber das, was imho die höhere Sicherheit herstellt. Aber egal, ist nicht so wirklich wichtig... es ist wohl auch das an Sicherheit ausreichend, was man persönlich als ausreichend erachtet.ganzen Heckmeck mit der Erstellung von SSL-Zertifikaten, die für OpenVPN nötig sind, nicht anzutun.
Das entspricht meiner Konfig., mit der ich sehr zufrieden binTomL hat geschrieben:16.06.2020 11:31:52Ändere den Port von 22 auf irgendwas zwischen 50000 und 64000, damit reduzierst Du das auf Port 22 bestehende Grundrauschen aus dem Internet (aka Scriptkiddies) quasi auf Null. Verbiete den Password-Zugang, verbiete die Anmeldung als Root und ermögliche den Zugang nur einem normalen User über PubKey-Authentifizierung. Danach kannst Du fail2ban vergessen, es wird nichts mehr zu tun haben und wird damit überflüssig.
Ich wollte eigentlich darauf hinaus, daß es ohne Port nicht geht. Wie die Portnummer lautet, bekommt jedes Sktiptkieddie mit einem Portscan raus. Den SSH-Port oder den OpenVPN-Port zu verlegen, ist Security by Obscurity. Klar, man bekommt das übliche Rauschen weg, ein Sicherheitsgewinn ist es aber nicht.TomL hat geschrieben:16.06.2020 12:32:14Nein, brauchst Du nicht, ich rate ebenso wie von Port 22 auch von Port 1194 ab.
Die höhere Sicherheit wird überhaupt erst mit Schlüsseln hergestellt. Nur lassen sich SSH-Schlüssel ohne großes Kopfweh mit ssh-keygen herstellen. Schlüssel für OpenVPN muß man mit OpenSSL herstellen, und das ist eben einigermassen kompliziert. Und weil ich mir diese Vorgänge nicht merken kann/will, weil ich das viel zu selten machen muß, habe ich dazu ein Skript geschrieben, das mir die Arbeit durch den Einsatz von...Das ist aber das, was imho die höhere Sicherheit herstellt.
dialog extrem vereinfacht.Nein, das ist es zumindest bei OpenVPN nicht. UDP ist zustandslos, irgendeinen beliebigen UDP-Port ohne das dahinterstehende Protokoll identifizieren zu können sagt ja erst mal gar nichts verwertbares für den Angreifer aus. Und wenn schon die Verbindung vor dem Aushandeln eines Sessionschlüssels und vor der etablierten Verbindung zur Schlüsselverhandlung aufgrund eines 'Verstoßes' bei der zusätzlichen TLS-Verschlüsselung auf dem Control-Channel abbricht, ist das definitiv ein anderer Sicherheitslevel.MSfree hat geschrieben:16.06.2020 13:37:19Wie die Portnummer lautet, bekommt jedes Sktiptkieddie mit einem Portscan raus. Den SSH-Port oder den OpenVPN-Port zu verlegen, ist Security by Obscurity.
Wie ich oberhalb begründet habe, ich bin da anderer Meinung.Klar, man bekommt das übliche Rauschen weg, ein Sicherheitsgewinn ist es aber nicht.
Ich sehe das Risiko nicht bei der Qualität der erfolgreich verschlüsselten Verbindung und des ephemeren Sitzungsschlüssels, da wird SSH vermutlich nicht schlechter sein, als OpenVPN. Ich sehe das Risiko (bei mir) in der fehlenden Kontrolle bei SSH, mit wem ich den Schlüssel aushandele. Das eigentliche Problem dabei ist, um Sokrates zu zitieren "ich weiß, dass ich nichts weiß.". Und weil ich deshalb bei SSH das Gefühl von Kontrollverlust bei der Schlüsselverhandlung habe, verzichte ich auf SSH über das Internet. Ich nutze natürlich SSH, aber erst nach der OpenVPN-Verbindung.Die höhere Sicherheit wird überhaupt erst mit Schlüsseln hergestellt.
PreSharedKeys sind ja nun das Gegenteil von Sicherheit (zumindest bei wiederholten Logins in unsicheren Netzen). Ich glaube allerdings nicht, dass man Sicherheit anders, als auf der Ebene "Perfect Forward Secrecy" vergleichen sollte.... und da fängt es mit der Schlüsselverhandlung an.OpenVPN mit einem einfach herzustellendem PSK zu nutzen, ist jedenfalls nicht sicherer als SSH mit Username/Paßwort.
Zunächst bringt dir ein Portscan die offenen Ports zutage, auch UDP-Ports. Natürlich weiß ich dann noch nicht viel. Wenn der Scann aber nur 2-3 offenen Ports liefert, kann ich meinen Angriff verfeinern und Portokolle auf genau diese 2-3 Ports testen.TomL hat geschrieben:16.06.2020 14:17:12Nein, das ist es zumindest bei OpenVPN nicht. UDP ist zustandslos, irgendeinen beliebigen UDP-Port ohne das dahinterstehende Protokoll identifizieren zu können sagt ja erst mal gar nichts verwertbares für den Angreifer aus.
Bei SSH gibt es dafür die Hostkeys.Ich sehe das Risiko (bei mir) in der fehlenden Kontrolle bei SSH, mit wem ich den Schlüssel aushandele.
Oft aber fast immer falsch zitiertDas eigentliche Problem dabei ist, um Sokrates zu zitieren "ich weiß, dass ich nichts weiß.".
Danke für die Bestätigung.Aber ganz ohne Zweifel... Du hast völlig Recht... OpenVPN ist nicht trivial....
Ich halte das für einen Irrtum. An dem Punkt gibt es noch gar kein VPN-Protokoll. Es sein denn, man will die zusätzliche Verschlüsselung des DTLS-Channels auf UDP als Protokoll definieren. Das ist ja noch, bevor es via DH anfängt, über einen Sitzungsschlüssel zu verhandeln. Das bedeutet, die HMAC-Firewall unterbricht sofort Verbindungsversuche, lange bevor z.B. mein Paketfilter via nftables wach wird oder bevor Daten auf dem VPN-Daten-Channel fließen.MSfree hat geschrieben:16.06.2020 14:54:07Wenn der Scann aber nur 2-3 offenen Ports liefert, kann ich meinen Angriff verfeinern und Portokolle auf genau diese 2-3 Ports testen.
Da musste mir jetzt helfen... ich sehe den Unterschied nicht.... abgesehen grammatikalisch. Aber siehe hier: https://sokratesberlin.de/philosophisch ... hts-weiss/Oft aber fast immer falsch zitiertDas eigentliche Problem dabei ist, um Sokrates zu zitieren "ich weiß, dass ich nichts weiß.".
Er sagte: Ich weiß, daß ich nicht weiß.
Wenn ich einen OpenVPN-Server angreifen will und nicht weiß, auf welchem Port der Server lauscht, kann ich alle 65565 möglichen Ports stumpf durchprobieren. Wie hilft dir in so einer Situation das Verlegen des Standardports von 1194 auf z.B. 21194?
iptables/nftables kommt immer als erster bei eintrudelnden Pakete dran.lange bevor z.B. mein Paketfilter via nftables wach wird
Das ist mir jetzt zu lang zum Lesen.
Bei 1194 weißt Du vorher, dass es OpenVPN ist, bei einem wilden Port >50000 bricht die HMAC-Firewall ab, bevor Du was von OpenVPN feststellen kannst. Du weißt als Angreifer also gar nicht, was Du da attackierst und welche Schwachstellen eines Protokolls Du angreifen könntest.MSfree hat geschrieben:16.06.2020 15:24:19Wenn ich einen OpenVPN-Server angreifen will und nicht weiß, auf welchem Port der Server lauscht, kann ich alle 65565 möglichen Ports stumpf durchprobieren. Wie hilft dir in so einer Situation das Verlegen des Standardports von 1194 auf z.B. 21194?
:::
Wie erhöht sich hier die Sicherheit dadurch, daß du von den Port 1194 auf 21194 verlegt hast?
Ja, stimmt, das ist in dem Fall aber irrelevant, weil die Pakete ja zum Prozess durch gehen müssen, sonst würde ich mich ja selber aussperren. Das bedeutet, die Firewall (also sowas wie fail2ban oder meine getime'ten Elementlist's können erst bei multiplen Versuchen wach werden. Und deswegen greift die HMAC-FW vorher.iptables/nftables kommt immer als erster bei eintrudelnden Pakete dran.
Die Überschrift ist also nicht wirklich zu lang zum lesen...Das ist mir jetzt zu lang zum Lesen.
Wie bzw. mit welchem Tool scannst Du auf offene/lauschende UDP-Ports?MSfree hat geschrieben:16.06.2020 15:24:19Der Angreifer kann auch durch einen Portscann vorweg herausfinden, daß auf Port 21194 irgendwas lauscht.
nmapmat6937 hat geschrieben:16.06.2020 15:55:32Wie bzw. mit welchem Tool scannst Du auf offene/lauschende UDP-Ports?
Wenn man z. B.:
Code: Alles auswählen
net.inet.udp.blackhole=1