O que o agente lê, e o que envia
Última atualização:
Um agente de segurança roda como root nos seus servidores, então você precisa saber exatamente o que ele faz com esse acesso. Esta página lista o que o agente InfraFence lê, o que ele altera, o que envia ao painel e o que acontece quando o painel não responde ou o recusa.
Você não precisa acreditar na nossa palavra: o código do agente é público no GitHub, e cada release pode ser conferido com a sua assinatura.
Por que ele precisa de root
O agente gerencia o firewall (iptables e ipset), lê os logs e o estado de rede do sistema e aplica as correções que você pede. Tudo isso exige root. Ele é um único binário Go estático, sem dependências, que roda como um serviço que você pode parar a qualquer momento.
As regras de firewall dele ficam em cadeias próprias, chamadas INFRAFENCE. Ele nunca altera as suas regras e nunca adiciona uma regra de accept por conta própria: as únicas regras de accept são as que você cria no painel. Quando outra ferramenta recarrega o firewall (csf -r, um reload do ufw ou do firewalld, iptables-restore), o agente coloca as cadeias dele de volta.
O que ele lê, e por quê
| O quê | Por quê |
|---|---|
O log de autenticação SSH (journal do systemd, /var/log/auth.log ou /var/log/secure) | Força bruta no SSH e risco das sessões |
| Os logs de acesso do servidor web e o audit log do ModSecurity | Firewall web e bots |
| Os logs de e-mail, banco de dados e FTP | Força bruta nesses serviços |
Os pacotes DNS (porta UDP 53, somente leitura) e as tabelas de conexões em /proc | Ameaças de saída e DNS, varreduras de portas |
Os arquivos dos sites, incluindo .env e arquivos de configuração | Varredura de malware e verificações de frameworks |
Posts, opções e usuários do WordPress, com as credenciais do wp-config.php | Varredura do banco de dados do WordPress |
| Os processos em execução | Crypto miners e reverse shells |
| Os arquivos de sistema monitorados (contas, sudoers, chaves SSH, cron, units do systemd) | Integridade de arquivos |
| Os pacotes instalados e as suas versões | Vulnerabilidades (CVE) |
| O socket do Docker, somente leitura, quando o Docker está presente | Logs e portas dos containers |
Ler um arquivo não é enviá-lo. Tudo o que está nesta tabela é analisado no servidor; a próxima seção lista o que sai dele.
O que ele altera
- As próprias cadeias de firewall e ipsets: banimentos, a lista de permissões, bloqueios por país, portas fechadas.
- Só quando você ativa Permitir alterações na configuração do servidor web: as regras ModSecurity dele e o bloqueio de user agents no nginx ou no Apache. Ele nunca altera uma configuração gerenciada por um painel de hospedagem.
- Só quando você, o AutoMode ou o modo de emergência pedem: correções de hardening, portas fechadas, bloqueios de saída, patches virtuais, atualizações de segurança e arquivos em quarentena.
Cada alteração é verificada logo depois e desfeita se o SSH ou um site para de responder. O modo monitor detecta tudo e não bloqueia nada, e um único comando desinstala o agente e tudo o que ele adicionou.
O que ele envia ao painel
Tudo vai para o painel por HTTPS:
- um heartbeat periódico: versão do agente, endereço, métricas do sistema (CPU, memória, disco, carga, rede), serviços e portas em escuta, o servidor web e os domínios que ele serve, contadores do firewall;
- eventos de segurança: o endereço do atacante, o tipo e o horário do ataque e os detalhes necessários para entendê-lo: para um ataque web, a única linha de log que o disparou; para um malware, o caminho do arquivo e o texto encontrado;
- a lista de pacotes instalados, para a verificação de vulnerabilidades;
- o hash SHA-256 dos arquivos PHP analisados, para procurá-los entre os malwares conhecidos.
Logs e arquivos completos nunca saem do servidor. Não há telemetria, e nada é compartilhado com terceiros, com uma exceção: as funções de IA. Quando você pede uma análise com IA, usa o assistente ou prepara um relatório, e enquanto o AutoMode ou o modo de emergência estão ativos, os eventos necessários são enviados à Anthropic para gerar a resposta. O painel avisa você antes de qualquer envio. A análise instantânea, em todos os planos, não envia nada a lugar nenhum.
Tokens, senhas e autenticação de dois fatores
- O token de instalação é de uso único e vale por uma hora.
- O token do próprio agente fica em
/etc/infrafence/config.json, legível só pelo root. O painel guarda apenas um hash dele, então uma cópia do banco de dados do painel não contém nenhum token de agente utilizável. - As alterações feitas no painel chegam ao agente por um canal que só diz a ele para sincronizar. Depois o agente busca a configuração por HTTPS com o próprio token: uma mensagem nesse canal nunca é tratada como instrução.
- As senhas são guardadas apenas como hash. As senhas novas são comparadas com vazamentos conhecidos (Have I Been Pwned), e só os 5 primeiros caracteres do hash SHA-1 delas saem do seu navegador.
- A autenticação de dois fatores (TOTP) está disponível para todos os usuários. Depois de ativada, é o próprio banco de dados que nega os dados da organização a uma sessão que não passou pela etapa do código. Aprovar uma ação do AutoMode exige uma sessão com 2FA.
Releases assinados, e como conferir um
Cada release é compilado pelo GitHub Actions a partir do repositório público, assinado com Cosign e publicado com build provenance. O agente só instala uma atualização vinda dos releases oficiais no GitHub, e só se o checksum e a assinatura forem válidos com a chave pública embutida no agente.
Para conferir você mesmo o binário no seu servidor, compare o checksum dele com o do release:
curl -sL https://github.com/infrafence/infrafence-agent/releases/latest/download/checksums.txt
sha256sum /usr/local/bin/infrafence-agentVerifique a assinatura Cosign:
cosign verify-blob \
--key https://raw.githubusercontent.com/infrafence/infrafence-agent/main/cosign.pub \
--signature https://github.com/infrafence/infrafence-agent/releases/latest/download/infrafence-agent-linux-amd64.sig \
/usr/local/bin/infrafence-agentE a build provenance, com a GitHub CLI:
gh attestation verify infrafence-agent-linux-amd64 --repo infrafence/infrafence-agentPara uma versão anterior, troque latest/download por download/v<versão>. A imagem de container e o chart Helm também são assinados: veja o SECURITY.md (em inglês).
Código no GitHub, sob a BSL 1.1
O agente é source-available sob a Business Source License 1.1: você pode ler e auditar cada linha antes de instalar. O uso em produção é gratuito em qualquer número de servidores, inclusive os dos seus clientes, desde que você não o use para oferecer um produto concorrente. Quatro anos depois da publicação de cada versão, essa versão passa a ficar disponível sob a Apache License 2.0.
O site e o painel
- Somente HTTPS, com HSTS por dois anos em infrafence.com e em todos os subdomínios.
- Uma Content Security Policy rígida: scripts só do nosso próprio domínio, cada um com um nonce por requisição, e nenhum outro site pode exibir as páginas em um frame.
- Fontes servidas pelo nosso próprio domínio. Cookies de análise ou publicidade só são ativados se você os aceitar no banner de cookies; sem consentimento, não há nenhum.
Onde ficam os dados
O painel e o banco de dados dele rodam em servidores da Contabo GmbH na Alemanha, na União Europeia. A Stripe, para os pagamentos, e o provedor de IA, quando você usa as funções de IA, podem tratar dados fora da UE com base nas Cláusulas Contratuais Padrão da Comissão Europeia ou em uma decisão de adequação. Nunca vendemos nem alugamos dados pessoais.
A Privacy Policy (em inglês) lista cada destinatário e por quanto tempo cada tipo de dado é guardado.
Quando o painel não responde
O agente nunca precisa do painel para proteger o servidor: detecção, banimentos e bloqueios rodam todos no servidor. Erros de rede, timeouts, falhas de DNS e erros do servidor nunca são tratados como recusa, então a proteção continua ativa enquanto durar a indisponibilidade. Banimentos, a lista de permissões, bloqueios por país e portas fechadas continuam valendo, novos ataques continuam sendo bloqueados e os eventos esperam em uma fila até o painel voltar a responder.
Uma recusa é diferente: o painel recusa um agente cujo token foi revogado, cuja organização está suspensa ou que passou do limite de servidores do plano, por exemplo depois de um cancelamento ou de uma fatura não paga.
- Nas primeiras 24 horas a proteção local continua valendo, e o agente continua perguntando.
- Depois de 24 horas de recusa sem uma única resposta bem-sucedida, o agente desliga a proteção de forma limpa: remove as cadeias de firewall e os ipsets dele, as regras dele no servidor web e o monitoramento de malware, e a detecção continua só em modo monitor. As regras de outras ferramentas nunca são tocadas.
- Onde o sistema permite, um aviso no login informa que o InfraFence não protege mais o servidor.
- O agente continua perguntando a cada 30 minutos. Na primeira resposta bem-sucedida, a proteção volta a funcionar e o aviso é removido.
Os proprietários da conta recebem um e-mail 12 horas antes do desligamento, no desligamento e quando o acesso é restabelecido.
Como relatar uma vulnerabilidade
Escreva para info@infrafence.com, o contato do nosso security.txt. Por favor, não abra uma issue pública no GitHub. Se puder, inclua os passos para reproduzir. Respondemos em até 48 horas e, com a sua permissão, damos o crédito a você nas notas de versão. A política completa está no SECURITY.md (em inglês).
Teste grátis em 1 servidor
O Starter protege um servidor por completo, grátis e sem cartão de crédito.
- 01
Crie uma conta gratuita e abra Servidores › Adicionar servidor para obter o token de instalação. Ele vale por uma hora.
Criar o token - 02
Depois execute isto como root no servidor:
curl -fsSL https://github.com/infrafence/infrafence-agent/releases/latest/download/install.sh | sudo bash -s -- --token <TOKEN>
