Snort reçoit du trafic, mais ne semble pas appliquer les règles

J'ai snort installé et exécuté en mode en ligne via NFQUEUE sur ma passerelle locale (comme dans je peux marcher dans la pièce voisine et la toucher). J'ai la règle suivante dans mon /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;)

Cette règle concerne une porte dérobée trouvée dans certains routeurs DLink. J'ai choisi cette règle car il semblait que ce serait simple à tester. La règle elle-même a été ajoutée par pullpork à partir de menaces émergentes, donc je suppose que la syntaxe de la règle est correcte.

Pour les tests, j'ai configuré ma passerelle avec lighttpd sur le port 80 face à Internet et confirmé qu'elle est accessible. Ensuite, sur une machine distante, j'ai exécuté la commande curl -A 'xmlset_roodkcableoj28840ybtide' 'http://<EXTERNAL_IP>'. Ceci imprime rapidement la réponse de lighttpd à la console et quitte. Aucune alerte snort n'est générée sur la passerelle.

De plus, netfilter ne semble utiliser que deux des quatre processus snort que j'ai en cours d'exécution. Je peux voir cela htopcar les processus snort sur les CPU 1 et 2 développent une lourde charge lors des tests avec bittorrent ... mais les processus snort sur les CPU 0 et 3 restent complètement inactifs.

Ma méthodologie de test est-elle incorrecte? Ou est-ce que Snort n'alerte pas quand il le devrait (c'est-à-dire à cause d'une erreur de configuration)? Où pourrais-je chercher pourquoi Netfilter ne répartit pas le trafic entre les quatre files d'attente?

Configuration

Ma configuration Snort / Netfilter

La partie spécifique pertinente de mes chaînes netfilter est:

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      

Une ride supplémentaire:

Je ne sais pas si c'est lié. J'ai découvert ce qui semble être quelque chose sur ma passerelle envoyant des paquets de réinitialisation TCP aux IP sur Internet. Et ces paquets ne sont pas associés à une connexion existante.

Étant donné que cela se produit lors de l'utilisation de bittorrent sur une machine derrière cette passerelle et que la majorité des paquets de réinitialisation répertorient le port torrent comme port source, la seule chose qui me semble logique est que cela envoie des réinitialisations snort quand il bloque quelque chose (yay? ).

Mais j'utilise le daq nfqueue ... donc, s'il s'agit de snort, alors pourquoi snort envoie-t-il ces paquets d'une manière que netfilter considère comme une nouvelle connexion plutôt que d'insérer les paquets directement dans les chaînes de netfilter et de les associer à l'existant les connexions qu'il bloque? Et aussi, snort n'est pas configuré pour supprimer des paquets ou pour envoyer des réinitialisations (seulement une alerte) ... alors pourquoi ferait-il cela pour commencer? Par conséquent, je ne suis pas sûr que ce soit quelque chose que Snort fait.

les autres informations

Selon la suggestion de @ Lenniey, j'ai également testé avec curl -A 'asafaweb.com' http://server-ip. Cela n'a pas non plus déclenché d'alerte. J'ai revérifié qu'une règle pour cela existe dans mon fichier de règles. Il y en a deux:

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;)

et

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;)

J'ai également mis à jour ma configuration. Celui que j'avais téléchargé était, apparemment, et ancien (montrait ACCEPT au lieu de NFQUEUE pour la règle http netfilter).

"Résolu" dans le chat.

Après avoir débogué à peu près tout (iptables + NFQUEUE, unités systemd.service et drop-in, alertes snort, etc.), le problème provient de la façon dont les tests ont été effectués.

Habituellement, snort comme IDS / IPS en ligne lui-même n'est pas défini pour être vérifié pour le trafic suspect, plutôt que pour les HOME_NETs (alias sous-réseaux LAN locaux), mais pas sur sa propre IP publique. Les règles d'origine ont été testées par rapport à cette adresse IP publique et n'ont donc généré aucune alerte, car la valeur par défaut pour les alertes est quelque chose du genre EXTERNAL_NET any -> HOME_NET any.