Gecloakte Seiten enttarnen - Surfen mit einer IP von Google

Beitrag von **ismap** » 06.01.2004, 16:24

Zitat:

sowohl über die Google-IP als auch über das spamblog-Tool werden Dateien angezeigt, wie sie bei Google im Cache liegen

Im diesen fall gibt es gar nicht im google cache. Diese Tool zeigt nur was eine Google spider sehen wird. Es ist keine cache version. Google hat doch die no-cache/noarchive respektiert.

Die Seite, die über das Tool angezeigt wird, ist eine gecachte Seite!!!! Ich kann es dir ganz einfach zeigen: Nimm von der Seite https://www.jeans.otto-angebote.de/6340 ... rock_x.htm irgendeinen der vorhandenen Links.
Probiere diese Seiten mal mit dem Tool - Du wirst redirected.
Warum sollten die Ersteller der Seiten die Jeansrock-Seite anzeigen lassen für das Tool/ die ProxyIPs, und die anderen Seiten nicht (die anderen werden alle redirected)??!!!???
ES IST EIN GOOGLE-CACHE!!!!

von **Anzeige von ABAKUS** »

Hochwertiger Linkaufbau bei ABAKUS:

Google-konformer Linkaufbau
nachhaltiges Ranking
Linkbuilding Angebote zu fairen Preisen
internationale Backlinks

Wir bieten Beratung und Umsetzung.
Jetzt anfragen: 0511 / 300325-0

Beitrag von **Southmedia** » 06.01.2004, 16:59

Muss man es erst mit Serverlogs beweisen...

Ich habe auf meinem Homeserver (jpiotrowski.homeip.net) gerade eine "google.htm" angelegt.

Aufruf von "https://jpiotrowski.homeip.net/google.htm"

Code: Alles auswählen

80.139.80.67 - - &#91;06/Jan/2004&#58;16&#58;55&#58;07 +0100&#93; "GET /google.htm HTTP/1.1" 200 28 "-" "Mozilla/4.0 &#40;compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322&#41;"

Aufruf von "https://216.239.37.92/gvps?vnum=1&url=h ... google.htm"

Code: Alles auswählen

216.239.37.5 - - &#91;06/Jan/2004&#58;16&#58;55&#58;36 +0100&#93; "GET /google.htm HTTP/1.0" 200 28 "-" "Mozilla/4.0 &#40;compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322&#41;"

Die anfragende IP ist also jeweils eine andere. Einmal meine T-Online-IP (80...) und einmal die von Google (216...). Auch hatte die google.htm zwischen meinen beiden Aufrufen keinen Besuch vom Googlebot, es kann also keine Chacheversion geben.

Beitrag von **Southmedia** » 06.01.2004, 17:02

Zu deiner Beobachtung bei den Pages von Otto, ich denke mal Abakus ist mittlerweile recht bekannt, vielleicht hat eprofessional einfach reagiert und die IP aus dem Cloakingscript rausgenommen. Vielleicht lesen sie ja nun auch diesen Beitrag hier...

von **Anzeige von ABAKUS** »

Beitrag von **ismap** » 06.01.2004, 17:03

Ja, die unterschiedliche IP ist ja gerade der Trick an dem Tool...216.239.37.5 ist eine Google-IP, die gecloakte Seiten als "Original" anzeigt und eben nicht redirected wird, weil es eine Google-IP ist...das ist so das Pinzip von "IP-Cloaking"....
Nur meine Frage bleibt: Warum wird die "Jeansrock"-Seite angezeigt, aber die anderen Seiten werden redirected? Die werden wohl kaum für jede Seite einzeln die IPs aussperren?!?!

Beitrag von **Southmedia** » 06.01.2004, 17:11

ismap, ich hab den Proxy "gefunden", weiss also dass es um die IP geht

Zu deiner Frage: Keine Ahnung. Proxies nehmen sich manchmal das Recht Seiten zwischenzuspeichern, weiss nicht inwieweit das bei Google so ist. Oder vielleicht will Eprofessional uns einfach den Spaß erhalten ihre eine Jeansrock-Page anzukucken, wer weiss.

Beitrag von **ismap** » 06.01.2004, 20:55

Oder vielleicht will Eprofessional uns einfach den Spaß erhalten ihre eine Jeansrock-Page anzukucken, wer weiss.

Ich denke nicht, das eprofessional sich hier einen Joke mit uns macht. An deren Stelle hätte ich im Moment genau ganz anndere Sorgen.

Zu deiner Frage: Keine Ahnung. Proxies nehmen sich manchmal das Recht Seiten zwischenzuspeichern, weiss nicht inwieweit das bei Google so ist.

Aber es scheint so, als stimmst Du mir zu: es ist ein CACHE, kein Proxy!
...und genau das finde ich bedauerlich: Google meint mal wieder, Gott spielen zu dürfen und sich über klare Anweisungen hinwegsetzen zu können...
Im Prinzip ist das genau so eine Sch**** wie ein Robot, der sich nicht an die robots.txt hält. Normalerweise geht sowas in meine htaccess und wird ins byte-nirvana umgelenkt, nur dazu ist Google dummerweise zu sehr in der Monopol-Macht-Position...naja, bald ist Yahoo wieder eine Macht auf dem Markt und MSN soll es ja auch bald geben....

Beitrag von **Southmedia** » 06.01.2004, 21:13

Nein ich stimme dir nicht zu.

Die Seiten kommen nicht aus dem Cache wie jemand oben sagte, der Cache ist nicht der des Googlebots der Seiten für die Ergebnisse spidert! Das ist wichtig!

Es kann sein dass der Proxy die Seiten cached, das ist eine der Grundfunktionen eines Proxies (machen die von T-Online zB auch teilweise). Inwieweit das bei diesem von Google der Fall ist weiss ich nicht und ich hab auch nicht die Zeit es nachzuprüfen.

Google hält sich soweit ich sehe an die Spielregeln.

Beitrag von **bugscout** » 06.01.2004, 21:18

moin ismap,

wenns ein google cache ist, dann dürftes du, wenn du dir eine seite test.html baust und die mit https://216.239.37.92/gvps?vnum=1&url=h ... /test.html aufrufst, nichts sehen, da die ja nicht im google cache liegen kann.

grüsse

Beitrag von **bugscout** » 06.01.2004, 21:30

moin Southmedia,

proxy ist unwahrscheinlich, da die seiten ja gar nicht gefunden werden sollen.
sonst müssten ja auch die anderen seiten im proxy-cache zu finden sein

gehe eher davon aus, dass sies gemerkt und den jeansrock dringelassen haben.

im moment funktioniert https://216.239.37.92/gvps?vnum=1&url= bei mir nicht

grüsse

Beitrag von **ismap** » 07.01.2004, 07:18

Moin,
@southmedia: stimmt, es ist nicht <b>der</b> Cache des Googlebots bzw. der GoogleSERPs, es ist ein eigenständiger ProxyCache. Und der hält sich nicht an die Spielregeln!

@bugscout: leider geht da im Moment gar nix ... da kommt nur ein lockeres "Server nicht gefunden" zurück. Schade. Aber mein Test wäre: seite schreiben, per Tool/IP testen, Seite editieren und nochmal testen. Jetzt der spannende Moment: zeigt das Tool/ die IP die neue, editierte Seite oder eine Cache-Version?

Schönen Tag,
ismap

Beitrag von **Webby** » 07.01.2004, 09:23

Bei mir geht das tool auch nicht mehr

Beitrag von **bugscout** » 07.01.2004, 12:29

moin moin,

vielleicht haben die google ja darum gebeten, das abschalten zu lassen

grüsse

Beitrag von **warmasol** » 07.01.2004, 18:27

Um den Spekulationen jetzt mal ein Ende zu bereiten. Google hat die Seite jeansrock_x.htm tatsächlich im Cache. Es kommen keine weiteren Anfragen mehr an. Da ihr ja alle die Seite ausprobiert habt, müsste im Logfile ja auch was auftauchen. Ist aber nicht.

Beitrag von **Michael** » 08.01.2004, 08:32

@bugscout

Google hat nicht darum gebeten den Dienst abzuschalten. Statt dessen haben die einfach das Skript (sogar den kompletten Webserver) unter der IP gesperrt oder abgeschaltet.

Ich habe mein Skript jetzt aktualisiert und es erkennt nur noch Cloaking Pages die mit dem UserAgent arbeiten.

Schade

Beitrag von **bugscout** » 08.01.2004, 12:14

moin moin Michael,

ich meinte auch nicht, dass google darum gebeten hat, ist ja ihr eigener server.

sondern eher das die herren von der otto-vermarktung darum gebeten haben.

@ warmasol,

Google hat die Seite jeansrock_x.htm tatsächlich im Cache

das script rief, als es noch funktionierte, aber den cache von google gar nicht auf (mehrfach getestet).

wenn man sein geneigtes auge mal auf https://www.google.de/search?hl=de&ie=U ... uche&meta= wirft, wird man feststellen, dass dort diverse seiten von google gespidert wurden, die nach dem muster des jeansrocks aufgebaut sind und die nur für google sichtbar sind.

wenn diese seiten gar nicht existieren, woher bekommt google denn dann diesen schönen code? (von quelltext erscheinungen analog zu https://www.marienerscheinungen.net/ hatte ich bis jetzt noch nichts gehört)

@ ismap

Aber mein Test wäre: seite schreiben, per Tool/IP testen, Seite editieren und nochmal testen. Jetzt der spannende Moment: zeigt das Tool/ die IP die neue, editierte Seite oder eine Cache-Version?

genau das habe ich gemacht.seite schreiben, test, seite ändern, beim zweiten test war die neue seite da.

alte seite die im cache von google liegt ändern, test, neue seite ist da-

also, nix cache.

grüsse
bugscout, der nicht an quelltext-erscheinungen glaubt