Seit ich den Zugriff auf FHEM von extern zulasse und SSl verwende, bekomme ich eigentlich immer
wieder obigen Fehler
mit folgendem Hinweis :
SSL routines:SSL23_GET_CLIENT_HELLO:http request
Es hat wohl etwas mit Zertifikaten zu tun. Teilweise finde ich Hinweise auf das attribute "longpoll"
Wie auch immer. Für die Sache mit Zertifikaten habe ich noch keine Doku gefunden, welche dann auch verlässlich durchzuführen ist und funktioniert.
Weiterhin kommen obige Fehlermeldungen auch von IP Seite, welche mir unbekannt sind.
Zumindest sollte das durch user/password erst mal einigermaßen geschützt sein. Trotzdem ist es ärgerlich das logfile damit zu füllen.
Vielleicht wäre es eine Möglichkeit diese NAchrichten nicht als Level 1 zu protokolieren -- man kann sie wohl eh nicht einfach verhindern.
Wer sollte eigentlich auf mein Smarthome von extern zugreifen können ? Eigentlich doch nur bekannte Personen und dies eigentlich mit bekannten Geräten.
Könne man eventuell eine Möglichkeit haben, nur bestimmte MAC Ids zuzulassen ?
Oder hat jemand eine gute Lösung HTTPS zu verwenden, sprich verschlüsselte Kommunikation, aber ohne Zertifikate erstellen zu müssen ?
https://forum.fhem.de/index.php?topic=56364.0
Eventuell hilft das hier.
Der Logeintrag kommt wohl immer, wenn versucht wird per HTTP auf die Seite zuzugreifen. Das versuchen wohl auch gerne "Fremde". Kann man diesen Logeintrag irgendwie gezielt unterdrücken, so dass "echte" Fehler besser zu finden sind?
Wenn du mit SSL keine client certification machst (was du wohl nicht tust), hat FHEM direkt nix im Internet verloren, auch nicht mit allowed o.ä.
Mach VPN oder Auth (mit SSL) über einen Reverse Proxy.
Zitat von: roli am 07 September 2020, 10:10:36
Oder hat jemand eine gute Lösung HTTPS zu verwenden, sprich verschlüsselte Kommunikation, aber ohne Zertifikate erstellen zu müssen ?
Wenn es nicht unbedingt https sein muss: vpn und gut.
Z.B. piVPN (läuft bei einem "meiner" Systeme direkt auf dem fhem-PI, damit ich notfalls mal drauf kann)...
Gruß, Joachim
Zitat von: MadMax-FHEM am 27 Oktober 2020, 13:48:37
Wenn es nicht unbedingt https sein muss: vpn und gut.
VPN und HTTPS schließen sich nicht aus und sollten sich auch nicht ausschließen.
Jaja, ich weiß ;)
Aber dann kommt ja wieder u.U. das mit dem Zertifikat ;)
Klar geht bei einer vpn-Verbindung auch https drüber...
Gruß, Joachim
Und warum sollte ein Zertifikat ein Problem sein?
Gibt doch mittlerweile mit letsencrypt sogar offizielle Zertifikate für "Umsonst"
Zitat von: MadMax-FHEM am 27 Oktober 2020, 13:52:26
Aber dann kommt ja wieder u.U. das mit dem Zertifikat ;)
Klar geht bei einer vpn-Verbindung auch https drüber...
Naja, gehen wir mal davon aus, dass die HTTP-Zugriff gar nicht von ihm, sondern halt von irgendwem gemacht werden, die halt das Web nach offenen Ports abklappern - dann würde ein Zugriff nur über VPN zumindest mal dafür sorgen, dass diese Leute nicht mehr anklopfen.
Glaskugel: Sein Problem ist eigentlich kein SSL-Problem, sondern ein Berechtigungs-/Security-Problem.
Zitat von: Christoph Morrison am 27 Oktober 2020, 14:03:43
Glaskugel: Sein Problem ist eigentlich kein SSL-Problem, sondern ein Berechtigungs-/Security-Problem.
Schauen wir mal, ob der Nebel in der Kugel gelichtet wird ;)
Gruß, Joachim
Ich weiß, dass ich die Meldungen wahrscheinlich nicht bekommen würde, wenn ich erst einmal auf einen Reverse Proxy umgebaut habe.
Ob und wann ich das mache, ist meine Sache.
Mein "Problem" ist nur, das wegen einer Banalität wie "jemand fragt per HTTP an einem HTTPS-Port an" etwas auf Level 1 ins Log geschrieben wird.
Meine Frage war nur, ob man diese Meldung nicht irendwie unterdrücken könnte oder zumindest auf ein höheres Loglevel heben.
Wenn es dafür eine einfache Lösung gibt: gut. Wenn nicht: auch nicht schlimm.
Zitat von: MiK77 am 27 Oktober 2020, 19:47:37
Ich weiß, dass ich die Meldungen wahrscheinlich nicht bekommen würde, wenn ich erst einmal auf einen Reverse Proxy umgebaut habe.
Ob und wann ich das mache, ist meine Sache.
Ja. Darf ich dich daran erinnern, dass du hier nach Hilfe gefragt hast und nicht wir? Die korrekte Antwort auf dein Problem ist, FHEM nicht über HTTP erreichbar zu machen, nicht die Meldungen zu unterdrücken. Du hast da ein Security-Problem.
Zitat von: MiK77 am 27 Oktober 2020, 19:47:37
Mein "Problem" ist nur, das wegen einer Banalität wie "jemand fragt per HTTP an einem HTTPS-Port an" etwas auf Level 1 ins Log geschrieben wird.
Es ist keine Banalität, sondern ein security incident.
Zitat von: MiK77 am 27 Oktober 2020, 19:47:37
Mein "Problem" ist nur, das wegen einer Banalität wie "jemand fragt per HTTP an einem HTTPS-Port an" etwas auf Level 1 ins Log geschrieben wird.
Meine Frage war nur, ob man diese Meldung nicht irendwie unterdrücken könnte oder zumindest auf ein höheres Loglevel heben.
Wenn es dafür eine einfache Lösung gibt: gut. Wenn nicht: auch nicht schlimm.
Und du wolltest wissen, ob es einen einfachen Zugang ohne solche Meldungen gibt: https://forum.fhem.de/index.php/topic,114107.msg1095891.html#msg1095891
Einfache Lösung deiner Frage: verbose auf 0 (vermutlich reicht das beim Fhem-Web)...
Aber wie geschrieben, nicht sehen, heißt nicht, dass es nicht weiterhin passiert...
Ist wie beim Versteckenspielen einfach die Augen zu schließen und dann denken nicht gefunden werden zu können... ;)
Gruß, Joachim
Es mag ja sein, dass ein FHEM direkt im Internet ein Security-Problem ist. Aber eine HTTP-Anfrage an einem HTTPS-Port ist kein Security Problem.
Wenn ein Reverse-Proxy läuft, kommen die gleichen Anfragen dort an. Schlägt dann nginx auch großen Alarm?
Meiner meinung nach, hat das Security Problem nichts mit den HTTP-Anfragen zu tun. Das das Problem da ist, stelle ich ja nicht in Frage. Ich sehe aber keinen Zusammenhang, warum deswegen bei jedem HTTP-Request ein Level 1 Log erfolgen muss.
Auch wenn es mir am Anfang nicht bewusst war: Wir sind hier im Bereich Wunschliste. Letztlich geht es hier für mich also gar nicht um die Lösung für ein Problem. Ich wünsche mir lediglich ein höheres Loglevel für diese Meldung. Wenn der nicht erfüllt wird, ist das für mich auch kein Problem.
PS.: Ja, ich werde das auch noch zeitnah auf Reverse Proxy umstellen.
Zitat von: MiK77 am 27 Oktober 2020, 23:07:15
Es mag ja sein, dass ein FHEM direkt im Internet ein Security-Problem ist. Aber eine HTTP-Anfrage an einem HTTPS-Port ist kein Security Problem.
Es gibt einen Unterschied zwischen "etwas ist ein Security-Problem" und "etwas ist ein security incident". Wenn jemand an deiner Haustür die Klinke versucht obwohl abgeschlossen ist und das mit böser Absicht tut - ist das auch ein security incident, aber noch kein Security-Problem, weil ja die TOM ausgereicht haben um dem Klinkendrücker den Zugang zu verwehren. Wissen dass da jemand rumläuft und offene Haustüren sucht möchte man aber doch wissen.
ZitatWenn ein Reverse-Proxy läuft, kommen die gleichen Anfragen dort an. Schlägt dann nginx auch großen Alarm?
"Großer Alarm" ist gut. Es ist ein Eintrag im Logfile, kein Shutdown oder so. Nginx hat für diesen Fall übrigens sogar einen eigenen, inoffiziellen HTTP-Status-Code definiert:
Zitat497 HTTP Request Sent to HTTPS Port
An expansion of the 400 Bad Request response code, used when the client has made a HTTP request to a port listening for HTTPS requests.
ZitatMeiner meinung nach, hat das Security Problem nichts mit den HTTP-Anfragen zu tun. Das das Problem da ist, stelle ich ja nicht in Frage. Ich sehe aber keinen Zusammenhang, warum deswegen bei jedem HTTP-Request ein Level 1 Log erfolgen muss.
YMMV. Ich sehe das als Reminder für Leute, die nicht lernen wollen, dass ihr FHEM nicht direkt ans Internet gehört. Ist doch nett von Rudi, dass er sich um seine User-Basis sorgt (naja und ihr würdet dann auch hier aufschlagen wenn jemand euer FHEM aufgemacht und dort Unsinn angestellt hat, dann ist das Geheule groß und alle anderen müssen sich mit nervigen Voreinstellungen und Logeinträgen rumärgern ... oh wait).
Du kannst die Meldung übrigens dafür nutzen, "Klinkendrücker" zu identifizieren und direkt über fail2ban auf einer unteren Netzwerkebene zu blocken.
ZitatPS.: Ja, ich werde das auch noch zeitnah auf Reverse Proxy umstellen.
Dann hat es ja funktioniert.
Meine Entscheidung für einen Reverse Proxy hat nichts mit diesen Meldungen zu tun.
Nur weil irgendwelche Kiddies schauen, ob irgendwo Türen offen stehen, ist das für mich kein schlimmer Sicherheitsvorfall. Sonst würde der ganze Internettraffic zum großen Teil aus Sicherheitsvorfällen vestehen.
Wenn ich etwas auf zweithöchster Stufe logge, sollte das ein schwerwiegendes Problem bzw. Alarm sein. Und das ist es für mich hier nicht. Siehe zum Beispiel die Loglevel von syslog:
0 Emergency
1 Alert
2 Critical
3 Error
4 Warning
5 Notice
6 Informational
7 Debug
Danach wäre das für mich eine 4.
ZitatNur weil irgendwelche Kiddies schauen, ob irgendwo Türen offen stehen,
Also wenn ich schaue, was auf unseren Firmenservern so lost ist ... dann ist der Berühmte Satz der "Script-Kiddies" schon seit Jahren obsolet. heute sitzen "auf der anderen Seite" Profis .... und das schon ziemlich lange ..
Zum Glück für die meisten, gibt es aktuell noch Leute, die noch schlechter abgesichert sind.
(Achtung: "Glück" ist hier sehr ironisch gemeint)