web-dev-qa-db-ja.com

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ルーターにあるバックドアに関連しています。簡単にテストできるように見えたので、このルールを選択しました。ルール自体は新興脅威からpulledporkによって追加されたので、ルール構文は正しいと思います。

テストのため、ゲートウェイをインターネットに面したポート80のlighttpdで構成し、アクセス可能であることを確認しました。次に、リモートマシンでcurl -A 'xmlset_roodkcableoj28840ybtide' 'http://<EXTERNAL_IP>'コマンドを実行しました。これは即座にlighttpdからの応答をコンソールに出力して終了します。ゲートウェイでsnortアラートは生成されません。

さらに、netfilterは、私が実行している4つのsnortプロセスのうち2つだけを使用しているようです。これはhtopで確認できます。ビットトレントでテストすると、CPU 1と2のsnortプロセスに大きな負荷がかかりますが、CPU 0と3のsnortプロセスは完全にアイドル状態のままです。

私のテスト方法は間違っていますか？または、snortが警告を出さない場合（つまり、構成エラーのため）ですか？ netfilterが4つすべてのキュー間でトラフィックのバランスをとらない理由をどこで確認したらよいですか

構成

My Snort/Netfilter Config

私のネットフィルターチェーンの特定の関連部分は次のとおりです。

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

追加のしわ：

それが関連しているかどうかはわかりません。 TCPリセットパケットをインターネット上のIPに送信しているゲートウェイ上で何かのように見えるものを発見しました。これらのパケットは既存の接続に関連付けられていません。

これがこのゲートウェイの背後にあるマシンでビットトレントを使用しているときに発生し、リセットパケットの大部分がトレントポートをソースポートとしてリストしていることを考えると、私が理解できる唯一のことは、何かをブロックするときにリセットが送信されるということです（そうですか？ ）。

しかし、私はnfqueue daqを使用します...ですから、snortである場合、パケットをnetfilterチェーンに直接挿入して既存のものと関連付けるのではなく、netfilterが新しい接続と見なす方法でsnortがこれらのパケットを送信するのはなぜですか？それがブロックしている接続？また、snortはパケットをドロップしたり、リセット（アラートのみ）を送信したりするように設定されていません...では、なぜそれを最初から行うのでしょうか？したがって、なぜこれが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と表示されていました）。

iptablessnortips
11
Cliff Armstrong

チャットで「解決済み」

ほぼすべて（iptables + NFQUEUE、systemd.service、ドロップインユニット、snortアラートなど）をデバッグした後、問題はテストが行​​われた方法に起因していました。

通常、インラインIDS/IPS自体としてのsnortは、疑わしいトラフィックのチェックではなく、HOME_NET（別名ローカルLANサブネット）のみをチェックするように定義されていません。元のルールはこのパブリックIPに対してテストされたため、アラートのデフォルトはEXTERNAL_NET any -> HOME_NET any。

5
Lenniey