whereisxuezugi/cplhfBoîte à outils Bash modulaire qui durcit les systèmes Debian/Ubuntu pour les compétitions CyberPatriot, automatisant le durcissement des comptes, du pare-feu, de SSH, de PAM et des services avec journalisation et sauvegardes.
Une boîte à outils Bash modulaire pour durcir les systèmes de la famille Debian/Ubuntu sous la pression du temps de compétition. Construite et affinée au fil de plusieurs saisons de la CyberPatriot National Youth Cyber Defense Competition, ayant récemment atteint le niveau Platine dans la division Linux lors du tour semifinal de 2025.
Ce n'est pas un cadre de conformité à usage général. C'est un automate de liste de contrôle pour un exercice chronométré de six heures : il effectue la majorité scriptable d'une passe de durcissement Linux correctement, rapidement et de manière idempotente, journalise tout ce qu'il a touché, et laisse les décisions de jugement à la personne qui l'exécute.
Les épreuves Linux de CyberPatriot évaluent une image live selon une grille qui récompense un ensemble assez prévisible d'étapes de durcissement -- hygiène des comptes, politique de mots de passe, configuration du pare-feu, exposition des services, permissions de fichiers, niveau de correctifs -- sous une limite de temps stricte, généralement sans préavis sur les vulnérabilités exactes qui ont été implantées. Faire cette liste de contrôle à la main, correctement, sous un compte à rebours, c'est là que les équipes perdent des points faciles à cause de fautes de frappe et d'étapes oubliées, et non à cause d'un contenu inconnu.
Cette boîte à outils a commencé comme un unique script monolithique écrit sous exactement cette pression. Ce dépôt est une réécriture de ce script : même couverture de la liste de contrôle, restructurée en petits modules à usage unique qui sont plus faciles à lire, à tester et à raisonner indépendamment, avec chaque décision non évidente rattachée à une section spécifique du CIS Benchmark ou à un contrôle NIST SP 800-53 (voir Contrôles de sécurité et références).
flowchart TD
A[bin/harden.sh] --> B[lib/common.sh<br/>logging, backups, run wrapper]
A --> C[Service-role prompts<br/>or --config file]
A --> D[lib/packages.sh<br/>updates, attack-tool removal]
A --> E[lib/firewall.sh<br/>default-deny + ufw]
A --> F[lib/ssh.sh]
A --> G[lib/services.sh<br/>samba/ftp/mail/http/mysql/dns]
A --> H[lib/users.sh<br/>account review, hidden UID 0]
A --> I[lib/kernel.sh<br/>sysctl hardening]
A --> J[lib/pam.sh<br/>password policy, lockout]
A --> K[lib/filesystem.sh<br/>permissions, cron, banners]
A --> L[lib/monitoring.sh<br/>fail2ban, auditd, rkhunter]
A --> M[lib/forensics.sh<br/>baseline snapshot]
D & E & F & G & H & I & J & K & L & M --> N[(~/hardening-run/<br/>log + backups + baseline)]
Chaque module est sourcé par bin/harden.sh, qui gère l'analyse des arguments, le questionnaire sur le rôle du service et l'ordre d'exécution. Les modules ne s'appellent pas directement entre eux, et chaque commande modifiant l'état dans chaque module passe par le wrapper run() de lib/common.sh, ce qui donne à l'ensemble du projet un seul endroit pour implémenter la prise en charge du dry-run, une journalisation cohérente et une gestion des erreurs non fatales.
git clone <this-repo>
cd cyberpatriot-linux-hardening
sudo ./bin/harden.sh
Une courte série de questions oui/non vous sera posée sur le rôle de la machine (a-t-elle besoin de Samba, FTP, SSH, d'un serveur web, etc.), puis il s'exécute sans surveillance à travers les modules listés ci-dessus. Un journal, un ensemble complet de sauvegardes de configuration horodatées et un instantané de référence du système sont écrits dans ~/hardening-run/.
Lors d'une épreuve réelle, évitez les invites de confirmation par paquet et répondez aux questions sur le rôle à partir d'un fichier de réponses préparé plutôt que de les saisir en direct :
cp examples/config.env.example my-machine.env
# edit my-machine.env for this box's actual role
sudo ./bin/harden.sh --config my-machine.env --auto-approve
Vous voulez voir exactement ce qu'il ferait avant qu'il ne touche à quoi que ce soit ?
sudo ./bin/harden.sh --dry-run --config my-machine.env
| Module | Fait |
|---|---|
lib/packages.sh | Mise à jour complète du système ; supprime automatiquement les craqueurs de mots de passe et les outils d'exploitation ; examine les outils à double usage (nmap, Wireshark, netcat) et les services hérités (VNC, NFS, telnet) avant de les supprimer |
lib/firewall.sh | Refus par défaut en entrée / autorisation par défaut en sortie via ufw, plus un blocage explicite d'un port de porte dérobée courant connu |
lib/ssh.sh | Chiffrements/KEX/MAC modernes, pas de connexion root, limites de connexion et de session -- ou supprime entièrement SSH si le rôle n'en a pas besoin |
lib/services.sh | Samba, FTP, mail, impression, MySQL, HTTP, DNS : chacun est installé et durci minimalement si le rôle en a besoin, ou purgé et bloqué par pare-feu sinon |
lib/users.sh | Examen interactif des comptes existants (droits d'administration, suppression, réinitialisation de mot de passe), détection des comptes cachés UID-0 et des mots de passe vides |
lib/kernel.sh | Paramètres sysctl de la pile réseau et d'auto-protection du noyau (routage par la source, redirections ICMP, ASLR, portée ptrace, restriction dmesg/kptr) |
lib/pam.sh | Complexité et historique des mots de passe via pam_pwquality/pam_pwhistory, verrouillage de compte via pam_faillock, vieillissement des mots de passe dans login.defs |
lib/filesystem.sh | Permissions des fichiers principaux, restriction cron/at, un rc.local minimal, bannières légales de connexion, analyse en lecture seule des fichiers SUID/accessibles en écriture par tous/sans propriétaire |
lib/monitoring.sh | fail2ban et auditd par défaut ; ClamAV et un balayage complet rkhunter/chkrootkit sont optionnels (voir Notes de sécurité en compétition) |
lib/forensics.sh | Instantané en lecture seule des utilisateurs, processus, ports en écoute et paquets installés pour comparaison ultérieure |
tools/find-port-owner.sh et tools/list-nonstandard-users.sh sont de petits utilitaires autonomes pour le même type de travail de triage, utilisables indépendamment du script principal -- voir leurs en-têtes pour l'utilisation.
Un script de durcissement qui casse la machine qu'il est censé protéger est pire qu'inutile lors d'une épreuve chronométrée. Quelques valeurs par défaut en tiennent compte, et méritent d'être comprises avant de l'exécuter sans surveillance :