OPNsense Forum
English Forums => Intrusion Detection and Prevention => Topic started by: elektroinside on February 16, 2018, 11:35:52 pm
-
So I've come up with some custom suricata rules.
The tutorial written by dcol was very helpful to integrate them in OPNsense, thanks (https://forum.opnsense.org/index.php?topic=7209.0)!
All of them are working, meaning I get either dropped packets or alerts, except these (or other similar variants, using suricata dns keywords):
drop tcp any any -> any !53 (msg:"DNS TCP query custom port"; flow:to_server; app-layer-protocol:dns; sid:2271015; rev:1;)
drop udp any any -> any !53 (msg:"DNS UDP query custom port"; flow:to_server; app-layer-protocol:dns; sid:2271017; rev:1;)
The culprit here looks like to be app-layer-protocol:dns; which in this case cannot identify (?) DNS queries by dig or nslookup for example, on non-standard ports, for example 208.67.220.220:5353. In Wireshark they do not appear as DNS protocol queries, but MDNS. Copy-pasting a standard DNS protocol query (on p53) hex stream (which appears on Wireshark as DNS protocol) and sending it to a public DNS server on port 5353 will list the query as MDNS (as in the attached picture), exactly like dig on non-standard ports.
I have no idea if this is the actual failing point of the rules. No errors importing them in suricata.
What I want to achieve is to block all non-standard port (53) DNS queries. Do I need byte_test, offsets, content regex matching and so forth?
Thank you!
-
Salut,
Interesting, I have no idea why it is not working your rule.
Can you please try if any of this rule work:
drop udp $HOME_NET any -> $EXTERNAL_NET !53 (msg:"Admin-Rule !53 dns Query *.* domain"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|01|."; fast_pattern; distance:0; classtype:bad-unknown; sid:9900202; rev:2;)
edit maybe better:
drop dns $HOME_NET any -> $EXTERNAL_NET !53 (msg:"Admin-Rule2 !53 dns Query"; dns_query; sid:9900204; rev:2;)
-
Nope.. none of them work unfortunately.
Imported successfully, can see the rules if I search for their ids.. but no alerts, no drops, dig works...
Stuff are getting blocked from the same machine, alerts are coming in, so IPS is up & running.
# dig google.com @208.67.220.220 -p 5353
; <<>> DiG 9.10.3 <<>> google.com @208.67.220.220
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41222
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 129 IN A 216.58.214.206
;; Query time: 30 msec
;; SERVER: 208.67.220.220#53(208.67.220.220)
;; WHEN: Mon Feb 19 16:07:38 EET 2018
;; MSG SIZE rcvd: 55
-
hmm... what about if you add the test domain:
drop dns $HOME_NET any -> $EXTERNAL_NET !53 (msg:"Admin-Rule2 !53 dns Query"; dns_query; content:"google"; nocase; sid:9900204; rev:2;)
p.s.
I hope it is not answer from local dns cache...
-
Nope... still doesn't work.
I'm fairly certain I didn't hit the cache and the query was forwarded, tried (also with the "content:" set as well, to match the rule) to dig for nonexistent random domains. They were not resolved of course but I got a response from the remote DNS server.
-
Nu mai am alte idei... sorry.
I am testing this one on Suricata 4.0.0 under diff firewall fork and I get hit on this rules.
-
Nici eu nu mai am idei :)
OPNsense uses 4.0.3, but 4.0.4 is out and maybe they'll work when it's upgraded.
Could also be a misconfig in the implementation, I'll try some more debugging later.
Thank you!
-
More tests:
I have in firewall General Setup as DNS servers:
208.67.222.222
208.67.220.220
If testing on this DNS server, traffic on any port will not be blocked as they are part of HomeNet -> alert it is triggered with few variation of dns rules.
Using Unbound Resolver with Enable DNSSEC Support -> Suricata will not see traffic from Unbound... dns traffic encrypted !?
with Unbound Resolver active testing on other DNS server ( dig .... @91.239.100.100 -p 5353 ) with few variation of dns rules and NO triggered alert so I have to admit rules are not working properly for me also and I discarded them.
-
I don't use these servers but I also have DNSSEC enabled.
I guess I'll just block 5353 altogether. Not ideal but more than nothing...
Thank you for your followup :)
-
I use 2 custom rules which works for me with UDP
pass udp $EXTERNAL_NET [53,123] -> $HOME_NET any (msg:"time-dns"; sid:9900008; rev:1;)
drop udp $EXTERNAL_NET [1:65535] -> $HOME_NET [1:65535] (msg:"Golden Rule UDP"; classtype:bad-unknown; sid:9900013; rev:1;)
Using [1:65535] instead of 'all' allows port 0 udp to pass.
-
Ar you using this policy in corporate or home environment ?
Because basically you are blocking all UDP traffic ( except DNS, NTP ), did you block UDP traffic in firewall rules also?
-
This particular OPNsense box is in a corporate environment with mostly servers, no DNS servers, and a couple of workstations. I did not need any specific port 53 or 123 firewall rules. All the legit UDP traffic is on the internal networks. And the GeoIP and RBL firewall blocks take care of the port 53 traffic that I do not want.
The other option is to use this pass rule instead:
pass udp [8.8.8.8,8.8.4.4] [53,123] -> $HOME_NET any (msg:"DNS OK"; sid:9900009; rev:1;)
But that would require you to add in all the legit DNS and NTP IP's
If you do use the rules I posted above, just watch the alerts to see if any legit UDP traffic is blocked. I had to add one port that I did not show for a VPN tunnel that I use.
Of course no one rule will work for everybody. I just try to give ideas to people as to how powerful IPS can be by stopping unwanted traffic at the source.
One more point. I had to add my static CIDR range of my external IPs to my Home network. The Home network IP's are crucial when using custom global pass and drop rules in IPS.
$HOME_NET is the list of IP's that are specified in Service>Intrusion Detection>Administration>Home Networks (Advanced Mode)
$EXTERNAL_NET is any IP that is NOT in the list of $HOME_NET IP's
I am still unsure as to the legitimacy of any inbound port DNS traffic outside your ISP DNS. Almost looks to me as a backdoor way for hackers to see what IP's reply to a DNS request. Personally I receive 100-500 port 53 inbound hits an hour. Mostly from China or Scandinavia. That why I used an IPS rule to allow the inbound DNS, then take care of it in the firewall so I do not flood the IPS alerts. I wish there was a 'do not alert' command for an IPS rule.