Como Implantar o SafeLine WAF em um VPS Linux

Aplicações web expostas à internet são rotineiramente sondadas em busca de injeção de SQL, abuso de credenciais e padrões de vulnerabilidades conhecidas. O SafeLine é um WAF auto-hospedado sob licença GPL-3.0 que roda como uma stack Docker Compose e filtra o tráfego HTTP/S antes de encaminhar as requisições permitidas para a origem. Seu plano Personal gratuito suporta até 10 aplicações.

Este tutorial cobre a instalação e três áreas que exigem atenção especial: a decisão sobre a arquitetura de proxy reverso, a configuração da rede Docker quando o SafeLine fica atrás de um proxy existente como o Nginx Proxy Manager, e um comando de verificação que você pode executar após a instalação para confirmar que o WAF está de fato interceptando ataques.

A versão curta

• Instale o SafeLine em um VPS Linux com Docker Compose. Use o instalador de uma linha ou opte pelo caminho manual com Docker Compose para inspecionar a definição do Compose e a configuração de ambiente antes de iniciar a stack.
• Decida a arquitetura de proxy reverso antes de instalar: o SafeLine como único proxy, o SafeLine atrás de um Nginx Proxy Manager existente, ou o SafeLine dividindo o servidor com o Caddy. Cada formato exige atribuições de portas e configurações de X-Forwarded-For diferentes.
• Após a instalação, verifique o WAF enviando com o curl uma sonda de injeção de SQL contra a URL protegida. No modo Balanced ou Strict, uma resposta 403 mais uma entrada correspondente em Attack Events confirma o bloqueio. No modo Monitor, o evento correspondente confirma a detecção mesmo que a resposta continue bem-sucedida.
• O nível Personal gratuito cobre até 10 aplicações e o motor de detecção principal. Bloqueio geográfico, exportação de logs de ataque e notificações externas exigem o nível Lite; detecção de ataques mais avançada e balanceamento de carga exigem o Pro.

Antes de Começar: Pré-requisitos e o Que Este Tutorial Cobre

Este tutorial presume que você tem um VPS Linux ao qual pode se conectar por SSH com acesso root ou sudo, e que o Docker está instalado. Você terminará com uma instância funcional do SafeLine protegendo ao menos um site e um comando de verificação que pode reexecutar a qualquer momento.

Você precisa de:

• Um VPS Linux. Os comandos a seguir presumem um sistema no estilo Debian ou Ubuntu com systemd; verifique os nomes de pacotes e serviços em outras distribuições.
• Ao menos 1 vCPU, 1 GB RAM e 5 GB de disco, de acordo com os requisitos oficiais de implantação. Para uma folga prática em produção, este guia recomenda 2 vCPU, 4 GB RAM e 20 GB de disco.
• Docker 20.10.14 ou posterior e Docker Compose 2.0 ou posterior.
• Uma CPU x86_64 com suporte a SSSE3; verifique isso com lscpu | grep ssse3 em vez de presumir que a instrução está presente.
• Um domínio ou subdomínio com DNS apontando para o IP público do VPS, caso você planeje expor a aplicação protegida por HTTPS público.
• Portas adequadas à topologia escolhida. Os formatos A e C normalmente entregam ao SafeLine as portas 80 e 443, enquanto o formato B mantém essas portas com o Nginx Proxy Manager e atribui ao SafeLine um listener diferente, como a 10080.
• Acesso root ou sudo.

No firewall ou grupo de segurança do provedor do VPS, exponha apenas as portas públicas que a topologia escolhida precisa. Restrinja o SSH e a TCP 9443 a fontes de administração confiáveis. No formato B, mantenha a TCP 10080 fechada para IPv4 e IPv6 públicos, e mantenha portas de backend como a 8080 privadas em toda topologia. O acesso direto à 10080 contornaria o NPM e invalidaria o limite de confiança do X-Forwarded-For.

Nota: Para implantação manual em ARM64, defina ARCH_SUFFIX=-arm. A documentação oficial de implantação do SafeLine afirma que o ARM exige uma licença Pro e que a Personal Edition não é suportada em ARM. Use um VPS x86_64 para a Personal Edition.

Verifique o Docker antes de começar:

docker --version
docker compose version

Ambos os comandos devem retornar as versões instaladas. Prossiga somente se o Docker for versão 20.10.14 ou posterior e o Docker Compose for versão 2.0.0 ou posterior; caso contrário, atualize antes de instalar o SafeLine.

Escolha Primeiro a Sua Arquitetura de Proxy Reverso

Um VPS novo permite que o SafeLine assuma diretamente as portas 80 e 443. Um VPS que já roda o Nginx Proxy Manager, o Caddy ou o próprio Nginx da aplicação não permite, e a decisão de arquitetura é a diferença entre uma instalação tranquila e um conflito de portas no primeiro boot. Acerte isso uma vez no início e o restante da implantação é mecânico.

Os três formatos:

• Formato A, o SafeLine como único proxy reverso. O SafeLine assume as portas 80 e 443 e gerencia o TLS para a aplicação protegida. As versões CE atuais incluem um fluxo de trabalho Free Cert, enquanto o upload manual de certificado continua disponível; verifique as opções exatas de certificado na versão instalada. O backend roda em uma porta não pública e o SafeLine roteia até ele.
• Formato B, o SafeLine atrás do Nginx Proxy Manager (NPM). O NPM mantém as portas 80 e 443 e cuida do SSL. O SafeLine escuta na porta 10080 (apenas HTTP, já que o NPM já encerrou o TLS). O NPM encaminha para o SafeLine; o SafeLine encaminha para o backend. Esta é uma configuração comum quando o NPM já está implantado.
• Formato C, o SafeLine ao lado do Caddy. O HTTPS automático do Caddy compete com o SafeLine pela porta 443. Um arranjo viável entrega ao SafeLine as portas 80 e 443 e move o Caddy para uma porta HTTP interna não pública, como a 8080, no salto do SafeLine para o Caddy e daí para a aplicação.

Ponto-chave: O formato A é o mais simples para um VPS novo; o formato B é a escolha certa quando o NPM já está em execução; o formato C exige uma reatribuição deliberada de portas do Caddy.

Instale o SafeLine no Seu VPS

A instalação em si é a parte fácil. O SafeLine oferece dois caminhos de instalação: um instalador automatizado que baixa um script remoto de waf.chaitin.com e um caminho manual com Docker Compose que permite inspecionar tudo antes de executar. Escolha o que combina com a sua política de segurança.

Passo 1: Confirme Que o Docker Está Pronto

Verifique novamente a versão do Docker e se o daemon do Docker está em execução:

docker --version
docker compose version
sudo systemctl status docker

A saída esperada inclui active (running) para o daemon do Docker. Se ele não estiver em execução, inicie-o com sudo systemctl start docker e habilite-o na inicialização com sudo systemctl enable docker.

Passo 2: Execute o Instalador do SafeLine

Há dois subcaminhos. Escolha um.

Passo 2a, instalação automatizada. Execute o instalador com privilégios de root:

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

O script pergunta onde colocar o diretório de dados do SafeLine, baixa as imagens do Docker e inicia a stack. Após a instalação, execute sudo docker exec safeline-mgt resetadmin para recuperar ou redefinir as credenciais de administrador, conforme descrito no guia oficial de implantação. Armazene as credenciais resultantes de forma segura.

Nota: Este comando baixa e executa como root um script de shell remoto de waf.chaitin.com. O comando de uma linha oficial inclui curl -k, que desabilita a verificação de certificado TLS. Revise o script baixado antes de executá-lo, ou use o Passo 2b se esse risco for inaceitável. O SafeLine também está disponível como uma implantação Cloudzy de um clique, mas essa imagem usa /opt/safeline, /opt/safeline/.env, e /opt/safeline/docker-compose.yml. Não use os caminhos /data/safeline deste guia sem alterações na imagem da Cloudzy.

Passo 2b, instalação manual com Docker Compose. Baixe e inspecione o arquivo Compose oficial e, em seguida, inicie a stack:

sudo mkdir -p /data/safeline
cd /data/safeline
sudo wget -O /data/safeline/compose.yaml "https://waf.chaitin.com/release/latest/compose.yaml"
POSTGRES_PASSWORD="$(openssl rand -hex 32)"
sudo tee .env >/dev/null <<EOF
SAFELINE_DIR=/data/safeline
IMAGE_TAG=latest
MGT_PORT=9443
POSTGRES_PASSWORD=$POSTGRES_PASSWORD
SUBNET_PREFIX=172.22.222
IMAGE_PREFIX=chaitin
ARCH_SUFFIX=
RELEASE=
REGION=-g
MGT_PROXY=0
EOF
unset POSTGRES_PASSWORD
# Also adjust SUBNET_PREFIX if your VPS already uses 172.22.222.0/24.
sudo chmod 600 /data/safeline/.env
sudo docker compose up -d

Depois docker compose up -d terminar, liste os contêineres em execução para confirmar:

sudo docker compose ps

Você deve ver contêineres para safeline-mgt, safeline-detector, safeline-tengine, safeline-pg, safeline-fvm, safeline-luigi e safeline-chaos. Se algum contêiner mostrar Exited, consulte o Passo 3 para as duas causas mais comuns.

Passo 3: Resolva Erros Comuns de Instalação

Dois erros aparecem com frequência suficiente para merecerem um passo próprio.

Sobreposição de sub-rede. Se a instalação falhar com Pool overlaps with other one on this address space, a sub-rede padrão do SafeLine entra em conflito com uma rede Docker existente. Conforme documentado em um guia de resolução de problemas de instalação do SafeLine, corrija isso editando /data/safeline/.env:

sudo nano /data/safeline/.env
# Find the line:
#   SUBNET_PREFIX=172.22.222
# Change to an unused range, for example:
#   SUBNET_PREFIX=172.30.30
sudo docker compose -f /data/safeline/compose.yaml down
sudo docker compose -f /data/safeline/compose.yaml up -d

Erro de resolver IPv6. Se o safeline-tengine travar com nginx: [emerg] invalid IPv6 address in resolver, primeiro inspecione o arquivo do resolver e determine quem o gerencia:

readlink -f /etc/resolv.conf
cat /etc/resolv.conf

Não edite /etc/resolv.conf diretamente se ele for gerado pelo systemd-resolved, pelo NetworkManager ou pelo provedor do VPS. Corrija o valor de nameserver malformado na configuração do serviço que o gerencia, regenere o arquivo do resolver e, em seguida, reinicie o Tengine:

sudo docker restart safeline-tengine

Passo 4: Acesse o Painel

O painel de gerenciamento do SafeLine escuta na TCP 9443 sobre HTTPS. Não deixe essa porta administrativa aberta para toda a internet. Restrinja-a a um endereço de origem confiável ou VPN, ou bloqueie o acesso público e use um túnel SSH:

ssh -L 9443:127.0.0.1:9443 USER@SERVER_IP

Abrir https://localhost:9443 através do túnel. Um aviso de certificado autoassinado é esperado no primeiro acesso; verifique se a conexão SSH chegou ao servidor pretendido antes de prosseguir.

Se você perdeu as credenciais iniciais, redefina a senha de administrador a partir do host:

sudo docker exec safeline-mgt resetadmin

O comando imprime credenciais de administrador que você pode usar para entrar novamente.

Configure o SafeLine para a Sua Arquitetura

O SafeLine está em execução agora, mas ainda não protege nada. A página Applications do painel é onde você informa ao SafeLine quais sites proteger e para onde encaminhar o tráfego limpo. A configuração difere conforme a arquitetura que você escolheu antes, então cada formato tem sua própria subseção. Trabalhe apenas naquela que corresponde à sua configuração.

Formato A: o SafeLine como Único Proxy Reverso

No formato A, o SafeLine escuta diretamente nas portas 80 e 443 e encaminha o tráfego limpo para a sua aplicação de backend em uma porta não pública. No painel:

1. Navegue para Applications, depois Add Application.
2. Defina a porta de escuta como 443 e habilite o SSL. Use o fluxo de trabalho de certificado disponível na versão do SafeLine que você instalou. As versões CE atuais incluem a emissão Free Cert e o tratamento de renovação, enquanto o upload manual de certificado continua disponível.
3. Defina o upstream como http://127.0.0.1:8080. Se o backend rodar no Docker, publique sua porta apenas no loopback, por exemplo "127.0.0.1:8080:8080" na seção de ports do serviço. Evite um IP de contêiner fixo como 172.17.0.5 porque ele pode mudar quando o contêiner é recriado.
4. Salve a aplicação. O SafeLine começa imediatamente a escutar na 443 e a encaminhar o tráfego limpo para o backend.
5. Confirme que o registro DNS A do seu domínio aponta para o IP público do VPS e que as portas 80 e 443 são acessíveis de fora.

Se a porta 443 já estava vinculada a outro processo, o contêiner do SafeLine não conseguirá vinculá-la e o painel mostrará um erro nessa aplicação. Pare o processo conflitante, ou escolha uma porta diferente, antes de adicionar a aplicação.

Formato B: o SafeLine Atrás do Nginx Proxy Manager

O formato B mantém o NPM fazendo o que já faz (assumindo as portas 80 e 443 e cuidando do Let's Encrypt) e encaixa o SafeLine como uma camada de segurança dedicada atrás dele. O fluxo de tráfego é: cliente, depois NPM (porta 443, encerramento de TLS), depois SafeLine (porta 10080, HTTP), depois a aplicação de backend.

Dentro do painel do SafeLine:

1. Applications, depois Add Application. Defina a porta de escuta como 10080 e deixe o SSL desativado (o NPM já encerrou o TLS).
2. Defina o upstream como o endereço interno da aplicação, conforme descrito no formato A.
3. Salve a aplicação.

No Nginx Proxy Manager:

1. Hosts, depois Proxy Hosts, depois Add Proxy Host.
2. Aba Details: defina o nome de domínio, o esquema httpe a porta de encaminhamento 10080. Se o NPM roda diretamente no host, use 127.0.0.1 como hostname de encaminhamento. Se o NPM roda no Docker em Linux, 127.0.0.1 aponta para o contêiner do NPM em vez do host do VPS. Adicione o mapeamento host-gateway do Docker ao serviço Compose do NPM e, em seguida, use host.docker.internal como hostname de encaminhamento:

extra_hosts:
  - "host.docker.internal:host-gateway"

A partir do diretório Compose do NPM, execute sudo docker compose up -d para que o contêiner seja recriado com o novo mapeamento de host.

3. Aba SSL: solicite um certificado Let's Encrypt, force o SSL e habilite o HTTP/2.
4. Deixe a aba Advanced do NPM vazia para o X-Forwarded-For. No template atual do NPM, o conteúdo de Advanced é inserido no escopo de server e não sobrescreve os cabeçalhos gerados no nível de location conforme as regras de herança do NGINX. O location gerado envia:

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

A segunda diretiva anexa o endereço observado pelo NPM como o valor mais à direita no cabeçalho.

5. Salve o Proxy Host.

De volta ao SafeLine, configure a extração do IP de origem somente após confirmar a cadeia de cabeçalhos efetiva. SafeLine 9.3.1 introduziu a extração flexível de XFF com seleção de direção e índice.

1. Settings, depois Advanced, depois Real IP from Header. Defina o nome do cabeçalho como X-Forwarded-For.
2. Use a extração personalizada a partir do final do cabeçalho e selecione o endereço mais à direita adicionado pelo NPM. Os rótulos exatos de índice variam conforme a versão, então verifique o resultado em Logs, depois Access. Se a versão instalada for anterior à 9.3.1, atualize-a antes de seguir esta topologia.
3. Se o Cloudflare ou outro CDN estiver antes do NPM, primeiro configure o NPM para confiar apenas nas faixas de proxy publicadas por esse provedor, de modo que o endereço anexado pelo NPM seja confiável. Não selecione uma posição fixa até ter inspecionado e testado a cadeia de cabeçalhos real.
4. Salve e recarregue a aplicação.

Teste a configuração a partir de uma máquina fora do VPS:

curl -H "X-Forwarded-For: 1.2.3.4" "https://yourdomain.com/"

O log de acesso do SafeLine deve mostrar o seu endereço público real, não 1.2.3.4 nem o endereço de bridge do NPM.

Impeça que usuários contornem o SafeLine mantendo o listener do backend privado. Para um backend Docker Compose, publique a porta apenas no loopback:

ports:
  - "127.0.0.1:8080:8080"

Para um serviço que roda diretamente no host, configure-o para escutar em 127.0.0.1:8080 em vez de 0.0.0.0:8080. Verifique ambas as portas internas a partir de uma máquina fora do VPS:

curl --connect-timeout 5 "http://YOUR_VPS_PUBLIC_IP:10080"
curl --connect-timeout 5 "http://YOUR_VPS_PUBLIC_IP:8080"

As conexões TCP devem ser recusadas ou atingir o tempo limite. Um erro HTTP ou "Empty reply from server" ainda significa que a porta é acessível publicamente e precisa ser protegida. Se a vinculação ao loopback for impossível, crie regras de firewall adaptadas à interface real, à rede Docker e ao contêiner de destino, em vez de aplicar uma regra DOCKER-USER genérica.

Formato C: o SafeLine com o Caddy

No formato C, o SafeLine assume as portas 80 e 443; o Caddy move para uma porta HTTP interna não pública. O fluxo de tráfego é: cliente, depois SafeLine (443, TLS), depois Caddy (8080, HTTP interno), depois o backend da aplicação.

Editar /etc/caddy/Caddyfile:

:8080 {
bind 127.0.0.1
reverse_proxy 127.0.0.1:3000
}

O :8080 O bloco de site é a parte importante: o Caddy agora escuta em uma porta HTTP interna em vez de competir com o SafeLine pela 443. A bind 127.0.0.1 linha mantém esse listener local ao VPS. Recarregue o Caddy com sudo systemctl reload caddy e confirme com sudo ss -ltnp | grep -E ':(443|8080)' que o Caddy está vinculado à 8080, e não à 443.

No SafeLine, adicione uma aplicação que escute na 443 com SSL habilitado e, em seguida, defina o upstream como http://127.0.0.1:8080. A configuração de X-Forwarded-For pode permanecer na opção padrão de conexão de rede, porque o Caddy fica atrás do SafeLine, não à frente dele.

Escolha um Modo de Proteção e Verifique Que o WAF Está Bloqueando Ataques

O SafeLine tem três modos de proteção que decidem o que acontece quando o motor sinaliza uma requisição como maliciosa. O modo inicial certo depende da aplicação; a etapa de verificação é a mesma em qualquer modo.

Modos de Proteção: Monitor, Balanced, Strict

Cada aplicação no SafeLine tem sua própria configuração de modo de proteção, configurável em Applications, depois seu aplicativo, depois Protection Mode:

• Monitor. O SafeLine registra as requisições que de outra forma bloquearia, mas não as bloqueia. Este é o ponto de partida mais seguro para uma aplicação de produção complexa com formulários de entrada ricos (um fórum, um painel de administração com campos WYSIWYG, uma API que aceita payloads JSON de formato livre). Rode o Monitor por alguns dias, revise a página Attack Events e confirme que não há falsos positivos contra usuários reais antes de promover para Balanced.
• Balanced. O modo padrão. Os números publicados pelo fornecedor no GitHub do SafeLine relatam 71.65% de detecção, 99.45% de precisão e uma taxa de 0.07% de falsos positivos para o modo Balanced. O modo Strict é relatado com 76.17% de detecção, 99.38% de precisão e uma taxa de 0.22% de falsos positivos. Esses são resultados informados pelo fornecedor, e não um benchmark independente, e o README não identifica o conjunto de dados como WAF-Eval. Trate-os como números comparativos do produto, não como desempenho garantido em produção.
• Strict. Um conjunto de regras mais agressivo, com heurísticas mais rígidas e o compromisso entre detecção e falsos positivos mostrado acima. Vale a pena experimentar após uma ou duas semanas de operação limpa em Balanced, depois de entender o seu tráfego.

Recomendação: Balanced para uma implantação nova sem tráfego real a ser perturbado. Para uma aplicação de produção existente, comece em Monitor por alguns dias, procure falsos positivos no log de Attack Events e promova para Balanced depois de ajustar quaisquer exceções. Vale a pena experimentar o Strict após uma ou duas semanas de Balanced, depois de entender o seu tráfego.

Verifique o WAF com um Teste de SQLi via curl

A etapa final, antes de considerar a instalação concluída, é confirmar que o WAF de fato intercepta um ataque. Rode uma sonda benigna de injeção de SQL contra o seu site protegido a partir de qualquer máquina fora do VPS:

curl -i "https://yourdomain.com/?id=1%20and%201=2%20union%20select%201"

Este é o vetor de teste de injeção de SQL publicado pelo SafeLine. No modo Balanced ou Strict, espere um status 403 e uma resposta de bloqueio do SafeLine. No modo Monitor, espere que a requisição seja registrada sem bloqueio. A versão do HTTP e o corpo exato da resposta podem variar, então confirme o resultado com uma entrada correspondente em Attack Events.

Em seguida, abra o painel pelo método de acesso restrito do Passo 4 e navegue até Logs, depois Attack Events. Você deve ver uma nova entrada com o timestamp correspondente, tipo de ataque SQL Injection, IP de origem correspondente à máquina de onde você rodou o curl e a query string ofensiva no detalhe da requisição. Clique no evento para ver a requisição e a resposta completas capturadas pelo SafeLine.

Se a requisição do curl retornou 200 OK, interprete o resultado junto com o log de Attack Events:

• Um evento SQL Injection correspondente significa que a aplicação provavelmente está no modo Monitor; registrar sem bloquear é o comportamento esperado.
• Se não houver evento correspondente, confirme que o DNS resolve para o VPS pretendido, verifique a configuração do listener e do upstream do SafeLine e correlacione o horário da requisição com o log de acesso do SafeLine.
• Confirme também que a proteção está habilitada e que nenhuma whitelist de IP, regra de permissão personalizada ou exceção de caminho abrange a requisição de teste.

Ponto-chave: Se a sonda do curl retornar 403 com a página de interceptação do SafeLine e uma entrada aparecer em Attack Events com o tipo de ataque SQL Injection, o WAF está interceptando o tráfego corretamente.

O Que o Nível Gratuito Cobre e o Que Exige um Plano Pago

O nível Personal gratuito é suficiente para proteger a maioria das implantações em um único VPS. Os níveis pagos começam a importar quando você precisa de recursos operacionais (notificações, exportação de logs, bloqueio geográfico) ou ultrapassa o limite de 10 aplicações.

O detalhamento, obtido da página de preços da CyberServal:

• Personal, gratuito. Até 10 aplicações. Inclui o motor de detecção semântica (SQLi, XSS, injeção de comando, path traversal, SSRF, XXE, CRLF), limitação de taxa, desafio CAPTCHA de bots, criptografia dinâmica de HTML/JS contra scrapers automatizados, regras de ACL web e gerenciamento de certificados. As versões CE atuais também incluem a emissão Free Cert e o tratamento de renovação.
• Lite, $10/mês ou $100/ano. Adiciona bloqueio geográfico, o banco de dados de IP de inteligência de ameaças, integração de notificações com Discord e Telegram, exportação de logs de ataque e eleva o limite de aplicações para 20.
• Pro, $100/mês ou $1,000/ano. Adiciona detecção de ataques mais avançada, configurações por serviço e globais, páginas de interceptação personalizadas, balanceamento de carga de upstream, sincronização de nós master-slave e aplicações ilimitadas. Consulte a tabela de preços atual para eventuais mudanças.
• Ultimate, preço personalizado. Termos corporativos sob medida com suporte individual em vários canais e desenvolvimento de recursos personalizados.

O SafeLine processa e armazena os dados da aplicação dentro de sua stack Compose local. No entanto, as notas da versão CE atual mencionam o Threat Intelligence Sharing, então os operadores devem revisar os controles de UEP, privacidade e compartilhamento da versão instalada e observar as conexões de saída antes de tratar a implantação como de saída zero.

Para Onde Ir a Partir Daqui

A instalação está concluída e o WAF está verificado. Algumas tarefas de acompanhamento ajudarão a manter a implantação saudável.

• Para qualquer aplicação de produção com entrada rica do usuário (um fórum, um painel de administração, uma API de formato livre), defina o modo de proteção como Monitor por três a sete dias, revise a página Attack Events diariamente e promova para Balanced depois de ajustar quaisquer falsos positivos.
• No nível Lite, configure a integração de notificações do Discord ou do Telegram para que os alertas de ataque cheguem até você fora do painel.
• Agende uma janela de manutenção mensal. Antes de atualizar, faça backup dos dados e da configuração de ambiente do SafeLine, leia as notas da versão atuale use o procedimento de atualização suportado para a versão que você instalou. Não confie apenas em docker compose pull seguido por docker compose up -d, porque a definição do Compose ou as variáveis de ambiente necessárias podem mudar entre as versões. Usuários da implantação de um clique da Cloudzy devem trabalhar a partir de /opt/safeline e seguir as instruções da imagem do marketplace.
• Assine a página de releases do SafeLine para notificações de patches de segurança e o repositório do projeto para acompanhamento de issues.

Se você ainda não tem um VPS para esta implantação, o SafeLine está disponível como uma implantação de um clique no O marketplace da Cloudzy. Um plano com 4 GB RAM oferece a margem prática recomendada neste guia; verifique novamente a tabela de preços atual no Cloudzy no momento da publicação, pois as especificações dos planos podem mudar. A imagem de um clique usa /opt/safeline e /opt/safeline/docker-compose.yml, então as instruções de arquitetura e de painel se aplicam, mas os comandos /data/safeline deste guia não se aplicam de forma idêntica.

Perguntas frequentes

O SafeLine WAF Substitui o Nginx Proxy Manager ou Rodo os Dois?

O SafeLine pode substituir o Nginx Proxy Manager quando implantado como único proxy reverso. No entanto, ele não precisa substituir o NPM. Uma configuração comum mantém o NPM à frente para SSL e roteamento e coloca o SafeLine atrás dele como uma camada de segurança dedicada. Ambos funcionam; a escolha depende de você querer uma ferramenta fazendo os dois trabalhos ou duas ferramentas, cada uma fazendo bem um trabalho.

O Nível Gratuito é Suficiente para um Único Site WordPress ou um Pequeno SaaS?

Sim, para proteção. O nível Personal gratuito inclui o motor de detecção semântica, limitação de taxa, desafio CAPTCHA de bots e criptografia dinâmica de HTML/JS, que são defesas essenciais para um único site. Os níveis pagos adicionam recursos operacionais como bloqueio geográfico, exportação de logs de ataque, notificações externas, limites de aplicações maiores, detecção mais avançada e balanceamento de carga. A necessidade de um nível pago depende dos recursos exigidos e da quantidade de aplicações, não apenas do volume de tráfego.

O SafeLine Funciona em um VPS de 1 GB RAM?

O mínimo oficial do SafeLine é 1 GB RAM. Isso pode ser suficiente para testes ou uma carga muito leve, mas a capacidade em produção depende do tráfego, dos recursos habilitados e da retenção de logs. Para uma pequena implantação de produção, 2 vCPU e 4 GB RAM é um ponto de partida conservador; monitore o uso de memória e dimensione a partir da carga medida.

Por Que o ARM64 Exige uma Licença Paga?

O documentação oficial de implantação afirma que as implantações em ARM exigem uma licença Pro e que a Personal Edition não é suportada em ARM. Se você quer a Personal Edition, escolha um VPS x86_64; se você precisa de ARM, planeje uma licença Pro.

O Que a Chaitin Tech Recebe da Minha Instância do SafeLine?

Os dados de saída exatos podem variar conforme a versão e os recursos habilitados. As notas da versão CE atual mencionam o Threat Intelligence Sharing, enquanto a versão instalada também pode expor o UEP ou outros controles de compartilhamento. Revise essas configurações e as notas de versão da sua instalação e, em seguida, valide a saída no nível de rede. Os contêineres locais do SafeLine lidam com os dados da aplicação, mas esse fato por si só não prova que recusar o UEP interrompe toda requisição de saída.