VPN-Tunnel Router auf vServer

mogbo

mogbo

Banned
Hallo,
ich möchte von meinem Router aus einen VPN-Tunnel für alle Geräte im internen Netzwerk einrichten, werde jedoch nach und nach immer mehr verunsichert, wie stark ich verschlüsseln sollte:

vServer 1GB RAM OpenBSD in Hamburg, Traffic etwa 250GB pro Monat, wobei der Traffic wohl täglich zu Stoßzeiten erfolgt.

Über diese Leitung möchte ich nicht nur surfen, sondern Wahlweise auch mal "zocken" ohne mit dem Ping groß in die Höhe zu schießen (falls das überhaupt möglich ist).

Jetzt noch zu meinem Halbwissen:
Ich habe des öfteren gelesen, dass 64bit Verschlüsselungen nach heutigen Standards zu "schwach" wären und würde gerne wissen, wie ich am besten verschlüsseln sollte um das Minimum an Latenz, jedoch ein maximales Maß an Sicherheit rauszuholen.
Nehme auch gerne Links zu Guides, falls mir jemand einen empfehlen kann, der das Thema nicht nur halbherzig kurz abarbeitet.
 
Man kann nun natürlich ein großes Fass aufmachen und darüber diskutieren, gegen welche Angriffe man sich schützen möchte, welche Gegenmaßnahmen notwenig sind und so weiter. Aber in der Praxis ist es ganz einfach: AES, am besten gleich in 256 Bit. AES ist schon in Software implementiert sehr schnell, schneller als die meisten anderen Algorithmen. Außerdem haben inzwischen sehr viele verbreitete CPUs die AESNI-Instruktionen, die den Overhead durch Hardwareimplementierung der einzelnen Schritte des Algorithmus dramatisch senken. Die meisten Hypervisor erlauben ihre Nutzung im Gastsystem, nahezu alle Crypto-Software unterstützt sie...
 
Blöde Frage: Ich höre immer wieder, dass dieser oder jener Algorithmus schneller und daher empfehlenswert sei. Aber will man das denn wirklich: Eigentlich will man es doch schwer machen, den Schlüssel zu knacken. Wenn ich einen Algorithmus nehme, der toll von der Hardware unterstützt wird, mache ich es dem Angreifer doch entsprechend leichter - oder nicht? Zumindest, wenn der Angreifer auf Brute Force zurück greifen muss.
 
@SolarCatcher Warum solltest du dir selbst Steine in den Weg legen? Nehmen wir mal an AES wäre schlecht implementiert (sehr langsam), das würde erstmal nichts an dem Verfahren dahinter ändern. Heißt, der Angreifer könnte eine bessere Version implementieren die schneller arbeitet, aber immer noch das selbe Ergebnis liefert. Für Brute Force ist eine zügige Implementierung natürlich vom Vorteil, aber auch für dich, denn du kannst eine "stärkere" Passphrase nutzen.
 
SolarCatcher schrieb:
Blöde Frage: Ich höre immer wieder, dass dieser oder jener Algorithmus schneller und daher empfehlenswert sei. Aber will man das denn wirklich: Eigentlich will man es doch schwer machen, den Schlüssel zu knacken. Wenn ich einen Algorithmus nehme, der toll von der Hardware unterstützt wird, mache ich es dem Angreifer doch entsprechend leichter - oder nicht? Zumindest, wenn der Angreifer auf Brute Force zurück greifen muss.
Zum Vergrößern anklicken....


Blowfish ist Hardware-Lastig, jedoch wird die 128bit Variante nicht von OpenVPN unterstützt.
Gibt andere Möglichkeiten, als Bruteforce, siehe Link.

https://sweet32.info/

Und in meinem Fall ist Performance wichtig, da ich mein gesamtes Subnetz verschlüsseln will, auch wenn ich zocke ohne direkt meinen Ping in die unendlichkeit zu treiben.
 
gadean schrieb:
Warum solltest du dir selbst Steine in den Weg legen?
Zum Vergrößern anklicken....
Also der FreeBSD-Installer macht genau das, wenn man ZFS-Vollverschlüsselung wählt. Der erhöht die Rundenzahl so lange, bis es auf der gegebenen Hardware mind. 2 Sekunden dauert. Eben damit ein Angreifer auf eben dieser Hardware auch mind. 2 Sekunden pro Versuch benötigt. Wenn ich jetzt einen Algorithmus hätte, der nur 1 Sekunde benötigte, würde der Installer halt mehr Runden davon laufen lassen, um die "Effizienz" wieder auszugleichen.
 
Da geht es aber doch darum Angriffe auf dem Server (lokal) zu verlangsamen? Wenn du den Netzwerkverkehr cracken willst, oder irgendwelche Hashes wirst du das doch kaum auf der Maschine die du angreifst tun? Ich muss gestehen, das ich kein Experte auf dem Gebiet bin, ich nutzte die Krypto nur mit rudimentären Grundwissen.

@mogbo lass doch einfach mal ein "openssl speed" laufen (auf dem Server und Router) und schau welcher Algorithmus dir die beste Balance zwischen Sicherheit und Geschwindigkeit bietet?
 
Man muss unterscheiden:
  • Rijndael, der dann zu AES wurde, ist darauf ausgelegt sowohl in Hardware als auch in Software einigermaßen effizient implementiert werden zu können. Anders als zum Beispiel sein Vorgänger DES, der mit Absicht so konstruiert war, das Softwareimplementierungen ineffizient und entsprechend langsam sind. Das heißt aber erst einmal nur, dass das Verschlüsseln eines Blockes mit einer vergleichsweise geringen Anzahl CPU-Zyklen möglich ist. Es sagt nicht aus, dass der Algorithmus schwach oder sogar generell schwächer als weniger effizient implementierbare Algorithmen ist.
    Allerdings war Rijndael im AES-Wettbewerb tatsächlich der schwächste Algorithmus, der die Finalrunde erreichte. Das Rijndael gewann und zum AES wurde - und nicht Serpent, MARS oder Twofish - lag wohl wirklich an der Geschwindigkeit und an der Möglichkeit zu relativ einfachen Hardwareimplementierungen. Der Gedankengang war wohl: "Lieber ein schneller, universell einsetzbarer Algorithmus, als ein theoretisch(!) sicherer, durch seine schlechte Geschwindigkeit aber nicht durchgehend nutzbarer Algorithmus".
    Nun wurde Rijndael 1998 veröffentlicht und 2000 zum AES. Seitdem ist es der mit Abstand am weitesten verbreitetste Algorithmus. Sicher weit über 90% aller Daten werdeb heute mit AES verschlüsselt. Das Ding ist also der heile Grahl, wer eine bedeutende Schwachstelle findet, hat ausgesorgt. Entsprechend dürfte kaum ein anderer Algorithmus so sehr analysiert und getestet worden sein. Trotzdem gab es in den nun 18 Jahren zwar ein paar Kratzer im Lack, eine ernsthafte Schwachstelle oder sogar einen praktisch nutzbaren Angriff hat man bisher (öffentlich bekannt) nicht gefunden. Sprich: AES ist nach bestem Wissen und Gewissen sicher und etwas anderes zu nutzen ist ungesunde Paranoia.
  • GELI nutzt eine Key Derviation Function. Der vom Nutzer eingegebene Schlüssel wird n Zyklen (je nach stärke der CPU) durch diese Funktion gedreht, um aus ihm den tatsächlich für die Verschlüsselung genutzten Schlüssel abzuleiten. Das macht man, um Bruteforce-Angriffe zu erschweren. Der Angreifer kann nicht mehr einfach seinen Rainbow-Table nehmen, er muss stattdessen jeden auszuprobierenden Schlüssel erst diese n Zyklen durch die Funktion drehen.
 
mogbo schrieb:
Müsste ich dann vermutlich am Router + vServer machen und vergleichen, wobei denke ich der vServer wohl eher zur Bremse wird.
Zum Vergrößern anklicken....
Was ist denn das für ein Router? Ein selbstgebauter mit PC-Hardware oder einer von der Stange aus dem Blödmarkt?

Bedenke auch Deinen Upstream. Selbst bei VDSL-100 dürfte der vServer nur mit der Schulter zucken. Die Latenz bleibt natürlich.

Ich habe solch einen Router von der Stange, allerdings mit OpenWRT bestückt, der nach Testberichten ca. 25MBit/s mit OpenVPN verschlüsseln können soll. Bei meinem Upstream von 1MBit/s ist da noch viel Luft. Der vServer würde dabei nicht mal zucken.

Abgesehen davon, was versprichst Du Dir durch das Tunneln des Traffics zum vServer?
 
crotchmaster schrieb:
Was ist denn das für ein Router? Ein selbstgebauter mit PC-Hardware oder einer von der Stange aus dem Blödmarkt?
Zum Vergrößern anklicken....
Der hier mit 4GB RAM
https://www.pcengines.ch/apu.htm

crotchmaster schrieb:
Abgesehen davon, was versprichst Du Dir durch das Tunneln des Traffics zum vServer?
Zum Vergrößern anklicken....
In meinem Netzwerk sind 2 Kinder, die in ihrem jugendlichen Leichtsinn evtl doch mal meinen Torrents zum Downloaden (bzw. unfreiwilligen Uploaden) von Pornos oder Musik nutzen zu müssen und ich werde lieber von meinem Anbieter angeschrieben: "hey, wir haben ein Schreiben vom Anwalt, dein Traffic wird geloggt", als ein Schreiben vom Anwalt selber, weil mir die Telekom nicht mitteilt, dass sie durch ein Schreiben vom Anwalt dazu gezwungen werden Traffic > 24std zu loggen.

crotchmaster schrieb:
Bei meinem Upstream von 1MBit/s
Zum Vergrößern anklicken....
Mir gehts dabei um die Dauer zum Verschlüsseln und Entschlüsseln, dass die Leitung nicht ausgelastet wird ist mir klar. Habe Angst, dass meine Ingamelatenz von einem 16ms (Standart) zu einem 500 ms ansteigt. Alles unter 150 ms wäre durchaus okay.
 
Okay. Macht das denn einen Unterschied, da Dein Server ja scheinbar auch in D steht?

Für solche speziell gelagerten Fälle gibt es ja Anbieter mit Austrittsknoten im ehemaligen Ostblock, wie z.B. Rumänien, die es nicht so genau mit dem Loggen nehmen.
Aber das Setup wird dann natürlich auch komplizierter.

Die genannte APU bzw. deren Nachfolger steht auch auf meiner Wunschliste. Ich würde meinen, die sollte genug Bums haben, um das ohne große Latenz zu schaffen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben