07.11.2022, aktualisiert um 12:53:41 Uhr

2665

Freigabe eines webdienstes nach Außen

Hi,

ich hab mal eine Frage. Ich bin als Dienstleister auf vielen unterschiedlichen Kunden-Systemen unterwegs. Da wir aber im Normalfall nur eine Anwendung betreuen und nicht die IT-Infrastruktur, kommen wir auch immer sehr viel in Kontakt mit diversen IT-Dienstleistern.

Unsere Software bietet auch die Möglichkeit, die Daten, in Form einer APP und in Form einer Webseite zur Verfügung zu stellen. Wir haben bereits ein Standard-Verfahren erarbeitet, dass wir unseren Kunden anbieten, wenn es um den Zugriff von außen geht. Die Informationen sind oft für den Außendienst relevant, sollen also nicht von Externen abgerufen werden, aber durchaus auch beim Kunden vor Ort (Wenn der Außendienst vor Ort ist), um Informationen aus dem System zu ziehen.

Mich würde interessieren. Wie würdet ihr den Zugriff auf diese Daten konzeptionell gestalten? Wir bekommen immer wieder die abstrusesten Vorschläge und mich würde einfach interessieren, ob ich schon zu lange aus dem Netzwerk Thema raus bin, oder die anderen einfach noch nicht lange genug drin.

Gruß
PJM

PS: Meistens Windows only Umgebung (Bis auf die Firewall natürlich)

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 4534257868

Url: https://administrator.de/contentid/4534257868

Ausgedruckt am: 23.11.2024 um 09:11 Uhr

18 Kommentare

Neuester Kommentar

sollen also nicht von Externen abgerufen werden, aber durchaus auch beim Kunden vor Ort (Wenn der Außendienst vor Ort ist)

Unter den Voraussetzungen ist dann ein klassisches VPN, wie immer, dein bester Freund.

Zitat von @aqui:

sollen also nicht von Externen abgerufen werden, aber durchaus auch beim Kunden vor Ort (Wenn der Außendienst vor Ort ist)

Unter den Voraussetzungen ist dann ein klassisches VPN, wie immer, dein bester Freund.

Oder einen ReverseProxy zwischenschalten, der den Aufruf per MFA ermöglicht, z. B. mittels NGINX (https://seantodd.co.uk/blog/putting-2fa-on-everything/)

1. VPN klassisch (Open VPN, IPSec, ...)
2. VPN per Wireguard
3. ngrok (siehe ngrok.io)
4. Tailscale

Die letzten beiden Lösungen kann man benutzen, wenn man keine IT-Infrastruktur zur Verfügung hat, um z.B. eine DMZ und einen Reverse Proxy selber zu betreiben. ngrok ist in der Lage, beliebige IP-Ports nach Außen zu bringen. In etwa so wie man es per dynamischen DNS machen würde.

Tailscale verfolgt einen anderen Einsatz und richtet so etwas wie ein VPN ein - allerdings Maschinen bezogen. Man startet Tailscale auf dem eigenen Arbeitsrechner und hat dann Zugriff auf die Rechner, auf denen quasi ein Tailscale Agent läuft.

Sowohl ngrok als auch Tailscale überwinden NATs.

Man kann ab ca.$10 pro Monat in ngrok eine feste URL reservieren. Wenn man mehrere Dienste freigeben will,kann man das über verschiedene IP-Ports machen. Oder einen Proxy (z.B. HAproxy) intern laufen lassen, der auf die verschiedenen, interne laufende Server ausgerichtet ist (sprich: macht den Reverse Proxy dafür) und dann nur die eine URL mit dem einen Port von HAproxy per ngrok nach Außen freigeben. Und schon kann man seinen ganzen Applikations-Park von Außen benutzen (sofern die Apps/Server sich auf Reverse Proxies konfigurieren lassen).

Sowohl ngrok als auch Tailscale solltest Du mal ausprobieren. Sind in der Grundkonfig kostenlos.

+1 für VPN. Ist ja meist schon da, bzw. Mehrwert in mehrerlei Hinsicht.

MFA und Reverse Proxy ist auch nicht verkehrt. Viele haben aber danenben noch die Server in einer DMZ.

Wenn es relativ klein aufgestellt ist und die Kunden VPN nicht blockieren wäre das eine Alternative. OPNVPN läufta auch mobil. Falls die Eingaben via Handy oder Tablett erfolgen sollen.

Okay, Interessant. Ich finde es immer sehr "Benutzerunfreundlich", wenn die Mitarbeiter erst ein VPN auf ihren Mobilen Endgeräten aktivieren müssen, bevor sie einen Dienst nutzen können. Aber da scheint es ja in dieser nicht repräsentativen Umfrage 3:1 zu stehen

Frage zu MFA, das hat doch erst mal nichts mit der Verbindungssicherheit an sich zu tun, oder? Ich kann doch auch eine HTTPS Verbindung mit öffentlichem Zertifikat über einen Reverse Proxy laufen lassen. Am Ende steht eine verschlüsselte Datenübertragung, oder gibt es Gründe, warum ihr ein VPN vorziehen würdet?

Ja, die Verbindung ist verschlüsselt, das ist richtig.
Gehen wir mal davon aus, dass der Aufruf eurer Plattform (an die ja nur die AUßendienstler gelangen sollen) portal.company.de lautet. div. Bots im WWW scannen allen $cheiß und finden irgendwann portal.company.de
Dann wird die Seite aufgerufen. Dank des Zertifikates ist alles verschlüsselt - und wenn das Zertifikat von einer öffentlichen, nicht gesperrten CA kommt, ist der Partner auch verifiziert.
Jetzt habt ihr zumindest mal einen Login auf der Seite, bestehend aus Passwort und Benutzername. Via SocialMedia-Portale (Xing, LinkedIn, ...) probiert man mal relevante Anwender zu identifizieren und über Social Engineering an deren Kennwörter zu gelangen (sofern die nicht eh schon im Darknet bekannt sind). Zack, kommen die böhsen Burschen an das Portal - mit einer sauber verschlüsselten Verbindung.*

Mit einer MFA muss (vom Smartphone) halt ein weiterer Faktor (am besten OTP) eingegeben werden. Dann bringt dem Angreifer Username und Password nüschts.

Beim VPN ist portal.company.de nicht öffentlich existent. Die Seite kann nur aus dem VPN-Netz (und dem Firmen-LAN) aufgerufen werden. ein Angreifer kann somit niemals Zugang erhalten (außer er hat es in eure Netze geschafft, aber dann habt ihr andere Probleme).

Pro VPN: wenn ihr ohnehin schon eine Firewall habt, ist das ratzefatz eingerichtet - niedrige Implementierungskosten
Bei der anderen Variante müsst ihr zunächst mal einen ReverseProxy in einer DMZ etablieren (sofern die Firewall/ UTM das nicht selbst mitbringt). Dann müsst ihr ein öffentliches Zertifikat kaufen und es jährlich verlängern (wenn ihr es eh nicht habt). Und eine MFA-Lösung muss auch eingerichtet werden.

* Das hier geschilderte Verfahren für einen Angriff stellt keine Anleitung dar sondern ist alltägliches vorkommen. Zudem wurde es in der c't 23/2022 ebenfalls beschrieben. Es dient also als Hinweis, weshalb öffentlich zugängliche Portale mit zu schützenden Informationen irgendwie immer per MFA abgesichert werden sollten.

Tunnel wird bei OPENVPN auch wiederverbunden. Die App rauscht einmal durch und man ist eingewählt. Das Problem ist mehr die Offline Verfügbarkeit, wenn man irgendwo im Keller sitzt.

Mehr als One-Click Anmeldung bei VPN geht nicht. Auch Connect on Boot gibt es als Option. Wäre normal kein K.O.-Kriterium.

Die sollen ja damit abeiten und nicht bei Facebook immer durch scrollen. Wie oft haben die denn jetzt ihre Mappen o.ä. in der Hand? Benefit sind die nahezu in Echtzeit verfügbaren Daten. Auf Laptops kannst du auch mit PowerShell oder Batch arbeiten. Tunnel + Firewall mit Link zur Seite. Man kann es auf ein Minimum an klicks reduzieren. Ist mehr die Gewohnheit. Der OPENVPN Client ist recht flott.

Die Zeiten der Einwahl sind mit Sicherheit ähnlich den Suchen in den Unterlagen oder händischen Eintragungen. Die vlt. noch doppelt, da keiner weiß was der Vorgänger gemacht hat . Denke das nimmt sich später in Betrieb nicht viel....

@Crusher79

MFA und Reverse Proxy ist auch nicht verkehrt. Viele haben aber danenben noch die Server in einer DMZ.

welchen Vorteil bringt dir ein Reverse Proxy in deinem Design?

@fisi-pjm

Wir stellen sowohl Applikationen mit als auch ohne VPN bereit. Ohne VPN gibt es einen MFA in Form eines Hardware OTP Token. Wann welches Verfahren zum Einsatz kommt, hängt davon ab welche Daten dort bereitgestellt werden, wie viele Personen darauf zugreifen können müssen und wie hoch die Verfügbarkeit sein muss.

Ich kann doch auch eine HTTPS Verbindung mit öffentlichem Zertifikat über einen Reverse Proxy laufen lassen.

Selbe Frage an dich wie an @Crusher79. Was gewinnst du mit dem Reverse Proxy?

Am Ende steht eine verschlüsselte Datenübertragung, oder gibt es Gründe, warum ihr ein VPN vorziehen würdet?

Wenn das Unternehmen nicht in IDS/IPS und WAF investieren kann/möchte/will, ist VPN die einzigste vernünftige Lösung. Anwendungen ohne WAF heute ins Internet zu stellen, gehört verboten und bestraft.

Gruß,
Dani

Zitat von @em-pie:
Bei der anderen Variante müsst ihr zunächst mal einen ReverseProxy in einer DMZ etablieren (sofern die Firewall/ UTM das nicht selbst mitbringt). Dann müsst ihr ein öffentliches Zertifikat kaufen und es jährlich verlängern (wenn ihr es eh nicht habt). Und eine MFA-Lösung muss auch eingerichtet werden.

Dazu noch meinen Senf

Wir etablieren immer einen Reverse Proxy in Form eines IIS mit ARR. Wie gesagt, Windows Umfeld daher ist der Server immer schon da, wenn es die Firewall kann um so besser, aber wenn nicht, machen wir es Windowsseitig. Als Zertifikat kommt eins von Let's Encrypt rein und wird automatisch alle 3 Monate verlängert. Somit keinerlei Zusatzkosten und kein Zertifikat, an das man alle 3 bzw. 12 Monate denken müsste. Die Software selbst hat schon Mechanismen um z.B. Brut Force zu verhindern, lässt sich aber auch mit MFA betreiben. Sehe ich aber nicht wirklich im Bereich des Verbindungsaufbaus, sondern in der Applikationssicherheit. Mich interessiert an der Stelle wirklich nur der Verbindungsaufbau.

Was hindert einen Angreifer daran, nach VPN Endpunkten zu scannen und die Zugänge über die von dir genannten Methoden zu erhalten?

Zitat von @Dani:

Ich kann doch auch eine HTTPS Verbindung mit öffentlichem Zertifikat über einen Reverse Proxy laufen lassen.

Selbe Frage an dich wie an @Crusher79. Was gewinnst du mit dem Reverse Proxy?

Ich verlagere die "Sicherheitsschicht" auf den Webserver, den ich unter Kontrolle habe. Die Anwendung an sich hat nur einen abgespeckten Webservice, der sich nur schwer administrieren und anpassen lässt. Durch den Reverse Proxy habe ich freie Hand und kann mich dort auch um SSL Abladung und der gleichen kümmern. Habe somit eine "Miniatur DMZ" im eigenen System. Ich kann also nur die erwarten, aufrufe und eingaben zulassen und den Rest ins Leere laufen lassen.

Würdest du unter diesen Aspekten sagen, man hat einen Sicherheitsgewinn, wenn man es per VPN verbindet im Vergleich zu der ReverseProxy, Lets Encrypt, MFA Variante? (MFA läuft so oder so, auch bei VPN, wie oben beschrieben sehe ich das in der Verantwortung der Anwendung, nicht im Aufbau der Verbindung)

Die Software selbst hat schon Mechanismen um z.B. Brut Force zu verhindern

Social Engineering lässt BrutForce obsolet werden

Das sieht dann wie ein realer Zugriff aus (wenn ordentlich gemacht).

Was hindert einen Angreifer daran, nach VPN Endpunkten zu scannen und die Zugänge über die von dir genannten Methoden zu erhalten?

Nichts. Da gebe ich dir recht. Aber hier muss erstmal der Endpunkt selbst (IP/ DNS-Name), der Port, das richtige VPN Protokoll sowie der richtige Port identifiziert werden. Wobei letzteres "einfach" ist: weiß ich, welcher VPN-Server über welchen Hersteller zum Einsatz kommt, kenne ich mit sehr hoher Wahrscheinlichkeit den Port.
aber auch VPN geht mit MFA oder Zertifikaten, die man z. B. per MDM an die Clients verteilt.

Wenn/ dass ihr bereits einen ReverseProxy einsetzt, ist schon mal von Vorteil, ob das nun auf einer Windows-Kiste läuft, ist Geschmackssache, denke ich. Mir wäre das zu ressourcenlastig...

Insgesamt gilt aber wie immer: der Grad der Sicherheit hängt von den zu schützenden Daten ab. Den öffentlichen Teil einer KnowledgeBase sichere ich sicherlich maximal mit einer HTTPS-Verbindung ab. Das Portal, zur Pflege der KB-Artikel mindestes mit Username + Pwd. Geht es um Personaldaten, wäre eine MFA zwingend Voraussetzung. Hier sind aber noch längst nicht alle Hersteller soweit...

Wenn man einen Reverse Proxy dazwischen hängt, bietet das aus meiner Sicht vor allem diese Vorteile:
- SSL-Endpunkt wird von Reverse Proxy und nicht von der Webanwendung betrieben. Kann performanter sein.
- Proxy ist schneller rekonfigurierbar. Statt jede Webanwendung einzeln zu konfigurieren, stellt man alles beim Proxy ein.
- Die meisten Proxies beherrschen umfangreiche Stellschrauben, um z.B. die Zugriffe zu filtern (z.B. "bitte nur maximal 10 Anfragen innerhalb von 3 Sekunden von einer IP-Adresse").
- Es lässt sich Load Balancing realisieren.
- Für die meisten Anwendungsfälle lassen sich die gängigen Reverse Proxies recht einfach konfigurieren, wenn man das Prinzip einmal verstanden hat.

@fisi-pjm

Ich verlagere die "Sicherheitsschicht" auf den Webserver, den ich unter Kontrolle habe.

Die Sicheheitsschicht zwischen Reverse Proxy und Server bzw. Application im Backend ist genau so wichtig. Dazu gehört auch das Härten von TLS PRotokollen und die dazugehörigen Cipher Suites. Nur weil die Verbindung zwischen Frontend und Backend stattfindet, ist diese nicht automatisch sicherer.

Ich kann also nur die erwarten, aufrufe und eingaben zulassen und den Rest ins Leere laufen lassen.

Und wie schaust du den Datenverkehr an? Das ist doch heute bei Angriffen der interessante Vektor. Weil IIS und AAR bieten hinsichtlich Layer 7 meines Wissens nach keine Modules o.ä. an um hier vernünftig ansetzen zu können. Es nutzt doch nichts nicht, wenn Verbindungen bzw. Daten 1:1 weitergeleitet werden. Denn so ist das Backend den gleichen Gefahren ausgesetzt.

Würdest du unter diesen Aspekten sagen, man hat einen Sicherheitsgewinn, wenn man es per VPN verbindet im Vergleich zu der ReverseProxy, Lets Encrypt, MFA Variante?

Wenn keine WAF (und IPS/IDS) zum Einsatz kommt -> VPN. Schau dir mal die Viezahl an Sicherheitslücken bei bekannten Produkten an. Zudem kommt dazu dass die Entwickler nach wie vor bei diesen PRodukten als auch bei Eigenentwicklungen nach wie vor schlampen. Pen Tests für Anwendungen => Fehlanzeige.

@137960
Ich denke deine Ausführungen sind heute das Minium. Je nachdem was als Reverse Proxy eingesetzt wird (und eine WAF ist im Grunde nichts anderes), können Dinge wie Ratelimits, GeoIP, Injections, erfolgreich abgewehrt werden. Ist aber dann kein Selbstläufer mehr sondern bedeutet laufender Aufwand bezüglich Personal, Zeit und Schulung.

Gruß,
Dani

@Dani hat war nur von @em-pie kurz aufgegriffen. Denke mal die wichtigsten Aspekte schwieren hier im Thread schon rum.

@fisi-pjm wohin geht die Tendenz? VPN find ich nur immer recht "nett", da es viele schon haben und die Fallhöhe gering ist. Config wird ja meist schon automatisch generiert und muss nur ausgerollt werden. MFA etc. brauchen etwas mehr Vorbereitung. So "unbequem" dürfte es für die MA ja auch nicht sein.

Denke der Knackpunkt hier ist, ob der Kunde VPN zulässt oder via Fw blockiert. Ihr seit ja nicht "der" IT-Dienstleister - wie du geschrieben hast. Dann wäre es in der Tat so, dass die MA mit mobilen Geräten (Mobile, Laptop, Tablett) arbeiten müssten - LTE.

Vlt könntest du kurz umreißen, ob VPN überhaupt so möglich wäre oder es sich schon durch diese Einschränkungen "verbietet". Dann bliebe nur noch die andere Variante....

Zitat von @Dani:

@fisi-pjm

Ich verlagere die "Sicherheitsschicht" auf den Webserver, den ich unter Kontrolle habe.

Da die Kommunikation nur im Localhost Bereich, also in einem gekapselten Interface auf dem gleichen System stattfindet, finde ich, ist das schon ein bisschen sicherer als der Kommunikationsweg vorher.

Ich kann also nur die erwarten, aufrufe und eingaben zulassen und den Rest ins Leere laufen lassen.

Okay, da geb ich dir recht, ich kann nur die aufgerufenen URLs interpretieren. Der Datenverkehr selbst bleibt ungesehen.

Würdest du unter diesen Aspekten sagen, man hat einen Sicherheitsgewinn, wenn man es per VPN verbindet im Vergleich zu der ReverseProxy, Lets Encrypt, MFA Variante?

Die Argumentation finde ich schwach. Die Frage war ja nicht, welcher Anbieter ist besser, sondern ob es einen signifikanten Sicherheitsvorteil von VPN gegenüber einer mit SSL und TLS 1.2 verschlüsselten Verbindung auf eine Webapplikation gibt. Auch VPN-Protokolle können falsch implementiert sein.

Der einzige Punkt, der aus meiner Sicht aktuell für ein VPN spricht ist, dass ich eine weitere Authentifizierungsebene habe, bevor ich die eigentliche Anwendung erreiche. Geht aber eben zulasten der Benutzerfreundlichkeit (was unter Umständen dann auch wieder auf die Sicherheit gehen kann. Stichwort aufgeschriebene Zugangsdaten etc.). Und, Ja, MFA hatten wir schon klar, nochmal sicherer, ist aber wie gesagt auch schon in der Anwendung implementiert.

Zu der Frage wie das mit dem VPN aussieht, ob es verboten ist oder nicht. Das kann ich nicht beeinflussen. Es liegt nun mal im Naturell eines Außendienstlers, dass er zu potenziellen Kunden fährt und sich dort vorstellt. Dort wird dann, sofern kein Netz vorhanden, die Infrastruktur des potenziellen neuen Kunden genutzt. Somit kein Einfluss auf Beschränkungen für VPN. Aber die Wahrscheinlichkeit, dass SSL geblockt ist, ist wahrscheinlich wesentlich kleiner.

Aus meiner Sicht gibt es einen Sicherheitsvorteil von VPN gegenüber reinen TLS-Verbindungen:
VPNs lassen sich so konfigurieren, dass der gesamte Datenverkehr über das VPN läuft. Im Idealfall dann auch DNS-Anfragen. Es bleibt also alles schön innerhalb der virtuellen Firmenwände.

(Uppps... ist auch ein Nachteil. Wenn die IP-Verbindung von/zur Firma nicht genug Bandbreite bietet oder der VPN-Server zu schwach ausgerüstet ist, wird es für alle langsamer).

@fisi-pjm

es geht mir nicht und Sicherheitslücken im Protokoll (IPSec, HTTP/S) sondern innerhalb der erreichbaren Web Applicationen. Das ist aus meiner Sicht essentiell wenn man eine Berurteilung vornehmen möchte VPN Ja/Nein. Denn es geht schlussendlich, wenn nicht 100% sauber segmentiert und getrennt wird, um die Sicherheit des kompletten Firmennetzwerks. Da Argument hat daher doch eine große Gewichtung, oder?

Der einzige Punkt, der aus meiner Sicht aktuell für ein VPN spricht ist, dass ich eine weitere Authentifizierungsebene habe, bevor ich die eigentliche Anwendung erreiche. Geht aber eben zulasten der Benutzerfreundlichkeit (was unter Umständen dann auch wieder auf die Sicherheit gehen kann.

Das ist je nach dem (k)ein Argument. Wir haben Applikationen, da können wir kein VPN realisieren weil anderenfalls uns die Kunden/Partner auf die Füße stehen.

Gruß,
Dani