Snort empfängt Datenverkehr, scheint jedoch keine Regeln anzuwenden

Ich habe snort im Inline-Modus über NFQUEUE auf meinem lokalen Gateway installiert (wie in Ich kann in den nächsten Raum gehen und ihn berühren). Ich habe die folgende Regel in meinem /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;)

Diese Regel bezieht sich auf eine Hintertür in einigen DLink-Routern. Ich habe diese Regel ausgewählt, weil es so aussah, als wäre es einfach zu testen. Die Regel selbst wurde von pullpork aus emergingthreats hinzugefügt, daher gehe ich davon aus, dass die Regelsyntax korrekt ist.

Zum Testen habe ich mein Gateway mit lighttpd auf Port 80 mit Blick auf das Internet konfiguriert und bestätigt, dass es zugänglich ist. Dann habe ich auf einem Remote-Computer den Befehl ausgeführt curl -A 'xmlset_roodkcableoj28840ybtide' 'http://<EXTERNAL_IP>'. Dadurch wird die Antwort von lighttpd sofort an die Konsole gedruckt und beendet. Auf dem Gateway werden keine Snort-Warnungen generiert.

Außerdem scheint netfilter nur zwei der vier Snort-Prozesse zu verwenden, die ich ausgeführt habe. Ich kann dies daran erkennen, dass htopdie Snort-Prozesse auf den CPUs 1 und 2 beim Testen mit Bittorrent eine hohe Last entwickeln ... aber die Snort-Prozesse auf den CPUs 0 und 3 bleiben vollständig inaktiv.

Ist meine Testmethode falsch? Oder warnt snort nicht, wann es sollte (dh aufgrund eines Konfigurationsfehlers)? Wo würde ich nachsehen, warum Netfilter den Datenverkehr zwischen allen vier Warteschlangen nicht ausgleicht?

Aufbau

Meine Snort / Netfilter-Konfiguration

Der spezifische relevante Teil meiner Netzfilterketten ist:

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      

Eine zusätzliche Falte:

Ich bin nicht sicher, ob es verwandt ist. Ich habe festgestellt, dass auf meinem Gateway TCP-Reset-Pakete an IPs im Internet gesendet werden. Und diese Pakete sind keiner bestehenden Verbindung zugeordnet.

Angesichts der Tatsache, dass dies geschieht, wenn Bittorrent auf einem Computer hinter diesem Gateway verwendet wird und die Mehrheit der Rücksetzpakete den Torrent-Port als Quellport auflistet, ist das einzige, was für mich sinnvoll ist, dass dies ein schnaubendes Senden von Resets ist, wenn etwas blockiert wird (yay? ).

Aber ich benutze den nfqueue daq ... also, wenn es schnaubt, warum sendet schnupfen diese Pakete dann so, dass netfilter sie als neue Verbindung sieht, anstatt die Pakete direkt in die Netzfilterketten einzufügen und sie mit den vorhandenen zu verknüpfen Verbindungen, die blockiert werden? Außerdem ist snort nicht so eingestellt, dass Pakete verworfen oder Resets gesendet werden (nur Alarm). Warum sollte das also zunächst so sein? Deshalb bin ich mir nicht sicher, ob Snort dies tut.

Andere Informationen

Gemäß @ Lennieys Vorschlag habe ich auch mit getestet curl -A 'asafaweb.com' http://server-ip. Dies erzeugte auch keine Warnung. Ich habe doppelt überprüft, ob eine Regel dafür in meiner Regeldatei vorhanden ist. Es gibt zwei:

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

und

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

Ich habe auch meine Konfiguration aktualisiert. Die, die ich hochgeladen hatte, war anscheinend eine alte (zeigte ACCEPT anstelle von NFQUEUE für die http-Netfilter-Regel).

"Gelöst" im Chat.

Nach dem Debuggen von fast allem (iptables + NFQUEUE, systemd.service und Drop-In-Einheiten, Snort-Warnungen usw.) entstand das Problem in der Art und Weise, wie die Tests durchgeführt wurden.

Normalerweise ist das Schnauben als Inline-IDS / IPS selbst nicht so definiert, dass es auf verdächtigen Datenverkehr überprüft wird, sondern nur die HOME_NETs (auch als lokale LAN-Subnetze bezeichnet), jedoch nicht auf ihrer eigenen öffentlichen IP. Die ursprünglichen Regeln wurden gegen diese besagte öffentliche IP getestet und haben daher keine Warnungen generiert, da die Standardeinstellung für Warnungen etwas in der Art von ist EXTERNAL_NET any -> HOME_NET any.