Herzlich willkommen im SEO Forum der ABAKUS Internet Marketing GmbH
registrieren registriertes Mitglied
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 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?
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
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 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.
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.
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.supervisior hat geschrieben: ↑28.01.2020, 03:36Ich 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.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
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.
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 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.
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: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.
Doch, genau das!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
Garantiert nicht.supervisior hat geschrieben: ↑28.01.2020, 09:53sondern kann ich auch von meinem lokalen Rechner aus auf meinen Webserver machen.
Hä, wieso musst du dazu die Quell-IP faken?supervisior hat geschrieben: ↑28.01.2020, 09:53Ich mach das doch 5x am Tag, um z.B. den Cache meines Lichtgeschwindigkeits Server aufzuwärmen.
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 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 ...
Ich würde mal auf Folgendes tippen: https://www.litespeedtech.com/products/ ... on/comparesupervisior 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 bin gespannt ...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.