У мене встановлений фронт і працює в режимі вбудованого режиму через 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 на консоль і виходить. На шлюзі не генеруються сповіщення про фронт.
Крім того, Netfilter лише використовує два з чотирьох процесів фронт. Я бачу це в htopтому, що процеси фронт в процесорах 1 і 2 розвивають велике навантаження при тестуванні з бітторентами ... але процеси фронт в процесорах 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 на машині, що знаходиться за цим шлюзом, і більшість пакетів скидання перераховує порт torrent як вихідний порт. Єдине, що для мене має сенс, це те, що це відправлення сміття скидає скидання, коли воно щось блокує (так? ).
Але я використовую nfqueue daq ... так, якщо це snort, то чому snort надсилає ці пакети таким чином, що netfilter бачить як нове з'єднання, а не вставляння пакетів безпосередньо в ланцюги netfilter та асоціювання їх з існуючими з'єднання, які він блокує? А також, 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;)
Я також оновив свою конфігурацію. Я завантажив, мабуть, і старий (показав ACCEPT замість NFQUEUE для правила http netfilter).
iptablesВихід ніколи не є вдалим вибором, якщо ви спеціально не зацікавлені в лічильниках. iptables-saveбажано замість цього, якщо ви очікуєте, що людина прочитає це