Comment empêcher les administrateurs d'accéder aux journaux de leur propre activité?
L'idée serait d'empêcher un attaquant qui a volé un compte root/admin ou escaladé pour effacer ses propres activités ou même lire les traces de ce qu'il fait. Supposons que nous soyons sous Linux, nous nous connectons avec auditd, avons des journaux centralisés, et nous pouvons utiliser MAC avec SELinux. Mais je suis également intéressé par les réponses sous Windows.
Une solution serait d'interdire à tous les comptes root d'accéder aux journaux. Les journaux sont gérés uniquement par des processus autorisés sur des serveurs spécifiques à partir de logrotate, syslog et tous les éléments SIEM. Ainsi, seul le SOC peut lire et analyser les journaux des administrateurs. Seul un processus de purge peut supprimer les anciens journaux. Quelqu'un peut-il confirmer que c'est faisable?
Est-il possible d'avoir quelque chose de plus flexible où les administrateurs avec leurs propres privilèges root pourraient lire les journaux des autres comptes root?
La solution acceptée est de ne pas stocker les journaux localement, mais sur un serveur de journaux. Une fois que les journaux sont là, vous pouvez restreindre ou limiter l'accès comme bon vous semble.
Dans certaines solutions de serveur/agrégateur de journaux, vous pouvez empêcher un utilisateur de voir les entrées contenant des références à certaines données (comme leurs comptes d'utilisateur ou les adresses IP des machines). Cela signifie que vous pouvez permettre aux administrateurs de voir d'autres activités d'administration, mais pas les leurs.
En règle générale, vous souhaitez placer des alertes dans le serveur/agrégateur de journaux pour qu'elles se déclenchent si les journaux d'une même machine cessent d'entrer ou sont inférieurs à certains seuils, ce qui permet de détecter si un administrateur local a empêché l'envoi des journaux au serveur de journaux/agrégateur.
Serveurs Syslog, SIEM, agrégateurs de journaux, piles ELK, etc. Il existe de nombreuses options à explorer.
Tout journal sur un hôte compromis est suspect. Vous avez besoin d'une plate-forme de journalisation centralisée, soit un serveur Syslog central/Splunk/Logrhythm/que ce soit. Gardez un ensemble différent d'administrateurs et de comptes. Voilà toute l'idée.
Une fois que vous avez mis en place une plate-forme, vous pouvez déléguer les droits pour afficher leurs actions, que ce soit leur propre administrateur ou d'autres administrateurs - peuvent être effectuées. Nous avions des droits de lecture sur des sources de journaux spécifiques et des hôtes délégués.
Si un attaquant a acquis des privilèges élevés sur une machine, alors la machine entière n'est plus fiable plus, sans parler des contrôleurs de journaux.
Un serveur de journalisation distant est la seule option ici, bien que les détails puissent varier. Vous serez en mesure de gérer les journaux et de gérer les contrôles d'accès d'une manière plus sûre que de stocker les journaux localement.
La première étape consiste à envoyer les journaux à un autre serveur, afin qu'après que le premier serveur soit compromis (et donc que leurs journaux puissent être modifiés), ce serveur de journal aurait ces entrées de journal. Et ce serveur peut (devrait) être protégé plus étroitement.
Néanmoins, quelqu'un doit être capable d'administrer ce serveur, ne serait-ce que pour que le serveur puisse être mis à jour!
Vous pouvez également protéger les journaux sur ce serveur:
- Exiger plusieurs administrateurs pour toute action (non triviale) (par exemple, les commandes introduites nécessitent la confirmation de N administrateurs)
- Les journaux peuvent être stockés en les liant aux précédents dans un arbre Merkle , de sorte que la suppression ou la modification d'une entrée affecterait les suivants¹
- Le hachage du journal actuel peut être envoyé à une partie externe (obtenir d'un serveur d'horodatage, envoyer une entreprise partenaire ou simplement envoyer à un flux Twitter²).
¹ En argumentant pour l'utiliser, il peut être préférable de déclarer qu'il utilise la technologie blockchain .
² Ou si les journaux eux-mêmes ne sont pas confidentiels, vous pouvez même envoyer certains événements du serveur de journaux en clair: "jdoe s'est connecté au serveur de journaux et a exécuté rm -rf / "
Quelques façons possibles de protéger les journaux de l'administrateur:
- connexion à distance à une machine qui n'est pas contrôlée par l'administrateur en question
- écrire le journal sur un support à écriture unique (par exemple Bluray Recordable), notez que vous pouvez également avoir besoin d'une stratégie pour éviter de surcharger le média, comme la déconnexion de tous les administrateurs si les journaux sont sur le point d'être saturés
- publier le hachage des journaux sur une blockchain publique, cela détecte la falsification, mais pas la destruction des journaux
- forcer l'accès à la machine via un serveur mitm, les administrateurs ne peuvent se connecter à la machine administrée que via le serveur mitm, qui enregistrera toutes les entrées clés/souris et la sortie écran/terminal (à l'aide de ssh mitm ou vnc/rdp mitm)
Filtre journaux auditd avec rsyslog par uid pour avoir un fichier par uid. Ensuite, SELinux peut être appliqué pour implémenter n'importe quelle politique, en particulier pour empêcher un administrateur d'accéder à ses propres journaux. La solution proposée ici évite d'exiger qu'une équipe indépendante d'administrateurs accède aux journaux sur les serveurs de journaux lorsque vous avez une politique restrictive.
Comme d'autres l'ont dit, les journaux doivent être centralisés. En outre, l'accès à ces serveurs de journaux centralisés doit être effectué avec des comptes locaux uniquement.
Une solution consiste à utiliser une diode de données pour protéger l'accès au serveur centralisé de collecteur de journaux, qui n'est alors accessible que physiquement, ce qui est facile à contrôler. De plus, des comptes d'utilisateurs individuels spécifiques peuvent être créés dessus pour une meilleure protection.