Guia de Instalação

Instalando o FlowSpec Analyzer

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
Requisitos de hardware
RecursoSmall (até ~5 Gbps)Medium (até ~20 Gbps)
CPU8 cores (Xeon / EPYC)16 cores
RAM32 GB DDR464 GB ECC
Disco500 GB NVMe SSD2 TB NVMe
OSDebian 13 server (instalação mínima), x86_64

Redes maiores (40 Gbps+): veja o dimensionamento completo.

Portas utilizadas
PortaProtoServiço
2055UDPColetor NetFlow v5/v9/IPFIX
6343UDPColetor sFlow
3099TCPDashboard Web
8123 / 9000TCPClickHouse (apenas local)
6379TCPRedis (apenas local)
179TCPBGP (GoBGP ↔ roteador)
80 / 443TCPProxy p/ domínio + 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. Também fica no Portal 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 trocá-la depois exige reconfigurar; se for domínio, o DNS já deve apontar para o servidor.
  • Duas senhas fortes — uma do ClickHouse, uma do MariaDB. Anote: cada uma é usada em mais de um passo.
Todos os comandos deste guia assumem execução como root. Se estiver usando um usuário comum, prefixe com sudo. Substitua SUA_SENHA_CH e SUA_SENHA_MYSQL pelas senhas que você separou acima.
1

Preparar o sistema

Atualize o Debian e instale as ferramentas base. O FlowSpec Analyzer é entregue como binário pronto — não é preciso nenhuma ferramenta de compilação:

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 runtime. 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 ele chama o snmpbulkwalk do sistema. Instalar agora custa poucos KB e evita uma armadilha — sem o binário, o poll v3 falha em silêncio: nenhum contador aparece e o log não acusa a causa.

Tuning do kernel (sysctl) — coletor — o coletor recebe rajadas intensas de UDP (NetFlow/sFlow) e os defaults 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
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.

Esse 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 por cima a cada update. Um valor que você edite direto em /etc/sysctl.d/99-flowspec-tuning.conf volta ao original no próximo update, sem erro e sem aviso — é o tipo de coisa que se descobre tarde.

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

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 — nenhuma atualização encosta nele.
nada a fazer agora Só entendimento: 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 que acompanham o FlowSpec Analyzer já trazem LimitNOFILE=65535, então não há o que 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 FlowSpec Analyzer não usa conntrack (a chain nftables dele entra em hook input priority -150, antes do rastreamento, e o XDP age antes do netfilter inteiro).

Se você mantém um firewall stateful próprio, acrescente na regra dele (não é um comando solto de terminal — é um trecho de regra nftables) a isenção das portas de flow: udp dport { 2055, 6343 } notrack. Numa máquina que faz scrubbing, isente também o tráfego de trânsito — 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 então mantenha nf_conntrack_buckets em cerca de ¼ do valor, senão a corrente 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 for o seu caso, siga normalmente.

Se ela for encaminhar, o tuning de 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 Node.js 22

O dashboard web roda sobre Node.js (via repositório oficial NodeSource):

bash
curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
apt install -y nodejs

node --version   # deve mostrar v22.x
3

Instalar 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 será solicitada a senha do usuário default. Defina uma senha forte e anote — este guia se refere a ela como SUA_SENHA_CH.
bash
systemctl enable --now clickhouse-server

curl http://localhost:8123/ping
Ok.
4

Instalar MariaDB e Redis

O MariaDB guarda usuários e configurações do dashboard; o Redis distribui 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 GoBGP mitigação

O GoBGP é o daemon BGP usado para anunciar 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 — a configuração dos peers vem depois do sistema no ar, e não é editada à mão: o gerador lê os roteadores que você cadastrar em Configurações → Dispositivos e monta o arquivo.

Quando chegar a hora, na ordem:
python3 /opt/flowspec-analyzer/scripts/gobgp/gen_config.py > /etc/gobgpd.conf
systemctl enable --now gobgpd && systemctl restart gobgpd
gobgp neighbor  (a sessão precisa aparecer como Establ)

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 peer nenhum e a mitigação nunca anuncia nada.

Sem mitigação automática por ora? Pode deixar para depois: coleta, dashboard e detecção funcionam sem BGP.
6

Baixar e extrair o FlowSpec Analyzer

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

bash
cd /opt
curl -fLO https://www.managerpro.dev.br/flowspec/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/corrompido), baixe novamente ou entre em contato com o suporte antes de prosseguir.
7

Configurar e criar os bancos

7.1 — 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.2 — Crie o banco e aplique o schema + dados iniciais (templates de detecção, 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.3 — Gere o ambiente do dashboard. Antes de rodar o comando, decida por qual endereço o dashboard será acessado — é a escolha que mais quebra instalação, e ela se faz aqui:

escolha agora O AUTH_URL tem que ser exatamente a URL que você vai digitar no navegador — protocolo, host e porta. O dashboard roda em modo standalone, onde 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 inerte e nenhum erro útil na tela. Rodar o setup-env.sh sem informar AUTH_URL grava um placeholder — e o login não funciona de jeito nenhum.

Opção A — vai usar 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.seudominio.com.br \
  MYSQL_USER=root MYSQL_PASSWORD='SUA_SENHA_MYSQL' ./scripts/setup-env.sh
✅ Gerado: frontend/.env.production ... AUTH_URL: https://flowspec.seudominio.com.br ✓
Escolheu A? O login vai funcionar pelo domínio. Termine o Passo 8, pule para o Passo 10 (Apache + 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 — vai acessar por IP (rede interna, ou o DNS ainda não propagou):

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 ensina a trocar o AUTH_URL — sem isso, o login para de funcionar ao mudar de endereço.
Já rodou sem AUTH_URL? Não precisa refazer nada — corrija a linha e reinicie:
grep AUTH_URL /opt/flowspec-analyzer/frontend/.env.production
sed -i 's|^AUTH_URL=.*|AUTH_URL=https://flowspec.seudominio.com.br|' /opt/flowspec-analyzer/frontend/.env.production
systemctl restart flowspec-frontend

7.4(Recomendado) Importe os dados públicos de ASN — 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 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.1 — Com os serviços de pé, confirme que o tuning do Passo 1 realmente chegou 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. Recopie-a 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 tudo → systemctl restart flowspec-analyzer.target · só o dashboard → systemctl restart flowspec-frontend · logs → journalctl -u flowspec-core -f
9

Firewall e primeiro acesso

9.1 — 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.2 — Acesse o dashboard e faça o primeiro login. Use exatamente a URL que você gravou no AUTH_URL lá no Passo 7.3 — por 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.dev.br
Senha: admin123
No primeiro acesso, troque o e-mail e a senha do administrador em Configurações → Usuários (após trocar o e-mail, deslogue e entre novamente). Em seguida, crie os usuários da sua equipe com os perfis adequados (admin / operator / viewer).

9.3 — Ative a licença: na primeira tela será solicitada a chave de licença fornecida na contratação. Informe a chave e reinicie o core para concluir a ativação:

bash
systemctl restart flowspec-core
Sua chave de licença, status da assinatura e faturas ficam no Portal do Cliente: license.managerpro.dev.br — o acesso é criado na contratação e enviado ao seu e-mail.

9.4 — Aponte seus roteadores para o coletor: configure 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–2 minutos os flows começam a aparecer no dashboard.

Instalação concluída! O dashboard já mostra tráfego em tempo real. Explore as Zonas de IP e os Templates de Threshold para calibrar a detecção de DDoS à sua rede.
10

Acesso via domínio + HTTPS opcional

O dashboard já funciona por http://IP:3099. Se quiser um endereço amigável com certificado (ex.: flowspec.seudominio.com.br), coloque o Apache como proxy reverso na frente:

10.1 — 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.2 — Crie o VirtualHost (troque o domínio pelo seu; o DNS já deve apontar para o servidor):

/etc/apache2/sites-available/flowspec.conf
<VirtualHost *:80>
    ServerName flowspec.seudominio.com.br

    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.3 — Ative o site e emita o certificado (o certbot cria o vhost HTTPS e o redirect 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.seudominio.com.br

# 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.seudominio.com.br|' \
  /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 provado, ela é sua rota de escape se algo no Apache ou no certificado não subir. 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 rodar mesmo assim.

Valide (deve responder 307 redirecionando para o login, mantendo o seu domínio):

bash
curl -sk -o /dev/null -w "%{http_code} -> %{redirect_url}\n" https://flowspec.seudominio.com.br/
307 -> https://flowspec.seudominio.com.br/login
11

Plano de dados: Packet Filter (XDP) e Clean Pipe opcional

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

Este passo vem 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 — a maioria das instalações não faz nada dele.

Ele só vale se esta máquina encaminha os pacotes do ataque, ou seja: é 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 FlowSpec Analyzer, o servidor apenas recebe amostras de NetFlow/sFlow e anuncia FlowSpec por BGP — quem descarta o ataque é o roteador, não ele. Se é o seu caso, sua instalação já terminou no Passo 9: pode fechar o guia.
seguro em qualquer máquina Aqui só entra desempenho. O ip_forward, o rp_filter e os ICMP redirect 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; ele 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 na mão. Ligar 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 1.2.3.4  # 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 deste projeto: a máquina reinicia, o core sobe, o XDP carrega, o roteador segue desviando a vítima para cá — e a appliance descarta cada pacote por não estar mais encaminhando. Todos os serviços aparecem active (running) e o painel não acusa nada. Cliente fora do ar durante o ataque. Que ele não seja o padrão também é proposital: caminho ainda não provado subindo sozinho no boot é pior que caminho que some. Por isso a ordem é provar primeiro, persistir depois — e o status avisa enquanto faltar.

Ajustes na NIC — nenhum sysctl compensa uma placa mal configurada. Acima de 100 Gbps é aqui que a coisa se decide: os comandos abaixo valem mais em 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 sobe, e quem estiver passando tráfego de cliente sente um a dois segundos de queda. O item 4 desliga um serviço do sistema. Rode em 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 contagem de núcleos. Numa máquina de dois sockets, uma fila RSS atendida por um núcleo do nó errado paga travessia de 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. E confirme 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.
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 — o mesmo cuidado que vale para o sysctl.d.

Atualizando para novas versões

A atualização é um comando — o updater valida a integridade, preserva suas configurações, troca a versão e testa a saúde do sistema (downtime típico: menos de 1 minuto; os dados históricos não são tocados):

bash
cd /opt
curl -fLO https://www.managerpro.dev.br/flowspec/flowspec-analyzer-stable.tar.gz

/opt/flowspec-analyzer/scripts/update.sh /opt/flowspec-analyzer-stable.tar.gz
Usa scrubbing / 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 viaja 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.

cp /opt/flowspec-analyzer/deploy/scrubber/scrubber-path.conf /root/  (antes)
cp /root/scrubber-path.conf /opt/flowspec-analyzer/deploy/scrubber/  (depois)

Se esquecer, o arquivo continua em /opt/flowspec-analyzer.previous/deploy/scrubber/. Depois de restaurar, rode ./scrubber-path.sh status para conferir que 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

Problemas comuns

SintomaSolução
Dashboard não abre / serviço não sobe journalctl -u flowspec-frontend -n 50 — causa mais comum: permissões. Rode chown -R www-data:www-data /opt/flowspec-analyzer e systemctl restart flowspec-analyzer.target
Login dá error=Configuration O dashboard não conectou no MariaDB. Confira usuário/senha e rode novamente: 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 é exportação do roteador ou firewall; se chegam, confira journalctl -u flowspec-core -f
ClickHouse não responde systemctl status clickhouse-server e curl http://localhost:8123/ping. Senha errada no config.toml é a causa mais comum
Acesso via 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 contador nenhum 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
Scrubbing funcionava, a máquina reiniciou e parou O caminho foi ligado sem persistência. ./scrubber-path.sh status lista as chaves que voltaram ao default e a tabela nftables ausente; ./scrubber-path.sh up --persist resolve e faz sobreviver aos próximos reboots
Ajuste de sysctl some depois de atualizar Editou /etc/sysctl.d/99-flowspec-tuning.conf à mão? O updater o reinstala a cada atualização. Ponha seus valores num arquivo à parte com prefixo zz-, que é aplicado depois e vence
Precisa de ajuda? Fale com o suporte pelo WhatsApp ou e-mail — atendemos durante a janela de instalação para colocar tudo no ar junto com você.

Ainda não tem sua licença?

Conheça os planos ou agende uma demonstração com seus próprios dados de rede.