Integracoes
O Implant e autossuficiente: um binario estatico que verifica, corrige e opera o servidor localmente. Nao precisa de servidor central, conta, banco de dados nem agente. Tudo o que esta nesta pagina e opcional.
Sem dependencias externas
| Aspecto | Como funciona |
|---|---|
| Execucao | Local, como root, a partir do binario |
| Estado | Arquivos locais (/var/lib/implant/, /etc/protocolo-implant/) |
| Saida | stdout (human, json, yaml); nada e enviado para fora |
| Rede | Somente para baixar pacotes da distro, o proprio update e componentes que voce pedir |
Componentes opcionais (`implant install`)
O comando `install` instala aplicacoes complementares. Nenhuma e necessaria para o Implant funcionar.
| Opcao | O que instala |
|---|---|
node |
Node.js via NVM |
claude-code |
Claude Code CLI (requer Node.js) |
sysinfo |
Monitoramento de sistema |
backupally |
Sistema de backup |
container |
Runtime de containers |
deployally |
Gerenciamento de deploys |
runner |
Execucao de CI/CD |
Os binarios sao baixados com as mesmas protecoes do proprio Implant (TLS pinning nos dominios oficiais e assinatura minisign obrigatoria em host sem pin). O destino de cada app pode ser trocado em [endpoints.apps] no config.toml.
Com implant check, o modulo de apps apenas compara a versao instalada com a publicada; o download so acontece com --auto-fix ou install.
Gerenciamento remoto (opcional)
O Implant pode ser operado por um agente de gerenciamento remoto que roda no servidor e conversa com um console. Nesse arranjo:
- O agente chama o Implant localmente e coleta a saida estruturada (
-o json); o Implant nao fala com o console diretamente. - Comandos com recuperacao automatica (
ssh-service,lockdown,emergency-mode,firewall-restore --confirm-timeout) foram desenhados para esse cenario: o console aplica a restricao, o agente envia heartbeats ou a confirmacao, e se o canal cair o servidor volta sozinho ao estado seguro. Veja Lockdown / Deadman. implant agent --install | --configure | --statusinstala e verifica um agent de controle remoto (veja agent).
Sem agente, os mesmos comandos funcionam manualmente pela linha de comando.
Claude Code (opcional)
Para servidores operados com o Claude Code:
| Passo | Comando |
|---|---|
| Node.js + Claude Code | implant install node, implant install claude-code (ou check --install-node --install-claude-code) |
| Usuario dedicado com ACL e sudoers restrito | `implant setup-claude-code` |
Guard-rail (CLAUDE.md com regras de operacao) |
`implant update-guardrail` |
O guard-rail so e baixado por HTTPS, do host configurado em [endpoints], com verificacao de pin.
Fluxo Tipico
Provisionar novo servidor
1. curl -sL https://implant.ccs.systems/init.sh | sudo bash
2. implant check (diagnostico, somente leitura)
3. implant check --auto-fix --dry-run (preview)
4. implant check --auto-fix
5. implant ssh-port 2222 (opcional, com watchdog)
6. implant install <app> (opcional)Manter conformidade
1. implant self-update
2. implant check
3. implant check --auto-fix (quando houver Fail)Gerenciamento de SSH
1. implant ssh-key --add-public-key "ssh-ed25519 AAAA... usuario"
2. implant ssh-port 2222 (alterar porta com watchdog)
3. implant ssh-port --confirm-change (confirmar)
4. implant ssh-rollback (reverter se necessario)Infraestrutura propria
Os endpoints padrao apontam para a distribuicao oficial. Para usar outra infraestrutura, sem recompilar, configure em /etc/protocolo-implant/config.toml:
[endpoints]
cdn_base = "https://cdn.exemplo.com"
guardrail_base = "https://cdn.exemplo.com/claudecode/"
[endpoints.apps.runner]
url = "https://cdn.exemplo.com/{arch}/runner"
path = "/opt/runner/runner"
# Opcional: pin SPKI do seu host
[[tls_pins]]
host = "cdn.exemplo.com"
pin = "sha256/SEU_HASH_BASE64="O config.toml precisa ser completo (as demais secoes sao obrigatorias); veja o MANUAL do Implant. O placeholder {arch} vira x86_64 ou aarch64 em runtime. Hosts sem pin usam validacao WebPKI padrao e exigem .minisig valida para binarios.
Seguranca dos Downloads
TLS Pinning
Os pins SPKI dos dominios oficiais de distribuicao sao extraidos em tempo de compilacao e embutidos no binario. O cliente HTTP do Implant usa rustls com esses pins (e com os de [[tls_pins]]) para validar o certificado antes de qualquer download. Isso protege contra MITM mesmo que uma autoridade certificadora seja comprometida.
Assinatura minisign
Cada release publica implant.minisig (Ed25519) ao lado do binario.
| Origem do download | .minisig ausente |
.minisig invalida |
|---|---|---|
| Dominio com pin embutido (distribuicao oficial) | segue, com warn |
aborta |
Qualquer outro host (--url, CDN proprio) |
aborta | aborta |
init.sh |
aborta | aborta |
┌─────────────────────────────────────────────────────────┐
│ FLUXO DE DOWNLOAD SEGURO │
│ │
│ 1. Exigir HTTPS │
│ 2. Estabelecer conexao TLS │
│ 3. Verificar pin SPKI (embutido ou [[tls_pins]]) │
│ - sem pin conhecido: validacao WebPKI │
│ 4. Pin divergente: BLOQUEAR conexao │
│ 5. Baixar binario e .minisig │
│ 6. Verificar assinatura Ed25519 │
│ 7. Troca atomica do binario, com backup │
│ │
└─────────────────────────────────────────────────────────┘Verificacao manual:
minisign -Vm implant -P "$(curl -s https://implant.ccs.systems/pubkey.pub | tail -1)"Compatibilidade de Arquiteturas
O instalador (init.sh) detecta a arquitetura automaticamente:
ARCH=$(uname -m)
# x86_64 / amd64 → /x86_64/implant
# aarch64 / arm64 → /aarch64/implant
# outras → instalacao recusadaClientes antigos que acessam a URL sem prefixo de arquitetura (https://implant.ccs.systems/implant) continuam funcionando: o arquivo na raiz e uma copia do x86_64.