whereisxuezugi/cplhfToolkit Bash modulare che rafforza i sistemi Debian/Ubuntu per le competizioni CyberPatriot, automatizzando l'hardening di account, firewall, SSH, PAM e servizi con logging e backup.
Un toolkit Bash modulare per irrobustire sistemi della famiglia Debian/Ubuntu sotto la pressione del tempo di gara. Costruito e perfezionato nel corso di molteplici stagioni della CyberPatriot National Youth Cyber Defense Competition, recentemente classificatosi al livello Platinum nella divisione Linux al turno semifinale del 2025.
Questo non è un framework di conformità generico. È un automatizzatore di checklist per un esercizio a tempo di sei ore: esegue la maggioranza scriptabile di un passaggio di hardening Linux in modo corretto, rapido e idempotente, registra tutto ciò che ha toccato e lascia le decisioni di giudizio alla persona che lo esegue.
I round Linux di CyberPatriot valutano un'immagine live rispetto a una rubrica che premia un insieme piuttosto prevedibile di passaggi di hardening -- igiene degli account, policy delle password, configurazione del firewall, esposizione dei servizi, permessi dei file, livello di patch -- entro un limite di tempo rigido, di solito senza preavviso su quali vulnerabilità siano state inserite. Eseguire quella checklist a mano, correttamente, sotto un conto alla rovescia, è dove i team perdono punti facili a causa di errori di battitura e passaggi dimenticati, non per materiale sconosciuto.
Questo toolkit è nato come un singolo script monolitico scritto esattamente sotto quella pressione. Questo repository è una riscrittura di quello script: stessa copertura della checklist, ristrutturata in piccoli moduli monofunzionali che sono più facili da leggere, testare e ragionare in modo indipendente, con ogni decisione non ovvia collegata a una specifica sezione del CIS Benchmark o a un controllo NIST SP 800-53 (vedi Controlli di sicurezza e riferimenti).
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)]Ogni modulo è caricato tramite source da bin/harden.sh, che gestisce il parsing
degli argomenti, il questionario sul ruolo del servizio e l'ordine di esecuzione. I moduli non si
chiamano direttamente tra loro, e ogni comando che modifica lo stato in ogni modulo
passa attraverso il wrapper run() in lib/common.sh, che dà
all'intero progetto un unico punto in cui implementare il supporto dry-run, un logging
coerente e una gestione degli errori non fatale.
git clone <this-repo>
cd cyberpatriot-linux-hardening
sudo ./bin/harden.sh
Ti verrà chiesta una breve serie di domande sì/no sul ruolo della macchina
(se necessita di Samba, FTP, SSH, un web server e così via), poi
viene eseguito senza supervisione attraverso i moduli elencati sopra. Un log, un set completo di
backup di configurazione con timestamp e uno snapshot di baseline del sistema vengono scritti in
~/hardening-run/.
In un round reale, salta i prompt di conferma per singolo pacchetto e rispondi alle domande sul ruolo da un file di risposte preparato invece di digitarle dal vivo:
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
Vuoi vedere esattamente cosa farebbe prima che tocchi qualcosa?
sudo ./bin/harden.sh --dry-run --config my-machine.env
| Modulo | Fa |
|---|---|
lib/packages.sh | Aggiornamento completo del sistema; rimuove automaticamente cracker di password e strumenti di exploitation; esamina strumenti a doppio uso (nmap, Wireshark, netcat) e servizi legacy (VNC, NFS, telnet) prima di rimuoverli |
lib/firewall.sh | Default-deny in ingresso / default-allow in uscita tramite ufw, più un blocco esplicito su una nota porta backdoor comune |
lib/ssh.sh | Cifrari/KEX/MAC moderni, nessun login root, limiti di connessione e sessione -- oppure rimuove completamente SSH se il ruolo non ne ha bisogno |
lib/services.sh | Samba, FTP, mail, printing, MySQL, HTTP, DNS: ciascuno viene installato e minimamente irrobustito se il ruolo ne ha bisogno, oppure rimosso e bloccato dal firewall se no |
lib/users.sh | Revisione interattiva degli account esistenti (diritti admin, cancellazione, reset password), rilevamento di account nascosti con UID 0 e password vuote |
lib/kernel.sh | Impostazioni sysctl per lo stack di rete e l'autoprotezione del kernel (source routing, redirect ICMP, ASLR, scope ptrace, restrizione dmesg/kptr) |
lib/pam.sh | Complessità e cronologia delle password tramite pam_pwquality/pam_pwhistory, blocco account tramite pam_faillock, scadenza password in login.defs |
lib/filesystem.sh | Permessi dei file principali, restrizione cron/at, un rc.local minimale, banner legali di login, scansione in sola lettura di SUID/world-writable/file senza proprietario |
lib/monitoring.sh | fail2ban e auditd per impostazione predefinita; ClamAV e una scansione completa rkhunter/chkrootkit sono opt-in (vedi Note di sicurezza per la competizione) |
lib/forensics.sh | Snapshot in sola lettura di utenti, processi, porte in ascolto e pacchetti installati per confronti successivi |
tools/find-port-owner.sh e tools/list-nonstandard-users.sh sono
piccole utility autonome per lo stesso tipo di lavoro di triage, utilizzabili
indipendentemente dallo script principale -- vedi le loro intestazioni per l'uso.
Uno script di hardening che rompe la macchina che dovrebbe proteggere è peggio che inutile in un round a tempo. Alcune impostazioni predefinite lo riflettono, e vale la pena comprenderle prima di eseguirlo senza supervisione:
SSH_PASSWORD_AUTH=no), ma l'impostazione predefinita qui favorisce il non chiudere fuori un
team dalla propria macchina quando nessuno ha ancora provisionato le chiavi.INSTALL_CLAMAV, RUN_BASELINE_SCAN), perché sono le due
cose più lente che questo script può fare e nessuna delle due modifica lo stato del sistema da
sola. Attivale se la tua checklist le richiede o se hai
tempo a disposizione.~/hardening-run/baseline/listening_ports.txt
da un'esecuzione precedente se non sei sicuro di cosa sia effettivamente in ascolto prima di
irrobustire una macchina per la prima volta.docs/security-controls.md per la
procedura manuale.bin/harden.sh chiederà interattivamente il ruolo di servizio della macchina
se non rispondi in anticipo. Per saltare i prompt, copia
examples/config.env.example, compila il ruolo effettivo e passalo con
--config. Qualsiasi variabile che ometti dal file ricade su un
prompt interattivo, quindi un file di configurazione parzialmente compilato va bene.
sudo ./bin/harden.sh --config my-machine.env
Flag:
| Flag | Effetto |
|---|---|
--config FILE | Carica le risposte su ruolo/policy da un file env |
--dry-run | Registra ogni azione che verrebbe intrapresa; non cambia nulla |
--auto-approve | Salta i prompt di conferma per la rimozione di singoli pacchetti |
.
├── bin/harden.sh orchestrator: parses args, asks role questions, runs modules in order
├── lib/
│ ├── common.sh logging, backups, idempotent file edits, the run() wrapper
│ ├── packages.sh updates, attack-tool removal
│ ├── ssh.sh SSH install/removal and hardening
│ ├── services.sh samba/ftp/telnet/mail/printing/mysql/http/dns
│ ├── firewall.sh ufw default-deny posture
│ ├── users.sh account review, hidden UID 0 / empty password detection
│ ├── kernel.sh sysctl hardening
│ ├── pam.sh password policy, account lockout
│ ├── filesystem.sh permissions, cron, rc.local, banners, anomaly scan
│ ├── monitoring.sh fail2ban, auditd, rkhunter, chkrootkit, ClamAV
│ └── forensics.sh read-only system baseline snapshot
├── tools/
│ ├── find-port-owner.sh resolve a listening TCP port to a process path
│ └── list-nonstandard-users.sh flag UID >= 1000 accounts not on an expected list
├── docs/
│ ├── security-controls.md every hardening decision, mapped to its source standard
│ └── editor-cheatsheet.md small editor commands worth remembering under pressure
├── examples/config.env.example annotated template for non-interactive runs
└── .github/workflows/shellcheck.yml lint on every push/PR
Ogni script viene analizzato con ShellCheck al
push tramite GitHub Actions (.github/workflows/shellcheck.yml). Per verificare
localmente prima di aprire una PR:
shellcheck lib/*.sh bin/*.sh tools/*.sh
bin/harden.sh --dry-run è anche, di per sé, un test: esercita il flusso di controllo
e il logging di ogni modulo senza toccare il filesystem o
installare nulla, ed è il modo più rapido per verificare un cambiamento
su una VM usa e getta prima di eseguirlo per davvero. Vedi
CONTRIBUTING.md per le aspettative complete sui nuovi moduli (idempotenza,
instradamento delle azioni distruttive attraverso run() e citazione di una fonte per qualsiasi
nuovo passaggio di hardening).
Il commento di intestazione di ogni modulo e docs/security-controls.md citano la
specifica sezione dello standard alla base di ogni decisione. Fonti primarie utilizzate
in tutto il progetto:
| Standard | Fonte |
|---|---|
| CIS Ubuntu Linux Benchmark | https://www.cisecurity.org/benchmark/ubuntu_linux |
| NIST SP 800-53 Rev. 5 | https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final |
| DISA STIG for Ubuntu | https://public.cyber.mil/stigs/downloads/ |
| Mozilla OpenSSH modern configuration guidelines | https://infosec.mozilla.org/guidelines/openssh |
| CyberPatriot National Youth Cyber Defense Competition | https://www.uscyberpatriot.org/ |
Strumenti di rilevamento referenziati (non inclusi nel repository, installati tramite apt):
fail2ban,
Linux Audit / auditd,
rkhunter,
chkrootkit. Lynis
e OpenSCAP sono raccomandati come audit successivo
e indipendente e non vengono eseguiti automaticamente da questo progetto.
Vedi docs/security-controls.md per il ragionamento completo dietro ciascuna di
queste scelte.
MIT. Vedi LICENSE.