Hi. Diese Meldungen häufen sich gerade seit 2-3 Wochen. Hab bisher keine eigenen Lösung gefunden.
Kann ich irgendwo feststellen, was da genau versucht über den Telnetport zuzugreifen?
2018.11.20 09:25:48 3: Login denied via telnetPort_127.0.0.1_42656
2018.11.20 09:30:48 3: Login denied via telnetPort_127.0.0.1_42882
2018.11.20 09:35:51 3: Login denied via telnetPort_127.0.0.1_43126
2018.11.20 09:40:47 3: Login denied via telnetPort_127.0.0.1_43364
2018.11.20 09:45:45 3: Login denied via telnetPort_127.0.0.1_43590
2018.11.20 09:50:46 3: Login denied via telnetPort_127.0.0.1_43824
Danke für jeden Tipp.
Jut, wie üblich habe ich gleich nach meinem Thread-Erstellen die Lösung des Problems gefunden.
Einfach SSL fürs Telnet eingeschaltet. Nun hab ich dafür ein neues Problem:
2018.11.20 11:05:46 1: telnet SSL/HTTPS error: SSL accept attempt failed error:1408F10B:SSL routines:ssl3_get_record:wrong version number (peer: 127.0.0.1)
Da schau ich aber erstmal selbst. Sollte jawohl lösbar sein ^^
ZitatJut, wie üblich habe ich gleich nach meinem Thread-Erstellen die Lösung des Problems gefunden.
Einfach SSL fürs Telnet eingeschaltet.
Ich bin nicht ganz sicher, dass das die Loesung ist.
"Login denied" meint, dass fuer die telnet Verbindung eine allowed Instanz konfiguriert ist, und die andere Seite kein oder ein falsches Passwort spezifiziert hat. Das kann natuerlich auch daran liegen, dass die andere Seite mit SSL kommt (und das SSL Handshake als Passwort interpretiert wird), aber dein Folgefehler (wo die SSL Verbindung nicht hergestellt werden kann) ist ein Indiz dafuer, dass es eher an dem Passwort liegt.
Verstehe. Ich habs gerade nochmal getestet. Nachstellbar bei SSL 0
Login denied via telnetPort_127.0.0.1_41712
bei SSL 1
telnet SSL/HTTPS error: Inappropriate ioctl for device
und zwar genau alle 5 Minuten.
telnetPort ist bei attr allowedWEB validfor eingetragen. sonst funktioniert alles.
Kann ich irgendwie rausfinden, welches Device hier versucht per Telnet zuzugreifen? Vielleicht greift hier tatsächlich irgendwas mit falschen Credentials zu.
Danke nochmal :-)
Ich hab User/Passwort erstmal für Telnet deaktiviert. Muss nun rausfinden, was da versucht per Telnet zuzugreifen...
ZitatKann ich irgendwie rausfinden, welches Device hier versucht per Telnet zuzugreifen?
Ich wuerde Passwort fuer telnet aktivieren, Uhrzeit/Frequenz notieren, dann Passwort deaktivieren, und kurz vor dem naechsten Anmelden "attr global verbose 5" setzen.
Das probiere ich mal. Danke!
Ich habe heute ebenfalls derartige Meldungen im Logfile vorgefunden, allerdings im 20s-Takt.
2018.12.15 07:00:22.875 3: Login denied via telnetPort_127.0.0.1_49072
2018.12.15 07:00:43.447 3: Login denied via telnetPort_127.0.0.1_49074
2018.12.15 07:01:04.054 3: Login denied via telnetPort_127.0.0.1_49078
2018.12.15 07:01:24.649 3: Login denied via telnetPort_127.0.0.1_49108
2018.12.15 07:01:45.212 3: Login denied via telnetPort_127.0.0.1_49110
Verursacher war der health-Check vom "offiziellen FHEM Docker Basis Image für verschiedene Plattformen" (https://forum.fhem.de/index.php/topic,89745.0.html (https://forum.fhem.de/index.php/topic,89745.0.html))
Da ich kurz zuvor ein FHEM-Update eingespielt hatte und dabei auch das Modul 99_DockerImageInfo.pm aktualisiert wurde, habe ich den entsprechenden docker-Container aktualisiert.
Anschließend war wieder alles ruhig und die Meldung verschwunden ...
Darf ich mal vorsichtig fragen, wie Docker bei FHEM überhaupt ins Spiel kommt?
Habt ihr FHEM oder irgend etwas davon in Docker isoliert? Oder passiert da was, was mich (ohne den Docker-Zirkus) auch ereilen könnte?
FHEM läuft in meinem Fall vollständig in einem docker-Container.
Wer docker allerdings gar nicht erst einsetzt, kann von genau meinem Fall wohl nicht ereilt werden.
Ob der ursprüngliche Fall aus #1 auch durch ein docker-Image verursacht wurde, kann ich nicht sagen, da es ja dafür bisher keine dokumentierte Lösung gibt.
Das 5-Minuten-Raster spricht ja irgendwie schon fast dagegen ...
Ich frug, weil ich (ohne Docker) den Terz seit Kurzem (mal wieder Update gemacht) habe:
SecurityCheck:
WEBtablet is not password protected
JA - und? Das ist (bei mir) konzeptgemäß. Soll so.
Blöderweise scheint (nicht genauer geprüft) FHEM nun die Kommunikation zu Port 8085 (eben WEBtablet) zu blockieren.
ZitatJA - und? Das ist (bei mir) konzeptgemäß. Soll so.
Mag sein, aber FHEM ist noch nicht in der lage, das lokal gueltige Konzeptdokument zu lesen.
Und da FHEM (leider) zunehmend von Unkundigen eingesetzt wird, die es per Router-Portweiterleitung ins oeffentliche Netz stellen, will ich nach einem GAU auf diese Zeile verweisen koennen.
ZitatBlöderweise scheint (nicht genauer geprüft) FHEM nun die Kommunikation zu Port 8085 (eben WEBtablet) zu blockieren.
Bei telnet/FHEMWEB/MQTT2_SERVER ohne Passwort blockiert FHEM Zugriffe aus dem "nicht lokalen Internet".
Als nicht lokal gilt:
$caddr !~ ^(::ffff:)?(127|192.168|172.(1[6-9]|2[0-9]|3[01])|10|169.254)\\.|^(f[cde]|::1)Im log sollte bei jedem Versuch eine Zeile in der Art stehen:
ZitatConnection refused from the non-local address $caddr:$port as there is no working allowed instance defined for it
Zitat von: rudolfkoenig am 16 Dezember 2018, 20:48:57
Mag sein, aber FHEM ist noch nicht in der lage, das lokal gueltige Konzeptdokument zu lesen.
Und da FHEM (leider) zunehmend von Unkundigen eingesetzt wird, die es per Router-Portweiterleitung ins oeffentliche Netz stellen, will ich nach einem GAU auf diese Zeile verweisen koennen.
Ja, wir hatten ja schon darüber gesprochen. Ich glaube sogar, der Hinweisvorschlag war von mir. Grundsätzlich sinnvoll.
Zitat von: rudolfkoenig am 16 Dezember 2018, 20:48:57
Bei telnet/FHEMWEB/MQTT2_SERVER ohne Passwort blockiert FHEM Zugriffe aus dem "nicht lokalen Internet".
Als nicht lokal gilt:$caddr !~ ^(::ffff:)?(127|192.168|172.(1[6-9]|2[0-9]|3[01])|10|169.254)\\.|^(f[cde]|::1)Im log sollte bei jedem Versuch eine Zeile in der Art stehen:
Ist bei mir 192.168 - allerdings verschiedene Subnetze. Ich schaue es mir gelegentlich genauer an.