mikrocontroller.net

Forum: www.mikrocontroller.net Warum macht µC.net HTTP Requests?


Autor: R. M. (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Manfred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> bei jedem Post

Antwort!

Autor: Manfred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> anscheinend

Anwort.

Autor: Manfred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ping1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ping1 (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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)

Autor: Mario M. (thelonging)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: R. M. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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.

Autor: ping1 (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Danke für die Aufklärung! :-)

Autor: Manfred (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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. ;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.