Configurazione di server SSH containerizzati per la registrazione della sessione con tlog

Nella prima parte di questa serie, ho evidenziato alcuni dei vantaggi della registrazione delle sessioni e dell'uso di server SSH containerizzati. Ho anche mostrato un'architettura di alto livello. Come passaggio preparatorio, uno dei server con RHEL 8.2 è stato configurato per creare e ospitare i container rootless del server SSH.

Dopo aver preparato il server e creato l'utente (tester2 ), creiamo un Dockerfile personalizzato per il server SSH con la registrazione della sessione configurata.

Nel seguente Dockerfile, utilizziamo l'immagine ubi-init (multiservizio), che supporta systemd e ha il CMD /sbin/init come impostazione predefinita per avviare il systemd servizio iniziale. Per questa configurazione vengono fatte le seguenti ipotesi.

• Il servizio espone la porta 2022 invece della 22 all'interno di un container per SSH
• Configura tre utenti (vale a dire tester , tester2 e tester3 )
• Utilizza lo stesso UID per l'utente contenitore tester come utente (tester2 ) eseguendo il contenitore senza root sull'host in modo che questo utente possa essere root all'interno del contenitore
• Cambia l'UID per tester all'interno del contenitore come 0 (root)
• Configura le chiavi SSH come argomenti di build per l'utente tester e tester2 e un accesso basato su password per tester3
• Configura la registrazione della sessione per gli utenti tester2 e tester3 impostando la shell di accesso come /usr/bin/tlog-rec-session
• Mappa i volumi persistenti per /home e /var/log/journal durante la creazione del contenitore per conservare le home directory degli utenti e il servizio SSH e i registri di registrazione delle sessioni
• Copia il tlog-rec-session.conf dall'host al contenitore con la seguente configurazione per l'acquisizione dei registri di registrazione della sessione utilizzando 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"}

[ Prova la registrazione della sessione in un lab dal vivo: Configurazione della registrazione della sessione terminale ]

File Docker per contenitore SSH

Ecco un esempio di Dockerfile per il contenitore 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"]

Salva il file nella home directory come sshdockfile. Copia il /etc/tlog/tlog-rec-session.conf predefinito alla directory principale.

Costruisci l'immagine del contenitore

Per creare l'immagine del contenitore con le chiavi desiderate, generare una nuova coppia di chiavi per l'utente. Quindi, esporta come variabili la chiave pubblica predefinita e quella appena creata. Infine, passali come argomenti di build usando quanto segue. Ecco il processo:

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

Il cgroup-manager l'argomento richiede cgroups-v2 ed è necessario affinché il contenitore senza root utilizzi systemd con successo. Podman segnala il seguente errore a meno che questo argomento non venga passato:

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

Se la compilazione riesce, il passaggio successivo consiste nell'eseguire il contenitore con i volumi persistenti desiderati. Questi volumi (per /var/log/journal e /home ) sono pre-creati oppure Podman li crea dinamicamente nel volume directory nella posizione di archiviazione predefinita (podman info | grep -i graphroot ).

Esegui il server SSH

Poiché i container rootless non supportano i plug-in CNI per il networking, viene mappata una porta superiore preferita (>1024) per esporre il servizio 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

Verifica l'accesso SSH

Dalla macchina host, accedi al server SSH utilizzando le chiavi SSH per gli utenti tester e tester2 e la password (redhat123 ) per 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

Viene visualizzato un messaggio di registrazione della sessione per tester2 e tester3 .

Convalida la registrazione della sessione

Dopo aver effettuato l'accesso come testuser2 e testuser3 ed eseguendo alcuni comandi, ci sono tlog voci nel file di registro del diario. Come tester utente, eseguire il seguente comando all'interno del contenitore:

# journalctl | grep tlog-rec-session

Ogni tlog voce ha un ID host, un ID record e un utente associato. Ad esempio:

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

Queste voci di registro sono accessibili anche dall'host utilizzando il volume posizione:

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

Potrebbe esserci più di una directory in ssh1logs/_data se i contenitori precedenti sono stati chiusi e uno nuovo lo ha sostituito.

Riproduci una sessione registrata

Il tlog-play comando supporta la riproduzione di una sessione. In genere l'amministratore è interessato a riprodurre una specifica sessione utente. Per ottenere ciò, esporta le voci di sessione per quella particolare sessione dai registri del diario e salvale in un file locale.

Identifica un ID record specifico e utilizzalo per filtrare tutti i record con il seguente awk comando:

# 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

In questo modo, gli amministratori possono separare e archiviare i registri di sessione specifici per ciascuna sessione utente e riprodurli su richiesta. Questi registri di sessione possono anche essere spediti a una posizione centrale per scopi di controllo. Per impostazione predefinita, tlog non acquisisce l'input standard per l'utente, in modo che le informazioni sensibili come le password non vengano acquisite e archiviate nei registri.

È possibile eseguire contemporaneamente più di un server SSH containerizzato sull'host (utilizzando diverse mappature delle porte), con ciascuno dei container con profili utente separati e mappature dei volumi persistenti separate. I contenitori stessi possono anche essere configurati come systemd servizi sull'host per avviarli all'avvio.

Concludi

Introduciamo Red Hat IDM e server back-end (integrati con IDM) nella parte successiva. Controllo degli accessi basato su host e sudo centralizzato sarà configurato per utenti/gruppi da IDM per gestire quali utenti possono eseguire quali comandi su quali host.

[ Iniziare con i container? Dai un'occhiata a questo corso gratuito. Distribuzione di applicazioni containerizzate:una panoramica tecnica. ]