Produkte ohne Traffic

staticweb · **staticweb** » 27.01.2020, 20:28 **Produkte ohne Traffic**

Google wäre niemals so dumm solche kausalen Zusammenhänge so leicht analysierbar zu machen. Sollte jemals nachweisbar werden, dass die organischen Suchergebnisse "optimiert" werden um zahlungskräftige User zu AdWords zu treiben, wäre die nächste Milliardenstrafe in Europa gewiss und es droht dann auch eine Zerschlagung des Konzerns.

> Warum sollte Google das machen? Die Kunden die Adsense nutzen stehen doch schon Schlange denn es gibt wohl nur maximum 6 Anzeigeplätze

Wenn man die Anzahl der User erhöhen kann, die um einen Anzeigenplatz in Adwords bieten, dann wird sich höchstwahrscheinlich auch das Gebot erhöhen.

**Hanzo2012** » 27.01.2020, 21:04 **Produkte ohne Traffic**

supervisior hat geschrieben: ↑27.01.2020, 19:52 @Hanzo2012

Nachdem das Thema ohnehin schon abgetriffted ist, kannst Du Dich an die Diskussion erinnern als darum ging, ob man eine IP maskieren kann und Du das vehement verneint hast?

Ja. Du warst der Meinung, dass du HTTP-Anfragen bei einem Server ankommen lassen kannst, wobei du die angebliche Quell-IP beliebig festlegen kannst. Ich sagte, dass das spätestens sobald der Server SSL forciert, praktisch unmöglich ist.

supervisior · **supervisior** » 28.01.2020, 03:36 **Produkte ohne Traffic**

Wie schon damals muss ich Dir auch jetzt widersprechen. Ich hatte mich damals aber nur deswegen zur Klärung nicht weiter geäußert, weil ich zu diesem Zeitpunnkt noch angenommen hatte, dass die Info darüber, dass es doch geht, Hacker Latein wäre. Isses aber gar nicht. Beim x-ten Studieren der cURL Parameter bin ich dann auf --resolve gestoßen, was genau das ermöglicht.

Code: Alles auswählen

curl http://www.example.com --resolve www.example.com:80:127.0.0.1 --resolve www.example.com:443:127.0.0.1

Ich bin nur ganz zufällig darauf gestoßen als ich beim sporadischen Checken der error_log Einträge gefunden hatte bei denen mit 127.0.0.1 und der IP meines Servers Requests auf meine Webseiten gemacht wurden, was Deiner Meinung nach ja nicht gehen würde.

supervisior · **supervisior** » 28.01.2020, 03:42 **Produkte ohne Traffic**

staticweb hat geschrieben: ↑27.01.2020, 20:28 Google wäre niemals so dumm solche kausalen Zusammenhänge so leicht analysierbar zu machen. Sollte jemals nachweisbar werden, dass die organischen Suchergebnisse "optimiert" werden um zahlungskräftige User zu AdWords zu treiben, wäre die nächste Milliardenstrafe in Europa gewiss und es droht dann auch eine Zerschlagung des Konzerns.

Dumm ist eine Sache. Ein kausaler ZUsammenhang aber ganz was anderes. Auch wenn es noch so einfach durchschaubar wäre/ist, ist es schlichtweg unmöglich einen Gegenbeweis zu schaffen. Wie auch?!Es ist wenn, dann max. eine Theorie ohne Fakten.

staticweb · **staticweb** » 28.01.2020, 07:57 **Produkte ohne Traffic**

> Ich bin nur ganz zufällig darauf gestoßen als ich beim sporadischen Checken der error_log Einträge gefunden hatte bei denen mit 127.0.0.1 und der IP meines Servers Requests auf meine Webseiten gemacht wurden, was Deiner Meinung nach ja nicht gehen würde.

Das ist doch nur eine lokale Manipulation des DNS mit Auswirkungen auf HTTP-Protokoll-Ebene und steht deshalb im access log. Das --resolve Argument wurde übrigens inzwischen abgeschafft und durch --connect-to ersetzt.

Alternativ kannst du auch deine lokale Host-Datei manipulieren, was du dir mit obiger Lösung sparst.

Geprüft werden sollte natürlich die auf IP-Ebene verwendete Adresse, da diese nicht manipuliert werden kann.

Wie du das bei QUIC absicherst, welches ja UDP nutzt musst du schon selbst wissen. Das ist ein Grund warum die Verbreitung auf Server-Ebene so gering ist.

supervisior · **supervisior** » 28.01.2020, 08:26 **Produkte ohne Traffic**

staticweb hat geschrieben: ↑28.01.2020, 07:57 und steht deshalb im access log.

Rein nur darum ging es und nicht mehr, wobei sich das nicht auf lokale Adressen begrenzt. Hättest Du meinen kompletten Thread vollständig gelesen, hättest Du auch gelesen, dass auch die (öffentliche) IP meines Servers genutzt wurde. Es geht also mit jeder anderen IP.

Ich weiß nicht wo Du die Info her hast, dass --resolve abgeschafft worden sei. Es gibt diesen Parameter nachwievor.

**Hanzo2012** » 28.01.2020, 09:10 **Produkte ohne Traffic**

supervisior hat geschrieben: ↑28.01.2020, 03:36
Code: Alles auswählen
curl http://www.example.com --resolve www.example.com:80:127.0.0.1 --resolve www.example.com:443:127.0.0.1
Ich bin nur ganz zufällig darauf gestoßen als ich beim sporadischen Checken der error_log Einträge gefunden hatte bei denen mit 127.0.0.1 und der IP meines Servers Requests auf meine Webseiten gemacht wurden, was Deiner Meinung nach ja nicht gehen würde.

Verstehst du überhaupt, was da passiert? curl verbindet sich mit deinem eigenen Server und schickt an deinen eigenen Server eine Anfrage "GET www.example.com/". Diese wird er nicht beantworten können, weil er keine derartige Domain konfiguriert hat, und einen Fehler loggen. Geloggt wird dann die Client-IP 127.0.0.1, weil die Anfrage ja von lokal kam.

Der echte Server example.com kriegt davon rein gar nichts mit. Dort wirst du nichts in den Logs finden, weil keinerlei Daten dorthin geschickt werden.

Auf einem fremden Webserver kannst du auf diese Weise keine 127.0.0.1-IP-Adresse hinterlassen, geschweige denn eine beliebige falsche Adresse (was du behauptet hattest).

Wenn du in deinem Access-Log Einträge von 127.0.0.1 siehst, dann wurden diese Anfragen tatsächlich von deinem eigenen Server aus geschickt, nicht von irgendwelchen bösen Hackern ... Warum dein Server Anfragen an sich selbst schickt, kann ich dir ohne Einsicht in deine Anwendungen/Konfiguration nicht sagen. Könnte sowas Banales wie ein [P]-Flag bei einer mod_rewrite-Regel sein, oder mod_pagespeed.

staticweb hat geschrieben: ↑28.01.2020, 07:57Wie du das bei QUIC absicherst, welches ja UDP nutzt musst du schon selbst wissen. Das ist ein Grund warum die Verbreitung auf Server-Ebene so gering ist.

UDP ist in der Tat anfälliger gegen IP-Spoofing als TCP, trotzdem kann man auch mit QUIC keine Anfragen mit gefälschter Absender-IP beim Server ankommen lassen. Dagegen wurde nämlich in Form eines Tokens ein Schutz eingebaut. Dass das ein Grund für die geringe Verbreitung von QUIC ist, würde ich also nicht sagen.

supervisior · **supervisior** » 28.01.2020, 09:53 **Produkte ohne Traffic**

Hanzo2012 hat geschrieben: ↑28.01.2020, 09:10 Verstehst du überhaupt, was da passiert? curl verbindet sich mit deinem eigenen Server und schickt an deinen eigenen Server eine Anfrage "GET www.example.com/". Diese wird er nicht beantworten können, weil er keine derartige Domain konfiguriert hat, und einen Fehler loggen. Geloggt wird dann die Client-IP 127.0.0.1, weil die Anfrage ja von lokal kam.

Natürlich, wobei es ja einzigst darum ging eine IP Adresse so zu maskieren, dass in der access_log eine ganz andere IP Adresse steht. Wie das letztlich netzwerktechnisch abläuft, steht auf einem ganz anderen Papier. Nachdem es außer der access_log ansonsten kein anderes Werkzeug existiert, um einen Request, bzw. dessen Absender identifizieren zu können, wird damit das Benötigte erreicht. Nicht mehr, aber auch nicht weniger und genau so finde ich das auch gelegentlich in meiner access_log. Es ist aber nicht so wie Du meinst, dass sich cURL mit meinem eigenen Server verbinden würde, quasi als Selbstaufruf, sondern kann ich auch von meinem lokalen Rechner aus auf meinen Webserver machen. Ich mach das doch 5x am Tag, um z.B. den Cache meines Lichtgeschwindigkeits Server aufzuwärmen.

**Hanzo2012** » 28.01.2020, 09:57 **Produkte ohne Traffic**

supervisior hat geschrieben: ↑28.01.2020, 09:53Natürlich, wobei es ja einzigst darum ging eine IP Adresse so zu maskieren, dass in der access_log eine ganz andere IP Adresse steht.

Und genau das geht eben nicht. Deine Methode ist Unfug. Jeder, der nur halbwegs Ahnung von Netzwerktechnik hat, wird dir das bestätigen.

supervisior hat geschrieben: ↑28.01.2020, 09:53Es ist aber nicht so wie Du meinst, dass sich cURL mit meinem eigenen Server verbinden würde, quasi als Selbstaufruf

Doch, genau das!

supervisior hat geschrieben: ↑28.01.2020, 09:53sondern kann ich auch von meinem lokalen Rechner aus auf meinen Webserver machen.

Garantiert nicht.

supervisior hat geschrieben: ↑28.01.2020, 09:53Ich mach das doch 5x am Tag, um z.B. den Cache meines Lichtgeschwindigkeits Server aufzuwärmen.

Hä, wieso musst du dazu die Quell-IP faken?

supervisior · **supervisior** » 28.01.2020, 10:05 **Produkte ohne Traffic**

Ich muss die IP nicht faken. Das war nur eine Randbemerkung, wobei ich dieses Faken auch in diesem Zusammenhang machen könnte, jedoch für das benötigte keine Funktion hat. Du weißt aber schon, dass man cURL auch lokal oder von wo aus auch immer an einen Zielserver ausführen kann, wobei cURL ein weitaus größeres Spektrum an Möglichkeiten bietet, als dass dies über einen Browser Request möglich ist? Du liegst aber nachwievor falsch, dass das Beschriebene nur über einen Selbstaufruf möglich wäre! Magst meine error_log sehen?

**Hanzo2012** » 28.01.2020, 10:08 **Produkte ohne Traffic**

Natürlich weiß ich, dass man cURL von wo auch immer ausführen kann. Ändert aber nix. Wenn du irgendwo 127.0.0.1 erscheinen lassen willst, musst du den Server dazu bringen, die Anfrage an sich selbst zu schicken.

Ja, zeig doch bitte mal deine error_log.

Und ich lade dich ein, mit deiner Methode eine gefälschte HTTP-Anfrage mit 127.0.0.1 als Quell-IP an https://epicsave.de/hacker.txt zu schicken. Wenn du das schaffst, nehme ich alles zurück und halte die Klappe.

supervisior · **supervisior** » 28.01.2020, 10:17 **Produkte ohne Traffic**

178.162.211.x == IP Adresse meines Servers.

Code: Alles auswählen

2020-01-25 16:24:24.819455 [INFO] [7727] [178.162.211.x:41234-2#APVH_xxxx.com:443] File not found [/home/xxxxx/
2020-01-25 16:24:23.812205 [INFO] [7727] [178.162.211.x:41234-1#APVH_xxxx.com:443] File not found [/home/xxxxx/
2020-01-25 14:32:15.803230 [INFO] [7727] [178.162.211.x:41420-1#APVH_xxxx.com:443] File not found [/home/xxxxx/
2020-01-25 13:18:13.814255 [INFO] [7727] [178.162.211.x:41376-1#APVH_xxxx.com:443] File not found [/home/xxxxx/ 
2020-01-25 08:41:20.615423 [INFO] [7727] [178.162.211.x:41234-1#APVH_xxxx.com:443] File not found [/home/xxxxx/ 
2020-01-24 23:20:45.635083 [INFO] [7727] [178.162.211.x:41376-1#APVH_xxxx.com:443] File not found [/home/xxxxx/ 
2020-01-24 23:20:45.577042 [INFO] [7727] [178.162.211.x:41376-1#APVH_xxxx.com:443] File not found [/home/xxxxx/ 
2020-01-24 19:48:09.585212 [INFO] [7727] [178.162.211.x:41234-1#APVH_xxxx.com:443] File not found [/home/xxxxx/
2020-01-24 18:50:19.903951 [INFO] [7727] [178.162.211.x:41234-1#APVH_xxxx.com:443] File not found [/home/xxxxx/
2020-01-24 18:02:14.234303 [INFO] [7727] [178.162.211.x:41234-1#APVH_xxxx.com:443] File not found [/home/xxxxx/
2020-01-24 18:01:56.582518 [INFO] [7727] [178.162.211.x:41928-1#APVH_xxxx.com:443] File not found [/home/xxxxx/
2020-01-24 18:00:15.729704 [INFO] [7727] [127.0.0.1:52816-1#APVH_xxxx.com:443] File not found [/home/xxxxx/
2020-01-24 15:40:44.451498 [INFO] [7727] [178.162.211.x:41234-1#APVH_xxxx.com:443] File not found [/home/xxxxx/
2020-01-24 12:53:19.817587 [INFO] [7727] [178.162.211.x:41928-1#APVH_xxxx.com] File not found [/home/xxxxx/
2020-01-24 11:58:19.972075 [INFO] [7727] [127.0.0.1:52816-1#APVH_xxxx.com:443] File not found [/home/xxxxx/
2020-01-24 11:09:30.515183 [INFO] [7727] [178.162.211.x:40892-2#APVH_xxxx.com:443] File not found [/home/xxxxx/

**Hanzo2012** » 28.01.2020, 10:26 **Produkte ohne Traffic**

Etwas auf deinem Server löst diese Anfragen aus. Mehr kann ich dazu nicht sagen, ohne mehr über deinen Server zu wissen. Vielleicht irgendein Feature deines Webservers, z. B. dieser Cache?

Was ist nun mit deiner Demonstration? Bitte schick mit deiner Methode eine gefälschte HTTP-Anfrage mit 127.0.0.1 als Quell-IP an https://epicsave.de/hacker.txt ...

supervisior · **supervisior** » 28.01.2020, 10:35 **Produkte ohne Traffic**

Hanzo2012 hat geschrieben: ↑28.01.2020, 10:26 Etwas auf deinem Server löst diese Anfragen aus. Mehr kann ich dazu nicht sagen, ohne mehr über deinen Server zu wissen. Vielleicht irgendein Feature deines Webservers, z. B. dieser Cache?

Was ist nun mit deiner Demonstration? Bitte schick mit deiner Methode eine gefälschte HTTP-Anfrage mit 127.0.0.1 als Quell-IP an https://epicsave.de/hacker.txt ...

Da is nix, was irgendwas auf meinem Server ausführt und findet sich in fast jeder error_log eines jeden Accounts. Die Ziel Adressen, bzw. deren Typus ähneln sehr einem Bot.

Wegen dem Demo, gib mir etwas Zeit, wenn ich das nächste Mal meinen Lichtgeschwindigkeitsserver aufwärme. Dann mache ich das mit.

**Hanzo2012** » 28.01.2020, 10:38 **Produkte ohne Traffic**

supervisior hat geschrieben: ↑28.01.2020, 10:35Da is nix, was irgendwas auf meinem Server ausführt und findet sich in fast jeder error_log eines jeden Accounts. Die Ziel Adressen, bzw. deren Typus ähneln sehr einem Bot.

Ich würde mal auf Folgendes tippen: https://www.litespeedtech.com/products/ ... on/compare

Da ist die Rede von "Pre-caching (built-in crawler)" und "Mobile / AMP Cache".

Klingt ganz danach, als würde der Server damit seine eigenen Websites crawlen bzw. Anfragen an sich selbst schicken. Ausgelöst wird das gewiss durch zuvor eingegangene Anfragen. Wenn jetzt irgendjemand eine Datei bei dir anfragt, dann versucht der Crawler später nochmal diese Datei abzurufen.

Also meine Theorie: Ein externer Crawler durchcrawlt deine Website und fragt allerhand (schwachsinniger) Dateien ab, z. B. um Sicherheitslücken zu finden. Das führt dann dazu, dass der eingebaute Crawler deines Webservers dieselben Dateien nochmal crawlt, um sie zu cachen. Dabei schickt er eine Anfrage an sich selbst, die du im Log findest, natürlich mit der eigenen IP als Quelle.

Wenn diese Theorie zutreffend ist, müsstest du in deiner error_log - wahrscheinlich mit Zeitversatz - zu denselben angefragten Dateien noch andere Anfragen finden, nämlich die vom Bot.

supervisior hat geschrieben: ↑28.01.2020, 10:35Wegen dem Demo, gib mir etwas Zeit, wenn ich das nächste Mal meinen Lichtgeschwindigkeitsserver aufwärme. Dann mache ich das mit.

Ich bin gespannt ...