La journalisation du terminal peut sembler une invasion de la vie privée, mais il existe de nombreuses raisons pour lesquelles vous voudrez peut-être savoir quelles commandes vos utilisateurs exécutent. Que ce soit pour des raisons de conformité ou simplement pour une bonne administration du système, vous voulez parfois simplement savoir ce que font vos utilisateurs. Si vous gérez une flotte de systèmes Linux et que vous avez besoin de savoir ce que font les personnes à qui vous avez confié un shell, vous voudrez peut-être envisager tlog . tlog est un enregistreur d'E/S de terminal inclus avec RHEL et plusieurs autres distributions. Il enregistre plus que des frappes au clavier ; il enregistre également la sortie reçue. Il peut être utilisé pour rejouer littéralement une session.
Dans cet article, je vous guide à travers un tlog de base configuration et démontrer une partie de la puissance qu'elle exerce. Linux est assez bon pour enregistrer les actions. Il peut, par exemple, enregistrer les commandes qui ont été exécutées via sudo . Le sécurisé log peut vous dire qui s'est connecté ou n'a pas réussi à se connecter, mais rien de prêt ne consigne de manière centralisée chaque action prises par un utilisateur non privilégié. Oui, la plupart des shells conservent un historique, mais les utilisateurs peuvent le modifier ou même le supprimer s'ils savent ce qu'ils font. Le tlog l'utilitaire lui-même n'est pas infaillible, mais une couche supplémentaire de journalisation ne peut pas faire de mal. Cependant, il a ses limites et ses problèmes, que la documentation Red Hat liée ci-dessous décrit. Aussi, tlog se connecte au JSON afin qu'il puisse être analysé ou même rejoué plus tard.
Mon objectif est de vous montrer la puissance de tlog avec Cockpit. Cockpit, si vous ne le savez pas, est une interface d'administration Web incluse avec RHEL. L'utilisation de Cockpit est facultative, et si vous souhaitez utiliser tlog sans ça, c'est très bien. Ignorez simplement les étapes d'instruction qui incluent la configuration du cockpit.
[ Vous pourriez également apprécier : Configurer logrotate sous Linux ]
Configurer le tlog
Pour ce tutoriel, j'utilise un système minimal RHEL 8.3 fraîchement installé. La documentation officielle de Red Hat Enterprise Linux 8 sur la journalisation des terminaux est disponible ici. Pour commencer, tout ce dont vous avez besoin est un système RHEL 8 avec un abonnement. Ce processus devrait également être presque identique sur CentOS 8. Installez tlog et Cockpit, puis activez l'enregistrement de session dans sssd (le démon des services de sécurité du système). Vous pouvez utiliser tlog de quelques autres manières, mais cette approche vous permet de gérer tlog via sssd, au lieu de par utilisateur.
Commencez par installer les packages requis :
[root@gangrif-tlogtest ~]# yum install -y tlog cockpit cockpit-session-recording Une fois l'installation terminée, activez et démarrez Cockpit :
[root@gangrif-tlogtest ~]# systemctl enable cockpit.socket --now
Created symlink /etc/systemd/system/sockets.target.wants/cockpit.socket → /usr/lib/systemd/system/cockpit.socket.
Vous pouvez tester Cockpit en pointant votre navigateur Web vers https://your-server's-IP . Si cela ne fonctionne pas, vous devrez peut-être activer Cockpit dans le pare-feu basé sur l'hôte ou sur le réseau. Dans mon cas, ce n'était pas nécessaire.
Ensuite, ajoutez tlog à la configuration sssd. Le démon sssd permet de nombreuses personnalisations de votre pile d'authentification, y compris des éléments tels que les répertoires d'utilisateurs distants. Dans ce cas, vous l'utilisez pour le tlog local l'intégration. Il existe plusieurs façons de configurer cela. Je vais ajouter tlog enregistrement de session à un groupe spécifique appelé utilisateurs suspects , afin que tout utilisateur ajouté à ce groupe soit connecté. Vous pouvez enregistrer des utilisateurs individuels ou tous les utilisateurs si vous le souhaitez. Ajoutez la configuration suivante à /etc/sssd/conf.d/sssd-session-recording.conf . Assurez-vous que ce fichier appartient à root:root , et les utilisateurs/autres ne peuvent pas lire ou écrire le fichier. Sssd est pointilleux à ce sujet pour une bonne raison.
[root@gangrif-tlogtest ~]# cat /etc/sssd/conf.d/sssd-session-recording.conf
[session_recording]
scope = some
groups = suspicious-users
Si vous n'utilisez pas ou ne pouvez pas utiliser sssd, il existe une option qui configure manuellement tlog pour les utilisateurs. L'option est décrite dans la documentation mentionnée précédemment.
Après avoir placé ce fichier, redémarrez sssd. Maintenant, testez la configuration.
Enregistrer les sessions utilisateur
Ce gangrif utilisateur, il a l'air suspect. Mettez-le dans les utilisateurs suspects groupe qui tlog est configuré pour enregistrer.
[root@gangrif-tlogtest tlog]# groupmems -g suspicious-users -a gangrif
[root@gangrif-tlogtest ~]# id gangrif
uid=1000(gangrif) gid=1000(gangrif) groups=1000(gangrif),10(wheel),1001(suspicious-users)
Lorsque vous vous connectez en tant que gangrif , une jolie bannière d'avertissement s'affiche pour indiquer que vous êtes surveillé. Cette bannière peut être modifiée ou supprimée en utilisant la notice directive dans /etc/tlog/tlog-rec-session.conf . Vous devrez peut-être informer les utilisateurs qu'ils sont surveillés. Pour moi, tlog est plus puissant si vous n'informez pas un attaquant potentiel qu'il est surveillé. Leur dire ce que vous avez mis en place leur permet simplement de savoir ce qu'il faut essayer de désactiver.
[nlager@batou-lan ~]$ ssh [email protected]
[email protected]'s password:
Web console: https://gangrif-tlogtest.tamlab.rdu2.redhat.com:9090/ or https://10.8.109.214:9090/
Last login: Tue Dec 22 15:29:44 2020 from 10.10.116.62
ATTENTION! Your session is being recorded!
[gangrif@gangrif-tlogtest ~]$ Afficher la session dans Cockpit
Par défaut, tlog journaux dans le journal système. Le moyen le plus simple de récupérer vos données enregistrées est d'utiliser Cockpit session-logging panneau. C'est en fait assez lisse et bien assemblé. Vous pouvez rejouer une session et voir quelles commandes ont été entrées, y compris les fautes de frappe, les commandes qui ont été tapées mais qui ont échoué ou les commandes qui ont été fermées en utilisant Ctrl+C . Si vous appuyez sur la vue du journal bouton, cette visionneuse vous montrera même les journaux système associés qui ont été mis à jour pendant la session. C'est vraiment un bel outil.
Passer du journal système à la journalisation des fichiers
Si vous n'utilisez pas Cockpit, l'affichage des journaux devient un peu plus compliqué, car les données que vous recherchez se trouvent dans le journal système. Dans ce cas, j'ai trouvé plus simple de changer simplement tlog passer à l'enregistrement dans un fichier. Vous pouvez également vous connecter à syslog, ce qui aurait un effet similaire et serait peut-être plus facile à entretenir. Par souci de simplicité, je vais juste écrire directement dans un fichier. Je dois vous avertir que déplacer tlog se déconnecte du journal système et dans un fichier rompt l'intégration Cockpit.
Tout d'abord, créez un emplacement pour stocker les fichiers et assurez-vous qu'il est accessible en écriture par le tlog utilisateur. J'ai ajouté un répertoire dans /var/log appelé tlog et définissez la propriété sur tlog:tlog .
Ensuite, dans /etc/tlog/tlog-rec-session.conf , dites tlog où stocker ses logs. Vous trouverez des strophes dans le fichier pour différentes configurations. L'un est étiqueté Paramètres du rédacteur de fichier . Ce paramètre permet de définir le chemin du fichier de sortie. La configuration de mon chemin ressemblait à ceci :
// File writer parameters
"file": {
// The "file" writer log file path.
"path" : "/var/log/tlog/tlog.log"
},
Dites maintenant à tlog pour utiliser le file writer au lieu de celui par défaut, qui est le journal. En bas du fichier de configuration, vous trouverez une ligne juste avant la fermeture } qui contient un //"writer":"journal" paramètre. Changez ce paramètre en fichier, comme ça :
// The type of "log writer" to use for logging. The writer needs
// to be configured using its dedicated parameters.
"writer" : "file"
}
La prochaine fois que votre utilisateur cible se connectera, le fichier /var/log/tlog/tlog.log doit être créé et les sessions enregistrées ici. Vous souhaiterez configurer la rotation des journaux à ce sujet, et si vous avez un enregistreur externe, vous devez y envoyer ce fichier. Ces données ne sont utiles que si elles sont disponibles lorsque vous en avez besoin. Si un attaquant le trouve et le supprime, cela ne vous servira à rien.
Voir la session avec tlog-play
Une fois que vous avez ces journaux dans un fichier, vous pouvez les consulter. Vous pouvez utiliser journalctl , mais comme les journaux sont au format JSON, ils ne sont pas faciles à lire pour les humains. Par exemple, mon rm -rf l'exemple de commande ci-dessus ressemble à ceci :
{"ver":"2.2","host":"gangrif-tlogtest.tamlab.rdu2.redhat.com","rec":"2a5a7ca40dd6424e91f587c0e012e623-3cf2-1f1e2d","user":"gangrif","term":"xterm-256color","session":31,"id":1,"pos":0,"timing":"=185x50+31>61+136>1+105>1+135>1+193>1+218>1+202>4+161>4+111>1+167>1+181>1+93>1+196>1+1412>2+2>166+1897>1+251>1+208>1+159>1+73>1+110>1+90>1+73>1+119>1+285>1+504>1+143>1+136>1+961>1+175>1+144>1+865>4","in_txt":"","in_bin":[],"out_txt":"\u001b]0;gangrif@gangrif-tlogtest:~\u0007[gangrif@gangrif-tlogtest ~]$ rm rf\b\u001b[K\b\u001b[K-rf /\r\nrm: it is dangerous to operate recursively on '/'\r\nrm: use --no-preserve-root to override this failsafe\r\n\u001b]0;gangrif@gangrif-tlogtest:~\u0007[gangrif@gangrif-tlogtest ~]$ mwahahaha!!!! \b\u001b[K","out_bin":[]}
L'information n'est pas facile à lire, mais heureusement, il existe un outil qui rend cela simple. Vous pouvez utiliser tlog-play avec les sessions enregistrées dans le journal, et il vous permet de spécifier l'ID d'enregistrement pour produire cet enregistrement spécifique. Lors de l'analyse d'un fichier à la place, l'ID d'enregistrement ne fonctionne pas. Tous les enregistrements se retrouvent dans le même fichier et vous ne pouvez pas tous les lire car les ID de session ne sont pas les mêmes. Vous devez les séparer. Vous pouvez identifier l'ID de session que vous souhaitez regarder, puis grep cet ID de session dans un nouveau fichier avant tlog-play en sera content. Peut-être que syslog peut être configuré pour diviser automatiquement ces fichiers au fur et à mesure qu'ils sont écrits.
[root@gangrif-tlogtest tlog]# grep 2a5a7ca40dd6424e91f587c0e012e623-3da9-1fdf38 tlog.log >> session.log
[root@gangrif-tlogtest tlog]# tlog-play -i session.log
[gangrif@gangrif-tlogtest ~]$ rm -rf /
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe
[gangrif@gangrif-tlogtest ~]$ logout
[root@gangrif-tlogtest tlog]#
La session est lue à l'écran à l'aide des données de synchronisation du journal JSON. C'est assez lisse. Vous pouvez imaginer à quel point cela pourrait être utile lors de l'exécution d'enquêtes judiciaires après la détection d'une panne ou d'un compromis. Vous pouvez même utiliser tlog pour des choses comme enregistrer une démo de quelque chose en ligne de commande.
[ Obtenez ce livre gratuit de Red Hat et O'Reilly - Kubernetes Operators :Automating the Container Orchestration Platform. ]
Récapitulez
Toutes ces discussions sur la surveillance de l'entrée de votre utilisateur peuvent soulever des questions. Par exemple, les entrées de mot de passe sont-elles enregistrées ? Qu'en est-il des sessions SSH qui sautent vers un autre hôte ? Qu'en est-il des séances X ? La documentation répertorie X sessions comme mise en garde, mais tlog ne les capture pas. La journalisation des mots de passe est désactivée par défaut, mais peut être activée si nécessaire.
Donc, que ce soit pour la conformité ou simplement pour enregistrer une démonstration astucieuse d'une nouvelle technologie, j'espère que cet article vous aidera à faire le travail en utilisant tlog.