Server mit ReversProxy auffinden

[Sinowal]

Hi,ich würde gerne mal wissen wie ich einen Server finden kann der mit einem ReversProxy getarnt ist. Es muss ja möglich sein ihn zu finden sonst hätte dieses ja Fatale folgen für das Inet.

 

[Firewire2002]

Es muss ja möglich sein ihn zu finden sonst hätte dieses ja Fatale folgen für das Inet.

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).

 

[Sinowal]

Also ich dachte eher so dann könnte sich das ja viele Kriminelle zu nutzte machen,aber naja welche Möglichkeiten gibt es den Server dahinter zu finden ?

 

[GwenDragon]

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.

 

[Lord Gurke]

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?

 

[Sinowal]

Den Reverse Proxy meine ich

 

[Lord Gurke]

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:

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 OK

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.

 

[Whistler]

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:

HTTP/1.0 200 OK
Date: Fri, 04 Nov 2011 18:25:48 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:27:49 GMT
X-Host: lnxp-2861
X-Robots-Tag: index, follow, noarchive
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 161597
Vary: Accept-Encoding
X-Cache: MISS from lnxp-3954.srv.mediaways.net
X-Cache-Lookup: MISS from lnxp-3954.srv.mediaways.net:91
Via: 1.1 www.spiegel.de, 1.0 lnxp-3954.srv.mediaways.net (squid/3.1.4)

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/1.0 200 OK
Date: Fri, 04 Nov 2011 18:43:57 GMT
Server: Apache
X-Content-Type-Options: nosniff
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Content-Language: de
Vary: Accept-Encoding,Cookie
Last-Modified: Fri, 04 Nov 2011 18:38:22 GMT
Content-Encoding: gzip
Content-Length: 11382
Content-Type: text/html; charset=UTF-8
X-Cache: MISS from sq75.wikimedia.org
X-Cache-Lookup: MISS from sq75.wikimedia.org:3128
X-Cache: MISS from amssq39.esams.wikimedia.org
X-Cache-Lookup: MISS from amssq39.esams.wikimedia.org:3128
X-Cache: MISS from amssq31.esams.wikimedia.org
X-Cache-Lookup: MISS from amssq31.esams.wikimedia.org:80
Connection: keep-alive

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.

 

[Lord Gurke]

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.

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...

 

[Karl34]

Er meint bestimmt ein Setup um den backend Server zu verstecken. Ala Kino.dumm
Ja das ist möglich , aber nicht sehr einfach zu konfigurieren.
Kenne einen der sowas einsetzt, soll viel arbeit sein. Aber läuft 1A.

 

[Whistler]

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.

 

[Karl34]

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.