Я установил и запускаю snort в режиме inline через 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, похоже, использует только два из четырех запущенных мной процессов snort. Я вижу это в htopтом, что процессы snort на CPU 1 и 2 развивают большую нагрузку при тестировании с помощью bittorrent ... но процессы snort на CPU 0 и 3 остаются полностью бездействующими.
Моя методика тестирования неверна? Или 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 не настроен на отбрасывание пакетов или отправку сброса (только оповещение) ... так с чего бы это было начинать с самого начала? Поэтому я не уверен, что это то, что делает фырканье.
Дополнительная информация
По предложению @ 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;)
Я также обновил свою конфигурацию. Тот, который я загрузил, был, по-видимому, старым (показывал ПРИНЯТЬ вместо NFQUEUE для правила http netfilter).
iptablesВыходные данные никогда не будут хорошим выбором, если вы не заинтересованы в счетчиках.iptables-saveвместо этого предпочтительнее, если вы ожидаете, что человек это прочтетОтветы:
«Решено» в чате.
После отладки практически всего (iptables + NFQUEUE, systemd.service и модулей drop-in, оповещения о фырканье и т. Д.) Проблема возникла в процессе тестирования.
Обычно фырканье как встроенный IDS / IPS само по себе не определяется для проверки на наличие подозрительного трафика, а только для HOME_NET (или локальных подсетей локальной сети), но не для его собственных общедоступных IP-адресов. Первоначальные правила были проверены на соответствие указанному общедоступному IP-адресу и поэтому не генерировали никаких предупреждений, поскольку по умолчанию для предупреждений используется что-то вроде
EXTERNAL_NET any -> HOME_NET any.источник