7
Portweiterleitung vs. Reverse Proxy
Hallo zusammen,
bei einem Server der bereits in der DMZ ist besteht eine Portweiterleitung von Port 50443 auf 443. Auf dem Server ist der IIS aktiv und stellt eine Seite für eine Application bereit. Der Nutzer muss sich an der Application anmelden und kann dann auf Daten zugreifen. Wenn in der Application jetzt eine Sicherheitslücke ist, kann diese natürlich voll ausgenutzt werden und ein Angreifer hat ggf. alle Zeit der Welt zu bruten. Es soll ja auch schon vorgekommen sein, das MS Sicherheitslücken im eigenen System hat... *hust*
Ich frage mich inwieweit bei diesem Szenario ein normaler Proxy (jetzt mal noch ohne WAF) die Sicherheit verbessern kann? Ein normaler Proxy (z.B. Linux mit Apache) leitet doch auch nur weiter?
Wenn ich jetzt eine Firewall habe die WAF kann und den Datenstrom aufbricht, Filtert bzw. scanned, erst dann sehe ich einen Mehrgewinn? Ohne hier SSL Interception zu betreiben sehe ich auch hier wenig sinn.
-- Bisschen OFFTOPIC --
Eine weitere sinnvolle Maßnahme ist in meinen Augen den Server in der DMZ nicht ins Internet zu lassen. Ein Angreifer der eventuell auf das System gekommen ist, kann dadurch selbst keinen Code nachladen. Updates kann ja auch ein WSUS machen, das muss nicht über das Internet sein.
Noch ein weiters Thema was mich hier interessiert wäre, wie man den Server am besten absichert. Benötigt man zwingend 3rd Party Virenscanner? Der Microsoft Defender der ja bereits ab Server 2016 inkludiert ist, hat wieder sehr gut abgeschnitten.
Wie seht ihr das? Was ist einfach umzusetzen und bringt viel Sicherheitsgewinn?
Grüße
Leon
bei einem Server der bereits in der DMZ ist besteht eine Portweiterleitung von Port 50443 auf 443. Auf dem Server ist der IIS aktiv und stellt eine Seite für eine Application bereit. Der Nutzer muss sich an der Application anmelden und kann dann auf Daten zugreifen. Wenn in der Application jetzt eine Sicherheitslücke ist, kann diese natürlich voll ausgenutzt werden und ein Angreifer hat ggf. alle Zeit der Welt zu bruten. Es soll ja auch schon vorgekommen sein, das MS Sicherheitslücken im eigenen System hat... *hust*
Ich frage mich inwieweit bei diesem Szenario ein normaler Proxy (jetzt mal noch ohne WAF) die Sicherheit verbessern kann? Ein normaler Proxy (z.B. Linux mit Apache) leitet doch auch nur weiter?
Wenn ich jetzt eine Firewall habe die WAF kann und den Datenstrom aufbricht, Filtert bzw. scanned, erst dann sehe ich einen Mehrgewinn? Ohne hier SSL Interception zu betreiben sehe ich auch hier wenig sinn.
-- Bisschen OFFTOPIC --
Eine weitere sinnvolle Maßnahme ist in meinen Augen den Server in der DMZ nicht ins Internet zu lassen. Ein Angreifer der eventuell auf das System gekommen ist, kann dadurch selbst keinen Code nachladen. Updates kann ja auch ein WSUS machen, das muss nicht über das Internet sein.
Noch ein weiters Thema was mich hier interessiert wäre, wie man den Server am besten absichert. Benötigt man zwingend 3rd Party Virenscanner? Der Microsoft Defender der ja bereits ab Server 2016 inkludiert ist, hat wieder sehr gut abgeschnitten.
Wie seht ihr das? Was ist einfach umzusetzen und bringt viel Sicherheitsgewinn?
Grüße
Leon
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 11028204066
Url: https://administrator.de/contentid/11028204066
Ausgedruckt am: 22.11.2024 um 07:11 Uhr
7 Kommentare
Neuester Kommentar
Hallo Leon,
nicht ganz Deien Frage, aber vieleicht auch hilfreich.
Sind kommerzielle UTM Firewalls besser als Open source Reverse Proxys?
Zu Deiner Frage
Ein Reverse-Proxy ist die 1. Stufe einer WAF.
Du kannst dort definieren welche URLs mit welchen Parameter von wo (Geo-Location) aufgerufen werden können.
Du verhinderst z.B. unbekannte URLs die den IIS angreifen und gar nicht bei Deiner Anwendung ankommen.
Eine einfache Möglichkeit ist ohne einen Session Cookie nur die Login-Seite erreichbar zu machen.
Kein Login, Kein Cookie, Kein Zugriff
Das ist die Basis-Version von Pre-Auth.
Auch Server-Header kann man gut filtern. Dadurch erhält ein böser Wicht weniger Informationen über das System.
Je nachdem wie viel Zeit man darin invenstieren kann.
Ich wäre nicht mutig genug einen IIS nackt ins WAN zu hängen...
Stefan
Btw: hohe Ports bringen fast gar nichts.
Es gibt dafür sogar Suchmaschienen.
nicht ganz Deien Frage, aber vieleicht auch hilfreich.
Sind kommerzielle UTM Firewalls besser als Open source Reverse Proxys?
Zu Deiner Frage
Ein Reverse-Proxy ist die 1. Stufe einer WAF.
Du kannst dort definieren welche URLs mit welchen Parameter von wo (Geo-Location) aufgerufen werden können.
Du verhinderst z.B. unbekannte URLs die den IIS angreifen und gar nicht bei Deiner Anwendung ankommen.
Eine einfache Möglichkeit ist ohne einen Session Cookie nur die Login-Seite erreichbar zu machen.
Kein Login, Kein Cookie, Kein Zugriff
Das ist die Basis-Version von Pre-Auth.
Auch Server-Header kann man gut filtern. Dadurch erhält ein böser Wicht weniger Informationen über das System.
Je nachdem wie viel Zeit man darin invenstieren kann.
Ich wäre nicht mutig genug einen IIS nackt ins WAN zu hängen...
Stefan
Btw: hohe Ports bringen fast gar nichts.
Es gibt dafür sogar Suchmaschienen.
Servus,
wenn ich mich nicht täusche, findet man über NMAP-Scans etc. beim Einsatz eines Proxies nicht direkt raus, welche Anwendung dahinter läuft. Das wird vermutlich die ganzen "Billo-Hacker" schon mal fernhalten.
Jemand, der euch (erfolgreich) angreifen will, wird das aber bei einem stinknormalen Proxy ohne WAF-Funktionalität schaffen.
Reverse Proxies (auch ohne WAF) haben immer den Vorteil, dass man sich Public-IPs einsparen kann, da man durch rewriting diverse Dienste über eine einzige, oder einige wenige Public IPs abfrühstücken kann.
Die Server dürfen durchaus ins Internet, aber über definierte Ports und an definierte Zieladressen.
Eine Any-HTTPS Freigabe wie man sie häufig vorfindet sollte man nicht einsetzen.
Der Defender ist gut, der Defender ATP aus der Cloud aber besser. Desweiteren hast du ohne SCCM etc. kein zentrales Management oder Reports.
Bei Defender ATP bzw. Defender for Servers aus dem Microsoft Defender for Cloud, hast du das Managament und Reporting aus der Cloud.
wenn ich mich nicht täusche, findet man über NMAP-Scans etc. beim Einsatz eines Proxies nicht direkt raus, welche Anwendung dahinter läuft. Das wird vermutlich die ganzen "Billo-Hacker" schon mal fernhalten.
Jemand, der euch (erfolgreich) angreifen will, wird das aber bei einem stinknormalen Proxy ohne WAF-Funktionalität schaffen.
Reverse Proxies (auch ohne WAF) haben immer den Vorteil, dass man sich Public-IPs einsparen kann, da man durch rewriting diverse Dienste über eine einzige, oder einige wenige Public IPs abfrühstücken kann.
Die Server dürfen durchaus ins Internet, aber über definierte Ports und an definierte Zieladressen.
Eine Any-HTTPS Freigabe wie man sie häufig vorfindet sollte man nicht einsetzen.
Der Defender ist gut, der Defender ATP aus der Cloud aber besser. Desweiteren hast du ohne SCCM etc. kein zentrales Management oder Reports.
Bei Defender ATP bzw. Defender for Servers aus dem Microsoft Defender for Cloud, hast du das Managament und Reporting aus der Cloud.
Moin,
Wir nutzen seit Jahren ausschließlich auf den Endpunkten den Defender. Die Konfiguration, Überwachung, etc. erfolgt inzwischen über ein Module von ACMP. Auf den Infrastruktur Proxy, Firewall, WAF, etc. nutzen wir dem entsprechend andere Hersteller. Um so auch ein 2 Tier Architektur zu haben. Wie immer eine Frage der Anforderungen, Geldes und Personalressourcen. Betreut sich alles nicht von allein.
Gruß,
Dani
Ein normaler Proxy (z.B. Linux mit Apache) leitet doch auch nur weiter?
Richtig. Ohne Module und wiederkehrender Konfiguration ist der Sicherheitsgewinn minimal. Einziger Vektor der aus meiner Sicht abgefangen wird ist, wenn der Service mit Verbindunganfragen geflutet wird. Dann wird der Reverse Proxy anstatt der Backend Server in die Knie gehen.Wenn ich jetzt eine Firewall habe die WAF kann und den Datenstrom aufbricht, Filtert bzw. scanned, erst dann sehe ich einen Mehrgewinn? Ohne hier SSL Interception zu betreiben sehe ich auch hier wenig sinn.
Die Verbindung muss nicht aufgebrochen werden. Die Verbindung muss an der WAF terminieren. Somit kann diese den Datenstrom vollumfängliche prüfen und baut dann eine neue Verbindung zum Backend Server auf.ine weitere sinnvolle Maßnahme ist in meinen Augen den Server in der DMZ nicht ins Internet zu lassen. Ein Angreifer der eventuell auf das System gekommen ist, kann dadurch selbst keinen Code nachladen. Updates kann ja auch ein WSUS machen, das muss nicht über das Internet sein.
Das gilt für alle Server, egal in welcher Zone dieser steht und wie die Zone heißt. Ein umfangreiches Outbound Firewall gehört heute zu. Am Besten noch mit einem Proxy-Server, damit Malware ohne Proxy Konfiguration gar nicht in Richtung Internet kommt. Wer es noch ausbauen möchte kann mit DNS Blocking als Pi-Hole, Adguard arbeiten. Wenn es größer, professioneller sein soll/muss, führt an Produkten wie Zscaler kein Weg vorbei. Benötigt man zwingend 3rd Party Virenscanner?
Brauch ich Maggi in der Suppe? Wir nutzen seit Jahren ausschließlich auf den Endpunkten den Defender. Die Konfiguration, Überwachung, etc. erfolgt inzwischen über ein Module von ACMP. Auf den Infrastruktur Proxy, Firewall, WAF, etc. nutzen wir dem entsprechend andere Hersteller. Um so auch ein 2 Tier Architektur zu haben. Wie immer eine Frage der Anforderungen, Geldes und Personalressourcen. Betreut sich alles nicht von allein.Gruß,
Dani
Naja - ein Proxly hat Vor- und Nachteile gleichzeitig... Einerseits kannst du natürlich die "üblichen" Verdächtigen schon mal ziemlich einfach zB. mittels Fail2Ban raushauen... Kommt zB. ein Anwender 10x auf die Seite "LoginFailed.html" (wie auch immer die bei dir heisst) lässt du die IP automatisch blocken. Fail2Ban kann ja eben nicht nur bei SSH sowas machen.
Gleichzeitig hast du aber natürlich einen weiteren Angriffspunkt geschaffen... Was passiert denn wenn zB. der Proxy selbst beim Aufruf von "ichBinBoese.php" sofort ne Shell mit Root-Rechten aufreisst?
Ich würde es vermutlich trotzdem machen - einfach aus dem Grund das der erste Fall deutlich häufiger auftreten wird. Denn man bekommt die ganzen Script-Kiddys ja schon schön weg wenn man zB. die üblichen "../cmd.exe" usw. raushaut... Und mir wäre jetzt eher kein Fall bekannt wo jemand legitim diese Datei aufrufen wollte...
Gleichzeitig hast du aber natürlich einen weiteren Angriffspunkt geschaffen... Was passiert denn wenn zB. der Proxy selbst beim Aufruf von "ichBinBoese.php" sofort ne Shell mit Root-Rechten aufreisst?
Ich würde es vermutlich trotzdem machen - einfach aus dem Grund das der erste Fall deutlich häufiger auftreten wird. Denn man bekommt die ganzen Script-Kiddys ja schon schön weg wenn man zB. die üblichen "../cmd.exe" usw. raushaut... Und mir wäre jetzt eher kein Fall bekannt wo jemand legitim diese Datei aufrufen wollte...
Hallo,
"Sophos does not officially support Microsoft Exchange 2016 with WAF. Engineers have tested these settings and verified that the WAF can pass Exchange 2016 in some basic configurations."
https://support.sophos.com/support/s/article/KB-000040209?language=en_US
Wozu dann eine Firewall?
Stefan
"Sophos does not officially support Microsoft Exchange 2016 with WAF. Engineers have tested these settings and verified that the WAF can pass Exchange 2016 in some basic configurations."
https://support.sophos.com/support/s/article/KB-000040209?language=en_US
Wozu dann eine Firewall?
Stefan
Und Securepoint hat scheinbar hat keine zusätzlichen Schutzfunktionen.
https://wiki.securepoint.de/UTM/APP/Reverse_Proxy-Exchange
https://wiki.securepoint.de/UTM/APP/Reverse_Proxy-Exchange
Moin,
Daher könnte ich mir vorstellen, dass die Angst wächst das demnächst die Support Anfragen in die Höhe schnellen. Weil die Admins nur die Hälfte oder gar nichts berücksichtigen haben und der Eindruck entsteht, dass muss ein Bug sein.
Gruß,
Dani
Wozu dann eine Firewall?
klassische Firewall != WAF. Die Funktionalitäten haben die Hersteller vermutlich auf Druck von Kunden nach und nach implementiert. Aber u.a. mit Extended Protection auf Exchange Server gibt es ein paar Dinge sowohl für den Exchange als auch Firewall Admin.Daher könnte ich mir vorstellen, dass die Angst wächst das demnächst die Support Anfragen in die Höhe schnellen. Weil die Admins nur die Hälfte oder gar nichts berücksichtigen haben und der Eindruck entsteht, dass muss ein Bug sein.
Gruß,
Dani
