11

I have snort installed and running in inline mode via NFQUEUE on my local (as in I can walk in the next room and touch it) gateway. I have the following rule in my /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;)

This rule relates to a backdoor found in some DLink routers. I selected this rule because it looked like it would be simple to test. The rule itself was added by pulledpork from emergingthreats so I presume the rule syntax to be correct.

For testing, I have configured my gateway with lighttpd on port 80 facing the internet and confirmed that it is accessible. Then, on a remote machine, I ran the command curl -A 'xmlset_roodkcableoj28840ybtide' 'http://<EXTERNAL_IP>'. This promptly prints the response from lighttpd to the console and exits. No snort alerts are generated on the gateway.

Additionally, netfilter only seems to be making use of two of the four snort processes I have running. I can see this in htop as the snort processes on CPUs 1 and 2 develop a heavy load when testing with bittorrent... but the snort processes on CPUs 0 and 3 remain completely idle.

Is my testing methodology wrong? Or is snort not alerting when it should (i.e. because of a configuration error)? Where would I look to see why netfilter in not balancing traffic between all four queues?

Configuration

My Snort/Netfilter Config

The specific relevant part of my netfilter chains is:

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

An additional wrinkle:

I'm not sure if it's related. I have discovered what appears to be something on my gateway sending TCP reset packets to IPs on the internet. And these packets are not associated with an existing connection.

Given that this happens when using bittorrent on a machine behind this gateway and the majority of the reset packets list the torrent port as the source port the only thing that makes sense to me is that this is snort sending resets when it blocks something (yay?).

But I use the nfqueue daq... so, if it is snort, then why is snort sending out these packets in a way that netfilter sees as a new connection rather than inserting the packets directly into the netfilter chains and associating them with the existing connections that it is blocking? And also, snort is not set to drop packets or to send resets (only alert)... so why would it be doing that to begin with? Hence why I'm unsure this is something snort is doing.

Other Information

As per @Lenniey's suggestion I also tested with curl -A 'asafaweb.com' http://server-ip. This also did not produce an alert. I double checked that a rule for this exists in my rules file. There are two:

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;)

and

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;)

I've also updated my configuration. The one I had uploaded was, apparently, and old one (showed ACCEPT instead of NFQUEUE for the http netfilter rule).

Cliff Armstrong
  • 172
  • 1
  • 11
  • Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/98207/discussion-on-question-by-cliff-armstrong-snort-is-receiving-traffic-but-doesn). – Michael Hampton Sep 02 '19 at 17:06
  • `iptables`'s output is never a good choice unless you are specifically interested in counters. `iptables-save` is preferable instead if you expect human to read it – poige Sep 02 '19 at 17:27
  • @poige Agreed. At the time I was simply following the recommendations that came with the "iptables" tag. In the future, however, I'll probably use iptables-save. – Cliff Armstrong Sep 02 '19 at 22:15

1 Answers1

5

"Solved" in chat.

After debugging just about everything (iptables + NFQUEUE, systemd.service and drop-in units, snort alerts etc.), the problem originated in the way the testing was done.

Usually, snort as inline IDS/IPS itself is not defined to be checked for suspicious traffic, rather only the HOME_NETs (aka local LAN subnets), but not on its own public IP. The original rules were tested against this said public IP and so did not generate any alerts, as the default for alerts is something along the lines of EXTERNAL_NET any -> HOME_NET any.

Lenniey
  • 5,090
  • 2
  • 17
  • 28