⏰ Por que automação de segurança importa
Auditoria manual é boa nas duas primeiras semanas. Depois vira "vou fazer no fim de semana", e aí "depois das férias", e aí nunca mais. Cron resolve: máquina não esquece, não cansa, não posterga.
⚖️ Manual vs automatizado
Manual
- • Depende da sua disciplina
- • Posterga em momento de stress
- • Falha quando mais precisa
- • Resultado inconsistente
Automatizado
- • Cron executa sozinho
- • Não tem mau humor nem férias
- • Sempre roda no horário
- • Você só revisa o relatório
⏱️Frequência ideal
- •Pesado (auditoria completa) — 1× por semana
- •Leve (heartbeat de RAM/disco) — a cada 5 min
- •Trimestral (rotação de tokens) — a cada 90 dias
- •Anual (revisão completa de arquitetura) — uma vez por ano
Frequência muito alta vira ruído ignorado. Muito baixa perde o evento. Calibre.
📜 Skill auditoria-vps
Em vez de descrever o procedimento toda vez, encapsule em uma SKILL.md em ~/.hermes/skills/auditoria-vps/. Procedimento claro = execução previsível. Você revisa um relatório consistente.
📄Estrutura da SKILL.md
---
name: auditoria-vps
description: Auditoria semanal de segurança e saúde da VPS
version: 1.0.0
metadata:
hermes:
tags: [security, devops, audit]
category: security
---
# Auditoria VPS
## When to Use
Cron semanal de domingo 9h, ou sob demanda em
incidente.
## Procedure
1. Portas abertas: `ss -tlnp` e `ufw status verbose`
2. Processos top: `ps aux --sort=-%mem | head -20`
3. Espaço em disco: `df -h` e `du -sh /var/log/*`
4. Logs estranhos: `tail -100 /var/log/auth.log`
5. fail2ban: `fail2ban-client status sshd`
6. Atualizações: `apt list --upgradable`
7. Containers: `docker ps -a`, `docker stats --no-stream`
## Verification
- Relatório tem todas as 7 seções
- Anomalias destacadas no topo
- Sugestões de ação com prioridade
## Pitfalls
- Logs de auth.log podem ser longos — pegar só ~100 linhas
- df -h em ZFS pode mostrar números enganosos
- Containers parados também precisam ser auditados🎯 Os 7 checks principais
- 1.Portas abertas — alguma nova que não deveria estar?
- 2.Processos suspeitos — top consumidores de CPU/RAM
- 3.Espaço em disco — partições próximas de 90%
- 4.Logs estranhos — auth.log, syslog, kern.log
- 5.fail2ban status — quantos IPs banidos esta semana?
- 6.Pacotes desatualizados — security updates pendentes
- 7.Containers — algum reiniciando, com OOM, parado inesperadamente?
📅 Cron semanal de segurança
Domingo 9h é o slot ideal: você acorda no fim de semana com café, lê o relatório, age se for o caso. Sem pressão da semana de trabalho. O Hermes injeta a skill na sessão fresh e roda sozinho.
⌨️Comando
/cron add "every Sunday at 09:00" \
"Rode auditoria-vps e me mande o relatório no Telegram. Destaque anomalias no topo." \
--skill auditoria-vps \
--deliver telegram🚩 Flags importantes
--skill auditoria-vps— injeta a skill na sessão fresh do cron--deliver telegram— entrega o relatório no Telegram (oudiscord,all,origin)--workdir /path— define cwd se houver contexto específico--name "auditoria-semanal"— nomeia o job para fácil gestão
🔧 Como funciona internamente
- 1. Scheduler lê
~/.hermes/cron/jobs.jsona cada tick - 2. Vê job vencido: domingo 9h chegou
- 3. Inicia sessão fresh do AIAgent
- 4. Injeta a skill
auditoria-vpsno system prompt - 5. Executa o prompt até conclusão
- 6. Entrega no Telegram
- 7. Atualiza
next_run_at
💓 Cron a cada 5 min em --no-agent
Modo --no-agent roda script sem chamar LLM. Custo zero. Um script Bash checa RAM e disco, sai silencioso se OK, retorna erro se passar do threshold. Sinal-ruído altíssimo.
📜memory-watchdog.sh
#!/bin/bash
# Checa RAM e disco. Silent se OK, exit 1 se crítico.
RAM_USED=$(free | awk '/Mem:/ {print int($3/$2 * 100)}')
DISK_USED=$(df / | awk 'NR==2 {print int($5)}')
if [ "$RAM_USED" -gt 90 ]; then
echo "ALERTA: RAM em ${RAM_USED}%"
exit 1
fi
if [ "$DISK_USED" -gt 85 ]; then
echo "ALERTA: Disco em ${DISK_USED}%"
exit 1
fi
# Tudo OK, sai sem output (silent tick)
exit 0📅 Comando do cron
hermes cron create "every 5m" \
--no-agent \
--script memory-watchdog.sh \
--deliver telegram \
--name "memory-watchdog"Comportamento:
- •stdout vazio + exit 0 → tick silencioso, nada é entregue
- •exit não-zero → alerta de erro entregue no Telegram
- •Scripts
.sh/.bashrodam sob/bin/bash
💡Por que --no-agent
A cada 5 min × 30 dias = ~8.640 execuções/mês. Com LLM, isso queimaria budget significativo. Com --no-agent, custo zero. Use LLM só quando precisa de raciocínio.
🔄 Rotação de tokens
Token vazado meses atrás e não trocado é vulnerabilidade silenciosa. Mesmo se você nunca souber do leak, rotação periódica garante que a janela de exposição é limitada. 90 dias é o padrão razoável.
⌨️Cron de lembrete
/cron add "every 90 days" \
"Hora de rotar tokens. Liste:
1. GitHub fine-grained tokens (verifique expiração)
2. OpenRouter API keys
3. OpenAI project keys
4. Telegram bot tokens (se houve incidente)
5. SSH keys (verificar authorized_keys)
Avise quais foram trocados. Atualize MEMORY.md."📋 Procedimento de rotação
- 1.Gere nova chave no provedor
- 2.Teste a nova chave em ambiente isolado
- 3.
hermes config set KEY nova_chave - 4.Reinicie gateway:
hermes gateway restart - 5.Confirme que está funcionando (mande mensagem de teste)
- 6.Revogue a chave antiga no provedor
- 7.Documente a rotação em
MEMORY.md
⚠️Não pule etapa 6
Trocar a chave nova mas não revogar a antiga = ter duas chaves válidas circulando. Revogar é o que efetivamente fecha a janela de exposição.
📒 Pós-incidente vira MEMORY.md
Quando algo deu errado — token vazou, cron consumiu loop infinito, comando destrutivo aprovado sem revisão — peça ao agente: "Salva isso na MEMORY.md como lição: 'não repetir esse erro'." Próxima sessão começa lembrando.
📝 Template de entrada
## Incidente 2026-04-12
- Sintoma: cron de "summarize feeds" entrou em loop chamando GPT-4 a cada 100ms.
- Causa-raiz: skill blogwatcher mal escrita não tratou erro de RSS 503,
re-tentou indefinidamente.
- Correção: adicionado retry com exponential backoff e limite de 3 tentativas.
- Lição: toda skill que faz HTTP precisa retry com cap. Hard cap de gasto
no provedor é a última linha de defesa.📊 Estrutura recomendada
- •Data — quando aconteceu
- •Sintoma — o que foi observado
- •Causa-raiz — o que efetivamente causou
- •Correção — o que foi feito
- •Lição — princípio generalizado pra futuras situações
📦Limite de memória
MEMORY.md tem ~800 tokens (2.200 chars). Quando enche, o agente consolida entradas antigas para abrir espaço. Padrão geral persiste mesmo quando incidente específico sai. Use linguagem reutilizável: "toda skill que faz HTTP precisa retry com cap" vale por anos.
💡Por que isso importa
É a forma mais barata de fazer pós-mortem. Não precisa convocar reunião, escrever doc formal, criar Jira. "Salva como lição" e segue. Reduz reincidência. Vira aprendizado persistente entre sessões. O agente lembra na próxima, mesmo sem você precisar lembrar.
🎯Resumo do módulo
Próxima trilha:
Trilha 5 - 🔍 Comparações com outros agentes