Snort yükledim ve yerel modda NFQUEUE aracılığıyla inline modda çalışıyor (olduğu gibi yan odada yürüyebilir ve dokunabilirim) ağ geçidi. Bende aşağıdaki kural var /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;)
Bu kural, bazı DLink yönlendiricilerinde bulunan bir arka kapı ile ilgilidir. Bu kuralı seçtim, çünkü test edilmesi kolay görünüyordu. Kuralın kendisi ortaya çıkan tehditlerden pulledpork tarafından eklendi, bu yüzden kural sözdiziminin doğru olduğunu varsayıyorum.
Test için, ağ geçidimi 80 numaralı portta internete bakan lighttpd ile yapılandırdım ve erişilebilir olduğunu doğruladım. Sonra uzaktaki bir makinede komutu çalıştırdım curl -A 'xmlset_roodkcableoj28840ybtide' 'http://<EXTERNAL_IP>'. Bu, lighttpd'den konsola yanıtı derhal yazdırır ve çıkar. Ağ geçidinde herhangi bir snort uyarısı oluşturulmaz.
Ayrıca, netfilter yalnızca çalıştırdığım dört snort işleminden ikisini kullanıyor gibi görünüyor. htopBittorrent ile test yaparken CPU 1 ve 2'deki snort süreçlerinin ağır bir yük geliştirdiği için bunu görebiliyorum ... ancak CPU 0 ve 3'teki snort işlemleri tamamen boşta kalıyor.
Test metodolojim yanlış mı? Veya snort ne zaman uyarı vermiyor (yani bir yapılandırma hatası nedeniyle)? Netfilter'ın neden dört kuyruk arasındaki trafiği dengelemediğini görmek için nereye bakmalıyım?
Yapılandırma
Snort / Netfilter Yapılandırmam
Netfilter zincirlerimin ilgili kısmı:
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
Ek bir kırışıklık:
İlişkili olup olmadığından emin değilim. Ağ geçidimde Internet'teki IP'lere TCP sıfırlama paketleri gönderen bir şey olduğunu gördüm. Ve bu paketler mevcut bir bağlantıyla ilişkili değildir.
Bunun, bu ağ geçidinin arkasındaki bir makinede bittorrent kullanırken ve sıfırlama paketlerinin çoğunun torrent portunu kaynak port olarak listelediği göz önüne alındığında, bana mantıklı olan tek şey, bunun bir şey engellediğinde snort göndermenin sıfırlanmasıdır (yay? ).
Ama ben nfqueue daq kullanıyorum ... öyleyse, eğer snort ise, neden snort bu paketleri netfilter paketleri doğrudan netfilter zincirlerine eklemek ve mevcut ile ilişkilendirmek yerine yeni bir bağlantı olarak görecek şekilde gönderiyor? engelliyor bağlantıları? Ve ayrıca, snort paketleri bırakmaya veya sıfırlama göndermeye ayarlanmamıştır (sadece uyarı) ... öyleyse neden başlamak için bunu yapıyor? Bu yüzden bunun snort'un yaptığı bir şey olduğundan emin değilim.
Diğer bilgiler
@ Lenniey'in önerisine göre ben de test ettim curl -A 'asafaweb.com' http://server-ip. Bu da bir uyarı vermedi. Kurallar dosyamda bunun için bir kuralın bulunduğunu iki kez kontrol ettim. İki tane:
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;)
ve
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;)
Ayrıca yapılandırmamı güncelledim. Yüklediğim, görünüşe göre ve eski (http netfilter kuralı için NFQUEUE yerine ACCEPT gösterdi).
iptablesÖzellikle sayaçlar ile ilgilenmediğiniz sürece çıktısı asla iyi bir seçim değildir. iptables-saveinsanın okumasını bekliyorsanız bunun yerine tercih edilir