Configuration de serveurs SSH conteneurisés pour l'enregistrement de session avec tlog

Dans la première partie de cette série, j'ai souligné certains des avantages de l'enregistrement de session et de l'utilisation de serveurs SSH conteneurisés. J'ai également présenté une architecture de haut niveau. En tant qu'étape préparatoire, l'un des serveurs avec RHEL 8.2 a été configuré pour créer et héberger les conteneurs sans racine du serveur SSH.

Après avoir préparé le serveur et créé l'utilisateur (tester2 ), nous créons un Dockerfile personnalisé pour le serveur SSH avec l'enregistrement de session configuré.

Dans le Dockerfile suivant, nous utilisons l'image ubi-init (multiservice), qui prend en charge systemd et a le CMD /sbin/init par défaut pour démarrer le systemd service d'initialisation. Les hypothèses suivantes sont faites pour cette configuration.

Le service expose le port 2022 au lieu du port 22 dans un conteneur pour SSH
Configurez trois utilisateurs (à savoir tester , tester2 , et tester3 )
Utiliser le même UID pour l'utilisateur de conteneur tester en tant qu'utilisateur (tester2 ) exécutant le conteneur sans racine sur l'hôte afin que cet utilisateur puisse être root à l'intérieur du conteneur
Modifier l'UID pour tester dans le conteneur en tant que 0 (racine)
Configurer les clés SSH en tant qu'arguments de compilation pour l'utilisateur tester et tester2 et une connexion basée sur un mot de passe pour tester3
Configurer l'enregistrement de session pour les utilisateurs tester2 et tester3 en définissant le shell de connexion comme /usr/bin/tlog-rec-session
Mappez les volumes persistants pour /home et /var/log/journal lors de la création du conteneur pour conserver les répertoires d'accueil des utilisateurs et les journaux d'enregistrement du service et de la session SSH
Copiez le tlog-rec-session.conf de l'hôte dans le conteneur avec la configuration suivante pour capturer les journaux d'enregistrement de session à l'aide de 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"}

[Essayez l'enregistrement de session dans un laboratoire en direct : Configuration de l'enregistrement de session de terminal]

Dockerfile pour conteneur SSH

Voici un exemple de Dockerfile pour le conteneur SSH :

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"]

Enregistrez le fichier dans le répertoire personnel sous sshdockfile. Copiez le /etc/tlog/tlog-rec-session.conf par défaut au répertoire personnel.

Créer l'image du conteneur

Pour créer l'image du conteneur avec les clés souhaitées, générez une nouvelle paire de clés pour l'utilisateur. Ensuite, exportez la clé publique par défaut et la clé publique nouvellement créée en tant que variables. Enfin, passez-les en tant qu'arguments de construction en utilisant ce qui suit. Voici le processus :

# 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"

Le cgroup-manager l'argument nécessite cgroups-v2 et est nécessaire pour que le conteneur sans racine utilise systemd avec succès. Podman signale l'erreur suivante à moins que cet argument ne soit passé :

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

Si la génération réussit, l'étape suivante consiste à exécuter le conteneur avec les volumes persistants souhaités. Ces volumes (pour /var/log/journal et /home ) sont soit pré-créés, soit Podman les crée dynamiquement dans le volume répertoire sous l'emplacement de stockage par défaut (podman info | grep -i graphroot ).

Exécutez le serveur SSH

Comme les conteneurs sans racine ne prennent pas en charge les plugins CNI pour la mise en réseau, un port supérieur préféré (> 1024) est mappé pour exposer le service SSH.

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

Tester l'accès SSH

Depuis la machine hôte, connectez-vous au serveur SSH à l'aide des clés SSH pour les utilisateurs tester et tester2 , et le mot de passe (redhat123 ) pour 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

Un message indiquant que la session est en cours d'enregistrement apparaît pour tester2 et tester3 .

Valider l'enregistrement de la session

Après vous être connecté en tant que testuser2 et testuser3 et en exécutant certaines commandes, il y a tlog entrées dans le fichier journal du journal. En tant que tester utilisateur, exécutez la commande suivante dans le conteneur :

# journalctl | grep tlog-rec-session

Chaque tlog l'entrée a un ID d'hôte, un ID d'enregistrement et un utilisateur associé. Par exemple :

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

Ces entrées de journal sont également accessibles depuis l'hôte en utilisant le volume emplacement :

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

Il peut y avoir plus d'un répertoire sous ssh1logs/_data si le ou les conteneurs précédents ont été résiliés et remplacés par un nouveau.

Rejouer une session enregistrée

Le tlog-play La commande prend en charge la relecture d'une session. Généralement, l'administrateur est intéressé par la relecture d'une session utilisateur spécifique. Pour ce faire, exportez les entrées de session pour cette session particulière à partir des journaux de journal et enregistrez-les dans un fichier local.

Identifiez un ID d'enregistrement spécifique et utilisez-le pour filtrer tous les enregistrements avec le awk suivant commande :

# 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

De cette façon, les administrateurs peuvent séparer et stocker les journaux de session spécifiques pour chaque session utilisateur et les relire à la demande. Ces journaux de session peuvent également être expédiés vers un emplacement central à des fins d'audit. Par défaut, tlog ne capture pas l'entrée standard pour l'utilisateur, de sorte que les informations sensibles telles que les mots de passe ne sont pas capturées et stockées dans les journaux.

Plusieurs serveurs SSH conteneurisés peuvent être exécutés simultanément sur l'hôte (à l'aide de différents mappages de ports), chacun des conteneurs ayant des profils utilisateur distincts et des mappages de volumes persistants distincts. Les conteneurs eux-mêmes peuvent également être configurés en tant que systemd services sur l'hôte pour les démarrer au démarrage.

Récapitulez

Nous présentons Red Hat IDM et les serveurs principaux (intégrés à IDM) dans la partie suivante. Contrôle d'accès basé sur l'hôte et sudo centralisé sera configuré pour les utilisateurs/groupes d'IDM afin de gérer quels utilisateurs peuvent exécuter quelles commandes sur quels hôtes.

[ Vous débutez avec les conteneurs ? Découvrez ce cours gratuit. Déploiement d'applications conteneurisées :présentation technique. ]