Ho snort installato e funzionante in modalità inline tramite NFQUEUE sul mio gateway locale (come posso camminare nella stanza successiva e toccarlo). Ho la seguente regola nel mio /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;)
Questa regola si riferisce a una backdoor trovata in alcuni router DLink. Ho selezionato questa regola perché sembrava che sarebbe stato semplice testarlo. La stessa regola è stata aggiunta da pullpork dalle minacce emergenti, quindi presumo che la sintassi della regola sia corretta.
Per i test, ho configurato il mio gateway con lighttpd sulla porta 80 di fronte a Internet e ho confermato che è accessibile. Quindi, su una macchina remota, ho eseguito il comando curl -A 'xmlset_roodkcableoj28840ybtide' 'http://<EXTERNAL_IP>'. Questo stampa prontamente la risposta da lighttpd alla console ed esce. Non vengono generati avvisi di snort sul gateway.
Inoltre, netfilter sembra utilizzare solo due dei quattro processi di snort che ho in esecuzione. Posso vederlo in htopquanto i processi di snort sulle CPU 1 e 2 sviluppano un carico pesante durante i test con bittorrent ... ma i processi di snort sulle CPU 0 e 3 rimangono completamente inattivi.
La mia metodologia di test è sbagliata? O snort non avvisa quando dovrebbe (cioè a causa di un errore di configurazione)? Dove guarderei per capire perché netfilter non bilancia il traffico tra tutte e quattro le code?
Configurazione
La parte specifica pertinente delle mie catene 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
Una ruga aggiuntiva:
Non sono sicuro che sia correlato. Ho scoperto ciò che sembra essere qualcosa sul mio gateway che invia pacchetti di ripristino TCP agli IP su Internet. E questi pacchetti non sono associati a una connessione esistente.
Dato che ciò accade quando si utilizza bittorrent su una macchina dietro questo gateway e la maggior parte dei pacchetti di ripristino elenca la porta torrent come porta di origine l'unica cosa che ha senso per me è che questo è snort che invia reimpostazioni quando blocca qualcosa (yay? ).
Ma io uso nfqueue daq ... quindi, se è snort, allora perché snort invia questi pacchetti in un modo che netfilter vede come una nuova connessione piuttosto che inserire i pacchetti direttamente nelle catene netfilter e associarli con quelli esistenti connessioni che sta bloccando? Inoltre, snort non è impostato per eliminare i pacchetti o inviare reimpostazioni (solo avviso) ... quindi perché iniziare? Quindi perché non sono sicuro che questo stia facendo qualcosa di sniff.
Altre informazioni
Come da suggerimento di @ Lenniey ho anche provato curl -A 'asafaweb.com' http://server-ip. Anche questo non ha prodotto un avviso. Ho ricontrollato che esiste una regola per questo nel mio file delle regole. Ci sono due:
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;)
e
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;)
Ho anche aggiornato la mia configurazione. Quello che avevo caricato era, apparentemente, vecchio (mostrato ACCETTA invece di NFQUEUE per la regola http netfilter).
iptablesL'output non è mai una buona scelta a meno che tu non sia specificamente interessato ai contatori. iptables-saveè preferibile invece se ti aspetti che l'essere umano lo legga