Mam snort zainstalowany i działa w trybie inline przez NFQUEUE na mojej lokalnej (jak mogę wejść do następnego pokoju i dotknąć go) bramie. Mam w mojej regule następującą zasadę /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;)
Ta reguła dotyczy backdoora znalezionego w niektórych routerach DLink. Wybrałem tę regułę, ponieważ wyglądało na to, że będzie to łatwe do przetestowania. Sama reguła została dodana przez pulledpork z pojawiających się zagrożeń, więc zakładam, że składnia reguły jest poprawna.
Do testów skonfigurowałem moją bramę z lighttpd na porcie 80 skierowanym do Internetu i potwierdziłem, że jest ona dostępna. Następnie na zdalnej maszynie uruchomiłem polecenie curl -A 'xmlset_roodkcableoj28840ybtide' 'http://<EXTERNAL_IP>'. To natychmiast wypisuje odpowiedź z lighttpd na konsolę i kończy działanie. W bramie nie są generowane żadne alerty snort.
Dodatkowo wydaje się, że netfilter wykorzystuje tylko dwa z czterech procesów snorta, które uruchomiłem. Widzę to, htopgdy procesy snortowania na procesorach 1 i 2 rozwijają duże obciążenie podczas testowania z bittorrentem ... ale procesy snortowania na procesorach 0 i 3 pozostają całkowicie bezczynne.
Czy moja metodologia testowania jest nieprawidłowa? A może Snort nie ostrzega, kiedy powinien (tj. Z powodu błędu konfiguracji)? Gdzie mogę sprawdzić, dlaczego netfilter nie równoważy ruchu między wszystkimi czterema kolejkami?
Konfiguracja
Konkretna istotna część moich łańcuchów filtrów sieciowych to:
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
Dodatkowe zmarszczki:
Nie jestem pewien, czy jest to powiązane. Odkryłem coś, co wydaje się być czymś na mojej bramie wysyłającej pakiety resetowania TCP do adresów IP w Internecie. I te pakiety nie są powiązane z istniejącym połączeniem.
Biorąc pod uwagę, że dzieje się tak, gdy używasz bittorrenta na maszynie za tą bramą, a większość pakietów resetowania wymienia port torrent jako port źródłowy, jedyną rzeczą, która ma dla mnie sens, jest to, że snort wysyła resety, gdy coś blokuje (tak? ).
Ale używam nfqueue daq ... więc jeśli jest to snort, to dlaczego snort wysyła te pakiety w sposób, który netfilter widzi jako nowe połączenie, zamiast wstawiać pakiety bezpośrednio do łańcuchów netfilter i kojarzyć je z istniejącymi połączenia, które blokuje? Ponadto snort nie jest ustawiony na odrzucanie pakietów lub wysyłanie resetów (tylko alert) ... więc dlaczego miałby to robić na początek? Dlatego nie jestem pewien, czy robi to parsknięcie.
Inne informacje
Zgodnie z sugestią @ Lennieya, z którą również testowałem curl -A 'asafaweb.com' http://server-ip. To również nie wywołało alarmu. Dokładnie sprawdziłem, czy reguła tego istnieje w moim pliku reguł. Istnieją dwa:
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;)
i
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;)
Zaktualizowałem również moją konfigurację. Ten, który przesłałem, był najwyraźniej stary i pokazał AKCEPTUJĘ zamiast NFQUEUE dla reguły http netfilter).
iptablesWynik nigdy nie jest dobrym wyborem, chyba że jesteś szczególnie zainteresowany licznikami.iptables-savejest lepsze, jeśli spodziewasz się, że człowiek to przeczytaOdpowiedzi:
„Rozwiązane” na czacie.
Po debugowaniu niemal wszystkiego (iptables + NFQUEUE, systemd.service i drop-in units, snort alerts itp.) Problem powstał w wyniku przeprowadzenia testu.
Zwykle snortowanie jako wbudowane IDS / IPS nie jest zdefiniowane jako sprawdzane pod kątem podejrzanego ruchu, a jedynie HOME_NET (zwane także lokalnymi podsieciami LAN), ale nie na własnym publicznym adresie IP. Oryginalne reguły zostały przetestowane w odniesieniu do wspomnianego publicznego adresu IP, a zatem nie wygenerowały żadnych alertów, ponieważ domyślne ustawienie dla alertów jest podobne
EXTERNAL_NET any -> HOME_NET any.źródło