Proteja seu site em 10 minutos com SafeLine WAF


Um guia prático para implantar o SafeLine e proteger seu primeiro site

1. Introdução

Todo site público é um alvo. A injeção de SQL ainda despeja bancos de dados. O cross-site scripting (XSS) ainda sequestra sessões. A travessia do caminho ainda vaza arquivos de configuração. Bots automatizados martelam páginas de login, coletam conteúdo e investigam painéis de administração esquecidos.

Um Web Application Firewall (WAF) confiável é essencial para proteger sites, APIs e outros aplicativos HTTP/HTTPS dos quais sua organização depende.

CyberServal SafeLine é um WAF auto-hospedado desenvolvido em Nginx. Ele fica na frente do seu aplicativo como um proxy reverso HTTP/HTTPS, inspeciona o tráfego de entrada com análise semântica inteligente, descarta solicitações maliciosas e encaminha apenas o tráfego limpo para a origem.

Você não começa com um conjunto de regras em branco. Pronto para uso, o SafeLine já entende cargas de ataques comuns, de modo que uma pequena equipe pode passar de um servidor Linux para um site protegido em cerca de dez minutos.

Este tutorial segue o caminho oficial de implantação automática e o fluxo de trabalho Adicionar aplicativo. Se você puder usar SSH em um host Linux, poderá concluir este guia.

Figura 1. Como funciona o SafeLine: os clientes acessam o WAF primeiro; apenas o tráfego limpo é encaminhado para o aplicativo de origem.

2. Pré-requisitos

Confirme se o host atende ao mínimo oficial antes de executar o instalador. A implantação automática ainda precisa de Docker, Compose e uma CPU compatível com SSSE3.

Item Exigência
Sistema operacional Linux
Arquitetura x86_64 ou ARM64
Docker 20.10.14 ou mais recente
Composição do Docker 2.0.0 ou mais recente
Recursos mínimos 1 núcleo de CPU / 1 GB de RAM / 5 GB de disco
Conjunto de instruções da CPU SSSE3

Verifique o host com:

uname -m
docker version
docker compose version
cat /proc/cpuinfo | grep "processor"
free -h
df -h
lscpu | grep ssse3

Planeje também o acesso à rede:

  • TCP 9443 — console Web SafeLine (HTTPS). Abra-o no firewall do host e no grupo de segurança da nuvem.
  • As portas do seu aplicativo — normalmente TCP 80 e/ou 443. O SafeLine escutará essas portas e fará proxy para a origem.
  • Privilégios de root — o instalador automático requer root (ou sudo).

Observação: SafeLine on ARM requer uma licença Pro; a edição Personal não é compatível com ARM. Prefira um host WAF dedicado em vez de colocar o WAF com uma carga de trabalho de origem pesada.

3. Etapa 1: Implantar SafeLine

Um comando baixa o script do gerenciador, verifica o ambiente, extrai imagens e inicia contêineres. Execute-o como root:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

O que o script faz:

  1. Verifica a arquitetura, Docker, Compose, disco e recursos de CPU.
  2. Cria o diretório de trabalho do SafeLine (o padrão normalmente está em /data/safeline).
  3. Extrai as imagens mais recentes do SafeLine do registro oficial.
  4. Inicia o plano de gerenciamento, mecanismo de detecção, PostgreSQL e serviços relacionados com Docker Compose.

Quando o comando for concluído sem erros, a instalação foi bem-sucedida. Você não precisa escrever um arquivo compose.yaml ou .env sozinho – esse é o objetivo da implantação automática. O console escuta na porta 9443 por padrão.

Se o instalador oferecer opções interativas (caminho de instalação, continuar/atualizar/desinstalar), siga as instruções. Para uma primeira instalação, aceite o diretório padrão, a menos que você tenha um disco de dados dedicado.

4. Etapa 2: Faça login e autentique-se

Abra um navegador e acesse:

https://:9443/

Substituir com o IP público ou privado do host WAF. O console usa HTTPS com um certificado autoassinado na primeira inicialização. Os navegadores irão avisá-lo. Continue após o aviso (Avançado → Aceitar o risco) para chegar à página de login.

Página de login do console Web SafeLine
Figura 2. Página de login do console Web SafeLine (https://:9443/).

Recupere a conta de administrador inicial do host WAF:

docker exec safeline-mgt resetadmin

Uma redefinição bem-sucedida imprime credenciais semelhantes a:

(SafeLine) Initial username: admin
(SafeLine) Initial password: **********
(SafeLine) Done

Armazene esta senha imediatamente. resetadmin gera um novo segredo; trate a saída como um despejo de credenciais único.

Faça login com o nome de usuário admin e a senha impressa. No primeiro login, o SafeLine normalmente solicita que você vincule um autenticador TOTP (MFA). Digitalize o código QR com um aplicativo autenticador (Google Authenticator, 1Password, Authy ou similar), insira o código de seis dígitos e finalize o registro. Mantenha um backup do segredo TOTP. Após a vinculação do MFA, você acessa o painel.

Painel SafeLine após um login bem-sucedido
Figura 3. Painel do SafeLine após login bem-sucedido.

5. Etapa 3: adicione seu site

CyberServal SafeLine protege aplicativos tornando-se a porta de entrada HTTP/HTTPS pública. Os clientes nunca falam diretamente com a origem. Eles falam com SafeLine. SafeLine inspeciona a solicitação, bloqueia ataques e faz proxy do restante para o servidor upstream que você configura.

Na consola:

  1. Abra a página Aplicativos.
  2. Clique em Adicionar aplicativo no canto superior direito.
  3. Preencha os campos de origem e ouvinte e salve.
Caixa de diálogo Adicionar aplicativo mostrando os campos Domínio, Porta, SSL e Upstream
Figura 4. Caixa de diálogo Adicionar aplicativo — Domínio, Porta, SSL e Upstream.

Campos principais, em linguagem simples:

  • Domínio: o nome do host que os clientes usarão, por exemplo www.example.com. Você também pode usar um nome de host ou IP. Este é o nome que você apontará para o WAF no DNS.
  • Porta: a porta em que o SafeLine escuta, geralmente 80 ou 443. Para sites HTTPS, habilite a opção SSL e carregue o certificado e a chave privada que correspondem ao domínio.
  • A montante: o endereço real do aplicativo para o qual o SafeLine encaminha, como http://10.0.0.12:8080 ou http://origin.internal:80. Esta é a origem, não o VIP público.

Proxy reverso em uma frase: o nome DNS público e as portas públicas pertencem ao SafeLine; a origem permanece em um endereço privado ou em uma porta não pública. Depois de salvar o aplicativo, aponte o registro A/AAAA do domínio para o IP do servidor SafeLine. Em seguida, navegue no site por meio desse domínio. Se a página for carregada e o contador de solicitações do painel aumentar, o caminho do proxy estará correto.

Pontas:

  • Não deixe a origem acessível pela internet nas mesmas portas públicas. Caso contrário, os invasores poderão ignorar o WAF.
  • Se a origem estiver no mesmo host do SafeLine, vincule a origem ao 127.0.0.1:8080 (ou outra porta alta) e configure o upstream para esse endereço. Deixe a SafeLine possuir 80/443.
  • Para HTTPS, encerre o TLS no SafeLine. O upstream pode permanecer HTTP na rede interna se isso corresponder ao seu modelo de ameaça.

6. Etapa 4: verificar a proteção contra ataques em tempo real

Com o site acessível através do SafeLine, comprove que a inspeção está acontecendo ao vivo. Substitua example.com pelo seu domínio protegido e abra estes URLs (ou o equivalente HTTP):

# SQL Injection
https://example.com/?id=1+and+1=2+union+select+1

# XSS
https://example.com/?id=

# Path Traversal
https://example.com/?id=../../../../etc/passwd

# Code Injection
https://example.com/?id=phpinfo();system('id')

# XXE
https://example.com/?id=

Você também pode tentar um teste SQLi clássico, como /?id=1' OR '1'='1 ou uma tag de script em uma string de consulta. Um site protegido não deve executar a carga. Em vez disso, o SafeLine retorna uma página de bloqueio (normalmente HTTP 403) informando que a solicitação foi negada.

Página de bloqueio do SafeLine mostrada após uma interceptação bem-sucedida
Figura 5. Página de bloqueio do SafeLine após uma interceptação bem-sucedida.

Abra o console do SafeLine e verifique os logs: Ataques -> LOGS. Você deverá ver a solicitação bloqueada, IP de origem, tipo de ataque e URL. Clique em “Detalhe” para ver a carga útil e o contexto da regra correspondentes.

Lista de ataques no console SafeLine
Figura 6. Lista de ataques no console do SafeLine.
Visualização detalhada do ataque para uma única solicitação bloqueada
Figura 7. Visualização detalhada do ataque para uma única solicitação bloqueada.

Se a origem ainda renderizar o ataque no navegador, no DNS ou no ouvinte estiver errado – o tráfego não está passando pelo SafeLine. Se você vir a página de bloqueio e uma linha de registro correspondente, a proteção está funcionando.

7. Conclusão e Próximos Passos

Em dez minutos você: instalou o SafeLine com um único comando oficial, abriu o console HTTPS na porta 9443, recuperou a senha do administrador, apontou um domínio para ele e confirmou que a injeção de SQL, XSS e testes relacionados estão bloqueados com logs de auditoria.

Essa é a vitória principal. A análise semântica já está ativada. Você não criou um pacote de regras personalizado para impedir a primeira onda de ataques oportunistas.

Quando você estiver pronto para ir mais longe:

  • Configure certificados SSL no ouvinte do aplicativo para que os clientes sempre usem HTTPS.
  • Ajuste listas de permissões e listas de bloqueio para scanners em bom estado ou IPs em mau estado.
  • Revise a Proteção Avançada nos documentos oficiais para controles relacionados a bot, frequência e autenticação.
  • Mantenha o mecanismo atualizado com o guia oficial de atualização após a primeira implantação bem-sucedida.

Recursos importantes:

Proteja o site primeiro. Em seguida, itere em certificados, topologia e política. O SafeLine foi projetado para que a primeira parte não ocupe a tarde inteira.



Source link