Einrichten von containerisierten SSH-Servern für die Sitzungsaufzeichnung mit tlog

Im ersten Teil dieser Serie habe ich einige der Vorteile der Sitzungsaufzeichnung und der Verwendung von containerisierten SSH-Servern hervorgehoben. Ich habe auch eine High-Level-Architektur präsentiert. Als vorbereitender Schritt wurde einer der Server mit RHEL 8.2 konfiguriert, um die Rootless-Container des SSH-Servers zu erstellen und zu hosten.

Nachdem Sie den Server vorbereitet und den Benutzer erstellt haben (tester2 ) erstellen wir ein benutzerdefiniertes Dockerfile für den SSH-Server mit konfigurierter Sitzungsaufzeichnung.

In der folgenden Dockerfile verwenden wir das ubi-init (Multi-Service)-Image, das systemd unterstützt und hat die CMD /sbin/init als Standard zum Starten von systemd init-Dienst. Für dieses Setup gelten die folgenden Annahmen.

• Der Dienst macht Port 2022 statt 22 in einem Container für SSH verfügbar
• Konfigurieren Sie drei Benutzer (nämlich tester , tester2 und tester3 )
• Verwenden Sie dieselbe UID für den Containerbenutzer tester als Benutzer (tester2 ) den Rootless-Container auf dem Host ausführen, sodass dieser Benutzer Root innerhalb des Containers sein kann
• UID für tester ändern innerhalb des Containers als 0 (root)
• SSH-Schlüssel als Build-Argumente für den Benutzer tester konfigurieren und tester2 und eine passwortbasierte Anmeldung für tester3
• Sitzungsaufzeichnung für Benutzer tester2 konfigurieren und tester3 indem Sie die Login-Shell als /usr/bin/tlog-rec-session festlegen
• Persistente Volumes für /home zuordnen und /var/log/journal während der Containererstellung, um die Home-Verzeichnisse der Benutzer und SSH-Dienst- und Sitzungsaufzeichnungsprotokolle aufzubewahren
• Kopieren Sie die tlog-rec-session.conf vom Host in den Container mit der folgenden Konfiguration zum Erfassen von Sitzungsaufzeichnungsprotokollen mit journald :

{"shell":"/bin/bash","notice":"\nATTENTION! Your session is being recorded!\n\n","latency":10,"payload":2048,"log":{"input":false,"output":true,"window":true},"limit":{"rate":16384,"burst":32768,"action":"pass"},"file":{"path":""},"syslog":{"facility":"authpriv","priority":"info"},"journal":{"priority":"info","augment":true},"writer":"journal"}

[ Testen Sie die Sitzungsaufzeichnung in einem Live-Lab: Konfigurieren der Terminal-Sitzungsaufzeichnung ]

Dockerfile für SSH-Container

Hier ist ein Dockerfile-Beispiel für den SSH-Container:

FROM ubi8/ubi-init

ARG ADMIN_PUBLIC_KEY
ARG TESTER2_PUBLIC_KEY

RUN yum -y install openssh-server ed openssh-clients tlog glibc-langpack-en && yum clean all && systemctl enable sshd;
RUN sed -i 's/#Port.*$/Port 2022/' /etc/ssh/sshd_config && chmod 775 /var/run && rm -f /var/run/nologin
RUN mkdir /etc/systemd/system/sshd.service.d/ && echo -e '[Service]\nRestart=always' > /etc/systemd/system/sshd.service.d/sshd.conf

COPY tlog-rec-session.conf /etc/tlog/tlog-rec-session.conf
RUN adduser --system -s /bin/bash -u 1001 tester && \ #UID matching user uid on host
           adduser --system -s /usr/bin/tlog-rec-session -u 1000 tester2 && \
           adduser --system -s /usr/bin/tlog-rec-session -u 1002 tester3 -p y5utxaxUDNFII && \
           mkdir -p /home/tester/.ssh /home/tester2/.ssh /home/tester3/.ssh

RUN touch /home/tester/.ssh/authorized_keys /home/tester2/.ssh/authorized_keys /home/tester3/.ssh/authorized_keys && \
           chmod 700 /home/tester/.ssh /home/tester2/.ssh /home/tester3/.ssh && \
           chmod 600 /home/tester/.ssh/authorized_keys /home/tester2/.ssh/authorized_keys /home/tester3/.ssh/authorized_keys && \
           sed -i 's/1001/0/g' /etc/passwd && \ #Update UID with root UID
           echo ${ADMIN_PUBLIC_KEY} >> /home/tester/.ssh/authorized_keys && \
           echo ${TESTER2_PUBLIC_KEY} >> /home/tester2/.ssh/authorized_keys && \
           chown -R tester2:tester2 /home/tester2/ && chown -R tester3:tester3 /home/tester3/ && chown -R tester:tester /home/tester
LABEL Description="This ssh server is running systemd with rootless podman"
EXPOSE 2022

CMD ["/sbin/init"]

Speichern Sie die Datei im Home-Verzeichnis als sshdockfile. Kopieren Sie die Standarddatei /etc/tlog/tlog-rec-session.conf in das Home-Verzeichnis.

Container-Image erstellen

Um das Container-Image mit den gewünschten Schlüsseln zu erstellen, generieren Sie ein neues Schlüsselpaar für den Benutzer. Exportieren Sie als Nächstes den Standard- und den neu erstellten öffentlichen Schlüssel als Variablen. Übergeben Sie sie schließlich als Build-Argumente, indem Sie Folgendes verwenden. Hier ist der Prozess:

# ssh-keygen-t ecdsa ; ssh-keygen -t ecdsa -f .ssh/tester2

# export ADMIN_PUBLIC_KEY=`cat /home/test2/.ssh/id_ecdsa.pub`

# export TESTER2_PUBLIC_KEY=`cat /home/test2/.ssh/tester2.pub`

# podman build -t testsshd -f sshdockfile --cgroup-manager=cgroupfs --build-arg ADMIN_PUBLIC_KEY="$ADMIN_PUBLIC_KEY" --build-arg TESTER2_PUBLIC_KEY="$TESTER2_PUBLIC_KEY"

Der cgroup-manager Das Argument erfordert cgroups-v2 und ist notwendig, damit der Rootless-Container systemd verwenden kann erfolgreich. Podman meldet den folgenden Fehler, wenn dieses Argument nicht übergeben wird:

systemd cgroup flag passed, but systemd support for managing cgroups is not available: OCI runtime error

Wenn der Build erfolgreich ist, besteht der nächste Schritt darin, den Container mit den gewünschten persistenten Volumes auszuführen. Diese Bände (für /var/log/journal und /home ) sind entweder vorab erstellt oder Podman erstellt sie dynamisch im volume Verzeichnis unter dem Standardspeicherort (podman info | grep -i graphroot ).

Führen Sie den SSH-Server aus

Da die Rootless-Container keine CNI-Plugins für Netzwerke unterstützen, wird ein bevorzugter höherer Port (>1024) zugeordnet, um den SSH-Dienst verfügbar zu machen.

# podman run -d --name=rootless_ssh1 -v ssh1home:/home:Z -v ssh1logs:/var/log/journal:Z -p 33000:2022 --cgroup-manager=cgroupfs localhost/testsshd

SSH-Zugriff testen

Melden Sie sich auf dem Hostcomputer mit den SSH-Schlüsseln für die Benutzer tester beim SSH-Server an und tester2 , und das Passwort (redhat123 ) für tester3 .

# ssh -l tester -i /home/test2/.ssh/id_ecdsa localhost -p 33000

# ssh -l tester2 -i /home/test2/.ssh/tester2 localhost -p 33000

# ssh -l tester3 localhost -p 33000

Für tester2 wird eine Meldung angezeigt, dass die Sitzung aufgezeichnet wird und tester3 .

Sitzungsaufzeichnung validieren

Nach der Anmeldung als testuser2 und testuser3 und Ausführen einiger Befehle gibt es tlog Einträge in der Journallogdatei. Als tester Benutzer, führen Sie den folgenden Befehl innerhalb des Containers aus:

# journalctl | grep tlog-rec-session

Jedes tlog Eintrag hat eine Host-ID, eine Datensatz-ID und einen zugeordneten Benutzer. Zum Beispiel:

"host":"0ce2921675b0","rec":"26b55a3aafd94f40b49473ac33bd2c96-42-f99b3","user":"tester2"

Auf diese Protokolleinträge kann auch vom Host aus über volume zugegriffen werden Standort:

/home/test2/.local/share/containers/storage/volumes/ssh1logs/_data/<containerid>/system.journal

Unter ssh1logs/_data kann es mehr als ein Verzeichnis geben wenn der vorherige Container beendet wurde und durch einen neuen ersetzt wurde.

Wiedergabe einer aufgezeichneten Sitzung

Das tlog-play Der Befehl unterstützt die Wiedergabe einer Sitzung. Normalerweise ist der Administrator daran interessiert, eine bestimmte Benutzersitzung wiederzugeben. Exportieren Sie dazu die Sitzungseinträge für diese bestimmte Sitzung aus den Journalprotokollen und speichern Sie sie in einer lokalen Datei.

Identifizieren Sie eine bestimmte Datensatz-ID und verwenden Sie diese, um alle Datensätze mit dem folgenden awk zu filtern Befehl:

# journalctl --file .local/share/containers/storage/volumes/ssh1logs/_data/<containerid>/system.journal | awk -F '{"' '$0~/<tlog record id>/{ print "\{\"" $2 }' 2>/dev/null > ~/session_recording.log

# tlog-play -r file -i ~/session_recording.log

Auf diese Weise können Administratoren die spezifischen Sitzungsprotokolle für jede Benutzersitzung trennen und speichern und bei Bedarf wiedergeben. Diese Sitzungsprotokolle können zu Prüfzwecken auch an eine zentrale Stelle gesendet werden. Standardmäßig tlog erfasst nicht die Standardeingabe für den Benutzer, sodass vertrauliche Informationen wie Passwörter nicht erfasst und in den Protokollen gespeichert werden.

Mehr als ein containerisierter SSH-Server kann gleichzeitig auf dem Host ausgeführt werden (unter Verwendung unterschiedlicher Portzuordnungen), wobei jeder der Container separate Benutzerprofile und separate persistente Volume-Zuordnungen hat. Die Container selbst können auch als systemd konfiguriert werden Dienste auf dem Host, um sie beim Booten zu starten.

Abschluss

Im nächsten Teil stellen wir Red Hat IDM und Backend-Server (in IDM integriert) vor. Hostbasierte Zugriffskontrolle und zentralisiertes sudo wird für Benutzer/Gruppen von IDM konfiguriert, um zu verwalten, welche Benutzer welche Befehle auf welchen Hosts ausführen können.

[ Erste Schritte mit Containern? Schauen Sie sich diesen kostenlosen Kurs an. Containerisierte Anwendungen bereitstellen:Eine technische Übersicht. ]