Warum macht µC.net HTTP Requests?

[R. M. (Gast)]

Folgende Ausgangssituation: Ich betreibe momentan testweise zuhause 
einen Webserver auf Port 80, der eine simple Webseite ausliefert. Dort 
überwache ich in Echtzeit auf einem zweiten Monitor, welche Anfragen 
ankommen:

tail --follow /var/log/apache2/access.log

Nun ist mir vorhin beim Absenden eines Beitrags in genau diesem Moment 
eine eingehende Anfrage aufgefallen. Bei einem weiteren Beitrag wurde 
ebenfalls genau in diesem Moment eine weitere Anfrage an diesen 
Webserver erzeugt:

78.46.249.179 - - [20/Feb/2019:21:24:34 +0000] "GET / HTTP/1.1" 400 0 "-" "curl/7.47.0"
78.46.249.179 - - [20/Feb/2019:21:27:01 +0000] "GET / HTTP/1.1" 400 0 "-" "curl/7.47.0"
78.46.249.179 - - [20/Feb/2019:21:31:29 +0000] "GET / HTTP/1.1" 400 0 "-" "curl/7.47.0"

Dies geschieht ebenfalls bei einem Klick auf den Vorschaubutton beim 
Erstellen eines neuen Themas.

Ein whois auf die IP Adresse verweist auf einen Hetzner Server. Da der 
Verdacht im Raum stand, dass es sich um mikrocontroller.net handelt, 
habe ich ein dig mikrocontroller.net ausgeführt:

; <<>> DiG 9.13.5 <<>> mikrocontroller.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63432
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mikrocontroller.net.           IN      A

;; ANSWER SECTION:
mikrocontroller.net.    86400   IN      A       78.46.249.179

;; Query time: 36 msec
;; SERVER: 10.1.10.1#53(10.1.10.1)
;; WHEN: Wed Feb 20 21:33:46 CET 2019
;; MSG SIZE  rcvd: 64

Wie eindeutig zu erkennen ist, ist die IP Adresse indentisch. Die Frage 
ist nun also, warum mikrocontroller.net derartige Anfragen an die 
Absender IP stellt.

[Gerd E. (robberknight)]

Hmm, das scheint jedenfalls nicht die Regel zu sein:

Obwohl ich heute schon mehrfach im Forum geposted hab, seh ich die 
78.46.249.179 nirgends in den Firewall-Logs von meinem Router.

Vielleicht abhängig davon ob Du als Gast postest oder angemeldet?

[Gerd E. (robberknight)]

Sorry, ich muss mich korrigieren: auch bei mir kommen diese Requests auf 
Port 80.

Ist anscheinend bei jedem Post, nicht nur beim Erstellen eines Threads.

[Manfred (Gast)]

Gerd E. schrieb:
> bei jedem Post

Antwort!

[Manfred (Gast)]

Gerd E. schrieb:
> anscheinend

Anwort.

[Manfred (Gast)]

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!

[Gerd E. (robberknight)]

Manfred schrieb:
> 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.

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.

[ping1 (Gast)]

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.

[ping1 (Gast)]

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)

[Mario M. (thelonging)]

Das könnte was mit der Erkennung von Tor-Exit-Nodes zu tun haben. Die 
betreiben auf Port 80 einen HTTP-Server, der über die Funktion als 
Exit-Node informiert. Das sieht meist so aus:
https://gitweb.torproject.org/tor.git/plain/contrib/operator-tools/tor-exit-notice.html

[R. M. (Gast)]

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.

[Andreas S. (andreas) (Admin)]

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

Genau. Speziell zur Erkennung von IPv6-Exit-Nodes, fuer die es keine 
Liste gibt. Da IPv6 im Moment hier allerdings abgeschaltet ist, ist der 
Check im Moment nicht noetig (und auch nicht funktionsfaehig). Ich habe 
ihn deshalb gerade deaktiviert.

R. M. schrieb:
> Erachtens sind das auch Dinge, die in die Datenschutzerklärung gehören,
> sofern dort Informationen gespeichert werden.

Es wurden keine personenbezogenen Daten verarbeitet oder gespeichert.

[ping1 (Gast)]

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

[Manfred (Gast)]

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

[Jörg W. (dl8dtl) (Moderator)]

Andreas S. schrieb:
> Speziell zur Erkennung von IPv6-Exit-Nodes, fuer die es keine Liste
> gibt.

Ah, daher auch die eckigen Klammern bei Host:

Dann könntest du ja IPv6 doch mal wieder einschalten. ;-)