guia de instalação

Instalando o EdgeWarden

Passo a passo completo para colocar a plataforma no ar em um servidor Debian 13 (server, instalação mínima), das dependências ao dashboard funcionando.

  • Debian 13 (Trixie)
  • x86_64
  • ~40 minutos
  • acesso root
Debian 13 · x86_64dashboard na porta 3099
Índice do guia

Antes de começar

leia uma vez Os nomes técnicos usam o prefixo flowspec. Para manter a compatibilidade com as instalações existentes, o diretório (/opt/flowspec-analyzer), os serviços (flowspec-core, flowspec-frontend e flowspec-analyzer.target), o banco ClickHouse (flowspec), o pacote (flowspec-analyzer-stable.tar.gz) e as chaves de API (fsk_) continuam com esse prefixo. Os comandos deste guia estão corretos para a versão atual.

Requisitos de hardware

Escolha o porte pelo volume de flows da sua rede. Os três rodam o mesmo pacote.

RecursoSmall: ISP regionalMedium (recomendado): ISP ou DC médioEnterprise: Tier-1 ou DC grande
VolumeAté 20 mil flows/s, redes até ~5 GbpsAté 50 mil flows/s, redes até ~20 Gbps100 mil+ flows/s, redes de 40 Gbps ou mais
CPU8 cores (Xeon / EPYC)16 cores (Xeon Scalable / EPYC)32+ cores (EPYC / Xeon Platinum)
RAM32 GB DDR464 GB DDR4 ECC128+ GB DDR4/DDR5 ECC
Disco500 GB NVMe SSD2 TB NVMe SSD4+ TB NVMe (RAID 10)
Rede1 Gbps10 Gbps25 / 40 / 100 Gbps
SistemaDebian 13 server (Trixie, instalação mínima), x86_64
  • eBPF/XDP: o Debian 13 já traz kernel 6.x. Use placa de rede com XDP nativo (Mellanox ou Intel).
  • ClickHouse: a partir do porte Medium, separe-o num servidor dedicado.
  • Retenção: dimensione o disco pelo período de retenção desejado; a compressão fica em torno de 10:1.
  • Alta disponibilidade: no porte Enterprise, recomenda-se cluster com 2 nós ou mais.

Portas utilizadas

PortaProtocoloServiço
2055UDPColetor NetFlow v5/v9/IPFIX
6343UDPColetor sFlow
11019TCPEstação BMP (opcional)
3099TCPDashboard web
8123 / 9000TCPClickHouse (apenas local)
6379TCPRedis (apenas local)
50051TCPgRPC do GoBGP (apenas local)
179TCPBGP (GoBGP ↔ roteador)
8090TCP/health do scrubber (só em instalação distribuída; libere apenas para o analyzer)
80 / 443TCPProxy para domínio com HTTPS (opcional, Passo 10)

tenha em mãos antes de começar A chave de licença é pedida logo no primeiro acesso ao dashboard, antes de qualquer configuração. Sem ela, você instala tudo e para na tela de ativação. Separe antes de abrir o terminal:

  • Chave de licença: enviada na contratação. Ela também fica na Área do cliente. Ainda não contratou? Veja os planos.
  • Como o dashboard será acessado: por IP ou por domínio com HTTPS. Essa escolha entra na configuração já no Passo 7.3, e mudá-la depois exige reconfigurar. Se for domínio, o DNS já deve apontar para o servidor.
  • Duas senhas fortes: uma para o ClickHouse e outra para o MariaDB. Anote as duas, porque cada uma é usada em mais de um passo.
Todos os comandos deste guia supõem execução como root. Se estiver usando um usuário comum, coloque sudo na frente. Troque SUA_SENHA_CH e SUA_SENHA_MYSQL pelas senhas que você separou.
  1. Preparar o sistema

    Atualize o Debian e instale as ferramentas base. O EdgeWarden é entregue como binário pronto, então nenhuma ferramenta de compilação é necessária:

    bash
    apt update && apt upgrade -y
    apt install -y curl sudo wget gnupg ca-certificates unzip \
      net-tools libpcap0.8 tcpdump htop \
      snmp                        # net-snmp: exigido para SNMPv3

    libpcap0.8 é a única biblioteca de sistema que o coletor usa em tempo de execução. Nada de compiladores, PHP ou pacotes extras: quanto menor a instalação, menor a superfície de ataque.

    O pacote snmp (net-snmp) só é usado se você cadastrar dispositivos com SNMPv3. O coletor traz SNMP v1/v2c embutido, mas para v3 chama o snmpbulkwalk do sistema. Instalar agora custa poucos KB e evita uma armadilha: sem esse binário, a coleta v3 falha em silêncio, nenhum contador aparece e o log não aponta a causa.

    Tuning do kernel (sysctl) para o coletor

    O coletor recebe rajadas intensas de UDP (NetFlow/sFlow), e os valores padrão do Debian são conservadores. O core pede 16 MB de buffer por socket, mas o net.core.rmem_max de fábrica é de apenas 208 KB. O pedido é truncado, o kernel descarta pacotes de flow em silêncio e o tráfego some dos gráficos sem nenhum erro visível. Aplique uma única vez:

    bash · /etc/sysctl.d/99-flowspec-tuning.conf
    cat > /etc/sysctl.d/99-flowspec-tuning.conf <<'EOF'
    # Buffers de rede — coletor NetFlow/sFlow (rajadas UDP)
    # São TETOS, não alocação: o kernel só reserva o que o socket pedir. O core
    # pede 16 MB por socket; o teto fica folgado de propósito.
    net.core.rmem_default = 31457280
    net.core.rmem_max = 134217728
    net.core.wmem_default = 31457280
    net.core.wmem_max = 134217728
    net.core.netdev_max_backlog = 250000
    net.core.optmem_max = 33554432
    net.core.somaxconn = 65535
    net.core.default_qdisc = fq
    
    # TCP — ClickHouse local + dashboard
    net.ipv4.tcp_rmem = 4096 87380 134217728
    net.ipv4.tcp_wmem = 4096 65536 134217728
    net.ipv4.tcp_max_syn_backlog = 65536
    net.ipv4.tcp_mtu_probing = 1
    net.ipv4.tcp_no_metrics_save = 1
    net.ipv4.ip_local_port_range = 1024 65535
    
    # Limites de arquivos/threads — core + ClickHouse
    # Teto do SISTEMA. NÃO é o limite do processo — veja a nota abaixo.
    fs.file-max = 3263776
    fs.aio-max-nr = 3263776
    fs.pipe-max-size = 8388608
    kernel.threads-max = 1031306
    kernel.pid_max = 262144
    
    # Memória — ClickHouse usa page cache pesado; swap mata a latência
    vm.swappiness = 1
    vm.vfs_cache_pressure = 50
    # 256 MB é o teto que o próprio kernel usa ao calcular este valor pela RAM.
    # O antigo 32768 ficava ABAIXO do default em máquina com 64 GB ou mais.
    vm.min_free_kbytes = 262144
    
    # Reboot automático 3s após kernel panic (appliance sem operador)
    kernel.panic = 3
    EOF
    
    # Aplicar e conferir
    sysctl --system 2>&1 | grep -iE "error|cannot|no such" || echo "OK sem erros"
    sysctl net.core.rmem_max net.core.netdev_max_backlog vm.min_free_kbytes

    Criar o arquivo agora está certo. Só não volte nele depois para mudar valores.

    O mesmo arquivo acompanha o pacote (scripts/sysctl/99-flowspec-tuning.conf) e, a partir da primeira atualização, o update.sh passa a reescrevê-lo a cada update. Um valor editado direto em /etc/sysctl.d/99-flowspec-tuning.conf volta ao original na atualização seguinte, sem erro e sem aviso. É o tipo de coisa que se descobre tarde.

    Para mudar um valor de forma permanente, coloque só o que você quer diferente num arquivo à parte, com o prefixo zz-:

    bash
    echo 'vm.swappiness = 10' > /etc/sysctl.d/99-zz-meus-ajustes.conf
    sysctl --system

    Funciona porque o sysctl.d lê os arquivos em ordem alfabética e quem define a chave por último vence: 99-zz-meus-ajustes vem depois de 99-flowspec-tuning. Esse arquivo é seu, e nenhuma atualização mexe nele.

    nada a fazer agora Só para entender: fs.file-max não é o limite do processo. Ele é o teto do sistema inteiro. Cada serviço continua preso ao LimitNOFILE do systemd, que por padrão é de apenas 1024 descritores. As units do EdgeWarden já trazem LimitNOFILE=65535, então não há nada a ajustar. A conferência disso e do buffer de socket está no Passo 8, quando os serviços já existirem.

    só se você tem firewall próprio Firewall stateful nesta máquina? Numa instalação Debian limpa, sem regras de firewall suas, pule esta nota. O EdgeWarden não usa conntrack: a chain nftables dele entra em hook input priority -150, antes do rastreamento, e o XDP age antes de todo o netfilter.

    Se você mantém um firewall stateful próprio, acrescente na regra dele a isenção das portas de flow: udp dport { 2055, 6343 } notrack. Não é um comando de terminal, e sim um trecho de regra nftables. Numa máquina que faz scrubbing, isente também o tráfego de trânsito: o conntrack cria estado por fluxo, e um flood com origem forjada enche a tabela em segundos. É o jeito clássico de derrubar o próprio scrubber. Só aumente net.nf_conntrack_max se realmente precisar de estado e, nesse caso, mantenha nf_conntrack_buckets em cerca de ¼ do valor; senão, a cadeia de hash vira o gargalo.

    quase sempre não se aplica Esta máquina vai encaminhar os pacotes do ataque? Só se for filtro eBPF/XDP em linha ou scrubber de clean pipe. Na instalação padrão, o servidor apenas recebe amostras de NetFlow/sFlow e anuncia FlowSpec por BGP; quem descarta o ataque é o roteador. Se esse é o seu caso, siga normalmente.

    Se ela for encaminhar, o tuning do plano de dados está no Passo 11, no fim do guia. Ele depende do pacote já instalado, então não dá para adiantar aqui.

    Fuso horário e NTP

    Timestamps corretos são essenciais para os gráficos de flows e para a validação da licença:

    bash
    timedatectl set-timezone America/Sao_Paulo   # ajuste para sua região
    apt install -y systemd-timesyncd
    printf '[Time]\nNTP=200.160.0.8\nFallbackNTP=a.ntp.br\n' > /etc/systemd/timesyncd.conf
    timedatectl set-ntp true
    timedatectl status   # "System clock synchronized: yes"
  2. Instalar o Node.js 22

    O dashboard web roda sobre Node.js, instalado pelo repositório oficial da NodeSource:

    bash
    curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
    apt install -y nodejs
    
    node --version   # deve mostrar v22.x
  3. Instalar o ClickHouse

    O ClickHouse é o banco de séries temporais que armazena os flows. Instale pelo repositório oficial:

    bash
    install -m 0755 -d /etc/apt/keyrings
    
    curl -fsSL 'https://packages.clickhouse.com/rpm/lts/repodata/repomd.xml.key' | \
        gpg --dearmor -o /etc/apt/keyrings/clickhouse.gpg
    
    echo "deb [signed-by=/etc/apt/keyrings/clickhouse.gpg] https://packages.clickhouse.com/deb stable main" | \
        tee /etc/apt/sources.list.d/clickhouse.list
    
    apt update
    apt install -y clickhouse-server clickhouse-client
    Durante a instalação, o ClickHouse pede a senha do usuário default. Defina uma senha forte e anote: este guia se refere a ela como SUA_SENHA_CH.

    Ative o serviço e confira se ele responde:

    bash
    systemctl enable --now clickhouse-server
    
    curl http://localhost:8123/ping
    Ok.
  4. Instalar MariaDB e Redis

    O MariaDB guarda os usuários e as configurações do dashboard; o Redis distribui os alertas em tempo real.

    bash
    apt install -y mariadb-server mariadb-client redis-server
    
    systemctl enable --now mariadb redis-server
    
    redis-cli ping
    PONG

    Defina a senha do root do MariaDB (troque SUA_SENHA_MYSQL):

    bash
    mariadb -u root -e "ALTER USER 'root'@'localhost' IDENTIFIED BY 'SUA_SENHA_MYSQL'; FLUSH PRIVILEGES;"
  5. Instalar o GoBGP mitigação

    O GoBGP é o daemon BGP que anuncia as regras de mitigação (FlowSpec/RTBH) ao seu roteador:

    bash
    apt install -y gobgpd

    só instalar por enquanto Instalar basta para seguir o guia. Os peers são configurados depois, com o sistema no ar, e o arquivo não é editado à mão: o gerador lê os roteadores que você cadastrar em Configurações → Dispositivos e monta a configuração.

    Quando chegar a hora, rode nesta ordem. No gobgp neighbor, a sessão precisa aparecer como Establ:

    bash · depois de cadastrar os roteadores
    python3 /opt/flowspec-analyzer/scripts/gobgp/gen_config.py > /etc/gobgpd.conf
    systemctl enable --now gobgpd && systemctl restart gobgpd
    gobgp neighbor

    Repare no >: o gerador escreve na saída padrão. Sem o redirecionamento, ele só imprime na tela e o /etc/gobgpd.conf continua vazio. O GoBGP sobe sem nenhum peer e a mitigação nunca anuncia nada.

    Ainda não vai usar mitigação automática? Pode deixar para depois: coleta, dashboard e detecção funcionam sem BGP.

  6. Baixar e extrair o pacote

    Baixe a versão estável e extraia em /opt:

    bash
    cd /opt
    curl -fLO https://www.edgewarden.com.br/download/flowspec-analyzer-stable.tar.gz
    
    tar -xzf flowspec-analyzer-stable.tar.gz -C /opt/
    cd /opt/flowspec-analyzer
    mkdir -p logs

    Crie o diretório da licença:

    bash
    mkdir -p /etc/flowspec-analyzer
    chown -R www-data:www-data /etc/flowspec-analyzer
    Se o download ou a extração falharem (arquivo incompleto ou corrompido), baixe de novo ou fale com o suporte antes de seguir.
  7. Configurar e criar os bancos

    7.1Senha do ClickHouse

    Edite o config.toml e informe a senha do ClickHouse definida no Passo 3:

    bash
    nano /opt/flowspec-analyzer/config.toml
    # na seção [storage.clickhouse]:
    #   password = "SUA_SENHA_CH"

    7.2Bancos, schema e dados iniciais

    Crie o banco e aplique o schema e os dados iniciais (templates de detecção e decoders):

    bash
    cd /opt/flowspec-analyzer
    
    clickhouse-client --password 'SUA_SENHA_CH' -q "CREATE DATABASE IF NOT EXISTS flowspec"
    
    clickhouse-client --password 'SUA_SENHA_CH' --database flowspec --multiquery < database/clickhouse/schema.sql
    clickhouse-client --password 'SUA_SENHA_CH' --database flowspec --multiquery < database/clickhouse/seed.sql
    
    # banco de autenticação (cria o usuário admin padrão)
    mysql -u root -p'SUA_SENHA_MYSQL' < database/mysql/auth_schema.sql

    7.3Ambiente do dashboard e AUTH_URL

    Antes de rodar o comando, decida por qual endereço o dashboard será acessado. É a escolha que mais quebra instalações, e ela é feita aqui:

    escolha agora O AUTH_URL tem de ser exatamente a URL que você vai digitar no navegador: protocolo, host e porta. O dashboard roda em modo standalone, no qual o Next monta a origem a partir dessa variável e ignora o cabeçalho Host. Não há como ele adivinhar.

    Se o valor não bater com a URL usada, o login falha para qualquer credencial, com o formulário parecendo travado e nenhum erro útil na tela. Rodar o setup-env.sh sem informar AUTH_URL grava um valor provisório, e aí o login não funciona de jeito nenhum.

    Opção A

    Domínio com HTTPS (recomendado em produção)

    Use o domínio já aqui, mesmo que o Apache ainda não esteja configurado:

    bash
    AUTH_URL=https://flowspec.example.net \
      MYSQL_USER=root MYSQL_PASSWORD='SUA_SENHA_MYSQL' ./scripts/setup-env.sh
    ✅ Gerado: frontend/.env.production ... AUTH_URL: https://flowspec.example.net ✓
    Escolheu A? O login só vai funcionar pelo domínio. Termine o Passo 8, pule para o Passo 10 (Apache e certificado) e só então volte ao Passo 9 para o primeiro login. O DNS do domínio já precisa apontar para este servidor.
    Opção B

    Acesso por IP (rede interna, ou DNS ainda não propagado)

    bash
    IP=$(ip -4 -br addr show | awk '$1!="lo"{print $3}' | cut -d/ -f1 | head -1)
    echo "Detectado: $IP"   # confira antes de seguir
    
    AUTH_URL=http://$IP:3099 \
      MYSQL_USER=root MYSQL_PASSWORD='SUA_SENHA_MYSQL' ./scripts/setup-env.sh
    Escolheu B? Siga a ordem normal do guia. Se um dia acrescentar domínio e HTTPS, o Passo 10 mostra como trocar o AUTH_URL. Sem essa troca, o login para de funcionar quando o endereço muda.

    Já rodou sem AUTH_URL? Não precisa refazer nada. Corrija a linha e reinicie o dashboard:

    bash
    grep AUTH_URL /opt/flowspec-analyzer/frontend/.env.production
    sed -i 's|^AUTH_URL=.*|AUTH_URL=https://flowspec.example.net|' /opt/flowspec-analyzer/frontend/.env.production
    systemctl restart flowspec-frontend

    7.4Dados públicos de ASN recomendado

    Importe os dados públicos de ASN. Eles habilitam as telas de Peering, CDN e Análise de AS:

    bash
    CH_PASS='SUA_SENHA_CH' ./scripts/import-asn-names.sh http://127.0.0.1:8123
    CH_PASS='SUA_SENHA_CH' ./scripts/import-ip2asn.sh http://127.0.0.1:8123
    CH_PASS='SUA_SENHA_CH' ./scripts/seed-cdn-providers.sh http://127.0.0.1:8123
  8. Ativar os serviços (systemd)

    O sistema roda como dois serviços supervisionados: se algum processo cair, o systemd o reinicia sozinho.

    bash
    cd /opt/flowspec-analyzer
    
    # dono correto ANTES de iniciar (os serviços rodam como www-data)
    chown -R www-data:www-data /opt/flowspec-analyzer
    
    cp scripts/systemd/flowspec-core.service \
       scripts/systemd/flowspec-frontend.service \
       scripts/systemd/flowspec-analyzer.target /etc/systemd/system/
    
    # Reinstala o tuning do Passo 1 a partir do pacote, para o arquivo ficar
    # idêntico ao que o update.sh vai manter daqui em diante (evita divergir).
    cp scripts/sysctl/99-flowspec-tuning.conf /etc/sysctl.d/ && sysctl --system
    
    systemctl daemon-reload
    systemctl enable --now flowspec-core flowspec-frontend flowspec-analyzer.target
    
    systemctl status flowspec-core flowspec-frontend
    ● flowspec-core.service — Active: active (running)
    ● flowspec-frontend.service — Active: active (running)

    8.1Conferir o tuning no processo

    Com os serviços de pé, confirme que o tuning do Passo 1 chegou de fato ao processo. São três leituras, e nenhuma delas altera nada:

    bash
    # 1. Descritores do core — tem que dar 65535, não 1024
    cat /proc/$(pgrep -f flowspec-analyzer-core)/limits | grep "open files"
    
    # 2. Buffer do socket do coletor. O core pede 16 MB e o kernel DOBRA o
    #    valor, então 32 MB é o número certo: rb33554432.
    #    Se aparecer rb425984, o sysctl do Passo 1 não foi aplicado.
    ss -ulnpme | grep -A1 -E "2055|6343"
    grep "Socket buffer" /opt/flowspec-analyzer/logs/core.log.*
    Socket buffer: solicitado 16MB, obtido 32MB
    
    # 3. Descarte de UDP — estes contadores NÃO podem crescer com o tempo
    nstat -az | grep -iE "Udp.*(InErrors|RcvbufErrors)"
    Atualizando uma instalação antiga? Se o item 1 ainda mostrar 1024, a unit em uso é da versão anterior. Copie-a de novo de scripts/systemd/ (comando acima) e rode systemctl daemon-reload seguido de systemctl restart flowspec-analyzer.target. Sem o daemon-reload, o limite novo não vale, mesmo com o arquivo já no lugar.

    Comandos do dia a dia

    • Reiniciar tudosystemctl restart flowspec-analyzer.target
    • Reiniciar só o dashboardsystemctl restart flowspec-frontend
    • Acompanhar os logsjournalctl -u flowspec-core -f
  9. Firewall e primeiro acesso

    9.1Liberar as portas

    Libere apenas o necessário (exemplo com ufw):

    bash
    apt install -y ufw
    ufw allow ssh
    ufw allow 3099/tcp    # dashboard
    ufw allow 2055/udp    # NetFlow
    ufw allow 6343/udp    # sFlow
    ufw enable
    ufw status

    9.2Primeiro login

    Acesse o dashboard e faça o primeiro login. Use exatamente a URL gravada no AUTH_URL no Passo 7.3: pelo IP, se escolheu a opção B; pelo domínio, se escolheu a A (e, nesse caso, o Passo 10 precisa estar pronto antes).

    URL
    a mesma do seu AUTH_URL
    Usuário
    flowspec@managerpro.networkou admin@edgewarden.com.br
    Senha
    admin123(as duas contas)
    No primeiro acesso, troque o e-mail e a senha das duas contas de administrador padrão (ou exclua a que não usar) em Configurações → Usuários (depois de trocar o e-mail, saia e entre de novo). Em seguida, crie os usuários da sua equipe com os perfis adequados: admin, operator ou viewer.

    9.3Ativar a licença

    Na primeira tela, o dashboard pede a chave de licença recebida na contratação. Informe a chave e reinicie o core para concluir a ativação:

    bash
    systemctl restart flowspec-core
    A chave de licença, o status da assinatura e as faturas ficam na Área do cliente: license.managerpro.dev.br. O acesso é criado na contratação e enviado para o seu e-mail.

    9.4Apontar os roteadores para o coletor

    Configure nos roteadores a exportação de NetFlow v9/IPFIX (porta 2055/UDP) ou sFlow (porta 6343/UDP) para o IP do servidor e cadastre cada equipamento em Configurações → Dispositivos. Em 1 a 2 minutos, os flows começam a aparecer no dashboard.

    Instalação concluída. O dashboard já mostra o tráfego em tempo real. Agora explore as Zonas de IP e os Templates de Threshold para calibrar a detecção de DDoS à sua rede.
  10. Acesso por domínio e HTTPS opcional

    O dashboard já funciona em http://IP:3099. Se você quer um endereço amigável com certificado (por exemplo, flowspec.example.net), coloque o Apache na frente como proxy reverso.

    10.1Apache e certbot

    Instale o Apache e o certbot e ative os módulos:

    bash
    apt install -y apache2 certbot python3-certbot-apache
    a2enmod proxy proxy_http proxy_wstunnel ssl headers rewrite
    systemctl restart apache2

    10.2VirtualHost

    Crie o VirtualHost, trocando o domínio pelo seu. O DNS já deve apontar para o servidor:

    /etc/apache2/sites-available/flowspec.conf
    <VirtualHost *:80>
        ServerName flowspec.example.net
    
        ProxyPreserveHost On
        ProxyRequests Off
    
        # WebSocket (atualizações em tempo real do dashboard)
        RewriteEngine On
        RewriteCond %{HTTP:Upgrade} =websocket [NC]
        RewriteRule /(.*) ws://127.0.0.1:3099/$1 [P,L]
    
        ProxyPass        / http://127.0.0.1:3099/
        ProxyPassReverse / http://127.0.0.1:3099/
    
        # IMPORTANTE: nunca defina X-Forwarded-Host manualmente — o Apache já
        # envia esse header sozinho, e duplicá-lo quebra o login (Invalid URL).
        RequestHeader unset X-Forwarded-Host
        # Esquema dinâmico (http/https) — continua correto quando o certbot
        # clonar este vhost para a porta 443:
        RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}
    
        ErrorLog  ${APACHE_LOG_DIR}/flowspec-error.log
        CustomLog ${APACHE_LOG_DIR}/flowspec-access.log combined
    </VirtualHost>

    10.3Site no ar e certificado

    Ative o site e emita o certificado. O certbot cria o vhost HTTPS e o redirecionamento automaticamente:

    bash
    # 1. Abrir 80 e 443 ANTES do certbot: ele valida o domínio por HTTP na
    #    porta 80, e o ufw do Passo 9 não a liberou. Fora de ordem, falha.
    ufw allow 80/tcp
    ufw allow 443/tcp
    
    # 2. Ativar o site
    a2ensite flowspec
    apachectl configtest && systemctl reload apache2
    
    # 3. Emitir o certificado (cria o vhost HTTPS e o redirect automaticamente)
    certbot --apache -d flowspec.example.net
    
    # 4. AUTH_URL passa a ser o domínio. Sem isto o login para de funcionar
    #    no instante em que você troca o IP pelo domínio no navegador.
    sed -i 's|^AUTH_URL=.*|AUTH_URL=https://flowspec.example.net|' \
      /opt/flowspec-analyzer/frontend/.env.production
    systemctl restart flowspec-frontend
    
    # 5. Só DEPOIS de o login pelo domínio funcionar (opcional):
    #    ufw deny 3099/tcp    # força o acesso só pelo domínio/HTTPS

    Não feche a porta 3099 antes da hora. Enquanto o login pelo domínio não estiver comprovado, ela é sua rota de escape se algo no Apache ou no certificado falhar. Deixe o ufw deny 3099/tcp por último, e só rode se realmente quiser bloquear o acesso direto.

    Se você veio da opção A do Passo 7.3, o AUTH_URL já é o domínio: o item 4 não muda nada e é seguro rodá-lo mesmo assim.

    Valide. A resposta deve ser 307, redirecionando para o login no seu domínio:

    bash
    curl -sk -o /dev/null -w "%{http_code} -> %{redirect_url}\n" https://flowspec.example.net/
    307 -> https://flowspec.example.net/login
  11. Plano de dados: Packet Filter (XDP) e clean pipe opcional

    O tuning do Passo 1 ajusta o coletor, que só recebe amostras de flow. Se esta máquina também encaminha os pacotes (filtragem eBPF/XDP em linha ou desvio para scrubbing em clean pipe), ela precisa de um segundo conjunto de chaves, voltado ao plano de dados: encaminhamento, softirq, qdisc e JIT do eBPF. É isso que decide quantos Gbps e Mpps a appliance aguenta no seu hardware; o buffer de socket do coletor não tem papel nenhum aqui.

    Este passo fica no fim do guia de propósito: parte dele usa arquivos que só existem depois da instalação (scripts/sysctl/ e deploy/scrubber/), e o caminho de scrubbing só faz sentido com o sistema já de pé.

    pare e decida Este passo inteiro é opcional, e a maioria das instalações não faz nada dele.

    Ele só vale se esta máquina encaminha os pacotes do ataque: se ela é filtro eBPF/XDP em linha ou o scrubber de um clean pipe (o tráfego da vítima entra e sai por ela).

    Na instalação padrão do EdgeWarden, o servidor apenas recebe amostras de NetFlow/sFlow e anuncia FlowSpec por BGP; quem descarta o ataque é o roteador. Se esse é o seu caso, a instalação terminou no Passo 9 e você pode fechar o guia.

    Tuning do plano de dados

    seguro em qualquer máquina Aqui só entra desempenho. O ip_forward, o rp_filter e os ICMP redirects não estão neste arquivo, de propósito: quem cuida deles é o scrubber-path.sh, que valida a topologia antes de ligar e sabe desfazer. Este bloco é seguro em qualquer máquina e só faz diferença onde há pacote atravessando.
    bash
    # O arquivo já vem pronto no pacote. Copiar em vez de digitar garante que
    # ele nunca divirja do que o produto testa — e vale abrir antes: cada
    # chave tem o porquê comentado ao lado dela.
    cat /opt/flowspec-analyzer/scripts/sysctl/99-zz-flowspec-dataplane.conf.example
    
    # O sufixo "zz" dá precedência sobre o 99-flowspec-tuning do Passo 1:
    # o sysctl.d aplica em ordem alfabética e o último a definir a chave vence.
    cp /opt/flowspec-analyzer/scripts/sysctl/99-zz-flowspec-dataplane.conf.example \
       /etc/sysctl.d/99-zz-flowspec-dataplane.conf
    
    sysctl --system 2>&1 | grep -iE "error|cannot|no such" || echo "OK sem erros"
    sysctl net.core.netdev_budget net.core.default_qdisc net.core.bpf_jit_harden

    Encaminhamento (clean pipe)

    Esta parte não se faz à mão. Ligar o ip_forward num arquivo de sysctl transforma a appliance em roteador sem validar nada. O scrubber-path.sh confere a topologia antes (o roteador precisa estar no mesmo segmento L2), aplica as chaves com os cuidados que um hairpin exige e sabe desfazer:

    bash
    cd /opt/flowspec-analyzer/deploy/scrubber
    cp scrubber-path.conf.example scrubber-path.conf
    $EDITOR scrubber-path.conf              # DIRTY_IF, ROUTER_IP, PROTECT_PREFIXES
    
    ./scrubber-path.sh check                # valida, não toca em nada
    ./scrubber-path.sh up                   # liga — em runtime apenas
    ./scrubber-path.sh verify 203.0.113.10  # simula a decisão para uma vítima
    
    # Só DEPOIS do verify passar, torne permanente:
    ./scrubber-path.sh up --persist
    ./scrubber-path.sh status               # deve dizer "Persistência ativa"

    Não pule o --persist. Sem ele, o caminho vive só na memória, e o modo de falha é o pior possível: a máquina reinicia, o core sobe, o XDP carrega, o roteador continua desviando a vítima para cá, e a appliance descarta cada pacote porque não está mais encaminhando. Todos os serviços aparecem como active (running) e o painel não acusa nada. O cliente fica fora do ar durante o ataque.

    O --persist também não é o padrão de propósito: um caminho ainda não comprovado subindo sozinho no boot é pior do que um caminho que some. Por isso a ordem é comprovar primeiro, persistir depois, e o status avisa enquanto a persistência faltar.

    Ajustes na placa de rede

    Nenhum sysctl compensa uma placa mal configurada. Acima de 100 Gbps, é aqui que a coisa se decide: os comandos abaixo rendem mais pps do que todo o bloco anterior.

    janela de manutenção Não copie este bloco inteiro numa máquina em produção. Os itens 1 e 2 (ethtool -G e ethtool -L) reinicializam a placa: o link cai e volta, e quem estiver passando tráfego de cliente sente de um a dois segundos de queda. O item 4 desliga um serviço do sistema. Rode numa janela combinada, um item por vez, conferindo entre eles.

    E troque o IF=eth0 pela sua interface real antes de qualquer coisa (ip -br link lista as disponíveis). Apontar para a interface errada mexe na placa errada.

    bash
    IF=eth0   # interface do plano de dados (a que recebe o tráfego sujo)
    
    # 1. Ring buffers no MÁXIMO que a placa suporta (lido da própria placa)
    RXMAX=$(ethtool -g $IF | awk '/^RX:/{print $2; exit}')
    TXMAX=$(ethtool -g $IF | awk '/^TX:/{print $2; exit}')
    ethtool -G $IF rx $RXMAX tx $TXMAX
    
    # 2. Filas RSS — uma por núcleo do MESMO nó NUMA da placa (veja a nota)
    NODE=$(cat /sys/class/net/$IF/device/numa_node)
    NCPU=$(lscpu -p=CPU,NODE | grep -c ",$NODE$")
    ethtool -L $IF combined $NCPU
    
    # 3. Coalescência adaptativa: menos IRQ por pacote sob rajada
    ethtool -C $IF adaptive-rx on adaptive-tx on
    
    # 4. IRQ fixa por fila — o irqbalance reembaralha justamente sob carga
    systemctl disable --now irqbalance
    
    # 5. Em que modo o XDP subiu?
    ip -d link show $IF | grep -i xdp
    #    "xdp"        = nativo, no driver — obrigatório nesta escala
    #    "xdpgeneric" = fallback SKB, roda DEPOIS do GRO. Nesse modo o filtro
    #                   vê pacotes já coalescidos e sub-conta pps, então:
    ethtool -K $IF gro off lro off
    
    # 6. Conferir se está sobrando pacote na placa (tudo deve ficar em zero)
    ethtool -S $IF | grep -iE "drop|discard|miss|nobuf|error" | grep -v ": 0$"

    NUMA importa mais que a contagem de núcleos. Numa máquina de dois sockets, uma fila RSS atendida por um núcleo do nó errado paga a travessia da interconexão em cada pacote. Se cat /sys/class/net/$IF/device/numa_node retornar 0, use só os núcleos do nó 0: 16 filas no nó certo rendem mais que 64 espalhadas.

    Confirme também a largura do slot: 200 Gbps exige PCIe 4.0 x16 (lspci -vv -s $(basename $(readlink /sys/class/net/$IF/device)) | grep -i "LnkSta:"). Num slot x8, a placa nunca entrega a taxa nominal, e nenhum tuning corrige isso.

    Os ajustes de ethtool não persistem após o reboot. Fixe-os num post-up em /etc/network/interfaces ou numa unit oneshot do systemd com After=network-online.target, com o mesmo cuidado que vale para o sysctl.d.
depois da instalação

Atualizar para novas versões

A atualização é um comando. O updater valida a integridade do pacote, preserva suas configurações, troca a versão e testa a saúde do sistema. O tempo fora do ar costuma ficar abaixo de 1 minuto, e os dados históricos não são tocados:

bash
cd /opt
curl -fLO https://www.edgewarden.com.br/download/flowspec-analyzer-stable.tar.gz

/opt/flowspec-analyzer/scripts/update.sh /opt/flowspec-analyzer-stable.tar.gz

Usa scrubbing ou clean pipe? Só nesta atualização, salve a topologia antes. O deploy/scrubber/scrubber-path.conf descreve a topologia da sua rede, por isso não vem no pacote, e o updater troca o diretório inteiro. A versão nova do update.sh já preserva esse arquivo, mas quem executa a troca é o updater que já está no servidor, ainda o antigo. Da próxima atualização em diante, é automático.

  • Antes: cp /opt/flowspec-analyzer/deploy/scrubber/scrubber-path.conf /root/
  • Depois: cp /root/scrubber-path.conf /opt/flowspec-analyzer/deploy/scrubber/

Se esquecer, o arquivo continua em /opt/flowspec-analyzer.previous/deploy/scrubber/. Depois de restaurar, rode ./scrubber-path.sh status para conferir se o caminho voltou inteiro.

Se algo não sair como esperado, voltar para a versão anterior também é um comando:

bash
/opt/flowspec-analyzer/scripts/update.sh --rollback
diagnóstico

Problemas comuns

SintomaSolução
O dashboard não abre ou o serviço não sobe journalctl -u flowspec-frontend -n 50. A causa mais comum são as permissões: rode chown -R www-data:www-data /opt/flowspec-analyzer e systemctl restart flowspec-analyzer.target.
O login dá error=Configuration O dashboard não conectou ao MariaDB. Confira usuário e senha e rode de novo: MYSQL_USER=root MYSQL_PASSWORD='...' ./scripts/setup-env.sh --force
Nenhum flow aparece Verifique se os pacotes chegam: tcpdump -i any -n udp port 2055. Se não chegam, o problema está na exportação do roteador ou no firewall; se chegam, confira journalctl -u flowspec-core -f.
O ClickHouse não responde systemctl status clickhouse-server e curl http://localhost:8123/ping. A causa mais comum é senha errada no config.toml.
O acesso pelo domínio redireciona errado Atrás de proxy reverso, preserve o Host: no Apache, use ProxyPreserveHost On e não defina X-Forwarded-Host manualmente; no nginx, use proxy_set_header Host $host;.
Dispositivo SNMPv3 sem nenhum contador Falta o net-snmp: o coletor traz v1/v2c embutido, mas chama o snmpbulkwalk do sistema para v3. Confira com command -v snmpbulkwalk e instale com apt install -y snmp. Em v2c, o pacote é dispensável.
O scrubbing funcionava, a máquina reiniciou e ele parou O caminho foi ligado sem persistência. ./scrubber-path.sh status lista as chaves que voltaram ao padrão e a tabela nftables ausente; ./scrubber-path.sh up --persist resolve e faz o caminho sobreviver aos próximos reboots.
Um ajuste de sysctl some depois da atualização Editou /etc/sysctl.d/99-flowspec-tuning.conf à mão? O updater o reinstala a cada atualização. Coloque seus valores num arquivo à parte com o prefixo zz-, que é aplicado depois e vence.
suporte

Travou em algum passo?

Fale com o suporte pelo WhatsApp ou por e-mail. Durante a janela de instalação, acompanhamos você até o dashboard estar no ar.

Atendimento de segunda a sexta, das 8h às 18h (horário de Brasília).

Ainda não tem sua licença?

Conheça os planos ou agende uma demonstração com os dados da sua própria rede.