whereisxuezugi/cplhfKit modular em Bash que fortalece sistemas Debian/Ubuntu para competições CyberPatriot, automatizando o endurecimento de contas, firewall, SSH, PAM e serviços com registro e backups.
Um toolkit modular em Bash para hardening de sistemas da família Debian/Ubuntu sob pressão de tempo de competição. Construído e refinado ao longo de várias temporadas da CyberPatriot National Youth Cyber Defense Competition, tendo mais recentemente alcançado o nível Platinum na divisão Linux na rodada semifinal de 2025.
Este não é um framework de conformidade de propósito geral. É um automatizador de checklist para um exercício cronometrado de seis horas: ele executa a maioria scriptável de uma passagem de hardening Linux de forma correta, rápida e idempotente, registra tudo o que tocou e deixa as decisões de julgamento para quem o executa.
As rodadas Linux do CyberPatriot pontuam uma imagem ativa contra uma rubrica que recompensa um conjunto bastante previsível de etapas de hardening -- higiene de contas, política de senhas, configuração de firewall, exposição de serviços, permissões de arquivos, nível de patches -- sob um limite de tempo rígido, geralmente sem aviso prévio de exatamente quais vulnerabilidades foram plantadas. Fazer esse checklist à mão, corretamente, sob contagem regressiva, é onde as equipes perdem pontos fáceis por erros de digitação e etapas esquecidas, não por conteúdo desconhecido.
Este toolkit começou como um único script monolítico escrito exatamente sob essa pressão. Este repositório é uma reescrita desse script: mesma cobertura de checklist, reestruturado em módulos pequenos e de propósito único que são mais fáceis de ler, testar e raciocinar de forma independente, com cada decisão não óbvia vinculada a uma seção específica do CIS Benchmark ou controle do NIST SP 800-53 (veja Controles de segurança e referências).
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)]
Cada módulo é carregado por bin/harden.sh, que é responsável pela análise de
argumentos, pelo questionário de função do serviço e pela ordem de execução. Os
módulos não chamam uns aos outros diretamente, e todo comando que altera estado em
cada módulo passa pelo wrapper run() em lib/common.sh, o que dá ao projeto
inteiro um único lugar para implementar suporte a dry-run, logging consistente e
tratamento de erros não fatais.
git clone <this-repo>
cd cyberpatriot-linux-hardening
sudo ./bin/harden.sh
Serão feitas uma breve série de perguntas de sim/não sobre a função da máquina (se
ela precisa de Samba, FTP, SSH, um servidor web, e assim por diante), e então ele
executa de forma não assistida pelos módulos listados acima. Um log, um conjunto
completo de backups de configuração com timestamp e um snapshot de baseline do
sistema são gravados em ~/hardening-run/.
Em uma rodada real, pule os prompts de confirmação por pacote e responda às perguntas de função a partir de um arquivo de respostas preparado, em vez de digitá-las ao 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
Quer ver exatamente o que ele faria antes de tocar em qualquer coisa?
sudo ./bin/harden.sh --dry-run --config my-machine.env
| Módulo | Faz |
|---|---|
lib/packages.sh | Atualização completa do sistema; remove automaticamente quebradores de senha e ferramentas de exploração; revisa ferramentas de uso duplo (nmap, Wireshark, netcat) e serviços legados (VNC, NFS, telnet) antes de removê-los |
lib/firewall.sh | Default-deny para entrada / default-allow para saída via ufw, além de um bloqueio explícito em uma porta de backdoor comum conhecida |
lib/ssh.sh | Cifras/KEX/MACs modernos, sem login root, limites de conexão e sessão -- ou remove o SSH completamente se a função não precisar dele |
lib/services.sh | Samba, FTP, mail, impressão, MySQL, HTTP, DNS: cada um é instalado e minimamente endurecido se a função precisar dele, ou removido e bloqueado por firewall se não precisar |
lib/users.sh | Revisão interativa das contas existentes (direitos de admin, exclusão, redefinição de senha), detecção de contas ocultas com UID 0 e senhas vazias |
lib/kernel.sh | Configurações sysctl de pilha de rede e autoproteção do kernel (source routing, redirecionamentos ICMP, ASLR, escopo de ptrace, restrição de dmesg/kptr) |
lib/pam.sh | Complexidade e histórico de senhas via pam_pwquality/pam_pwhistory, bloqueio de conta via pam_faillock, expiração de senha em login.defs |
lib/filesystem.sh | Permissões de arquivos principais, restrição de cron/at, um rc.local mínimo, banners legais de login, varredura somente leitura de SUID/gravable por todos/arquivos sem dono |
lib/monitoring.sh | fail2ban e auditd por padrão; ClamAV e uma varredura completa de rkhunter/chkrootkit são opt-in (veja Notas de segurança para competição) |
lib/forensics.sh | Snapshot somente leitura de usuários, processos, portas em escuta e pacotes instalados para comparação posterior |
tools/find-port-owner.sh e tools/list-nonstandard-users.sh são pequenos
utilitários autônomos para o mesmo tipo de trabalho de triagem, utilizáveis
independentemente do script principal -- veja seus cabeçalhos para uso.
Um script de hardening que quebra a máquina que deveria proteger é pior que inútil em uma rodada cronometrada. Alguns padrões refletem isso e vale a pena entendê-los antes de executá-lo de forma não assistida: