Code publié
Open source
Un outil de sécurité que vous ne pouvez pas inspecter est un outil que vous ne contrôlez pas.
Nous publions aartool, notre outillage de durcissement Linux, en GPL-3.0 : auditez-le, modifiez-le, déployez-le chez vous. AarSOC est lui-même construit exclusivement sur des composants open source.
v3.5.3 | auditer, planifier, appliquer, prouver Plan pour web-01 · score 62/100 ── Vague 1 · Atteignable depuis le réseau, sans aucun compte FAIL SSH-01 Connexion root autorisée FAIL NET-01 Aucun pare-feu actif [décision requise] WARN SYS-11 Noyau installé non démarré aperçu aartool plan --target web-01 --only firewall,ssh appliquer aartool apply --target web-01 --only firewall,ssh ── À décider avant d'appliquer NET-01 Aucun pare-feu actif aartool explain NET-01
Sortie de aartool advise sur un hôte d'exemple. Les vagues sont ordonnées par accessibilité : ce qu'un attaquant atteint sans aucun compte, puis ce qui transforme un compte en root, puis ce qui vous aurait empêché de vous en apercevoir.
Le tour complet, sur une vraie machine
Enregistré sur un ordinateur portable ordinaire, pas sur un hôte préparé : l'audit, le plan ordonné, ce que coûte une correction, les portes d'entrée du noyau, et le rapport HTML anonymisé que vous envoyez à un client. Le score est celui que cette machine a réellement obtenu.
aartool
Auditer un hôte Linux, obtenir un plan ordonné, appliquer les correctifs, prouver ce qui a changé
sudo aartool inspect # 109 contrôles. Ne modifie rien. aartool advise # quoi corriger en premier, et ce que ça coûte aartool explain KRN-01 # pourquoi c'est important, et ce que la correction casse aartool apply --target web-01 --user ubuntu --only ssh aartool diff avant.json apres.json
La plupart des scanners produisent une liste. aartool produit un ordre, et pour chaque recommandation il indique ce qu'elle casse.
Fermer les espaces de noms utilisateur non privilégiés neutralise une classe entière d'élévations de privilèges locales. Cela casse aussi Docker rootless, le bac à sable de Chrome et la plupart des exécuteurs d'intégration continue. aartool le dit avant que vous appliquiez, parce qu'un outil qui ne défend qu'un seul camp finit désactivé, et plus rien de ses conseils ne s'applique alors.
Validé en environnement réel
Une intégration continue ne prouve pas qu'un outil fonctionne sur une vraie machine, seulement qu'il fonctionne sur celle qui exécute les tests. Chaque version est donc exercée sur des serveurs en production avant publication.
- + 15 nœuds audités à travers un bastion, 15 sur 15 réussis. Cette campagne a révélé un défaut sur le parc lui-même : une règle d'espacement Jinja avait replié tout le bloc de supervision de /etc/hosts sur une seule ligne, sur chaque nœud, depuis des mois, sans que rien ne le signale.
- + Durcissement appliqué de bout en bout sur un serveur de documentation en service : score 72 à 75, trois constats corrigés, aucune régression et le service disponible du début à la fin.
- + Cette seule campagne a mis au jour quatre défauts dans aartool qu'aucun test n'avait vus, dont un contrôle qui ne pouvait jamais réussir et un contrôle dont la propre remédiation écrivait une valeur que le contrôle rejetait.
Systèmes couverts
RHEL 9, Ubuntu 22.04/24.04, Debian 12
Contrôles audités
109 contrôles, 9 familles
Rôles Ansible
52 rôles indépendants et composables
Parc distant
Audit via bastion, sans agent à installer
Rapport
HTML autonome et JSON, consultables hors ligne
Détection de dérive
Code de sortie exploitable en tâche planifiée
Licence
GPL-3.0 : réutilisation libre, modifications publiables
Le rapport HTML s'ouvre sans serveur et sans réseau, ce qui le rend utilisable en environnement isolé. L'export JSON s'intègre à vos pipelines, et aartool diff renvoie un code de sortie non nul dès qu'un contrôle régresse : un audit hebdomadaire qui reste silencieux tant que rien ne bouge est un audit qu'on lit encore au bout de six mois.
Ce que nous publions d'autre
Le principe est simple : ce qui renforce l'écosystème sans exposer un client se publie.
Règles de détection Sigma
Alignées MITRE ATT&CK, vérifiées sur des données réelles, portables vers les principaux moteurs de corrélation.
Travaux de recherche
Publiés dès qu'ils sont généralisables. Nos propres incidents et post-mortems sont déjà en ligne.
Lire nos publications →Contribuer
Les correctifs, les rôles pour de nouvelles distributions et les contrôles manquants sont les bienvenus.
Forkez et clonez
Créez une branche dont le nom décrit le changement.
Testez localement
Les rôles se testent avec Molecule, les scripts avec la suite de garde-fous du dépôt.
Ouvrez une PR
Décrivez le changement, les systèmes testés et les contrôles CIS affectés.
Une règle de maison, si vous ajoutez un garde-fou : prouvez qu'il échoue. Cassez la chose exprès, regardez le test passer au rouge, puis remettez-la en état. Chaque test du dépôt a été écrit après le défaut qu'il décrit, trouvé en production.