Server mit ReversProxy auffinden
- Thread starter Sinowal
- Start date
Firewire2002
Registered User
Bitte was? Diese fatalen Folgen musst nun bitte näher erklären.
Ein vernünftiges Reverse-Proxy Setup würde dir nie sein Backend offenbaren. Somit nein, die Server dahinter findest du nur selten raus (oder wenn der Admin schlampig gearbeitet hat).
GwenDragon
Registered User
Wer anonym surfen will, kann das und tut das auch - egal ob kriminell oder nicht.
Du wirst es nicht rausbekommen, notfalls blockiert du eben solche Proxies.
Du wirst es nicht rausbekommen, notfalls blockiert du eben solche Proxies.
Lord Gurke
Nur echt mit 32 Zähnen
ReverseProxy !== (Forward)Proxy
Reverse Proxy:
Du rufst z.B. heise.de auf. Deine Anfrage geht an den ReverseProxy, der diese Anfrage dann an einen oder mehrere Server weiterleitet. Das dient dem Schutz der eigentlichen Backend-Server und der Lastverteilung.
Das soll nichts verschleiern oder das Internet abstürzen lassen, das ist eine praktische Sache.
(Forward-)Proxy:
Ein krimineller oder ich surfen z.B. über einen in .nl stehenden Proxy-Server auf Youtube um diese hirnlosen GEMA-Sperren zu umgehen.
Das kann man dazu benutzen seine Identität zu verschleiern und/oder kriminelle Dinge zu tun, impliziert aber nicht dass man das System identifizieren kann, was die Anfrage durch den Proxy geschickt hat.
In meinem Fall mit .nl und Youtube ist das sogar ganz gut, dass man nicht sieht dass die Anfrage ursprünglich aus .de kam...
Also: Welchen Proxy-Typ meinst du jetzt?
Reverse Proxy:
Du rufst z.B. heise.de auf. Deine Anfrage geht an den ReverseProxy, der diese Anfrage dann an einen oder mehrere Server weiterleitet. Das dient dem Schutz der eigentlichen Backend-Server und der Lastverteilung.
Das soll nichts verschleiern oder das Internet abstürzen lassen, das ist eine praktische Sache.
(Forward-)Proxy:
Ein krimineller oder ich surfen z.B. über einen in .nl stehenden Proxy-Server auf Youtube um diese hirnlosen GEMA-Sperren zu umgehen.
Das kann man dazu benutzen seine Identität zu verschleiern und/oder kriminelle Dinge zu tun, impliziert aber nicht dass man das System identifizieren kann, was die Anfrage durch den Proxy geschickt hat.
In meinem Fall mit .nl und Youtube ist das sogar ganz gut, dass man nicht sieht dass die Anfrage ursprünglich aus .de kam...
Also: Welchen Proxy-Typ meinst du jetzt?
Lord Gurke
Nur echt mit 32 Zähnen
Mit dem kann man nur bedigt kriminelle Dinge anstellen, denn der leitet (wie immer unter der Prämisse, dass der Administrator von dem Ding weiß wie er das Teil konfigurieren muss) nur Anfragen an fest vorgegebene Server weiter.
Mir fällt spontan nicht ein, wie sich das mit krimineller Energie ausnutzen ließe, vielleicht fehlt mir aber auch die Phantasie.
Egal, die einzig sichere Methode den originalen Server dahinter zu finden ist: Sieh dir die HTTP-Header an.
Wenn es nicht explizit abgeschaltet ist oder gefiltert wird, werden sich die Proxies mit dem "Via"-Tag verewigt haben - Beispiel SPON:
Aber um es direkt vorwegzunehmen:
Ein funktionierendes Reverse-Proxy-Setup ist nichts, was man "mal eben" mit apt-get install großartigerreverseproxymitvollanonymisierung zum Laufen bringt.
In nicht wenigen Fällen dient der Proxy zeitgleich als vorgelagerte L7-Firewall.
Die Server mit dem eigentlichen Inhalt stehen i.d.R. in einem LAN dahinter, nutzen private IP-Adressen und sind aus dem Internet nicht erreichbar.
Mir fällt spontan nicht ein, wie sich das mit krimineller Energie ausnutzen ließe, vielleicht fehlt mir aber auch die Phantasie.
Egal, die einzig sichere Methode den originalen Server dahinter zu finden ist: Sieh dir die HTTP-Header an.
Wenn es nicht explizit abgeschaltet ist oder gefiltert wird, werden sich die Proxies mit dem "Via"-Tag verewigt haben - Beispiel SPON:
Code:
Date: Fri, 04 Nov 2011 18:35:57 GMT
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231054)/Tomcat-5.5
Cache-Control: max-age=120
Expires: Fri, 04 Nov 2011 18:37:57 GMT
X-Host: lnxp-3734
X-Robots-Tag: index, follow, noarchive
Content-Type: text/html;charset=ISO-8859-1
Vary: Accept-Encoding
Content-Encoding: gzip
Age: 13
X-Cache: HIT from lnxp-3951.srv.mediaways.net
X-Cache-Lookup: HIT from lnxp-3951.srv.mediaways.net:80
Via: 1.1 www.spiegel.de, 1.0 lnxp-3951.srv.mediaways.net (squid/3.1.4)
200 OKAber um es direkt vorwegzunehmen:
Ein funktionierendes Reverse-Proxy-Setup ist nichts, was man "mal eben" mit apt-get install großartigerreverseproxymitvollanonymisierung zum Laufen bringt.
In nicht wenigen Fällen dient der Proxy zeitgleich als vorgelagerte L7-Firewall.
Die Server mit dem eigentlichen Inhalt stehen i.d.R. in einem LAN dahinter, nutzen private IP-Adressen und sind aus dem Internet nicht erreichbar.
Einen gut getarnten Reverse Proxy kann man nicht erkenne, da er ja im Prinzip dieselben Informationen liefern kann wie ein direkter Webserver.
Oftmals merkt man nur an Fehlermeldungen (wenn z.B. das Backend nicht erreichbar ist), daß man es mit einem Proxy oder Accelerator zu tun hat. Tendenziell findet man Reverse Proxies bei hochverfügbaren oder sehr stark frequentierten Angeboten.
Allerdings besteht in der Regel überhaupt kein Anlaß, das Vorhandensein eines Reverse Proxy überhaupt zu verbergen - wozu auch.
Hier ist mal ein Beispiel für einen solchen "fatalen" proxy:
Wie Du siehst, ist die Anfrage von lnxp-2861.srv.mediaways.net beantwortet worden.
Dieser Server hat die RFC-1918-Addresse 10.229.0.92 und ist damit im Internet nicht erreichbar.
Weitergeleitet hat die Anwort lnxp-3954.srv.mediaways.net (10.228.9.112, mit einen Squid 3.1.4 als Cache) und schlußendlich www.spiegel.de (195.71.11.67), vermutlich ein Loadbalancer.
Hier noch ein anderes Beispiel:
Auch hier sind mehrere Squids als Reverse Proxy (sq75 steht im Tampa in Florida, amssq31/39 in Amsterdam) hintereinandergeschaltet.
Hier ist das ganze Setup übrigens weitergehend dokumentiert.
Grund ist ganz einfach, daß bestimmte Daten (etwa die Hauptseite) immer wieder abgerufen werden und es einfach Verschwendung wäre, jedesmal in Mediawiki die Seite neu rendern zu lassen und alle damit zusammenhängenden Datenbankoperationen auszulösen.
Das muß man freilich, wenn sich die Seite geändert hat oder man sie z.B. gerade editieren will, nicht aber für die x-fache Anzeige.
Mir erschließt sich noch nicht so ganz, von welchen fatalen Folgen Du eigentlich sprichst.
Sicherlich ist es so, daß diejenigen, die sich ein solches Setup leisten können, im Vorteil gegenüber uns kleinen Serverbetreibern sind, die eben wirklich immer den Apache, PHP und damit viel CPU-Zeit zum Seitebaufbau einsetzen müssen und damit auch mit langsameren Seiten getraft sind, aber "fatal" würde ich das nun wirklich nicht nennen.
Oftmals merkt man nur an Fehlermeldungen (wenn z.B. das Backend nicht erreichbar ist), daß man es mit einem Proxy oder Accelerator zu tun hat. Tendenziell findet man Reverse Proxies bei hochverfügbaren oder sehr stark frequentierten Angeboten.
Allerdings besteht in der Regel überhaupt kein Anlaß, das Vorhandensein eines Reverse Proxy überhaupt zu verbergen - wozu auch.
Hier ist mal ein Beispiel für einen solchen "fatalen" proxy:
http://www.spiegel.de/ said:
Wie Du siehst, ist die Anfrage von lnxp-2861.srv.mediaways.net beantwortet worden.
Dieser Server hat die RFC-1918-Addresse 10.229.0.92 und ist damit im Internet nicht erreichbar.
Weitergeleitet hat die Anwort lnxp-3954.srv.mediaways.net (10.228.9.112, mit einen Squid 3.1.4 als Cache) und schlußendlich www.spiegel.de (195.71.11.67), vermutlich ein Loadbalancer.
Hier noch ein anderes Beispiel:
http://de.wikipedia.org/wiki/Wikipedia:Hauptseite said:
Auch hier sind mehrere Squids als Reverse Proxy (sq75 steht im Tampa in Florida, amssq31/39 in Amsterdam) hintereinandergeschaltet.
Hier ist das ganze Setup übrigens weitergehend dokumentiert.
Grund ist ganz einfach, daß bestimmte Daten (etwa die Hauptseite) immer wieder abgerufen werden und es einfach Verschwendung wäre, jedesmal in Mediawiki die Seite neu rendern zu lassen und alle damit zusammenhängenden Datenbankoperationen auszulösen.
Das muß man freilich, wenn sich die Seite geändert hat oder man sie z.B. gerade editieren will, nicht aber für die x-fache Anzeige.
Mir erschließt sich noch nicht so ganz, von welchen fatalen Folgen Du eigentlich sprichst.
Sicherlich ist es so, daß diejenigen, die sich ein solches Setup leisten können, im Vorteil gegenüber uns kleinen Serverbetreibern sind, die eben wirklich immer den Apache, PHP und damit viel CPU-Zeit zum Seitebaufbau einsetzen müssen und damit auch mit langsameren Seiten getraft sind, aber "fatal" würde ich das nun wirklich nicht nennen.
Attachments
Lord Gurke
Nur echt mit 32 Zähnen
Du vergisst da einen nicht unwichtigen Punkt: Ich habe damit auch die Möglichkeit, mit dem Proxy Anfragen herauszufiltern, die garnicht erst ans Backend weitergeleitet werden sollen.
Wenn ich Squid als Proxy und den Apache httpd als Webserver verwende und jemand will eine Sicherheitslücke im Apache ausnutzen, kann ich bestimmte Anfragen auf dem Squid filtern, der ja nicht dafür anfällig ist (siehe diese "Range"-Header-Geschichte).
Ein Angreifer müsste zwei Sicherheitslücken in zwei unterschiedlichen Programmen auf zwei unterschiedlichen Systemen zur selben Zeit ausnutzen - und die Wahrscheinlichkeit, dass dies dann auch noch gelingt ist ja nun wirklich niedriger als die Bonität Griechenlands
Gut, wenn jetzt die Sicherheitslücke im Squid ist hilft mir das nur bedingt weiter...
Wie soll das denn funktionieren? Den Proxy kann man ja nicht verstecken, der ist öffentlich bekannt.
Wohin er die Anfragen weiterleitet, kann man mit Hilfe des Hosters sehr leicht herausfinden.
Dazu muß man den Proxy noch nicht einmal beschlagnahmen, es reicht, die Datenströme zu verfolgen.
Wenn der Hoster nicht kooperieren will (und die Gesetzgebung des Landes ihn auch nicht zwingen kann) ist es erst recht egal, dann kann ich auch gleich den Server dort platzieren.
Wohin er die Anfragen weiterleitet, kann man mit Hilfe des Hosters sehr leicht herausfinden.
Dazu muß man den Proxy noch nicht einmal beschlagnahmen, es reicht, die Datenströme zu verfolgen.
Wenn der Hoster nicht kooperieren will (und die Gesetzgebung des Landes ihn auch nicht zwingen kann) ist es erst recht egal, dann kann ich auch gleich den Server dort platzieren.
Wie das genau Konfiguriert wird kann ich dir nicht sagen.
Weiss nur das es sehr gut funktionieren soll.
Wird der Reverse Proxy in den meisten fällen nginx beschlagnahmt, wird einfach ein neuer davor geschaltet. Die daten sind ja nicht beschlagnahmt da sie auf dem Backend liegen.
Weiss nur das es sehr gut funktionieren soll.
Wird der Reverse Proxy in den meisten fällen nginx beschlagnahmt, wird einfach ein neuer davor geschaltet. Die daten sind ja nicht beschlagnahmt da sie auf dem Backend liegen.