Ich habe vor Kurzem OpenVPN mit Dnsmasq als DNS eingerichtet und möchte etwas tun, worüber ich scheinbar keine Informationen finden kann.
Hier ist mein aktuelles Verständnis, das auch auf dem basiert, was ich derzeit auf meinem Server eingerichtet habe.
A. Der Client stellt eine Verbindung zu OpenVPN her, beispielsweise von einem Telefon
B. Clients senden Datenverkehr, d. h. öffnen eine Website, beispielsweise YouTube
C. Der OpenVPN-Server nimmt die Anfrage entgegen.
D. Leitet die Anfrage an den Zielserver, z. B. YouTube, weiter.
E. YouTube antwortet.
F. OpenVPN leitet die Antwort von A an den Client weiter
Natürlich ist das oben Gesagte stark vereinfacht.
Was ich machen will; was ich vorhabe zu tun?
Zwischen den Phasen C und D, also nachdem OpenVPN die Anfrage entgegennimmt (oder eine Antwort vom Zielserver erhält, d. h. D->C), möchte ich die eigentlichen Daten verarbeiten.
Beispielsweise ein typischer Anwendungsfall.
Zwischen D und C möchte ich die Nutzlast beispielsweise an ein Python-Skript übergeben und den gesamten „Ich liebe dich“-Text im HTML der Webseite in „Ich hasse dich“ ändern, bevor die Nutzlast verpackt und an den Client gesendet wird.
Frage
Gibt es bei OpenVPN irgendeine Form von „Life Cycle Hooks“, mit denen ich grundsätzlich die Nutzlast einer Anfrage abhören und ändern kann?
Ich verstehe, dass jede eingehende oder ausgehende Verbindung von OpenVPN mit „Fort Knox“ gesichert ist. Mich interessiert der Punkt, an dem die Antwortnutzlast nackt auf dem Server liegt.
Welche Optionen stehen mir zur Verfügung? Muss ich ein anderes Paket/eine andere Software verwenden, um solche Ergebnisse zu erzielen?
Antwort1
Ihre Idee ist aus mehreren Gründen nicht umsetzbar:
1)
Soweit ich mich erinnere, gibt es in OpenVPN selbst keine Funktion, um Daten von einer VPN-Verbindung vor der Weiterleitung in einen benutzerdefinierten Prozess umzuleiten.
Zur schnellen Referenz: Sehen Sie sich an, wo TCP/IP im OSI-Stapel verwendet wird.
OpenVPN befindet sich auf Schicht 3 des OSI-Stapels (Netzwerkschicht), während TCP-Pakete auf Schicht 4 (Transportschicht) gehören.
Ihre Frage liegt schon aus diesem Grund außerhalb des Rahmens dessen, was OpenVPN erreichen möchte.
Das Einzige, was Sie manipulieren können, ist, was passiert, wenn ein Client eine Verbindung zum Server herstellt oder die Verbindung trennt.
Diese Situationen können in Ihrer Serverkonfigurationsdatei durch die folgenden Einstellungen definiert werden:
# client connected to VPN server
client-connect "/script/client_connect.sh"
# client disconnected from VPN server
client-disconnect "/script/client_disconnect.sh"
Alle Umgebungsvariablen, die für Ihr benutzerdefiniertes Skript verfügbar sind, sind hier verfügbar:
Im Wesentlichen können Sie jedoch nur die Informationen überwachen, welches Client-Zertifikat für die Verbindung mit dem Server verwendet wurde und welche IP-Adresse dem Client zugewiesen wurde. Anschließend können Sie auf dem Server eine benutzerdefinierte Logik erstellen, je nachdem, wer die Verbindung herstellt und was zu tun ist, wenn die Verbindung wieder getrennt wird.
Eine typische Konfiguration könnte darin bestehen, auf der Serverseite einen dynamischen DNS zu implementieren oder benutzerdefiniertes Routing durchzuführen, beispielsweise Failover-Routing, je nachdem, welche VPN-Verbindung aktiv ist.
2)
In diesem Diagramm eines IPv4-Pakets vonWikiPedia:
Im Wesentlichen möchten Sie das Datenfeld je nach Quell- oder Zieladresse manipulieren.
Dies wird auch als Man-in-the-Middle-Angriff bezeichnet.
Wie Sie festgestellt haben, ist es schwierig, dies durch Abhören der OpenVPN-Schnittstelle zu tun, da der gesamte Inhalt verschlüsselt ist. Was passiert, ist, dass ein für das Internet bestimmtes IPv4-Paket in ein anderes IPv4-Paket gekapselt wird, das für den OpenVPN-Server bestimmt ist.
Das gekapselte IPv4-Paket wird im Datenfeld im obigen Diagramm gespeichert.
Es ist das entkapselte Paket, das vom VPN-Server an das Internet weitergeleitet wird.
Es gibt jedoch einen Vorbehalt:
Ich gehe davon aus, dass der VPN-Clientnichteine öffentliche IP-Adresse haben. Das bedeutet, dass eine NAT-Übersetzung erforderlich ist und die Quelladresse so umgeschrieben wird, dass sie der des VPN-Servers entspricht, bevor ein Host im Internet kontaktiert wird.
Wenn der Host mit einer Antwort zurückantwortet, ist die Ziel-IPv4-Adresse ebenfalls dieselbe wie die des VPN-Servers.
Dies bedeutet, dass wir, um das Datenfeld zu manipulieren, im Auge behalten müssen, welche Ports im network address translation table(auch als NAT bezeichneten) Netzwerk verwendet werden.
Die verwendeten Ports sind normalerweise dynamischer Natur, da mehr als ein VPN-Client über VPN und NAT eine Verbindung zum Internet herstellen kann und jede TCP-Sitzung (Mail, Web, SSH, was auch immer) einen anderen Port verwendet.
Wenn Sie also manipulieren möchten,entschlüsseltes TCP-PaketDies muss nach der Entschlüsselung, aber vor der Übersetzung im NAT geschehen.
Theoretisch können Sie das Paket mithilfe von abfangen iptables, dies ist jedoch nicht trivial, wenn sich VPN und NAT auf derselben Maschine befinden.
Ein anderer Ansatz besteht darin, den verschlüsselten OpenVPN-Verkehr direkt anzugreifen. Da Sie den OpenVPN-Server kontrollieren, haben Sie auch die Kontrolle darüber, welche Zertifikate und privaten Schlüssel auf dem Server und dem Client verwendet werden.
Dies ist als klassischer Man-in-the-Middle-Angriff machbar. Ich weiß allerdings nicht, wie das geht. :-)
... aber das führt mich zu meinem letzten Argument:
3)
Der meiste Datenverkehr im Internet ist TLS-verschlüsselt.
Selbst nachdem Sie den OpenVPN-Verkehr entschlüsselt haben, gibt es eine weitere Verschlüsselungsebene, die Sie überwinden müssen, um den Inhalt des Datenfelds zu manipulieren.
Dieser Teil ist sogar noch schwieriger anzugreifen als nur den verschlüsselten OpenVPN-Verkehr, da Sie keine Kontrolle über die für die Sitzung verwendeten Verschlüsselungsschlüssel haben.
Selbst wenn Sie versuchen würden, den TLS-Verkehr zu entschlüsseln und den Inhalt neu zu verschlüsseln, sodass es für den Endbenutzer so aussieht, als stamme der verschlüsselte Verkehr tatsächlich von YouTube oder wo auch immer, wäre dies immer noch zwecklos, da das Zertifikat, das Sie zum Verschlüsseln des https-Verkehrs verwenden,nicht vertrauenswürdigdurch die Browser auf den Computern der Endbenutzer.
Dies allein macht Ihren Man-in-the-Middle-Angriff erfolglos.
Dies kommt einer vollständigen Antwort auf Ihre Frage sehr nahe.
Es gibt noch andere Möglichkeiten, eine TCP-Sitzung anzugreifen, aber jetzt betreten wir ein fortgeschrittenes Gebiet, das in ein Forum voller Sicherheitsexperten gehört.
Dieser Teil geht WEIT über meine Qualifikationen hinaus. :-)