Una inundación dirigida a la propia dirección del router puede obligar a su CPU a procesar tráfico que no debería alcanzar los servicios de control y gestión. En Linux, una política de entrada de nftables permite aceptar lo necesario para el router y descartar el resto; el tráfico que solo atraviesa el equipo sigue otra ruta de filtrado.
El ejemplo configura BGP para un vecino, SSH y SNMP para una red de gestión y ping con límite de tasa. Usa 192.0.2.1 y 2001:db8:ffff::1 como direcciones del router, 192.0.2.2 y 2001:db8:ffff::2 para el vecino, y 192.0.2.0/27 y 2001:db8:100::/48 para las redes de gestión. Sustitúyelas por las de tu entorno antes de aplicar las reglas.
El problema: proteger lo que termina en el router
El punto clave es distinguir entre tráfico de tránsito y tráfico destinado al propio equipo. En nftables, la cadena con hook input procesa los paquetes entregados al sistema local; forward corresponde a los paquetes que el sistema reenvía a otro host. Esta política trabaja solo en input, así que no pretende sustituir las reglas de tránsito.
La idea de control-plane policing (CoPP) es clasificar qué tráfico puede llegar a la CPU y aplicar un trato distinto por clase. En un router Linux, el filtro de entrada es una forma de llevar esa lógica al firewall. La secuencia será: establecer una política de denegación, conservar conexiones establecidas, permitir protocolos imprescindibles, abrir servicios solo a orígenes autorizados y limitar las solicitudes de eco.
flowchart TD
A["Paquete recibido"] --> B{"¿Va al router?"}
B -->|"No"| C["Ruta de tránsito"]
B -->|"Sí"| D{"¿Está permitido?"}
D -->|"Sí"| E["Aceptar o limitar"]
D -->|"No"| F["Contar y descartar"]Crear la política de entrada
1. Declara vecinos y redes de gestión
Los conjuntos reúnen las direcciones que pueden iniciar sesiones de enrutamiento o administrar el equipo. En el ejemplo, BGP se limita a un vecino IPv4 y otro IPv6. La administración permite SSH desde las redes indicadas y SNMP desde la red IPv4 de gestión. No dejes direcciones de ejemplo en producción: configura las reales antes de continuar.
2. Permite lo necesario y descarta lo demás
Guarda este ruleset, por ejemplo, como router.nft. La política predeterminada de la cadena es drop. Primero se permiten conexiones establecidas o relacionadas, se descartan estados inválidos y se acepta el tráfico de loopback. Después aparecen las excepciones para descubrimiento de vecinos, protocolos de enrutamiento y gestión.
La lista ICMPv6 incluye mensajes de descubrimiento y errores de red, entre ellos packet-too-big. El ejemplo no limita el descubrimiento de vecinos: restringirlo puede interferir con la resolución de direcciones bajo carga. ARP, en cambio, no se filtra dentro de esta tabla inet; requiere reglas en la familia arp.
table inet cp {
set peers4 {
type ipv4_addr
elements = { 192.0.2.2 }
}
set peers6 {
type ipv6_addr
elements = { 2001:db8:ffff::2 }
}
set mgmt4 {
type ipv4_addr
flags interval
elements = { 192.0.2.0/27 }
}
set mgmt6 {
type ipv6_addr
flags interval
elements = { 2001:db8:100::/48 }
}
chain input {
type filter hook input priority 0; policy drop;
ct state established,related accept
ct state invalid drop
iif lo accept
# ICMPv6 necesario para vecinos y errores de ruta
meta l4proto ipv6-icmp icmpv6 type {
nd-router-solicit,
nd-router-advert,
nd-neighbor-solicit,
nd-neighbor-advert,
packet-too-big,
destination-unreachable,
time-exceeded,
parameter-problem
} accept
ip protocol icmp icmp type {
destination-unreachable,
time-exceeded
} accept
# BGP, OSPFv3 desde direcciones link-local y BFD
ip saddr @peers4 tcp dport 179 accept
ip6 saddr @peers6 tcp dport 179 accept
ip6 saddr fe80::/10 ip6 nexthdr 89 accept
ip saddr @peers4 udp dport { 3784, 4784 } accept
# Gestión desde las redes autorizadas
ip saddr @mgmt4 tcp dport 22 accept
ip6 saddr @mgmt6 tcp dport 22 accept
ip saddr @mgmt4 udp dport 161 accept
# Ping con límite y margen para ráfagas
ip protocol icmp icmp type echo-request limit rate 20/second burst 40 packets accept
meta l4proto ipv6-icmp icmpv6 type echo-request limit rate 20/second burst 40 packets accept
# Muestra pocos descartes en el registro y cuenta el resto
limit rate 5/minute log prefix "cp-drop: " counter drop
counter drop
}
}Las reglas de BGP comprueban la dirección de origen además del puerto TCP 179. La regla de OSPFv3 acepta tráfico de direcciones IPv6 link-local con el número de protocolo 89. Para BFD, el ejemplo permite UDP desde el vecino IPv4 en los puertos 3784 y 4784. Ajusta estas excepciones si la topología usa otros protocolos o vecinos.
3. Valida antes de aplicar
Comprueba la sintaxis con nft -c -f. La opción -c valida la configuración sin aplicarla. No cargues un filtro restrictivo en un router remoto sin una vía de recuperación: un error en las reglas de SSH puede dejarte sin acceso de administración. El ejemplo original recomienda probar en un laboratorio virtual y aplicar con una reversión temporizada.
# Comprueba el archivo sin aplicar los cambios
sudo nft -c -f router.nft
# Si la validación no devuelve errores, carga las reglas
sudo nft -f router.nftLa carga de un archivo de reglas se realiza con nft -f. Ejecuta la segunda orden solo después de revisar las direcciones y servicios permitidos y de preparar una forma de recuperar el acceso si algo sale mal.
4. Inspecciona contadores y prueba con tráfico controlado
Después de cargar la política, lista el conjunto de reglas y la cadena concreta. Los contadores ayudan a identificar qué reglas reciben tráfico y si los descartes aumentan. El límite de ping acepta hasta 20 solicitudes por segundo con una ráfaga de 40 paquetes; las solicitudes que superen el límite no coinciden con esa regla de aceptación y terminan en el descarte final.
# Revisa el ruleset cargado
sudo nft list ruleset
# Examina las reglas y sus contadores
sudo nft list chain inet cp inputLa prueba debe hacerse desde un host de laboratorio, no contra un router en producción. Un ping -f controlado puede generar solicitudes por encima del límite; mientras lo haces, comprueba desde el entorno de prueba que la sesión BGP sigue activa. La publicación que aporta el ejemplo advierte que sus reglas se redactaron a partir de documentación y no se probaron en un router real.
Errores que pueden cortar el acceso
No limites el tráfico de tránsito con esta cadena: el hook input solo cubre paquetes entregados al router. Para filtrar tráfico reenviado hace falta una política separada en forward.
También es fácil olvidar que una regla de aceptación debe cubrir todos los orígenes válidos. Si el vecino BGP real no coincide con los conjuntos, la política predeterminada lo descartará. Y si administras el router por IPv6, comprueba que la dirección de origen de tu estación pertenece a mgmt6 antes de activar el filtro.
Por último, no trates todos los protocolos como si fueran tráfico de diagnóstico. La publicación distingue entre enrutamiento, descubrimiento, gestión y eco: limitar con dureza los protocolos de enrutamiento puede afectar a las sesiones, mientras que el ping sí admite un límite explícito. La gestión de BGP también puede complementarse con protecciones de sesión como TCP-AO o MD5, seguridad TTL y límites de prefijos máximos; el filtro del firewall no las reemplaza.
La política queda así centrada en una pregunta concreta: qué servicios debe atender el router, desde qué orígenes y con qué límites. Antes de desplegarla fuera del laboratorio, confirma que las direcciones, los protocolos y la vía de recuperación corresponden a tu red.
Fuentes: DEV Community, Netfilter Project, nftables wiki
