SSL/TCP:443 mit zwei Diensten teilen: HTTPS/OpenVPN

[daFreak]

Hi!

Laut openVPN gibt es in Version 2.1rc7 das Feature des Port-Sharing.

Meine Frage ist ob man so etwas auch mit iptables realisieren kann? Ich habe meinen Webserver sowieso auf einem anderen Server laufen.
Kann man von der zentralen Firewal aus per iptables ein NAT auf den jeweiligen Server machen je nach dem ob es sich um HTTPS oder OpenVPN handelt?
Oder bräuchte man einen Proxy, welcher die Header entsprechend ausliest?

[bse]

Sowas geht mit IPTables meines Wissens nicht. Bei NAT wird beim ersten Paket einer TCP-Verbindung entschieden wohin es weitergeleitet wird, und in diesem sind noch keine anwendungsspezifischen Daten.

[daFreak]

Gibt es vielleicht noch eine andere Alternative?

[Hendri]

Hallo,
mit verschlüsselten Verbindungen ist das ein Problem, da das Key-Handshake vor dem eigentlichen Inhalt (HTTP-Header) gemacht wird und da die Entscheidung mit wem man Kommunizieren will schon längst gefallen ist.

Das einzige was ich mir vorstellen kann ist folgendes:
Default geht alles zum HTTPS Webserver.
Für OpenVPN mußt du zuerst auf eine HTTPS Webseite auf deinem Webserver, der mittels CGI Script dann deine IPTABLES Regel (geht ja auch per ssh auf einer remote Maschine) in den Kernel klopft. Die Regel setzt von der jetzigen Absender IP das NAT zum OpenVPN Server.

Dann geht von dieser IP zwar HTTPS von extern nicht mehr, aber innerhalb vom VPN schon.
Eine Seite die diese Regel wieder löscht oder ein timeout währe zum beenden nicht schlecht...

[daFreak]

Hallo,
mit verschlüsselten Verbindungen ist das ein Problem, da das Key-Handshake vor dem eigentlichen Inhalt (HTTP-Header) gemacht wird und da die Entscheidung mit wem man Kommunizieren will schon längst gefallen ist.

Das einzige was ich mir vorstellen kann ist folgendes:
Default geht alles zum HTTPS Webserver.
Für OpenVPN mußt du zuerst auf eine HTTPS Webseite auf deinem Webserver, der mittels CGI Script dann deine IPTABLES Regel (geht ja auch per ssh auf einer remote Maschine) in den Kernel klopft. Die Regel setzt von der jetzigen Absender IP das NAT zum OpenVPN Server.

Dann geht von dieser IP zwar HTTPS von extern nicht mehr, aber innerhalb vom VPN schon.
Eine Seite die diese Regel wieder löscht oder ein timeout währe zum beenden nicht schlecht...

Hi,

das ist auf jeden Fall eine gute Idee.
Portknocking ist mir auch schon in den Sinn gekommen.

1. Wäre es denn möglich das ein Proxy versucht an den Header zu kommen? Und wenn es sich um HTTP handelt an den Webserver weiterzuleiten und an sonsten an den VPN-Server?
2. Könnte man eine Verbindung intern durch 443 schicken und am Ziel auf einen anderen Port? Dann könnte ich HTTPS auf 443 laufen lassen und VPN auf einem anderen Port.

[Hendri]

AD 1) Ja, aber der Reverse Proxy macht dann die HTTPS Verschlüsselung und OpenVPN wird dann nicht funktionieren!
AD 2) Ja, aber nur mit Reverse Proxy und nur bei HTTP -> wie bei 1

Bei Portknocking kannst du auf Grund der krummen Ports im manchen Netzwerken Probleme bekommen durch Firewalls. HTTPS geht fast immer...

[daFreak]

AD 1) Ja, aber der Reverse Proxy macht dann die HTTPS Verschlüsselung und OpenVPN wird dann nicht funktionieren!
AD 2) Ja, aber nur mit Reverse Proxy und nur bei HTTP -> wie bei 1

Ok,

War ein wenig anders gemeint.
Zu 1. Bei HTTPS kommt der Proxy ja dran und da er die VPN-Verbindung eh nicht entschlüsseln kann, könnte er die Verbindung ja einfach an den VPN-Server weiterleiten. Quasi alles außer HTTPS an den VPN-Server.
Zu 2. War vielleicht nicht so gut überdacht

Bei Portknocking kannst du auf Grund der krummen Ports im manchen Netzwerken Probleme bekommen durch Firewalls. HTTPS geht fast immer...

Ich lasse die DMZ nicht per ssh an meine Firewall dran. Einzige Möglichkeit wäre Portknocking von dem Webserver aus.
Hab mir auch schon mal überlegt das über ISDN und Spracherkennung zu regeln und dann per Portknocking eine Regel zu aktiveren

Ich werde mich mal an einem Reverse Proxy versuchen. Ich schätz mal squid ist da auch gut geeignet, oder?
Eine automatische Weiche wäre natürlich schöner, vorallem da 443 ein doch so beliebter Port ist
Dann wäre das für mehrere User auch flexibler

Schonmal danke für deine Tipps Hendri.
Für weitere Ideen bin ich gerne offen.

[Hendri]

Wie willst du die Absender IP per Portnocking übertragen? Da musst du dir etwas einfallen lassen wie du das Überträgst.
IHMO ist es dasselbe Risiko die IP per Portnocking zu übertragen wie über einen unprivilegierten User, der ein File überträgt in dem eine IP steht das per cron in eine IPTABLES Regel geladen wird. Mit ipset könntest du auch arbeiten...

[gms]

Möglicherweise habe ich da etwas nicht ganz verstanden, aber OpenVPN verwendet doch eigentlich UDP und der Webserver verwendet eigentlich TCP. Das läßt sich doch leicht über iptables lösen, wo gibts da ein Problem ?
( Und 443 ist doch auch eigentlich nicht der Standardport für OpenVPN )

Gruß
gms

[Hendri]

OpenVPN lässt sich aber auch über z.B. HTTP Proxy per TCP Port 443 betreiben, was fast jede Firmen Firewall zulässt...

[gms]

OpenVPN lässt sich aber auch über z.B. HTTP Proxy per TCP Port 443 betreiben, was fast jede Firmen Firewall zulässt...

ja, das tragt ja hauptsächlich zu meiner Verwirrung bei. Der Einsatz eines HTTP Proxies wurde hier als Lösung für das Portsharing-Problem erwogen, das Portsharing würde man jedoch nicht benötigen, wenn man keinen HTTP Proxy verwendet
Da beißt sich die Katze doch in den Schwanz
Daß der HTTP Proxy hier nur wegen dem Portsharing eingesetzt werden soll, entnehme ich z.B diesem Zitat

Kann man von der zentralen Firewal aus per iptables ein NAT auf den jeweiligen Server machen je nach dem ob es sich um HTTPS oder OpenVPN handelt?
Oder bräuchte man einen Proxy, welcher die Header entsprechend ausliest?

Gruß
gms

[Hendri]

Gut, das ist jetzt anscheinend nicht ganz angekommen was gemeint war. Ich versuche es anders...

OpenVPN Client -> HTTP Proxy z.B. in einer Firma -> Internet -> HTTPS/OpenVPN Server auf Port 443

In vielen Firmen kommt man nicht direkt ins Internet sondern nur über HTTP Proxies/Firewalls, die noch zusätzlich nicht zulassen sich auf jedes Port connecten zu dürfen. Deswegen auf TCP Port 443 den OpenVPN Server lauschen lassen. Jetzt geht natürlich HTTPS nicht mehr wirklich, da man ja nur eine IP Adresse hat...

BTW: Warum willst du eigentlich das Feature PortSharing nicht von OpenVPN nutzen?

Code: Alles auswählen

--port-share host port
    When run in TCP server mode, share the OpenVPN port with another application, such as an HTTPS server. If OpenVPN senses a connection to its port which is using a non-OpenVPN protocol, it will proxy the connection to the server at host:port. Currently only designed to work with HTTP/HTTPS, though it would be theoretically possible to extend to other protocols such as ssh.

[gms]

In vielen Firmen kommt man nicht direkt ins Internet sondern nur über HTTP Proxies/Firewalls, die noch zusätzlich nicht zulassen sich auf jedes Port connecten zu dürfen. Deswegen auf TCP Port 443 den OpenVPN Server lauschen lassen.

diesen Wunsch kann ich zwar nachvollziehen, aber ohne jetzt den Moralapostel raushängen zu lassen, möchte ich doch darauf hinweisen, daß sich in diesem Fall der Mitarbeiter auf sehr dünnem Eis bewegt.
Durch diese VPN Verbindung schlägt man ein Loch in die Firmenfirewall, die dann nicht einmal mehr in der Lage ist, das Firmennetz vor Angriffen (z.B Würmer ) aus dem VPN zu schützen. Das kann daher sogar zu einer fristlosen Kündigung und zu Schadensansprüchen gegenüber den Mitarbeiter führen.

Gruß
gms

[Hendri]

Klar hast du damit recht. Ein Messer kann z.B. zum Brot schneiden und zum töten benutzen.
Was man damit macht steht in der Verantwortung jedes einzelnen.
Wenn man z.B. als Vertreter unterwegs ist und in vielen Firmen mit seinem Notebook ans Netz geht ist das ein sehr nützliches Feature...

[gms]

Ein Messer kann z.B. zum Brot schneiden und zum töten benutzen.
Was man damit macht steht in der Verantwortung jedes einzelnen.

Das sehe ich zwar ähnlich, beim Messer gehe ich aber eher davon aus, daß den Lesern dieses Forums die Technologie dahinter bekannt ist
Mein Einwand war daher hauptsächlich an Personen ( Newbies ) gerichtet, die sich jetzt vielleicht denken: "so ein VPN Zugang ins Heimnetz ist klasse, sowas möchte ich auch haben", sich aber nicht darüber im klaren sind, daß von so einem VPN eine größere Gefährdung für das Firmennetz ausgeht, als z.B von einem SSH Zugang in das Heimnetz

Gruß
gms

[Hendri]

Das den Leuten hier klar ist wie man Messer eingesetzt wird war mir schon bewusst, es ging mir mehr um die Analogie dahinter.
Man kann fast alles "im Guten" sowie "im Bösen" benutzen.

daß von so einem VPN eine größere Gefährdung für das Firmennetz ausgeht, als z.B von einem SSH Zugang in das Heimnetz

Da muß ich dir leider widersprechen. Mit SSH kann man die gleichen Dinge machen wie mit OpenVPN auch

[gms]

daß von so einem VPN eine größere Gefährdung für das Firmennetz ausgeht, als z.B von einem SSH Zugang in das Heimnetz

Da muß ich dir leider widersprechen. Mit SSH kann man die gleichen Dinge machen wie mit OpenVPN auch

Ich habe allgemein die Gefährdung des Firmennetzes bei Verwendung von VPN Lösungen und bei Verwendung von einem ausgehenden SSH Zugang verglichen!
Ich weiß jetzt nicht auf was du hinauswillst. Entweder beziehst du dich darauf, daß man auch über SSH ein VPN bzw Tunnel aufbauen kann. Dann sollte dir aber eigentlich auch klar sein, daß dieses dann im obigen Vergleich als VPN Lösung anzusehen ist.
Oder du möchtest jetzt behaupten, daß eine Technologie , welche eingehende Verbindungen in das Firmennetz, ohne jegliche Überprüfung durch eine Firewall erlaubt, das gleiche Gefahrenpotential bietet, wie eine ausgehende SSH Verbindung.
In beiden Fällen möchte ich eigentlich nicht mehr über dieses OT Thema weiter diskutieren, belassen wir es einfach dabei

Gruß
gms

[daFreak]

BTW: Warum willst du eigentlich das Feature PortSharing nicht von OpenVPN nutzen?

Code: Alles auswählen

--port-share host port
    When run in TCP server mode, share the OpenVPN port with another application, such as an HTTPS server. If OpenVPN senses a connection to its port which is using a non-OpenVPN protocol, it will proxy the connection to the server at host:port. Currently only designed to work with HTTP/HTTPS, though it would be theoretically possible to extend to other protocols such as ssh.

Das Feature ist leider in stable (openvpn 2.0.9) nicht enthalten.

Klar, gms, wichtiger Hinweis vonwegen Datenschutz.
VPN ist durchaus gefährlich, da man auch vom Server aus über den Client, sprich Heimnetz -> Firmennetz, locker auf jeden Rechner im Subnet des Firmennetzes rumstöbern kann. VPN ist auf jeden Fall ein scharfes Messer. SSH auch. Genauso wie UDP-Tunnel, Ping-Tunnel und alles was so mit Tunneln zu tun hat.

Wie willst du die Absender IP per Portnocking übertragen? Da musst du dir etwas einfallen lassen wie du das Überträgst.
IHMO ist es dasselbe Risiko die IP per Portnocking zu übertragen wie über einen unprivilegierten User, der ein File überträgt in dem eine IP steht das per cron in eine IPTABLES Regel geladen wird. Mit ipset könntest du auch arbeiten...

Guter Einwand.
Man könnte natürlich während der knockd den knocking erhält in der Regel die Quellip aus den Logs erkennen wer zu diesem Zeitpunkt den Webserver genutzt hat. Aber fraglich ist natürlich ob diese Lösung machbar/flexibel/eindeutig ist...

[gms]

t;]Wie willst du die Absender IP per Portnocking übertragen? Da musst du dir etwas einfallen lassen wie du das Überträgst.
I

Man könnte natürlich während der knockd den knocking erhält in der Regel die Quellip aus den Logs erkennen wer zu diesem Zeitpunkt den Webserver genutzt hat.

diese IP brauchst du nicht einmal aus den Logs auslesen, die bekommst du vom knockd "geschenkt". Du brauchst daher nur die Variable %IP% in den Regeln von knockd benutzen.
Das Problem ist bei deiner Konfiguration wahrscheinlich eher, daß du für Knockd auch zumindest einen Port zum anklopfen benötigst.

Wenn du gut im basteln bist, könntest du die Freigabe von OpenVPN für eine spezielle IP auch über HTTPS auslösen, das Zurücksetzen könnte dann ein OpenVPN Script erledigen.
Eventuell geht soetwas auch mit dem "string match" von iptables. Damit müßte sich eigentlich herausfinden lassen um welches Protokoll es sich bei der jeweiligen Verbindung handelt.

Gruß
gms

[daFreak]

Das Problem ist bei deiner Konfiguration wahrscheinlich eher, daß du für Knockd auch zumindest einen Port zum anklopfen benötigst.

Die Ports müssen jedoch nicht offen sein, oder habe ich dich falsch verstanden?

[gms]

Das Problem ist bei deiner Konfiguration wahrscheinlich eher, daß du für Knockd auch zumindest einen Port zum anklopfen benötigst.

Die Ports müssen jedoch nicht offen sein, oder habe ich dich falsch verstanden?

Sorry, Ich habe dich falsch verstanden. Ich dachte du möchtest von der Firma aus knocken, dann hätte natürlich die Firmenfirewall diese Ports für ausgehende Verbindungen durchlassen müssen.
Nachdem du aber vom Webserver das Knocking anstoßen möchtest, ist auch das was ich über die %IP% Variable geschrieben haben, nicht sehr hilfreich gewesen, das ist dann natürlich die "falsche" IP

Gruß
gms