Hallo ihr ...

Ich stehe da vor einem Problem, dass im allgeimen Netzwerkbereich anfängt und bei Perl aufhört. Hat vielleicht jemand von euch einen Tipp?

Folgends: (Prefix) Wähle ich einen untransparenten Proxyserver ($proxy) für folgendes:

$ua = LWP::UserAgent->new;
$ua->agent('Irgendwas') ;
$ua->timeout(15);
$ua->proxy('http',$proxy);
$request = HTTP::Request->new('GET', $url);
$request ->header( 'Referer' => $referer);
$response = $ua->request($request, $file_temp);

Wird die URL per Proxy requested und als File gespeichert. Soweit so gut. Prüfe ich dass mit der URL: www.myip.name, dann stimmt die remote IP mit der IP des Proxyservers überein und "HTTP_X_Forwarded_for" ist logischerweise nicht gesetzt. (anderes bei transparentem Proxy)

Jetzt zum Problem: Ich möchte gern mehrere Proxies kaskadieren - ähnlich eines Proxychains. Mindestens zwei sollen es sein.

Das geht natürlich nicht über das LWP Modul -> aber hat jemand eine Idee ob sowas irgendwo Perlnah realisiert wurde? CPAN läßt mich leider im Stich :( Für C++ finde ich eine Lösung die Funktionieren könnte, aber ich brauche reinen Perl-Code.

Zweite Frage: Sofern man Proxies kaskadiert, was passiert mit dem "HTTP_X_Forwared_for" Tag? Wird zum Beispiel bei transparentem Proxies die lokale IP meines Clients "durchgeschleift"? Oder bekommt jeder Proxie den IP-Tag mit der IP vom vorhergehenden Proxyserver?

Worauf will ich hinaus? Konstellation: Client -> Anonymer Proxy -> Transparenter Proxy -> Server ... Was zeigt der "HTTP_X_Forwarded_For" Tag beim Transparenten Proxy an? *Nichts*, oder die IP vom *Anonymen Proxy*?

Dritte und letzte Frage: Sollte die Kaskadierung nicht zu realisieren sein, kann man den "HTTP_X_Forwarded_for" Tag anderweitig spoofen? bzw. die Pakete im Core derartig manipulieren, dass ein Transparenter Proxy diesen Tag als *emty* oder *faked ip* erhält?

Lieben Dank

Janice

X-Forwarded-For ist kein Standard-HTTP-Header und es ist auch kein Pflichtheader, der von Proxys eingesetzt wird. Es gibt bestimmt Proxysoftware, bei denen dieser Header nicht erzeugt wird oder ausgeschaltet werden kann.

Jeder Proxy kann an Proxy-Headern herum maninpulieren.
Es existieren meines Wissens folgende:

So, hätte gern schon früher ein Update gepostet - aber konnte mich nicht registrieren.

Also: Ja, ich bin bezüglich des Proxychains fündig geworden ->
LWP::Protocol::http::SocksChain <- von Igor Okunev. Ist eine "Erweiterung" von Net-SC und erledigt das ganze Proxy-Kaskading fast von selbst.

Um das "X_Forwarded_for" field im HTTP Header zu *manipulieren* genügt HTTP::Headers (header, push_header,remove_header). Das selbe funktioniert natürlich auch für andere Prroxy-  relevante Felder wie "Via". Natürlich könnt ihr aber auch einen eigenen Proxy Server dazwischen Schalten und dort die Header manipulieren.

Der X_Fwd.Tag wird auch von transparenten Proxy-servern unterschiedlich gehandhabt. In der Regel wird wie erwartet der Tag durchgereicht. Hier kann man mit der Header-Manipulation ansetzen:

$h = HTTP::Headers->new;
$h->header( MIME_Version =>'1.0',User_Agent   =>  $browser,VIA => $via,X_Forwarded_for => $x_forwarded_for,Referer => $referer);
$request_ad = HTTP::Request->new('GET', $adlink, $h);

In der Regel zeigt der letzte Proxy in der Kette dann die "manipulierte" Ip als X_Fwd_for: an -> aber Vorsicht -> einige Proxies verstehen den Tag als Listenfeld und hängen jeden Proxy-Hopp seperat ans Feld an oder extrahieren die Source-IP des Requestes etwas genauer.  

Beipiel:
Firefox -> trans.Proxy -> ipchecker.com
(ip checker zeigt x_fwd_for: meine IP)

Perl Skript + manipulierter Header -> Proxy -> ipchecker.com
(ip checker zeigt x_fwd_for: manipulierte IP, meine IP)

Es gibt übrigens auch Tr-Proxies - die sich eher wie anonyme verhalten und in der Regel kein X_Fwd_for Feld weitergeben -> sich aber völlig anderes verhalten sobald ihr einen eingenen *manipulierten* Header verwendet. Sie geben dann den X_Forw_Tag weiter, da sie meinen, dass vor ihnen nur ein weitere Proxy hängt.

Beipiel:
Firefox -> trans.Proxy -> ipchecker.com
(ip checker zeigt x_fwd_for: *nichts*)

Perl Skript + manipulierter Header -> trans. Proxy -> ipchecker.com
(ip checker zeigt x_fwd_for: manipulierte IP)

Dass ist natürlich manchmal unnötig -> da der IPChecker dann weiß, dass ihr von einem Proxy kommt. Hättet ihr den Header nicht gesendet meint der ipchecker, dass die "Trans"-Proxy-IP eine tatsächliche Client Adresse ist.

Fazit: Ihr solltet bevor ihr soetwas nutzt immer gegen eine ipcheck Website prüfen - bevor ihr das reale Ziel abruft. Dabei aber das Via und X_Forwarded_for Feld weglassen oder über remove_header entfernen. Taucht dann bei Check eure Client-IP auf -> seit ihr eben nicht anonym und ihr prüft selbiges nocheinmal mit gefakten Header-Feldern. Möglicherweise taucht jetzt eure IP beim IPChecker nicht mehr auf, sondenr nur die Faked IP.  

Werden die relevanten Felder von vornherein als *leer* angezeigt, dann seit ihr anonym und es ist unnötigt den Header zu manipulieren, da ihr zwar auch dann anonym mit gefakter IP seit -> aber eben manchmal unnötigerweise die Proxy-IP eben als "Proxy"-IP entarnt werden kann. Manchmal ist es eben sinnvoll, wenn der Remote Server nicht weiß, dass ihr über einen Proxy kommt.

Nun, sei's drum. Natürlich kann man das ganze Dilema auch umschiefen indem man von Anfang an auf Anonyme Proxies setzt -> aber auch hier solltet ihr eben im Einzelfall prüfen ob ihr wirklich anonym seit und des weiteren sind für manche Vorhaben die erhältichen Anonymen-Proxy-Listen leider unzureichend ...

Wofür dies auch immer zu grbrauchen sein mag -> denkt an das Proxychain Modul! Dann kann auch nicht mehr viel schiefgehen.