Snort получает трафик, но, похоже, не применяет правила

У меня есть snort, установленный и работающий во встроенном режиме через NFQUEUE на моем локальном (например, я могу пройти в соседнюю комнату и коснуться его) шлюз. У меня в моем /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;)

Это правило относится к бэкдору, обнаруженному в некоторых маршрутизаторах DLink. Я выбрал это правило, потому что казалось, что его будет просто проверить. Само правило было добавлено pullpork из возникающих угроз, поэтому я полагаю, что синтаксис правила правильный.

Для тестирования я настроил свой шлюз с lighttpd на порт 80, обращенный в Интернет, и подтвердил, что он доступен. Затем на удаленной машине я выполнил команду curl -A 'xmlset_roodkcableoj28840ybtide' 'http://<EXTERNAL_IP>'. Это сразу выводит ответ от lighttpd на консоль и завершает работу. На шлюзе не генерируются предупреждения snort.

Вдобавок netfilter, похоже, использует только два из четырех запущенных мной процессов snort. Я вижу это в htop поскольку процессы snort на ЦП 1 и 2 создают большую нагрузку при тестировании с помощью BitTorrent ... но процессы snort на ЦП 0 и 3 остаются полностью бездействующими.

Моя методология тестирования неверна? Или snort не предупреждает, когда должен (т.е. из-за ошибки конфигурации)? Куда мне обратиться, чтобы понять, почему netfilter не распределяет трафик между всеми четырьмя очередями?

Конфигурация

Моя конфигурация Snort / Netfilter

Конкретная релевантная часть моих цепочек netfilter:

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      

Дополнительная морщинка:

Я не уверен, связано ли это. Я обнаружил что-то на моем шлюзе, отправляющее пакеты сброса TCP на IP-адреса в Интернете. И эти пакеты не связаны с существующим подключением.

Учитывая, что это происходит при использовании BitTorrent на машине за этим шлюзом, и большинство пакетов сброса указывают торрент-порт в качестве исходного порта, единственное, что имеет смысл для меня, это то, что это сброс посылки snort, когда он что-то блокирует (ура? ).

Но я использую nfqueue daq ... так что, если это snort, то почему snort отправляет эти пакеты таким образом, что netfilter рассматривает как новое соединение, а не вставляет пакеты непосредственно в цепочки netfilter и связывает их с существующими? соединения, которые он блокирует? Кроме того, snort не настроен на отбрасывание пакетов или отправку сброса (только предупреждение) ... так зачем ему это делать с самого начала? Поэтому я не уверен, что snort делает это.

Дополнительная информация

В соответствии с предложением @Lenniey я также тестировал с curl -A 'asafaweb.com' http://server-ip. Это также не вызвало предупреждения. Я дважды проверил, существует ли соответствующее правило в моем файле правил. Есть два:

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

и

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

Я также обновил свою конфигурацию. Тот, который я загрузил, по-видимому, был старым (для правила http netfilter был показан ACCEPT вместо NFQUEUE).