Tôi đã khịt mũi được cài đặt và chạy trong chế độ nội tuyến thông qua NFITEUE trên cổng cục bộ (như tôi có thể đi bộ ở phòng bên cạnh và chạm vào nó). Tôi có quy tắc sau đây trong /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;)
Quy tắc này liên quan đến một cửa hậu được tìm thấy trong một số bộ định tuyến DLink. Tôi đã chọn quy tắc này vì có vẻ như nó sẽ đơn giản để kiểm tra. Bản thân quy tắc đã được thêm vào bởi pullpork từ những người mới nổi nên tôi cho rằng cú pháp quy tắc là chính xác.
Để thử nghiệm, tôi đã cấu hình cổng của mình với lighttpd trên cổng 80 đối diện với internet và xác nhận rằng nó có thể truy cập được. Sau đó, trên một máy từ xa, tôi chạy lệnh curl -A 'xmlset_roodkcableoj28840ybtide' 'http://<EXTERNAL_IP>'. Điều này kịp thời in phản hồi từ lighttpd đến bàn điều khiển và thoát. Không có cảnh báo snort được tạo ra trên cổng.
Ngoài ra, netfilter dường như chỉ sử dụng hai trong số bốn quy trình snort mà tôi đang chạy. Tôi có thể thấy điều này htopkhi các quá trình snort trên CPU 1 và 2 phát triển một tải nặng khi thử nghiệm với bittorrent ... nhưng các quá trình snort trên CPU 0 và 3 vẫn hoàn toàn không hoạt động.
Là phương pháp thử nghiệm của tôi sai? Hoặc là snort không cảnh báo khi cần (nghĩa là do lỗi cấu hình)? Tôi sẽ tìm ở đâu để xem tại sao netfilter không cân bằng lưu lượng giữa cả bốn hàng đợi?
Cấu hình
Cấu hình Snort / Netfilter của tôi
Phần liên quan cụ thể của chuỗi bộ lọc mạng của tôi là:
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
Một nếp nhăn bổ sung:
Tôi không chắc nó có liên quan hay không. Tôi đã phát hiện ra những gì dường như là một cái gì đó trên cổng của tôi gửi các gói đặt lại TCP đến IP trên internet. Và các gói này không được liên kết với một kết nối hiện có.
Cho rằng điều này xảy ra khi sử dụng bittorrent trên một máy phía sau cổng này và phần lớn các gói đặt lại liệt kê cổng torrent là cổng nguồn, điều duy nhất có ý nghĩa với tôi là đây là việc khịt mũi gửi lại khi nó chặn thứ gì đó (yay? ).
Nhưng tôi sử dụng daq nfqueue ... vì vậy, nếu đó là tiếng khịt mũi, thì tại sao snort lại gửi những gói này theo cách mà netfilter xem như một kết nối mới thay vì chèn các gói trực tiếp vào chuỗi netfilter và liên kết chúng với chuỗi hiện có kết nối mà nó đang chặn? Ngoài ra, snort không được đặt để thả các gói hoặc gửi lại (chỉ cảnh báo) ... vậy tại sao nó lại bắt đầu như vậy? Do đó tại sao tôi không chắc đây là điều gì đó khịt mũi đang làm.
Thông tin khác
Theo đề nghị của @ Lennie, tôi cũng đã thử nghiệm curl -A 'asafaweb.com' http://server-ip. Điều này cũng không tạo ra một cảnh báo. Tôi đã kiểm tra lại rằng một quy tắc cho điều này tồn tại trong tệp quy tắc của tôi. Có hai:
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;)
và
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;)
Tôi cũng đã cập nhật cấu hình của mình. Cái mà tôi đã tải lên là, rõ ràng, và cái cũ (đã hiển thị ACCEPT thay vì NFITEUE cho quy tắc http netfilter).
iptablesĐầu ra không bao giờ là một lựa chọn tốt trừ khi bạn đặc biệt quan tâm đến quầy. iptables-savethay vào đó, tốt hơn là nếu bạn mong đợi con người đọc nó