Je vois deux bonnes façons d'obtenir ce genre d'informations. L'une consiste à augmenter la journalisation à partir de sshd lui-même et l'autre à effectuer une surveillance plus approfondie du référentiel git sur le disque. Étant donné qu'aucun d'eux ne vous donne individuellement les informations que vous souhaitez, vous pouvez faire les deux et corréler les données de journal à l'aide d'un moteur d'analyse de journal externe ou à la demande à l'aide des yeux humains et d'horodatages.
Modifications de sshd
Par défaut, comme vous l'avez sans doute vu, vous pouvez voir quand un utilisateur s'est connecté et d'où, en utilisant les journaux d'authentification ssh. Ce que vous voulez faire, c'est changer le niveau auquel vous vous déconnectez de sshd. Modifiez donc votre /etc/ssh/sshd_config
et trouvez la ligne qui ressemble à
#LogLevel INFO
et changer cela en
LogLevel VERBOSE
puis redémarrez le service sshd. Cela augmente le niveau de journalisation de sshd d'une étape, ce qui donne beaucoup plus d'informations. Consultez cet extrait de journal de mon accès à distance après avoir apporté cette modification.
Nov 2 08:37:09 node1 sshd[4859]: Connection from 10.10.10.5 port 50445
Nov 2 08:37:10 node1 sshd[4859]: Found matching RSA key: f2:9e:a1:ca:0c:33:02:37:9b:de:e7:63:d5:f4:25:06
Nov 2 08:37:10 node1 sshd[4860]: Postponed publickey for scott from 10.10.10.5 port 50445 ssh2
Nov 2 08:37:10 node1 sshd[4859]: Found matching RSA key: f2:9e:a1:ca:0c:33:02:37:9b:de:e7:63:d5:f4:25:06
Nov 2 08:37:10 node1 sshd[4859]: Accepted publickey for scott from 10.10.10.5 port 50445 ssh2
Nov 2 08:37:10 node1 sshd[4859]: pam_unix(sshd:session): session opened for user scott by (uid=0)
Nov 2 08:37:10 node1 sshd[4859]: User child is on pid 4862
Nov 2 08:40:27 node1 sshd[4862]: Connection closed by 10.10.10.5
Nov 2 08:40:27 node1 sshd[4862]: Transferred: sent 30632, received 7024 bytes
Nov 2 08:40:27 node1 sshd[4862]: Closing connection to 10.10.10.5 port 50445
Nov 2 08:40:27 node1 sshd[4859]: pam_unix(sshd:session): session closed for user scott
Les choses importantes à noter ici sont doubles
- Nous voyons l'empreinte digitale de la clé publique utilisée pour m'authentifier
- Nous voyons l'horodatage de ma déconnexion
L'utilisation du sshd LogLevel (INFO) par défaut ne consigne aucun de ces éléments. Obtenir l'empreinte digitale d'une clé est une étape supplémentaire. Vous devez traiter le authorized_keys
fichier approprié avec ssh-keygen en tant que tel.
[root@node1 ssh]# ssh-keygen -l -f /home/scott/.ssh/authorized_keys
4096 f2:9e:a1:ca:0c:33:02:37:9b:de:e7:63:d5:f4:25:06 /home/scott/.ssh/authorized_keys (RSA)
Alors maintenant, vous connaissez les informations suivantes:
- Nom d'utilisateur connecté
- Heure à laquelle cet utilisateur s'est connecté
- Quelle clé publique a été utilisée pour l'authentification
- Heure à laquelle l'utilisateur s'est déconnecté
Maintenant que nous avons un moyen d'attribuer l'action de l'utilisateur à un moment précis, en supposant que les deux utilisateurs n'étaient pas connectés en même temps, nous pouvons commencer à examiner les modifications apportées au référentiel.
Surveillance d'annuaire avec Auditd
Comme l'a dit sysadmin1138, cela pourrait être un excellent cas d'utilisation pour le sous-système auditd. Si vous n'utilisez pas une distribution basée sur RedHat, il y a probablement un analogue, mais vous devrez le trouver. La configuration pour auditd est assez intense et a un nombre redonkulous d'options de configuration. Pour avoir une idée de certaines des options, veuillez consulter cette question sur notre site partenaire pour les professionnels de la sécurité de l'information .
Au minimum, je recommanderais de configurer ce qu'on appelle une "surveillance" sur le répertoire sur le disque qui contient votre dépôt git en question. Cela permet au module du noyau de signaler les tentatives d'effectuer des appels d'accès aux fichiers, tels que open()
ou creat()
, sur les descripteurs de fichiers pointant vers les fichiers ou répertoires que nous listons.
Voici un exemple de configuration qui ferait cela, et seulement cela. Veillez donc à lire et comprendre votre existant /etc/audit/audit.rules
afin d'intégrer les changements de manière appropriée.
# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.
# First rule - delete all
-D
# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 1024
-w /path/to/git/repos-p wa
# Disable adding any additional rules - note that adding *new* rules will require a reboot
-e 2