Snort está recibiendo tráfico, pero no parece estar aplicando reglas

He instalado y ejecutado en modo en línea a través de NFQUEUE en mi puerta de enlace local (ya que puedo caminar en la habitación contigua y tocarla). Tengo la siguiente regla en mi /etc/snort/rules/snort.rules:

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ET CURRENT_EVENTS D-LINK Router Backdoor via Specific UA"; flow:to_server,established; content:"xmlset_roodkcableoj28840ybtide"; http_header; pcre:"/^User-Agent\x3a[^\r\n]*?xmlset_roodkcableoj28840ybtide/Hm"; reference:url,www.devttys0.com/2013/10/reverse-engineering-a-d-link-backdoor/; classtype:attempted-admin; sid:2017590; rev:2; metadata:created_at 2013_10_13, updated_at 2013_10_13;)

Esta regla se refiere a una puerta trasera que se encuentra en algunos enrutadores DLink. Seleccioné esta regla porque parecía que sería fácil de probar. La regla en sí fue agregada por pullpork de las amenazas emergentes, por lo que supongo que la sintaxis de la regla es correcta.

Para las pruebas, configuré mi puerta de enlace con lighttpd en el puerto 80 frente a internet y confirmó que es accesible. Luego, en una máquina remota, ejecuté el comando curl -A 'xmlset_roodkcableoj28840ybtide' 'http://<EXTERNAL_IP>'. Esto imprime rápidamente la respuesta de lighttpd a la consola y sale. No se generan alertas de snort en la puerta de enlace.

Además, netfilter solo parece estar haciendo uso de dos de los cuatro procesos de inhalación que estoy ejecutando. Puedo ver esto htopcuando los procesos de snort en las CPU 1 y 2 desarrollan una gran carga al probar con bittorrent ... pero los procesos de snort en las CPU 0 y 3 permanecen completamente inactivos.

¿Mi metodología de prueba es incorrecta? ¿O snort no alerta cuando debería (es decir, debido a un error de configuración)? ¿Dónde miraría para ver por qué netfilter no equilibra el tráfico entre las cuatro colas?

Configuración

Mi configuración de Snort / Netfilter

La parte relevante específica de mis cadenas netfilter es:

Chain wan-fw (1 references)
 pkts bytes target     prot opt in     out     source               destination         
25766 2960K smurfs     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID,NEW,UNTRACKED
    4  1380 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpts:67:68
 4267  246K tcpflags   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           
 3820  550K ~comb0     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate ESTABLISHED     <<=== this one for established connections ====!
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED
  937 79669 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:!0x17/0x02
   13   506 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8 /* Ping */
    4   240 ~log0      tcp  --  *      *       <remote_server>      0.0.0.0/0            tcp dpt:80 /* Tiphares Allowed In */     <<=== this one for new connections ====!
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type BROADCAST
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type ANYCAST
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type MULTICAST
21506 2454K NFLOG      all  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: up to 1/sec burst 10 mode srcip nflog-prefix  "IPv4 wan-fw REJECT " nflog-threshold 1
24808 2878K reject     all  --  *      *       0.0.0.0/0            0.0.0.0/0           [goto] 

Chain ~log0 (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    4   240 NFLOG      all  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: up to 1/sec burst 10 mode srcip /* Tiphares Allowed In */ nflog-prefix  "IPv4 HTTPTest NFQUEUE " nflog-group 1 nflog-threshold 1
    4   240 NFQUEUE    all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* Tiphares Allowed In */ NFQUEUE balance 0:3 bypass cpu-fanout     <<=== passes packets to one of 4 snort processes ====!

Chain ~comb0 (4 references)
 pkts bytes target     prot opt in     out     source               destination         
 474K  196M NFQUEUE    all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate ESTABLISHED NFQUEUE balance 0:3 bypass cpu-fanout     <<=== all established connections from 'wan' are monitored by snort ====!
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0      

Una arruga adicional:

No estoy seguro si está relacionado. He descubierto lo que parece ser algo en mi puerta de enlace que envía paquetes de restablecimiento de TCP a IP en Internet. Y estos paquetes no están asociados con una conexión existente.

Dado que esto sucede cuando se usa bittorrent en una máquina detrás de esta puerta de enlace y la mayoría de los paquetes de reinicio enumeran el puerto de torrent como el puerto de origen, lo único que tiene sentido para mí es que este es el envío de restituciones de resoplido cuando bloquea algo (¿yay? )

Pero uso el daf nfqueue ... así que, si es snort, entonces ¿por qué es snort enviando estos paquetes de una manera que netfilter ve como una nueva conexión en lugar de insertar los paquetes directamente en las cadenas de netfilter y asociarlos con los existentes? conexiones que está bloqueando? Y también, snort no está configurado para descartar paquetes o para enviar restablecimientos (solo alerta) ... entonces, ¿por qué estaría haciendo eso para empezar? Por eso no estoy seguro de que esto sea algo que Snort está haciendo.

Otra información

Según la sugerencia de @ Lenniey también probé curl -A 'asafaweb.com' http://server-ip. Esto tampoco produjo una alerta. Verifiqué dos veces que exista una regla para esto en mi archivo de reglas. Hay dos:

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ET POLICY ASafaWeb Scan User-Agent (asafaweb.com)"; flow:established,to_server; content:"User-Agent|3a| asafaweb.com|0d 0a|"; http_header; reference:url,asafaweb.com; classtype:network-scan; sid:2014233; rev:2; metadata:created_at 2012_02_16, updated_at 2012_02_16;)

y

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"MALWARE-CNC User-Agent ASafaWeb Scan"; flow:to_server,established; content:"User-Agent|3A| asafaweb.com"; fast_pattern:only; http_header; metadata:policy balanced-ips alert, policy security-ips drop, ruleset community, service http; reference:url,asafaweb.com; classtype:network-scan; sid:21327; rev:7;)

También he actualizado mi configuración. El que había subido era, aparentemente, y uno viejo (mostraba ACEPTAR en lugar de NFQUEUE para la regla http netfilter).

"Resuelto" en el chat.

Después de depurar casi todo (iptables + NFQUEUE, systemd.service y unidades de entrega, alertas de snort, etc.), el problema se originó en la forma en que se realizaron las pruebas.

Por lo general, esnifar como IDS / IPS en línea no está definido para verificar el tráfico sospechoso, sino solo las HOME_NET (también conocidas como subredes LAN locales), pero no en su propia IP pública. Las reglas originales se probaron contra esta IP pública y, por lo tanto, no generaron ninguna alerta, ya que el valor predeterminado para las alertas es algo similar EXTERNAL_NET any -> HOME_NET any.