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

[joerg_rw]

nur was ueber logger auf syslogd auflaeuft.
Man koennte natuerlich sowas machen wie ein Umleiten eines gesamten "cat lighttpd" auf logger. Als alternative zum per mail verschicken z.B.
bzw: in

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

irgendwo am ende statt "tee -a /tmp/access.txt" ein "logger -t 'access.txt_TAG' -s" reinbauen und auf dem logserver dann entsprechend filtern und in eine eigene datei (access.txt?) schreiben

[Xel66]

... Umleiten eines gesamten "cat lighttpd" auf logger. Als alternative zum per mail verschicken z.B.

Benötige ich alles nicht. Ziel der Übung war ja, explizit unbekannte Adressen (außerhalb des eigenen Netzwerkes und der Adressen von Alexa und Cloudmatic) zu erfassen und diese (und nur diese!) Daten per Push, Mail or whatever als Warnung zuzusenden. Ein Eintrag in einem Log als eine unter Millionen Meldungen hilft mir nicht weiter. Ich möchte explizit Fremdzugriffe erkennen und warnen. Ein globales Log ist für diese Aufgabe ungeeignet. Ich benötige genau diesen einen Trigger und einen vollständig autarken Meldeweg schon während eines Angriffsversuchs.

Gruß Xel66

[joerg_rw]

Ein Eintrag in einem Log als eine unter Millionen Meldungen

Deswegen der ``-t 'access.txt'´´ (--tag) am logger Befehl, mit dem kann der empfangende rsyslogd auf dem logserver genau diese und nur diese loglines filtern und in ein eigenes file schreiben. Im Endeffekt hast Du am Schluss genau die gleiche access.txt Datei nur halt auf dem remote logserver und vermutlich dort dann in /var/log/ anstatt in /tmp/, und sie ist immanent schreib/loeschgeschuetzt gegenueber einem Angreifer der sich auf die CCU einloggen konnte.Das zeitversetze Versenden per mail kannst Du immer noch machen wenn du willst, aber wenn Du das auf der CCU machst dann besteht die Gefahr dass das nie stattfindet weil vorher schon alles gekapert und ausgehebelt wurde.

Ich benötige genau diesen einen Trigger und einen vollständig autarken Meldeweg schon während eines Angriffsversuchs

Eben. Das gelingt am sichersten wenn der Zugriff *sofort* auf ein anderes System geloggt wird, noch bevor die erste boesartige URL die CCU zum Absturz gebracht hat. Aber klar kann man das auch so machen wie du skizziert hast, ich wollte nur drauf hinweisen dass die CCU serienmaessig remote logging unterstuetzt und das ist eigentlich das Mittel der Wahl fuer genau so einen Anwendungsfall.

Sieht auf einem meiner Systeme so aus

Code: Alles auswählen

/sbin/syslogd -n -m 0 -s 4096 -b 1 -D -R 192.168.178.21 -L

[aus htop] - Ich hab nur in der WebUI wie weiter oben beschrieben die IP Adresse eingetragen
Auf meinem logserver PC ist in /etc/rsyslog.conf dann sowas un der Art:

Code: Alles auswählen

# HOMEMATIC  messages into separate file and stop their further processing
#
if      ($hostname == 'homematic') \
then    /var/log/homematic
&       stop

cheers
jOERG

[Xel66]

Im Endeffekt hast Du am Schluss genau die gleiche access.txt Datei nur halt auf dem remote logserver und vermutlich dort dann in /var/log/ anstatt in /tmp/...

Das habe ich doch alles schon und will das gar nicht. Und das war gar nicht Intension dieser Bemühungen. Ich habe die zugreifende IP separat in einer Systemvariable und kann diese als Trigger für Programme (Push, Mail etc.) nutzen. Es nützt mir also was. Wenn in irgendeinem Log auf meinem Logserver irgendwas geloggt wird (das Syslog der CCU da drauf reicht mir), dann hilft mir das nicht mal im Ansatz. Es ist schlichtweg überflüssig. Das mit dem lokalen /tmp ist eben ein Hilfsmittel für die Aufbereitung und den Versand der Daten, da ich diese Daten eben nicht auf einen lokalen Datenträger (SD, USB etc.) schreiben will und ich sie nicht in /var/log der CCU haben will. Auf dem Logserver brauche ich sie auch nicht.

Ich bekomme alle relevanten Daten relativ kurzfristig zugesandt und kann auch noch ein Licht leuchten lassen oder was auch immer mir einfällt, weil ich ja einen Trigger habe, den ich für solche Aktionen benutzen kann. Ein zusätzlicher Logeintrag (auf einem Server zu Hause) ist weder notwendig noch gewünscht. Er ist schlichtweg überflüssig. Die detaillierten Zugriffslogs habe ich doch. Ich möchte eben alle relevanten Daten per Mail oder Push, wo auch immer ich in der Welt mich rumtreibe, so dass ich ggf. darauf reagieren kann (oder auch nicht, wenn ich der Zugreifende selbst war). Intension war eine automatische Warnung und kein Log. Projektvorstellung der funktionierenden Lösung kommt noch. Habe im Moment nur wenig Zeit.

Gruß Xel66

[jmaus]

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

Wollt ihr das denn?

[Xel66]

Wollt ihr das denn?

Nee, nicht wirklich, wenn ich mir anschaue, was da so aufläuft. Betrachte ich eher als hyperliquide.

Gruß Xel66

[Baxxy]

Nee bloß nicht.
Wenn man Jack drauf hat und ggf. noch einen HA über die Integration dranhängt kann man sich vor Logs kaum retten.

Da wäre eher eine Filteroption für "vertrauenswürdige Zugriffe" sinnvoll.

[joerg_rw]

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

Wollt ihr das denn?

noe, es ging eher ganz allgemein um

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.

und wie ein remote-syslog eben relativ immun gegen nachtraegliches loeschen/verfaelschen ist, selbst wenn system von dem das log stammt, kompromitiert wurde. Ich hab remote logging fier einige CCUs am laufen und ich verwende in eigenen skripts gerne mal ein

logger -t ${unique.tag}

[Xel66]

und wie ein remote-syslog eben relativ immun gegen nachtraegliches loeschen/verfaelschen ist, selbst wenn system von dem das log stammt, kompromitiert wurde.

Wenn jemand soweit eingedrungen ist, um auf Systemebene Logs zu löschen bzw. zu verändern, ist diesem auch zuzutraun, dass das loggende System ebenfalls kompromitiert wurde. Die erste Maßnahme wäre das umkonfigurieren der Adresse des externen Loghosts. Insofern haben wie ein Henne-Ei-Problem. Und "Beweissicherung" ist nicht die Aufgabe dieser Lösung gewesen, sondern eine direkte Warnung beim Zugriff auf den Webserver der CCU, um ggf. Gegenmaßnahmen einleiten zu können.

Gruß Xel66

[joerg_rw]

Wenn jemand soweit eingedrungen ist, um auf Systemebene Logs zu löschen bzw. zu verändern, ist diesem auch zuzutraun, dass das loggende System ebenfalls kompromitiert wurde.

Das haengt (gluecklicherweise) vom Einzelfall ab und stellt sich in meinen Systemen anders dar. Da laeuft auf dem logserver keine remote-scripting API oder aehnliches, tatsaechlich laeuft auf denen gar nichts was "nach aussen" so ohne weiteres ansprechbar waere.

cheers
jOERG