Wunzlmann Posted January 31 Share Posted January 31 Aktuell werden Zugriffe (Logins) auf den MediaServer in der svcusers.log gespeichert. Besteht die Möglichkeit diese Zugriffe als Event in der Ereignisanzeige abzubilden? Falls nein, besteht die Möglichkeit das als Feature für den MediaServer mitaufnehmen? Quote Link to comment
Griga Posted February 1 Share Posted February 1 Am 31.1.2024 um 19:54 schrieb Wunzlmann: Besteht die Möglichkeit diese Zugriffe als Event in der Ereignisanzeige abzubilden? Nein. Am 31.1.2024 um 19:54 schrieb Wunzlmann: Falls nein, besteht die Möglichkeit das als Feature für den MediaServer mitaufnehmen? Wahrscheinlich ja, aber wozu? Quote Link to comment
Wunzlmann Posted February 1 Author Share Posted February 1 1 hour ago, Griga said: Wahrscheinlich ja, aber wozu? Der Hintergrund meiner Anfrage ist, dass die IP Adressen fehlerhafter Loginversuche über einen rsyslog Clienten an einen ReverseProxy (nginx) auf dem fail2ban läuft weitergeleitet werden sollen und mir aktuell keine andere Möglichkeit einfällt, dies zu realisieren. Quote Link to comment
Griga Posted February 3 Share Posted February 3 Der Media Server bestückt bereits die Ereignisanzeige -> Windows-Protokolle -> Anwendung. Die Quellangabe ist der Servicenamen "DVBVRecorder". Das beschränkt sich aber auf Meldungen, die die Service-Funktionalität betreffen. Notiert wird dort der erfolgreiche Start (etwas unglücklich als "Media Server Create" formuliert, werde ich ändern) sowie der Stop. Wahrscheinlich finden dort auch Fehlermeldungen bei misslungenem Start/Stop Eingang. Diese Möglichkeit ist bereits in der Service-Basisklasse implementiert, auf der der Media Server aufbaut. Sie funktioniert allerdings nur, solange der Media Server als Service läuft. Startet man ihn als Anwendung, fehlen ihm die Rechte für die Ereignisanzeige. Insofern wäre es wohl kein Problem, weitere Meldungen zu ergänzen. Allerdings ist dein Vorhaben Am 1.2.2024 um 23:42 schrieb Wunzlmann: dass die IP Adressen fehlerhafter Loginversuche über einen rsyslog Clienten an einen ReverseProxy (nginx) auf dem fail2ban läuft weitergeleitet werden sollen ziemlich partikulär, bringt also für andere Anwender nichts, denen unnütz in die Ereignisanzeige geschrieben wird, auch wenn es sich auf Login-Fehlversuche beschränkt (oder möchte das sonst jemand haben?). Die Implementation solcher Anwenderwünsche ist eine ziemlich sichere Methode, eine Anwendung mit der Zeit zu ruinieren und unwartbar zu machen. Jedes Feature muss bei zukünftigen Änderungen Berücksichtigung finden, auch, wenn es nur optional ist, wobei mangels Telemetrie in Zukunft unbekannt bleibt, ob es überhaupt noch jemand nutzt. Es fehlt also der allgemeine Nutzen, d.h. selbst bei vertretbarem Implementationsaufwand ist das Aufwand/Nutzen-Verhältnis schlecht. Ich frage mich, ob sich das nicht auch auf andere Weise realisieren lässt. Eine Reverse Proxy sollte "401 Unauthorized"-Antworten des Media Servers eigentlich mitbekommen und auch, wenn sie gehäuft eine Client-IP-Adresse betreffen. Übrigens enthält der Media Server selbst Schutzmaßnahmen bei Zugriffen aus anderen Netzen als seinem. Standardmäßig greift eine gewisse Verzögerung, die automatisierte Brute Force-Attacken auf das Webserver-Passwort erschwert. Außerdem gibt es eine per Tweak aktivierbare verschärfte Variante, die solche Angriffe scheitern lässt, selbst wenn sie zufällig das richtige Passwort probieren. Darüber informiere ich bei Bedarf (und nicht öffentlich). Quote Link to comment
Trill Ian Posted February 3 Share Posted February 3 Du solltest lieber überlegen, ob es nicht sinnvoller wäre, dem NGINX die User/Passwort Abfrage zu überlassen und bei Fehlschlag dort gleich zu sperren. Der Mediaserver kennt ja nur "gast" und "admin". Die kann man zwar umbenennen, aber keine feinen Abstufungen einrichten. Beim NGINX kannst Du eine eigenen Benutzerverwaltung einrichten, mit vielen Usern. Allerdings wird es etwas diffizil, zu entscheiden, wann Admin und wann Gast anzuwenden ist. Eventuell deshalb ZWEI NGinx Einträge. Zumindest hast Du dann ohne großen Aufwand die fail2ban Daten verfügbar und kannst die Aktionen direkt aufrufen. Quote Link to comment
Wunzlmann Posted February 3 Author Share Posted February 3 Erstmal Danke für die Rückmeldungen. 1 hour ago, Griga said: Der Media Server bestückt bereits die Ereignisanzeige -> Windows-Protokolle -> Anwendung. Die Quellangabe ist der Servicenamen "DVBVRecorder". Das beschränkt sich aber auf Meldungen, die die Service-Funktionalität betreffen. Notiert wird dort der erfolgreiche Start (etwas unglücklich als "Media Server Create" formuliert, werde ich ändern) sowie der Stop. Wahrscheinlich finden dort auch Fehlermeldungen bei misslungenem Start/Stop Eingang. Genau, die "Media Server Create" und "Media Server Stop" Ereignisse sind dort gelistet. 1 hour ago, Griga said: Die Implementation solcher Anwenderwünsche ist eine ziemlich sichere Methode, eine Anwendung mit der Zeit zu ruinieren und unwartbar zu machen. Jedes Feature muss bei zukünftigen Änderungen Berücksichtigung finden, auch, wenn es nur optional ist, wobei mangels Telemetrie in Zukunft unbekannt bleibt, ob es überhaupt noch jemand nutzt. Das kann ich abschätzen, vermute aber das auch die "svcusers.log" den meisten Usern unbekannt ist und tatsächlich nur im Fehlerfall Verwendung findet. 1 hour ago, Griga said: Es fehlt also der allgemeine Nutzen, d.h. selbst bei vertretbarem Implementationsaufwand ist das Aufwand/Nutzen-Verhältnis schlecht. Ich frage mich, ob sich das nicht auch auf andere Weise realisieren lässt. Eine Reverse Proxy sollte "401 Unauthorized"-Antworten des Media Servers eigentlich mitbekommen und auch, wenn sie gehäuft eine Client-IP-Adresse betreffen. Guter Ansatz, ich werde mal recherchieren, ob es möglich ist einen HTTP-Status-Code abzufangen, der von einer Anwendung hinter dem ReverseProxy generiert wird. 1 hour ago, Griga said: Übrigens enthält der Media Server selbst Schutzmaßnahmen bei Zugriffen aus anderen Netzen als seinem. Standardmäßig greift eine gewisse Verzögerung, die automatisierte Brute Force-Attacken auf das Webserver-Passwort erschwert. Außerdem gibt es eine per Tweak aktivierbare verschärfte Variante, die solche Angriffe scheitern lässt, selbst wenn sie zufällig das richtige Passwort probieren. Darüber informiere ich bei Bedarf (und nicht öffentlich). Evtl. komme ich darauf nochmal zurück. 48 minutes ago, Trill Ian said: Du solltest lieber überlegen, ob es nicht sinnvoller wäre, dem NGINX die User/Passwort Abfrage zu überlassen und bei Fehlschlag dort gleich zu sperren. Der Mediaserver kennt ja nur "gast" und "admin". Die kann man zwar umbenennen, aber keine feinen Abstufungen einrichten. Beim NGINX kannst Du eine eigenen Benutzerverwaltung einrichten, mit vielen Usern. Allerdings wird es etwas diffizil, zu entscheiden, wann Admin und wann Gast anzuwenden ist. Eventuell deshalb ZWEI NGinx Einträge. Zumindest hast Du dann ohne großen Aufwand die fail2ban Daten verfügbar und kannst die Aktionen direkt aufrufen. Grundsätzlich wäre das sicher möglich, im FAQ wird auf diese Möglichkeit auch hingewiesen. Nur ließt es sich so, als ob lokal dann nach keiner Authentifizierung mehr gefragt wird (was grundsätzlich in einem sicheren Netzwerk kein Beinbruch wäre, aber man weiß ja nie). Die Idee ist (sofern eben möglich) die Authentifizierung weiterhin dem MediaServer zu überlassen, mit der Hoffnung auf dessen Log zuzugreifen. Ich habe auch schon versucht, das Ganze erst mit der Überwachungsfunktion von Dateien/Ordner in Windows zu realisieren. D.h. sobald sich die Datei "svcusers.log" ändert soll ein Eventeintrag kommen und basierend auf diesem Trigger ließt man dann die letzte Zeile aus dem log. Leider scheinen sich die jeweiligen Logeinträge bei Login(versuchen) nicht immer sofort in einer protokollierbaren Änderung der Datei widerzuspiegeln, deswegen taucht nur sporadisch ein Eventeintrag auf und nicht bei jedem neuen Eintrag in der log Datei. Wenn ich aktiv in einer Datei etwas verändere funktioniert dieser Ansatz sofort und jedes Mal. Das gleiche Verhalten wie bei der Überwachungsfunktion sieht man auch bei einem PowerShell Script und einem FileWatcher auf die "svcusers.log". Es ist wohl so, dass der Ansatz der Überwachung mit Dateiänderungen im Hintergrund nicht funktioniert. Falls eine Implementierung von diesen weiteren Events in der Ereignisanzeige wegen dem Edge use case nicht gewünscht ist, wird es wohl auf die Möglichkeit der Authentifizierung direkt in nginx hinauslaufen bzw. auf die Ergebnisse der Recherche bzgl. des HTTP-Status-Code. Quote Link to comment
Trill Ian Posted February 3 Share Posted February 3 vor 2 Stunden schrieb Wunzlmann: Nur ließt es sich so, als ob lokal dann nach keiner Authentifizierung mehr gefragt wird (was grundsätzlich in einem sicheren Netzwerk kein Beinbruch wäre, aber man weiß ja nie). Das liest sich falsch. Du musst vom Proxy aus eigene Anmeldedaten (nicht die, die der Proxy bekommen hat) mitschicken. Lokal angsprochen fehlen die ja, da will der Mediaserver wieder seine normale Anmeldung. vor 2 Stunden schrieb Wunzlmann: Ich habe auch schon versucht, das Ganze erst mit der Überwachungsfunktion von Dateien/Ordner in Windows zu realisieren. Der Ansatz ist ja schon prinzipiell zum Scheitern verursacht. Jedes OS hat doch nun einen Schreibcache und die neuen Einträge werden somit nicht sofort auf die Disk geschrieben. Manchmal dauert es mehrere Minuten, bis ein "Flush" ausgeführt wird. Das ist also russisches Roulette mit 5 Kugeln. vor 2 Stunden schrieb Wunzlmann: Es ist wohl so, dass der Ansatz der Überwachung mit Dateiänderungen im Hintergrund nicht funktioniert. Jep, hätte man eher drauf kommen können, statt solche Verrenkungen zu machen Quote Link to comment
Wunzlmann Posted February 3 Author Share Posted February 3 Also die Idee mit der Authentifizierung über nginx ist diejenige gewesen, die ich jetzt umgesetzt habe. Es geht tatsächlich ziemlich einfach. Falls sich jemand auch die gleiche Frage gestellt hat, einfach dieser Anleitung folgen. Fehlerhafte Loginversuche kann man sich dann aus der error.log von nginx holen. Mithilfe der access.log von nginx hätte man auch die Idee mit dem HTTP-Status-Code wahrscheinlich umsetzen können. Manchmal ist die Lösung einfacher als gedacht, danke für die Anregung 😄 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.