Wie in einem der vorhergehenden Artikel beschrieben, beschäftige ich mich mit Gedankenexperimenten zum Thema Certificate Authority. Hier nun ein weiterer Aspekt dazu...
Ich wollte eigentlich vorschlagen, den Nutzer, der mit der CA arbeitet, zu auditieren - lies: ich wollte alle seine Interaktionen mit dem System in einem Logfile speichern.
Dazu fand ich verschiedene Lösungen für Linux, darunter Snoopy und rootsh. Von beiden gefiel mir rootsh eigentlich besser, da ich hier in der Lage bin, dies als Login-Shell für einzelne Nutzer zu definieren. Bei Snoopy dagegen habe ich nur die Chance, zwischen "loggt nur root" und "loggt alle Nutzer" zu wählen.
Nachdem ich nun rootsh ausprobieren wollte, musste ich feststellen, dass es dafür kein Debian-Paket gibt und man es daher aus den Quellen installieren muss. Das wäre eigentlich weiter kein großes Problem - aber die Letzte Änderung an dem Paket liegt schon Jahre zurück. Daher sollte man ja generell vorsichtig sein - wenn OpenSource-Software nicht mehr gewartet wird, kann es sein, dass Fehler drin sind... Im Produktivsystem plädiere ich daher wahrscheinlich doch für Snoopy...
Nach dem Auspacken des Quellcode-Archivs
sudo -i
./configure --disable-logfiles --disable-linenumbering
make
make install
Anschließend habe ich noch /etc/shells erweitert.
Danach kann man rootsh bereits als Login-Shell einrichten. Tut man das zu diesem Zeitpunkt, werden alle Interaktionen jedes Users, der rootsh als Login-Shell eingerichtet hat, ins syslog geschrieben. Um das abzustellen, habe ich folgende Zeile in (Ubuntu!) /etc/rsyslog.d/50-default.conf hinzugefügt:
local5.* /var/log/local5
Damit werden alle Meldungen von rootsh zusätzlich in /var/log/local5 gespeichert. Damit benötigen wir sie im syslog nicht mehr - daher wurde wieder in /etc/rsyslog.d/50-default.conf folgende Zeile
*.*;auth,authpriv.none -/var/log/syslog
in
*.*;auth,authpriv.none,local5.none -/var/log/syslog
geändert. Natürlich muss man beim Einsatz von rootsh dafür sorgen, dass Nutzer ihre eigene Login-Shell nicht ändern dürfen.
Als Ausblick sei hier noch angemerkt, dass das Material aus diesem Audit nur dann Sinn macht, wenn das Log auf einem entsprechenden Syslog-Server ausgelagert wird...
Keycloak, OTP, FIDO
11.06.2021
Ich berichtete neulich über die Installation und erste Tests von Keycloak. Nun bin ich tiefer eingetaucht und habe die diversen Möglichkeiten untersucht, die Authentifizierung mittels zweiten Faktors sicherer zu machen.
WeiterlesenAI und ML Android Basteln C und C++ Chaos Datenbanken Docker dWb+ ESP Wifi Garten Geo Go GUI Hardware Java Jupyter JupyterBinder Komponenten Links Linux Markdown Markup Music Numerik OpenSource PKI-X.509-CA Präsentationen Python QBrowser Rants Raspi Revisited Security Software-Test sQLshell TeleGrafana Verschiedenes Video Virtualisierung Windows Upcoming...
In meinem letzten Artikel zum Thema dWb+ beschrieb ich ein neues Feature der Lösung - nunmehr wende ich mich einer wichtigen nichtfunktionalen Anforderung zu
WeiterlesenEin weiteres Self-Hosting-Experiment hat zu zwei neuen Diensten in meinem Docker-Zoo geführt...
WeiterlesenNach meinen Erfolgen mit einem TPM in der Version 1.2 zur Absicherung von SSH-Verbindungen wollte ich versuchen, seine Funktionalität in Java-Anwendungen zu integrieren...
WeiterlesenManche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.
Wer daran teilhaben und eventuell sogar davon profitieren möchte, muss damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.
Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...
PS: Meine öffentlichen Codeberg-Repositories findet man hier.