[HaBo]

Squaiacoda

Anzeige

Viele von euch haben sicherlich die neue c't gelesen, die Titelgeschichte dreht sich um Anonymität im Netz. Nun stellen sich für mich einige Fragen; ich lese eigentlich schon sehr lange Zeit in diesem sowie in den zwei Vorgänger-Foren mit und muss feststellen, daß sie zum Teil im krassen Widerspruch zu einigen Inhalten der diversen Artikel stehen. So heißt es dort auf Seite 128:

Bei Studium aller Beiträge zum Thema "Proxy" und "Anonymität" war die einhellige Meinung, "Proxies" (besonders http-Proxies) seien alles andere als anonym oder sicher; der Webserver bekäme ohnehin die IP-Adresse des Netz-Surfers, da sie im TCP-Header nicht geändert wird.
Der Webserver schickt nun seine HTML-Seite an genau jene IP-Adresse, somit gäbe es keine Anonymität. Etwas anders sähe es bei "Socksproxies" aus, aber warum werden diese dann nicht explizit im c't Artikel erwähnt? Hier wird eigentlich überhaupt keine Terminologie angeboten.
Der Leiter der Arbeitsgruppe Internet des LKA Berlin erklärt, daß die Software JAP seine Arbeit erschwert, obwohl im ersten Board "Vergiss JAP" zu lesen ist. Was denn nun?

Wer besitzt jetzt mehr Glaubwürdigkeit? Eine (vermeintlich?) seriöse Computerzeitschrift oder ein Webforum?

Squaiacoda

Aber so ist es hier zu lesen

http://www.prettywoman-online.de/boa...ML/000084.html

Der Moderator antwortet darauf:

"Im groben ist das ungefähr richtig, was du schreibst."

Entweder haben die beiden unrecht oder du.

sticky bit

Also ersten ist das TCP-Packet, oben TCP-Teil genannt in dem IP-Packet, oben IP-Teil genannt, verpackt und es folgt nicht dem TCP-Packet ein IP-Packet (ein TCP-Packet wirst du ohne das einpacken in ein IP-Packet auch schwer routen können ). Im TCP-Packet ist dann wiederum das HTTP-Packet verpackt und im HTTP-Packet der eigentliche Content (HTML-Sourcecode, und was man halt alles so über HTTP ziehen kann also eigentlich alles...). Soviel grob zur Packettechnischen Hirachie.
Wenn du nun einen HTTP-Proxy benutzt, Cachingfunktionen (das heisst der Proxy liefert nicht das eigentliche Original vom Server sondern zwischengespeicherte Daten, u. A. aus Performance Gründen) lass ich jetzt mal weg, zu mal er Definitionsmässig nicht zu einem HTTP-Proxy dazu gehören muss (aber meisst in einem Atemzug genannt wird...), geschieht folgendes:
Dein Client (der Netzwerk technische Teil in deinem Browser oder Downloadmanager z. B.) öffnet eine TCP Verbindung zu dem Proxy. Die TCP Packete werden per IP da hingeroutet übrigens (deshalb das Verpacken), steht die Verbindung sendet der Client weiter TCP-Packete in die er Stücke weise das HTTP-Packet reinbaut, das den Request enthält. Der Proxy nimmt diesen Request an und untersucht ihn. Anhand der Header-Daten des HTTP-Packetes des Requests kann er dann, sofern alles stimmt den eigentlichen "ursprünglichen" Server ermitteln und macht seinerseits die selbe Prozedur (TCP-Verbindung erstellen, Request senden, ) noch mal und verhält sich also wie ein Client zu dem eigentlichen Server. Wenn er die Antwort des Servers empfangen hat kappt der Server die TCP-Verbindung und der Proxy schickt die Response wieder zu deinem Browser und kappt anschliessend nun diese IP-Verbindung, er verhält sich deinem Browser gegenüber also wie ein Server (ist n kleiner Hacken drinne, die Request-Line muss bei ner Anfrage bei nem Proxy anders sein, weil der den kompletten URL braucht nicht nur den Pfad wie ein ursprünglicher Server und und es gibt u. U. andere Header-Direktive die gesetzt sein müssen oder nicht gesetzt sein dürfen / sollten, aber das sind Details...).
Also haben wir folgendes Schema:
Es sind also zwei völlig verschiedene Netzwerkverbindungen die bei so einer Requestline zustande kommen und da die IP-Adresse in den IP-Packeten (man höre und staune...) notiert ist wird der ursprüngliche Client bei einer solchen Aktion nichts von der IP-Adresse des ursprünglichen Servers zu Gesicht bekommen (zumindest nicht in den IP-Headern an anderer stelle kann es vorkommen dazu gleich mehr...) und der ursrüngliche Server nicht die IP-Adresse des Servers, weil der Proxy alles bis auf das HTTP-Packet auspackt das interpretiert uns für seinen Request sogar ein neues kreieren muss, er muss also sein HTTP-Packet mit dem Request auch wieder einpacken und generier so völlig neue TCP- und dann IP-Packete, in denen er als seine Adresse als Source angibt (sonst würds auch wenig bringen weil die Antwort des Servers sonst irgendwo hingeht wo sie nicht erwartet wird und niemand wird sie je sehen (im Regelfall, Aussnahmen werden nicht bhandelt um die Uhrzeit... *g*). Und zum Client wird er natürlich auch als Source-Adresse seine angeben, der Proxy, weil sonst kommt von dem ja nichts an (TCP erfordert das mehrmalige hin und hersenden (aber nicht des gleichen!) von TCP-Packeten, auch wenn der eigenliche Content nur in eine Richtung transferiert wird um zu wissen von wem was kommt muss deshalb in den IP-Packeten die Absender Adresse vermerkt sein...). Auf IP Ebene wissen also der Client nur von dem Proxy und der Server auch nur von dem Proxy, der Proxy weiss von beiden...
Nu gibt es aber natürlich Möglichkeiten wie diese Unsichtbarkeit brechen kann (auf anderer Ebene nämlich). Erstens weiss der Client eh von dem Server, er gibt dem Proxy ja die Adresse, zwar meisst in Form von einem Hostnamen in einem URL, aber man könnte so auf der Clientseite natürlich auch die IP-Adresse des Servers bekommen...
Und der zweite Punkt liegt am Proxy. Zum einem können die Dinger können natürlich loggen was sie so treiben und einfach aufzeichen welche Requests von wem sie an wen geschickt haben und wer sie intiert hat (der Proxy kennt ja beide, auch IP-Adressmässig), so liesse sich im Nachhinein dursch studieren der Logdatei wieder auslesen wer wo "gesurft" ist. Andererseits kann der Proxy die HTTP-Packete ja gestalten wie er will (wenn er funktionier hällt er sich an Regeln, aber theorethisch kann er auch Rotz hin und her schicken...) und auch zusätliche Header Einträge in diese einfügen, wo bei dem X-Forwarded (X- hat sich so als Präfix eigebürgert, für nicht offizielle Header oder Format-Direktiven in Text basierten Protokollen, Forwarded sollte bei genug englisch Kenntnissen den Sinn erkennen lassen, es sei aber gesagt, das man auch theorethisch X-Weitergleitet oder X-Hier-Haste oder etwas in der Art verwenden könnte, es ist ja kein offiziell festgelegter Heade!) Header wären, in diesen kann der Proxy natürlich eintragen was er will, auch die IP Adresse der jeweiligen Ursrungs Instanzen, des Server, bzw des Clients. Die IP-Adresse ist dann also HTTP-Pakete verborgen. Diese spielt zwar für das Routing keine Rolle (könnte auch ne falsch drin stehen, wenn die richtige im IP-Header ist, dann kommt trotzdem alles ordnungsgemäss an...) kann also auch nicht von der IP Facility des Client bzw. des Servers geloggt werden, aber natürlich von dem Part der Software, die für HTTP zuständig ist. Und aus ist mit der Anonymität...
Übrigens @Damein, dieser Header dient sicher nicht dazu, das der eigentlich Server die Antwort dann direkt an den eigentlichen Client schickt. Das geht nicht (TCP mässig), ausser auf dem Clientrechner wartet ein Server auf die Antwort des eigentlichen Servers, was aber nicht Bestandteil von HTTP ist, oder der Server würde seine IP-Adresse spoofen (inkl. das Erraten der richtigen Sequenz...) und sich als der Proxy ausgeben (der dann am Ende mit ner halb offenen Verbindung in die Röhre guckt...), was auch nicht in HTTP vorgesehen ist...

Literatur:
http://www.ietf.org/rfc/rfc0791.txt (IP)
http://www.ietf.org/rfc/rfc0793.txt (TCP)
http://www.ietf.org/rfc/rfc1945.txt (HTTP/1.0)
http://www.ietf.org/rfc/rfc2616.txt (HTTP/1.1)

Rushjo

So, jetzt sage ich auch mal noch was dazu!!!!

1. @Squaiacoda
Wir hatten vor kurzem das Thema, hier !

2. @Damien

Nobody is perfect, und dabei schliesse ich mich mit
ein!
Weiter unten im Posting habe ich übriges Folgendes
geschrieben!

Und das war die Diskussionsgrundlage für die
fehlende Anonymität!!!! Wenn Server die angeforderten
Daten nur aufgrund der IP im Header unter Vernach-
lässigung der "echten" IP im TCP-Teil verschicken,
dann tritt der eigene Rechner natürlich nicht in
Erscheinung! Logisch!!! (--> ähnelt ein bißchen
Deinen Ausführungen?! )
Mit Hilfe eines Packet-Sniffers dürfte mal aber auf dem Packet trotzdem die "echte" IP extrahieren können!?!
Wie gesagt, es ist nur eine Frage des Aufwandes und
zum Beispiel bei einem "Honeypot" kannst Du davon
ausgehen, das hier eventuell der maximale Aufwand
getrieben wird, inklusive Mitsniffen der Pakete etc.

MfG Rushjo

Squaiacoda

Erstmal danke für den umfangreichen Text, hab soeben (leider jetzt erst, ja, ich benutz in Zukunft die Suchfunktion ;-)) einen Thread entdeckt, der mir auch einige Fragen beantwortet

http://www.hackerboard.de/thread.php?threadid=2866&sid= edit: Rushjo war schneller

Mir stellt sich allerdings die Frage, wie man in Zukunft mit Beiträgen der genannten Art umgehen soll, wenn offensichtlich nicht mal die Moderatoren Ahnung haben und nur Unsinn erzählen.

Rushjo

@Squaiacoda

Ich habe doch schon oben geschrieben

Manche wissen halt mehr und andere lernen noch
und jeder von Uns allen lernt jeden Tag!!! Desweiteren
ist der Thread schon älter als 1,5 Jahre!

MfG Rushjo

Tec

Das waren eben noch Zeiten damals!

Am besten nur noch die Such-Funktion für dieses Board nutzen.