guía de instalación

Instalación de EdgeWarden

El paso a paso completo para poner la plataforma en marcha en un servidor Debian 13 (server, instalación mínima), desde las dependencias hasta el dashboard funcionando.

  • Debian 13 (Trixie)
  • x86_64
  • ~40 minutos
  • acceso root
Debian 13 · x86_64dashboard en el puerto 3099
Índice de la guía

Antes de empezar

léalo una vez Los nombres técnicos usan el prefijo flowspec. Para mantener la compatibilidad con las instalaciones existentes, el directorio (/opt/flowspec-analyzer), los servicios (flowspec-core, flowspec-frontend y flowspec-analyzer.target), la base de datos de ClickHouse (flowspec), el paquete (flowspec-analyzer-stable.tar.gz) y las claves de API (fsk_) conservan ese prefijo. Los comandos de esta guía son correctos para la versión actual.

Requisitos de hardware

Elija el tamaño según el volumen de flows de su red. Los tres usan el mismo paquete.

RecursoSmall: ISP regionalMedium (recomendado): ISP o DC medianoEnterprise: Tier-1 o DC grande
VolumenHasta 20 mil flows/s, redes de hasta ~5 GbpsHasta 50 mil flows/s, redes de hasta ~20 Gbps100 mil+ flows/s, redes de 40 Gbps o más
CPU8 núcleos (Xeon / EPYC)16 núcleos (Xeon Scalable / EPYC)32+ núcleos (EPYC / Xeon Platinum)
RAM32 GB DDR464 GB DDR4 ECC128+ GB DDR4/DDR5 ECC
Disco500 GB NVMe SSD2 TB NVMe SSD4+ TB NVMe (RAID 10)
Red1 Gbps10 Gbps25 / 40 / 100 Gbps
SistemaDebian 13 server (Trixie, instalación mínima), x86_64
  • eBPF/XDP: Debian 13 ya trae kernel 6.x. Use una tarjeta de red con XDP nativo (Mellanox o Intel).
  • ClickHouse: a partir del tamaño Medium, sepárelo en un servidor dedicado.
  • Retención: dimensione el disco según el período de retención deseado; la compresión ronda 10:1.
  • Alta disponibilidad: en el tamaño Enterprise, se recomienda un clúster de 2 nodos o más.

Puertos utilizados

PuertoProtocoloServicio
2055UDPColector NetFlow v5/v9/IPFIX
6343UDPColector sFlow
11019TCPEstación BMP (opcional)
3099TCPDashboard web
8123 / 9000TCPClickHouse (solo local)
6379TCPRedis (solo local)
50051TCPgRPC de GoBGP (solo local)
179TCPBGP (GoBGP ↔ router)
8090TCP/health del scrubber (solo en instalación distribuida; ábralo solo para el analyzer)
80 / 443TCPProxy para dominio con HTTPS (opcional, Paso 10)

téngalo a mano antes de empezar La clave de licencia se pide en el primer acceso al dashboard, antes de cualquier configuración. Sin ella, instala todo y se queda en la pantalla de activación. Antes de abrir la terminal, prepare:

  • Clave de licencia: enviada al contratar. También está disponible en el Área de clientes. ¿Todavía no contrató? Vea los planes.
  • Cómo se accederá al dashboard: por IP o por dominio con HTTPS. Esta decisión entra en la configuración ya en el Paso 7.3, y cambiarla después obliga a reconfigurar. Si es por dominio, el DNS ya debe apuntar al servidor.
  • Dos contraseñas fuertes: una para ClickHouse y otra para MariaDB. Anote ambas, porque cada una se usa en más de un paso.
Todos los comandos de esta guía suponen ejecución como root. Si usa un usuario común, anteponga sudo. Reemplace SUA_SENHA_CH y SUA_SENHA_MYSQL por las contraseñas que preparó.
  1. Preparar el sistema

    Actualice Debian e instale las herramientas base. EdgeWarden se entrega como binario listo, así que no hace falta ninguna herramienta de compilación:

    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: requerido para SNMPv3

    libpcap0.8 es la única biblioteca del sistema que el colector usa en tiempo de ejecución. Nada de compiladores, PHP ni paquetes extra: cuanto más pequeña la instalación, menor la superficie de ataque.

    El paquete snmp (net-snmp) solo se usa si registra dispositivos con SNMPv3. El colector trae SNMP v1/v2c integrado, pero para v3 llama al snmpbulkwalk del sistema. Instalarlo ahora cuesta pocos KB y evita una trampa: sin ese binario, la recolección v3 falla en silencio, no aparece ningún contador y el log no indica la causa.

    Tuning del kernel (sysctl) para el colector

    El colector recibe ráfagas intensas de UDP (NetFlow/sFlow), y los valores por defecto de Debian son conservadores. El core pide 16 MB de buffer por socket, pero el net.core.rmem_max de fábrica es de apenas 208 KB. El pedido se trunca, el kernel descarta paquetes de flow en silencio y el tráfico desaparece de los gráficos sin ningún error visible. Aplíquelo una sola vez:

    bash · /etc/sysctl.d/99-flowspec-tuning.conf
    cat > /etc/sysctl.d/99-flowspec-tuning.conf <<'EOF'
    # Buffers de red — colector NetFlow/sFlow (ráfagas UDP)
    # Son TOPES, no asignación: el kernel solo reserva lo que pida el socket. El core
    # pide 16 MB por socket; el tope queda holgado a 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
    
    # Límites de archivos/hilos — core + ClickHouse
    # Tope del SISTEMA. NO es el límite del proceso — vea la nota más abajo.
    fs.file-max = 3263776
    fs.aio-max-nr = 3263776
    fs.pipe-max-size = 8388608
    kernel.threads-max = 1031306
    kernel.pid_max = 262144
    
    # Memoria — ClickHouse usa mucho page cache; el swap mata la latencia
    vm.swappiness = 1
    vm.vfs_cache_pressure = 50
    # 256 MB es el tope que el propio kernel usa al calcular este valor según la RAM.
    # El antiguo 32768 quedaba POR DEBAJO del default en máquinas con 64 GB o más.
    vm.min_free_kbytes = 262144
    
    # Reinicio automático 3 s después de un kernel panic (appliance sin operador)
    kernel.panic = 3
    EOF
    
    # Aplicar y verificar
    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

    Crear el archivo ahora es lo correcto. Solo no vuelva a él después para cambiar valores.

    El mismo archivo viene en el paquete (scripts/sysctl/99-flowspec-tuning.conf) y, a partir de la primera actualización, el update.sh lo reescribe en cada update. Un valor editado directamente en /etc/sysctl.d/99-flowspec-tuning.conf vuelve al original en la siguiente actualización, sin error y sin aviso. Es el tipo de cosa que se descubre tarde.

    Para cambiar un valor de forma permanente, ponga solo lo que quiere distinto en un archivo aparte, con el prefijo zz-:

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

    Funciona porque sysctl.d lee los archivos en orden alfabético y gana quien define la clave al final: 99-zz-meus-ajustes viene después de 99-flowspec-tuning. Ese archivo es suyo, y ninguna actualización lo toca.

    nada que hacer ahora Solo para entender: fs.file-max no es el límite del proceso. Es el tope de todo el sistema. Cada servicio sigue sujeto al LimitNOFILE de systemd, que por defecto es de apenas 1024 descriptores. Las units de EdgeWarden ya traen LimitNOFILE=65535, así que no hay nada que ajustar. La verificación de esto y del buffer de socket está en el Paso 8, cuando los servicios ya existan.

    solo si tiene firewall propio ¿Firewall stateful en esta máquina? En una instalación limpia de Debian, sin reglas de firewall propias, omita esta nota. EdgeWarden no usa conntrack: su chain de nftables entra en hook input priority -150, antes del seguimiento de conexiones, y XDP actúa antes de todo netfilter.

    Si usted mantiene un firewall stateful propio, agregue en sus reglas la exención de los puertos de flow: udp dport { 2055, 6343 } notrack. No es un comando de terminal, sino un fragmento de regla nftables. En una máquina que hace scrubbing, exima también el tráfico de tránsito: conntrack crea estado por flujo, y un flood con origen falsificado llena la tabla en segundos. Es la forma clásica de tumbar su propio scrubber. Solo aumente net.nf_conntrack_max si realmente necesita estado y, en ese caso, mantenga nf_conntrack_buckets en cerca de ¼ del valor; si no, la cadena de hash se vuelve el cuello de botella.

    casi nunca aplica ¿Esta máquina va a reenviar los paquetes del ataque? Solo si es un filtro eBPF/XDP en línea o un scrubber de clean pipe. En la instalación estándar, el servidor solo recibe muestras de NetFlow/sFlow y anuncia FlowSpec por BGP; quien descarta el ataque es el router. Si ese es su caso, siga normalmente.

    Si va a reenviar, el tuning del plano de datos está en el Paso 11, al final de la guía. Depende del paquete ya instalado, así que no se puede adelantar aquí.

    Zona horaria y NTP

    Los timestamps correctos son esenciales para los gráficos de flows y para la validación de la licencia:

    bash
    timedatectl set-timezone America/Sao_Paulo   # ajuste a su región
    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

    El dashboard web corre sobre Node.js, instalado desde el repositorio oficial de NodeSource:

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

    ClickHouse es la base de datos de series temporales que almacena los flows. Instálela desde el repositorio 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 la instalación, ClickHouse pide la contraseña del usuario default. Defina una contraseña fuerte y anótela: esta guía se refiere a ella como SUA_SENHA_CH.

    Active el servicio y verifique que responda:

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

    MariaDB guarda los usuarios y la configuración del dashboard; Redis distribuye las alertas en tiempo real.

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

    Defina la contraseña de root de MariaDB (reemplace SUA_SENHA_MYSQL):

    bash
    mariadb -u root -e "ALTER USER 'root'@'localhost' IDENTIFIED BY 'SUA_SENHA_MYSQL'; FLUSH PRIVILEGES;"
  5. Instalar GoBGP mitigación

    GoBGP es el daemon BGP que anuncia las reglas de mitigación (FlowSpec/RTBH) a su router:

    bash
    apt install -y gobgpd

    por ahora, solo instalar Instalarlo basta para seguir la guía. Los peers se configuran después, con el sistema en marcha, y el archivo no se edita a mano: el generador lee los routers que usted registre en Configuración → Dispositivos (Configurações → Dispositivos) y arma la configuración.

    Cuando llegue el momento, ejecute en este orden. En gobgp neighbor, la sesión debe aparecer como Establ:

    bash · después de registrar los routers
    python3 /opt/flowspec-analyzer/scripts/gobgp/gen_config.py > /etc/gobgpd.conf
    systemctl enable --now gobgpd && systemctl restart gobgpd
    gobgp neighbor

    Fíjese en el >: el generador escribe en la salida estándar. Sin la redirección, solo imprime en pantalla y /etc/gobgpd.conf sigue vacío. GoBGP arranca sin ningún peer y la mitigación nunca anuncia nada.

    ¿Todavía no va a usar mitigación automática? Puede dejarlo para después: la recolección, el dashboard y la detección funcionan sin BGP.

  6. Descargar y extraer el paquete

    Descargue la versión estable y extráigala en /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

    Cree el directorio de la licencia:

    bash
    mkdir -p /etc/flowspec-analyzer
    chown -R www-data:www-data /etc/flowspec-analyzer
    Si la descarga o la extracción fallan (archivo incompleto o dañado), descárguelo de nuevo o contacte al soporte antes de seguir.
  7. Configurar y crear las bases de datos

    7.1Contraseña de ClickHouse

    Edite el config.toml e indique la contraseña de ClickHouse definida en el Paso 3:

    bash
    nano /opt/flowspec-analyzer/config.toml
    # en la sección [storage.clickhouse]:
    #   password = "SUA_SENHA_CH"

    7.2Bases de datos, schema y datos iniciales

    Cree la base de datos y aplique el schema y los datos iniciales (templates de detección y 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
    
    # base de autenticación (crea el usuario admin por defecto)
    mysql -u root -p'SUA_SENHA_MYSQL' < database/mysql/auth_schema.sql

    7.3Entorno del dashboard y AUTH_URL

    Antes de ejecutar el comando, decida por qué dirección se accederá al dashboard. Es la decisión que más instalaciones rompe, y se toma aquí:

    decida ahora AUTH_URL tiene que ser exactamente la URL que usted va a escribir en el navegador: protocolo, host y puerto. El dashboard corre en modo standalone, en el que Next arma el origen a partir de esa variable e ignora el encabezado Host. No hay forma de que lo adivine.

    Si el valor no coincide con la URL usada, el login falla con cualquier credencial, el formulario parece trabado y no aparece ningún error útil en pantalla. Ejecutar setup-env.sh sin indicar AUTH_URL graba un valor provisional, y entonces el login no funciona de ninguna manera.

    Opción A

    Dominio con HTTPS (recomendado en producción)

    Use el dominio desde ya, aunque Apache todavía no esté 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 ✓
    ¿Eligió A? El login solo va a funcionar por el dominio. Termine el Paso 8, salte al Paso 10 (Apache y certificado) y recién entonces vuelva al Paso 9 para el primer login. El DNS del dominio ya debe apuntar a este servidor.
    Opción B

    Acceso por IP (red interna, o DNS aún no propagado)

    bash
    IP=$(ip -4 -br addr show | awk '$1!="lo"{print $3}' | cut -d/ -f1 | head -1)
    echo "Detectado: $IP"   # verifíquelo antes de seguir
    
    AUTH_URL=http://$IP:3099 \
      MYSQL_USER=root MYSQL_PASSWORD='SUA_SENHA_MYSQL' ./scripts/setup-env.sh
    ¿Eligió B? Siga el orden normal de la guía. Si algún día agrega dominio y HTTPS, el Paso 10 muestra cómo cambiar el AUTH_URL. Sin ese cambio, el login deja de funcionar cuando cambia la dirección.

    ¿Ya lo ejecutó sin AUTH_URL? No hace falta rehacer nada. Corrija la línea y reinicie el 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.4Datos públicos de ASN recomendado

    Importe los datos públicos de ASN. Habilitan las pantallas de Peering, CDN y Análisis de AS (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. Activar los servicios (systemd)

    El sistema corre como dos servicios supervisados: si algún proceso cae, systemd lo reinicia solo.

    bash
    cd /opt/flowspec-analyzer
    
    # propietario correcto ANTES de iniciar (los servicios corren 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 el tuning del Paso 1 desde el paquete, para que el archivo quede
    # idéntico al que update.sh va a mantener de aquí en adelante (evita divergencias).
    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.1Verificar el tuning en el proceso

    Con los servicios en marcha, confirme que el tuning del Paso 1 llegó realmente al proceso. Son tres lecturas, y ninguna modifica nada:

    bash
    # 1. Descriptores del core — tiene que dar 65535, no 1024
    cat /proc/$(pgrep -f flowspec-analyzer-core)/limits | grep "open files"
    
    # 2. Buffer del socket del colector. El core pide 16 MB y el kernel DUPLICA el
    #    valor, así que 32 MB es el número correcto: rb33554432.
    #    Si aparece rb425984, el sysctl del Paso 1 no se aplicó.
    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 — estos contadores NO pueden crecer con el tiempo
    nstat -az | grep -iE "Udp.*(InErrors|RcvbufErrors)"
    ¿Actualiza una instalación antigua? Si el ítem 1 todavía muestra 1024, la unit en uso es de la versión anterior. Cópiela de nuevo desde scripts/systemd/ (comando de arriba) y ejecute systemctl daemon-reload seguido de systemctl restart flowspec-analyzer.target. Sin el daemon-reload, el nuevo límite no se aplica, aunque el archivo ya esté en su lugar.

    Comandos del día a día

    • Reiniciar todosystemctl restart flowspec-analyzer.target
    • Reiniciar solo el dashboardsystemctl restart flowspec-frontend
    • Seguir los logsjournalctl -u flowspec-core -f
  9. Firewall y primer acceso

    9.1Abrir los puertos

    Abra solo lo necesario (ejemplo con 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.2Primer login

    Abra el dashboard e inicie sesión por primera vez. Use exactamente la URL grabada en AUTH_URL en el Paso 7.3: por IP, si eligió la opción B; por dominio, si eligió la A (y, en ese caso, el Paso 10 debe estar listo antes).

    URL
    la misma de su AUTH_URL
    Usuario
    flowspec@managerpro.networko admin@edgewarden.com.br
    Contraseña
    admin123(las dos cuentas)
    En el primer acceso, cambie el e-mail y la contraseña de las dos cuentas de administrador predeterminadas (o elimine la que no use) en Configuración → Usuarios (Configurações → Usuários) (después de cambiar el e-mail, cierre sesión y vuelva a entrar). Luego cree los usuarios de su equipo con los perfiles adecuados: admin, operator o viewer.

    9.3Activar la licencia

    En la primera pantalla, el dashboard pide la clave de licencia recibida al contratar. Ingrese la clave y reinicie el core para completar la activación:

    bash
    systemctl restart flowspec-core
    La clave de licencia, el estado de la suscripción y las facturas están en el Área de clientes: license.managerpro.dev.br. El acceso se crea al contratar y se envía a su e-mail.

    9.4Apuntar los routers al colector

    Configure en los routers la exportación de NetFlow v9/IPFIX (puerto 2055/UDP) o sFlow (puerto 6343/UDP) hacia la IP del servidor y registre cada equipo en Configuración → Dispositivos. En 1 a 2 minutos, los flows empiezan a aparecer en el dashboard.

    Instalación completada. El dashboard ya muestra el tráfico en tiempo real. Ahora explore las Zonas de IP y los Templates de Threshold para calibrar la detección de DDoS a su red.
  10. Acceso por dominio y HTTPS opcional

    El dashboard ya funciona en http://IP:3099. Si quiere una dirección amigable con certificado (por ejemplo, flowspec.example.net), ponga Apache delante como proxy inverso.

    10.1Apache y certbot

    Instale Apache y certbot y active los 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

    Cree el VirtualHost, reemplazando el dominio por el suyo. El DNS ya debe apuntar al servidor:

    /etc/apache2/sites-available/flowspec.conf
    <VirtualHost *:80>
        ServerName flowspec.example.net
    
        ProxyPreserveHost On
        ProxyRequests Off
    
        # WebSocket (actualizaciones en tiempo real del 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 — Apache ya
        # envía ese header por su cuenta, y duplicarlo rompe el login (Invalid URL).
        RequestHeader unset X-Forwarded-Host
        # Esquema dinámico (http/https) — sigue siendo correcto cuando certbot
        # clone este vhost al puerto 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.3Sitio en línea y certificado

    Active el sitio y emita el certificado. certbot crea el vhost HTTPS y la redirección automáticamente:

    bash
    # 1. Abrir 80 y 443 ANTES de certbot: valida el dominio por HTTP en el
    #    puerto 80, y el ufw del Paso 9 no lo abrió. Fuera de orden, falla.
    ufw allow 80/tcp
    ufw allow 443/tcp
    
    # 2. Activar el sitio
    a2ensite flowspec
    apachectl configtest && systemctl reload apache2
    
    # 3. Emitir el certificado (crea el vhost HTTPS y el redirect automáticamente)
    certbot --apache -d flowspec.example.net
    
    # 4. AUTH_URL pasa a ser el dominio. Sin esto, el login deja de funcionar
    #    en el instante en que cambia la IP por el dominio en el navegador.
    sed -i 's|^AUTH_URL=.*|AUTH_URL=https://flowspec.example.net|' \
      /opt/flowspec-analyzer/frontend/.env.production
    systemctl restart flowspec-frontend
    
    # 5. Solo DESPUÉS de que el login por el dominio funcione (opcional):
    #    ufw deny 3099/tcp    # fuerza el acceso solo por dominio/HTTPS

    No cierre el puerto 3099 antes de tiempo. Mientras el login por el dominio no esté comprobado, es su vía de escape si algo falla en Apache o en el certificado. Deje el ufw deny 3099/tcp para el final, y ejecútelo solo si realmente quiere bloquear el acceso directo.

    Si viene de la opción A del Paso 7.3, el AUTH_URL ya es el dominio: el ítem 4 no cambia nada y es seguro ejecutarlo de todos modos.

    Valide. La respuesta debe ser 307, redirigiendo al login en su dominio:

    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 datos: Packet Filter (XDP) y clean pipe opcional

    El tuning del Paso 1 ajusta el colector, que solo recibe muestras de flow. Si esta máquina también reenvía los paquetes (filtrado eBPF/XDP en línea o desvío a scrubbing en clean pipe), necesita un segundo conjunto de claves orientado al plano de datos: reenvío, softirq, qdisc y JIT de eBPF. Eso es lo que define cuántos Gbps y Mpps soporta la appliance en su hardware; el buffer de socket del colector no tiene ningún papel aquí.

    Este paso está al final de la guía a propósito: parte de él usa archivos que solo existen después de la instalación (scripts/sysctl/ y deploy/scrubber/), y el camino de scrubbing solo tiene sentido con el sistema ya en marcha.

    deténgase y decida Todo este paso es opcional, y la mayoría de las instalaciones no hace nada de él.

    Solo aplica si esta máquina reenvía los paquetes del ataque: si es un filtro eBPF/XDP en línea o el scrubber de un clean pipe (el tráfico de la víctima entra y sale por ella).

    En la instalación estándar de EdgeWarden, el servidor solo recibe muestras de NetFlow/sFlow y anuncia FlowSpec por BGP; quien descarta el ataque es el router. Si ese es su caso, la instalación terminó en el Paso 9 y puede cerrar la guía.

    Tuning del plano de datos

    seguro en cualquier máquina Aquí solo entra rendimiento. ip_forward, rp_filter y los ICMP redirects no están en este archivo, a propósito: de ellos se encarga scrubber-path.sh, que valida la topología antes de activar y sabe deshacer los cambios. Este bloque es seguro en cualquier máquina y solo marca diferencia donde hay paquetes en tránsito.
    bash
    # El archivo ya viene listo en el paquete. Copiarlo en vez de tipearlo garantiza
    # que nunca diverja de lo que el producto prueba — y conviene abrirlo antes: cada
    # clave tiene el porqué comentado a su lado.
    cat /opt/flowspec-analyzer/scripts/sysctl/99-zz-flowspec-dataplane.conf.example
    
    # El sufijo "zz" da precedencia sobre el 99-flowspec-tuning del Paso 1:
    # sysctl.d aplica en orden alfabético y gana el último que define la clave.
    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

    Reenvío (clean pipe)

    Esta parte no se hace a mano. Activar ip_forward en un archivo de sysctl convierte la appliance en router sin validar nada. scrubber-path.sh verifica antes la topología (el router debe estar en el mismo segmento L2), aplica las claves con los cuidados que exige un hairpin y sabe deshacer los cambios:

    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, no toca nada
    ./scrubber-path.sh up                   # activa — solo en runtime
    ./scrubber-path.sh verify 203.0.113.10  # simula la decisión para una víctima
    
    # Solo DESPUÉS de que verify pase, hágalo permanente:
    ./scrubber-path.sh up --persist
    ./scrubber-path.sh status               # debe decir "Persistência ativa"

    No omita el --persist. Sin él, el camino vive solo en memoria, y el modo de falla es el peor posible: la máquina se reinicia, el core arranca, XDP carga, el router sigue desviando a la víctima hacia aquí y la appliance descarta cada paquete porque ya no está reenviando. Todos los servicios aparecen como active (running) y el panel no reporta nada. El cliente queda fuera de servicio durante el ataque.

    --persist tampoco es el valor por defecto, a propósito: un camino aún no comprobado que se activa solo en el arranque es peor que un camino que desaparece. Por eso el orden es comprobar primero, persistir después, y status avisa mientras falte la persistencia.

    Ajustes en la tarjeta de red

    Ningún sysctl compensa una tarjeta mal configurada. Por encima de 100 Gbps, aquí es donde se define todo: los comandos de abajo rinden más pps que todo el bloque anterior.

    ventana de mantenimiento No copie este bloque completo en una máquina en producción. Los ítems 1 y 2 (ethtool -G y ethtool -L) reinicializan la tarjeta: el enlace cae y vuelve, y si está pasando tráfico de clientes se nota una caída de uno a dos segundos. El ítem 4 desactiva un servicio del sistema. Ejecútelo en una ventana acordada, un ítem a la vez, verificando entre uno y otro.

    Y cambie IF=eth0 por su interfaz real antes que nada (ip -br link lista las disponibles). Apuntar a la interfaz equivocada modifica la tarjeta equivocada.

    bash
    IF=eth0   # interfaz del plano de datos (la que recibe el tráfico sucio)
    
    # 1. Ring buffers al MÁXIMO que soporta la tarjeta (leído de la propia tarjeta)
    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. Colas RSS — una por núcleo del MISMO nodo NUMA de la tarjeta (vea la nota)
    NODE=$(cat /sys/class/net/$IF/device/numa_node)
    NCPU=$(lscpu -p=CPU,NODE | grep -c ",$NODE$")
    ethtool -L $IF combined $NCPU
    
    # 3. Coalescencia adaptativa: menos IRQ por paquete bajo ráfaga
    ethtool -C $IF adaptive-rx on adaptive-tx on
    
    # 4. IRQ fija por cola — irqbalance las reacomoda justamente bajo carga
    systemctl disable --now irqbalance
    
    # 5. ¿En qué modo arrancó XDP?
    ip -d link show $IF | grep -i xdp
    #    "xdp"        = nativo, en el driver — obligatorio a esta escala
    #    "xdpgeneric" = fallback SKB, corre DESPUÉS de GRO. En este modo el filtro
    #                   ve paquetes ya coalescidos y subcuenta pps, entonces:
    ethtool -K $IF gro off lro off
    
    # 6. Verificar si la tarjeta está descartando paquetes (todo debe quedar en cero)
    ethtool -S $IF | grep -iE "drop|discard|miss|nobuf|error" | grep -v ": 0$"

    NUMA importa más que la cantidad de núcleos. En una máquina de dos sockets, una cola RSS atendida por un núcleo del nodo equivocado paga el cruce de la interconexión en cada paquete. Si cat /sys/class/net/$IF/device/numa_node devuelve 0, use solo los núcleos del nodo 0: 16 colas en el nodo correcto rinden más que 64 repartidas.

    Confirme también el ancho del slot: 200 Gbps exige PCIe 4.0 x16 (lspci -vv -s $(basename $(readlink /sys/class/net/$IF/device)) | grep -i "LnkSta:"). En un slot x8, la tarjeta nunca entrega la tasa nominal, y ningún tuning lo corrige.

    Los ajustes de ethtool no persisten tras un reinicio. Fíjelos en un post-up en /etc/network/interfaces o en una unit oneshot de systemd con After=network-online.target, con el mismo cuidado que aplica a sysctl.d.
después de la instalación

Actualizar a nuevas versiones

La actualización es un comando. El updater valida la integridad del paquete, conserva su configuración, cambia la versión y prueba la salud del sistema. El tiempo fuera de servicio suele quedar por debajo de 1 minuto, y los datos históricos no se tocan:

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 o clean pipe? Solo en esta actualización, guarde antes la topología. deploy/scrubber/scrubber-path.conf describe la topología de su red, por eso no viene en el paquete, y el updater reemplaza el directorio entero. La nueva versión de update.sh ya conserva ese archivo, pero quien ejecuta el cambio es el updater que ya está en el servidor, todavía el antiguo. De la próxima actualización en adelante, es automático.

  • Antes: cp /opt/flowspec-analyzer/deploy/scrubber/scrubber-path.conf /root/
  • Después: cp /root/scrubber-path.conf /opt/flowspec-analyzer/deploy/scrubber/

Si lo olvida, el archivo sigue en /opt/flowspec-analyzer.previous/deploy/scrubber/. Después de restaurarlo, ejecute ./scrubber-path.sh status para verificar que el camino volvió completo.

Si algo no sale como se esperaba, volver a la versión anterior también es un comando:

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

Problemas comunes

SíntomaSolución
El dashboard no abre o el servicio no arranca journalctl -u flowspec-frontend -n 50. La causa más común son los permisos: ejecute chown -R www-data:www-data /opt/flowspec-analyzer y systemctl restart flowspec-analyzer.target.
El login devuelve error=Configuration El dashboard no se conectó a MariaDB. Verifique usuario y contraseña y ejecute de nuevo: MYSQL_USER=root MYSQL_PASSWORD='...' ./scripts/setup-env.sh --force
No aparece ningún flow Verifique si los paquetes llegan: tcpdump -i any -n udp port 2055. Si no llegan, el problema está en la exportación del router o en el firewall; si llegan, revise journalctl -u flowspec-core -f.
ClickHouse no responde systemctl status clickhouse-server y curl http://localhost:8123/ping. La causa más común es una contraseña incorrecta en config.toml.
El acceso por dominio redirige mal Detrás de un proxy inverso, preserve el Host: en Apache, use ProxyPreserveHost On y no defina X-Forwarded-Host manualmente; en nginx, use proxy_set_header Host $host;.
Dispositivo SNMPv3 sin ningún contador Falta net-snmp: el colector trae v1/v2c integrado, pero llama al snmpbulkwalk del sistema para v3. Verifique con command -v snmpbulkwalk e instálelo con apt install -y snmp. En v2c, el paquete no es necesario.
El scrubbing funcionaba, la máquina se reinició y dejó de funcionar El camino se activó sin persistencia. ./scrubber-path.sh status lista las claves que volvieron al valor por defecto y la tabla nftables ausente; ./scrubber-path.sh up --persist lo resuelve y hace que el camino sobreviva a los próximos reinicios.
Un ajuste de sysctl desaparece después de la actualización ¿Editó /etc/sysctl.d/99-flowspec-tuning.conf a mano? El updater lo reinstala en cada actualización. Ponga sus valores en un archivo aparte con el prefijo zz-, que se aplica después y prevalece.
soporte

¿Se trabó en algún paso?

Hable con el soporte por WhatsApp o por e-mail. Durante la ventana de instalación, lo acompañamos hasta que el dashboard esté en marcha.

Atención en portugués, de lunes a viernes, de 8 a 18 h (hora de Brasilia).

¿Todavía no tiene su licencia?

Conozca los planes o agende una demostración con los datos de su propia red.