Lockdown / Deadman

A primitiva lockdown permite restringir um serviço temporariamente com garantia de auto-recovery mesmo se tudo dependente cair. É usada pelo ssh-service (modo SSH restrito, normalmente acionado por um console de gerenciamento remoto), pelo emergency-mode e pelos emergency-disable dos comandos granulares, e pela confirmação do firewall-restore. É genérica e pode ser aplicada a qualquer serviço do sistema.

Problema que resolve

"Quero conseguir desligar o SSH de um servidor remotamente por tempo determinado, mas se algo der errado no console, no canal de comunicação, ou no próprio binário, o SSH tem que voltar sozinho."

Padrão clássico de deadman switch: a falta de sinal libera o estado. Em vez de exigir comando explícito para soltar, a ausência de heartbeat dispara a recuperação.

Como funciona

                            +----------------+
       create lockdown      |                |
   ----------------------> | implant CLI    |
                            |                |
                            +--------+-------+
                                     |
              +----------------------+----------------------+
              |                                              |
              v                                              v
    +-------------------+                       +----------------------+
    | lockdown_cmd      |                       | systemd-run          |
    | (stop+block agora)|                       | --on-active={ttl}s   |
    +-------------------+                       | --unit=...-restore   |
                                                | -- sh -c '{restore}' |
                                                +----------+-----------+
                                                           |
                                                           v
                                              (deadman: dispara após TTL,
                                               independente do implant)
  1. Disable roda lockdown_cmd (ex: systemctl stop ssh + ufw deny 22)
  2. Em paralelo, agenda um systemd-run --on-active={ttl}s que vai rodar restore_cmd quando o TTL expirar
  3. Heartbeat atualiza expires_at e reagenda o systemd-run
  4. Sem heartbeat por ttl segundos: o systemd-run dispara → serviço é restaurado automaticamente

O recovery acontece dentro do systemd, totalmente desacoplado do implant. Se o binário implant for deletado, o agente que manda os heartbeats cair, ou o servidor reiniciar (systemd-run com --on-active é persistente), o serviço ainda volta.

Componentes

Componente Responsabilidade
implant ssh-service disable --ttl-seconds N Inicia o lockdown
implant ssh-service heartbeat --ttl-seconds N Renova o TTL
systemd-run --on-active=Ns (transient unit) Faz o recovery sozinho
/var/lib/implant/lockdowns/<service>.json Estado persistido
implant ssh-service emergency-restore Recovery manual (exige TTY)
implant lockdown list / status Inspeção das entradas ativas
Agente de gerenciamento (opcional) Manda os heartbeats em loop

Salvaguardas

TTL cap

MAX_TTL_SECONDS = 21600 (6h). Tentativa de TTL maior retorna erro.

O teto vale para cada criação ou renovação; o número de renovações não tem limite. Quem renova pode manter o lockdown enquanto continuar renovando. O teto garante outra coisa: parou de renovar (console fora do ar, agente parado, rede cortada), o SSH volta em no máximo 6h.

Opt-in only

Lockdown nunca é ativado por check --auto-fix. Só ativa quando o operador explicitamente aciona pelo console de gerenciamento (ou roda a CLI). O init.sh não cria nenhum lockdown.

Validação de service

Identificador deve casar [A-Za-z0-9._-]{1,64} — bloqueia injeção de comando via nome.

Shell quoting

lockdown_cmd e restore_cmd são entregues ao sh -c via shell_quote() interno — caracteres especiais escapados.

Atomic writes

State file escrito como .tmp + fs::rename, mode 0600. Diretório mode 0700.

Threat model

Cenário O que acontece
Console de gerenciamento cai Heartbeat para, TTL atual expira, SSH volta
Agente que manda o heartbeat morre Idem
implant binário deletado Recovery via systemd-run mesmo assim
Servidor reinicia systemd preserva timers --on-active; recovery dispara no boot ou no TTL restante (depende da versão do systemd)
Console comprometido Pode criar lockdown e renová-lo sem limite de vezes (até 6h por renovação), mantendo o SSH restrito enquanto renovar. Saídas: emergency-restore no servidor (exige terminal local) ou cortar o acesso do console — sem renovação, o SSH volta em até 6h
Operador local quer recuperar agora sudo implant ssh-service emergency-restore (exige TTY)

O modelo não defende contra ataque local com root — quem tem root no servidor pode parar o systemd-run, editar o state file, ou matar qualquer processo. A defesa é só contra falhas de canal ou abuso remoto via console.

Veja também