Zugrifffe auf das Webinterface einer CCU/RM loggen/überwachen

[Henke]

">> /tmp/access.txt" ersetzen durch ein tcl Script.
Da die Datei als Log beschreiben und gefiltert direkt die Systemvariable setzen.
Damit fällt der zyklischer Aufruf weg.

[Xel66]

">> /tmp/access.txt" ersetzen durch ein tcl Script.

Gute Idee! Danke erst mal. Ich denke mal, das muss ich irgendwie pipen. Oder parallel mit tee in die Datei schreiben und ans Script senden. Ich hirne das mal.

EDIT: So habe die Ausgabe schon mal testweise mit tee gesplittet und habe jetzt eine parallele Ausgabe in die Datei und per less auf der Konsole. Das less möchte ich dann mit dem Script ersetzen. Im Moment sieht es als Konsolenbefehl so aus:

Code: Alles auswählen

tail -f /var/log/lighttpd-access.log  | awk '!/^192.168.178.3/ && !/^192.168.178.252/ && !/^127.0.0.1/ { print $0 }' | tee -a /tmp/access.txt | less

Soweit alles gut. Das TCL-Script für das Schreiben der Systemvariable macht mir noch Probleme. Der String wurde auch schon aus $argv und dem Rest des Aufrufes korrekt zusammengebaut. Es schreibt aber nicht in die Sytemvariable. Bin mir eigentlich sicher, dass meine Syntax korrekt ist.
EDIT2: Das war ein PEBCAK. Ich habe nun ein Script, welches erst mal das tut, was es soll. Es schreibt einen übergebenen Parameter in eine Systemvariable. Die Scriptidee stammt aus dem Forum und dies ist der aktuelle Bearbeitungsstand ohne jegliches Fehlerhandling. Da baue ich dann noch was ein.

Code: Alles auswählen

#!/usr/bin/env tclsh
load tclrega.so
# tclrega.so available. Get Metadata from ReGaHss
        set isecmd ""
        set state $argv
        append isecmd "var x = dom.GetObject('Watchdog-Access');"
        append isecmd "x.State('"
        append isecmd $state
        append isecmd "');"
        rega_script $isecmd
	puts $isecmd

Was ich jetzt nicht hinbekomme ist, die Bildschirmausgabe, die im obigen String in eine Datei geschrieben wird, in einen Aufruf des Scripts (chown ist erledigt) zu pipen. Ich finde im Netz viele Wege, aus TCL-Scripts Daten zu übergeben, aber eben keinen das was sonst auf die Konsole geschrieben würde als Argument in das Script zu pipen. Hat da jemand eine Idee? Derzeit extrahiere ich mit awk zyklisch das erste Datenfeld aus der access.txt (das ist die aufrufende IP) per Homematic-Script in eine Systemvariable.

Was ich letztendlich eigentlich möchte, orientiert sich an obigen Befehl. Tail übergibt die letzte Zeile an awk (funktioniert) und awk filtert die Zeilen mit bekannten Adressen raus (funktionert auch noch) diese Ausgabe schreibe ich derzeit nach access.txt. An dieser Stelle hätte ich eben gern das Script, welches die letzte Zeile in eine Sysvar schreibt (bzw. nur die IP). Also letztendich soll der vorgelagerte Filterweg das Script mit seiner Ausgabe triggern, so wie sonst der Schreibvorgang mit >> in eine Datei getriggert wird.

Andere Idee: Ich setze noch mal eine zweite tail/awk-Instanz auf den Output in der access.txt an. Aber auch dieser Output müsste ja wieder das Script triggern. Ich drehe mich im Kreis. Hmmm... EDIT: habe xargs gefunden. Mal schauen, ob das auf der CCU existiert. Sitze derzeit nicht davor. To be continued.

Gruß Xel66

[Xel66]

Zusatzfrage: Kennt sich jemand mit dem Logrotate aus? Wenn ich die /etc/logrotate.d/syslogd.conf richtig verstehe, werden alle *.log-Dateien bei einer Größe größer 2MB rotiert und eine neue .log angelegt. Heißt für mich, wenn ich meine "access.txt" als "access.log" in /var/log ablegen würde, würde der Job diese Datei auch mit behandeln. Somit hätte ich noch ein Langzeitarchiv (natürlich nur bis zum Löschen) für die unbekannten Zugriffe von außerhalb meines Netzwerkes. So viel fällt da ja nicht an (gelegentliche Fernzugriffe via VPN, cloudmatic und die Alexa-Steuerung). Das sollte also das System nicht zumüllen. Man kann ja zyklisch aufräumen. Kann meine Annahme jemand bestätigen?

Gruß Xel66

[jmaus]

Zusatzfrage: Kennt sich jemand mit dem Logrotate aus? Wenn ich die /etc/logrotate.d/syslogd.conf richtig verstehe, werden alle *.log-Dateien bei einer Größe größer 2MB rotiert und eine neue .log angelegt.
[...]
Das sollte also das System nicht zumüllen. Man kann ja zyklisch aufräumen. Kann meine Annahme jemand bestätigen?

Ruf einfach

Code: Alles auswählen

/usr/sbin/logrotate -v /etc/logrotate.conf

Auf der Kommandozeile auf um zu sehen was passiert.

Also ja, es werden alle *.log Dateien unter /var/log und unterverzeichnissen darunter mit in das logrotate einbezogen. Im übrigen wird es in Zukunft bei RaspberryMatic auch möglich sein eigene logrotate config files unter /usr/local/etc/logrotate.d abzulegen, sodass man dann eigene regeln zusätzlich zu den in der syslogd.conf definieren kann die dann auch teil des Backups werden.

[Xel66]

Ruf einfach

Code: Alles auswählen

/usr/sbin/logrotate -v /etc/logrotate.conf

Auf der Kommandozeile auf um zu sehen was passiert.

Getan: Für mich sieht das funktional aus. Eine neue Logdatei wurde erkannt und ein "new state" angelegt. Sollte dann demnächst mit dabei sein. Die relevante Ausgabe:

Code: Alles auswählen

considering log /var/log/alien-access.log
Creating new state
  Now: 2023-11-09 16:46
  Last rotated at 2023-11-09 16:00
  log does not need rotating (log size is below the 'size' threshold)

Danke nochmals. Ich denke mal, für eigene Logrotates fehlt der breite Anwenderkreis. Aber lieber haben als brauchen. Ich wurstle mich auch gerade mit meinem Projekt durch und bin in der Erprobungsphase meiner Loglösung. Bisher bin ich zufrieden. Die Idee von Henke mit dem Senden an ein Script war nicht schlecht. Funktioniert. Danke. Stelle das dann später mal als Projekt vor. Ich bin auch der Meinung, dass damit Leute mit einem Problem (z.B. eingerichteter Portweiterleitung oder fremde User im WLAN, weil die Kids den Key an die Kumpels gegeben haben) ganz schnell aufgeschreckt wären, wenn sie ständig Meldungen von fremden Zugriffen (z.B. Bots oder eben die Kids) erhielten. Von den Scriptkiddies will ich noch gar nicht reden, aber die sind meine eigentliche Zielgruppe.

Gruß Xel66

[MichaelN]

In der RaspberryMatic wird ja jetzt schon vor offenen Ports gewarnt und trotzdem wird das regelmäßig ignoriert. Das ist dann eben nur eine weitere Meldung die ignoriert wird.

Logs zur Beweissicherung wären im Nachhinein zwar auch hilfreich, aber wenn die CCU die schreiben kann, dann kann man sie von dort auch löschen.

[Xel66]

Logs zur Beweissicherung wären im Nachhinein zwar auch hilfreich, aber wenn die CCU die schreiben kann, dann kann man sie von dort auch löschen.

Soweit richtig. Ein Neustart und sie wären ja auch weg. Darum habe ich mir auch Gedanken gemacht. Ziel ist es, dass bei einem Zugriff (schon beim ersten!) eine Warnung (Telegram mit IP) rausgeht und relevante Logs per Mail an einen separaten Account (nicht der Versand-Account auf der CCU) geschickt wird. Soweit funktioniert das auch alles. Dieses Verfahren (Log-Versand) praktiziere ich auch schon eine Weile z.B. bei staken Anstiegen des Duty Cycles.

Auf der Startseite steht derzeit immer die letzte "Alien"-IP und der Status der Überwachung (zyklisch per pgrep -x ausgelesen) in zwei Systemvariablen. Bei Änderung der Watchdog-Systemvariable wird sofort ein Programm getriggert, welches die IP umgehend versehen mit einer Warnung per Telegram versendet. Zeitverzögert geht das alien-access.log per Mail raus, in dem ich hoffentlich das Angriffsmuster sehe. Ich filtere derzeit ein paar lokale IPs sowie meinen Zugriff per meine-homematic raus. Der Rest wären eben unautorisierte Zugriffe (zumindest auf die WebUI).

Gruß Xel66

[joerg_rw]

Logs zur Beweissicherung wären im Nachhinein zwar auch hilfreich, aber wenn die CCU die schreiben kann, dann kann man sie von dort auch löschen.

Ausser man macht remote logging (Einstellungen ->Sstemsteuerung ->ZentralenWartung "Fehlerprotokoll: Syslog-Server Adresse") Das hat zwar seine eigenen Schwaechen, vor allem auf dem logger Rechner, weil dort im Standardfall nicht geprueft wird wer da loggt und ob der das darf, aber... LOESCHEN geht nicht so ohne weiteres.

jOERG

[Baxxy]

Werden die lighttpd-Logs überhaupt an den Syslogserver weitergeleitet?

[Xel66]

Nö.