Snort가 트래픽을 수신하고 있지만 규칙을 적용하지 않는 것 같습니다.

내 로컬에서 NFQUEUE를 통해 인라인 모드로 snort를 설치하고 실행했습니다 (다음 방을 걷고 터치 할 수 있음). 내 규칙은 다음과 같습니다 /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 라우터에있는 백도어와 관련이 있습니다. 테스트하기 쉬운 것처럼 보이기 때문에이 규칙을 선택했습니다. 규칙 자체는 신흥 위협에서 끌어 당겨진 포크에 의해 추가되었으므로 규칙 구문이 올바른 것으로 가정합니다.

테스트를 위해 포트 80의 lighttpd가 인터넷을 향하도록 게이트웨이를 구성하고 액세스 가능한지 확인했습니다. 그런 다음 원격 컴퓨터에서 명령을 실행했습니다 curl -A 'xmlset_roodkcableoj28840ybtide' 'http://<EXTERNAL_IP>'. 그러면 lighttpd에서 콘솔로 응답이 즉시 인쇄되고 종료됩니다. 게이트웨이에서 코 고는 경고가 생성되지 않습니다.

또한 netfilter는 내가 실행중인 4 가지 snort 프로세스 중 2 개만을 사용하는 것으로 보입니다. 나는이를 볼 수 있습니다 htop비트 토 런트와 함께 테스트 할 때 CPU를 1과 2에 흡입 프로세스의 부하를 개발할 때 ...하지만 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      

추가 주름 :

관련이 있는지 확실하지 않습니다. 인터넷에서 IP로 TCP 재설정 패킷을 보내는 내 게이트웨이에있는 것으로 나타났습니다. 그리고 이러한 패킷은 기존 연결과 관련이 없습니다.

이 게이트웨이 뒤에있는 컴퓨터에서 비트 토 런트를 사용할 때 발생하고 대부분의 리셋 패킷은 토런트 포트를 소스 포트로 나열하는 것이 유일한 의미는 무언가를 막을 때 리셋을 보내는 것입니다. ).

그러나 나는 nfqueue daq를 사용합니다 ... 그래서 그것이 코골이라면 왜 netfilter가 패킷을 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;)

구성도 업데이트했습니다. 내가 업로드 한 것은 분명히 오래된 것입니다 (http netfilter 규칙에 대해 NFQUEUE 대신 ACCEPT가 표시됨).

채팅에서 "해결됨".

거의 모든 것 (iptables + NFQUEUE, systemd.service 및 drop-in units, snort alerts 등)을 디버깅 한 후 문제는 테스트 수행 방식에서 비롯되었습니다.

일반적으로 인라인 IDS / IPS 자체의 snort는 의심스러운 트래픽이 아닌 HOME_NET (일명 로컬 LAN 서브넷)만이 아닌 자체 공개 IP가 아닌 것으로 확인되도록 정의되지 않습니다. 원래 규칙은이 공개 IP에 대해 테스트되었으므로 경고의 기본값은의 라인을 따라 표시되므로 경고를 생성하지 않았습니다 EXTERNAL_NET any -> HOME_NET any.