Warum macht µC.net HTTP Requests?

Gerd E. schrieb:
> bei jedem Post

Antwort!

Gerd E. schrieb:
> anscheinend

Anwort.

Gerd E. schrieb:
> Ist anscheinend bei jedem Post, nicht nur beim Erstellen eines Threads.

Das lässt sich hier nicht nachvollziehen: Mein Unfug von 22:32 und 22:41 
lässt keinen Datenverkehr zu 78.46.249.179:8* erkennen.

Alle Verbindungen sind über 443 gelaufen!

Bei mir kommt folgende Anfrage rein, sogar schon wenn ich nur auf 
"Vorschau" drücke (letztes Byte des Host (=meine IP) von mir durch XXX 
ersetzt):

GET / HTTP/1.1
Host: [91.12.22.XXX]
User-Agent: curl/7.47.0
Accept: */*


Da würde ich jetzt aber schon mal um eine Erklärung bitten, welche Daten 
des Besuchers hier erfasst werden sollen, warum dies geschieht, und wie 
lange diese Daten gespeichert bleiben.

Wilde Theorie: Eventuell hats was mit Spam-Abwehr zu tun?

Spammer benutzen gerne gekaperte Server. Viele Server die übernommen 
wurden sind Webserver (große Angriffsfläche dank oftmals ungepatchter 
Software etc.). Wenn dort also ein Webserver lauscht dann könnte es sich 
um einen gekaperten Server handeln, damit wäre die 
Der-Beitrag-ist-SPAM-Wahrscheinlichkeit höher. Viele solche Faktoren 
könnten kombiniert werden um eine SPAM-Einschätzung zu bekommen.


Was dafür spricht: Die Antwortzeit des µc.net Webservers ist um etwa 
1000ms höher wenn auf meinem Rechner ein Webserver läuft der einfach die 
EINGEHENDE Verbindung maximal lange offen lässt. (nach 1 Sekunde wird 
die eingehende Verbindung von der Gegenseite geschlossen). Wenn ich die 
eingehende Verbindung sofort ablehne dann liegt die Antwortzeit des 
Servers bei nur so 200ms. Wenn ich sie offen halte bei ca. 1200ms.
D.h. der Server nutzt die Info aus der Anfrage tatsächlich um irgendwas 
mit meinem Post zu machen.
(muss man keinen Post absenden, klappt schon mit der Vorschau)

ping1 schrieb:
> Wilde Theorie: Eventuell hats was mit Spam-Abwehr zu tun?

Das war auch meine erste Vermutung. Wobei ich mich da noch frage, ob man 
nicht inzwischen auch 443 mit reinnehmen müsste. Meines Wissens gibt es 
inzwischen erste Server, die ganz ohne Port 80 auskommen. Moderne 
Webbrowser versuchen es ohnehin auch auf 443.

Mario M. schrieb:
> Das könnte was mit der Erkennung von Tor-Exit-Nodes zu tun haben

Wobei es dafür eigentlich keinen eigenen Tests bedarf: 
https://check.torproject.org/cgi-bin/TorBulkExitList.py

ping1 schrieb:
> Da würde ich jetzt aber schon mal um eine Erklärung bitten, welche Daten
> des Besuchers hier erfasst werden sollen, warum dies geschieht, und wie
> lange diese Daten gespeichert bleiben.

Genau. Wir können hier zwar raten, aber ich hätte da auch gerne eine 
Erklärung, warum das gemacht wird. Meines Erachtens sind das auch Dinge, 
die in die Datenschutzerklärung gehören, sofern dort Informationen 
gespeichert werden. Selbst wenn es nur ein Flag Webserver=True ist.

Danke für die Aufklärung! :-)

Gerd E. schrieb:
> Ich vermute Du hast das falsch verstanden:
> Dein Browser kommuniziert rein über HTTPS mit 78.46.249.179.
>
> Dann versucht aber die 78.46.249.179 von sich aus eine Verbindung zu
> Port 80 Deiner externen IP aufzubauen.

Stimmt:

22:32:44 <134>INET: NAT: refused incoming session on ifc 10001 prot 6 
xxx.yyy.2.64:80 <- 78.46.249.179:60990
22:41:58 <134>INET: NAT: refused incoming session on ifc 10001 prot 6 
xxx.yyy.1.46:80 <- 78.46.249.179:40088

22:45:27 <134>INET: NAT: refused incoming session on ifc 10001 prot 6 
xxx.yyy.4.90:80 <- 78.46.249.179:57410
22:46:10 <134>INET: NAT: refused incoming session on ifc 10001 prot 6 
xxx.yyy.4.90:80 <- 78.46.249.179:57424
22:46:44 <134>INET: NAT: refused incoming session on ifc 10001 prot 6 
xxx.yyy.4.90:80 <- 78.46.249.179:57438