Best practice: Suppressing ET POLICY DNS Update From External net

[Paul Siess]

I'm new to SO. Been running a single instance since last Thursday. I don't know how I've come this far without knowing about the product. In five days, we've uncovered several vulnerabilities and potential threats.

I'm in fine tuning mode now, try to make Squert results less noisy and hence more meaningful. I'm seeing a lot of "ET POLICY DNS Update From External net" events, always between endpoints and DNS servers on our internal network.

I currently have EXTERNAL_NET set to any. I've read some articles about changing this to !$HOME_NET, but I'm concerned about missing lateral scans/attacks.

What is the best practice?

- Suppress the event where destination is any of my DNS servers?
- Set EXTERNAL_NET to !$HOME_NET?
- Any other suggestions?

[Brian Dorr]

That’s exactly what I do, it’s easier and more accurate because you can define what is trusted. You won’t miss lateral movements, everything will be In your CONN logs, you just need to develop rules to detect connections you want to know about. Also, define your DNS Servers, unless you have external DNS that is not trusted. Hopefully that answers your question 

--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
To post to this group, send email to securit...@googlegroups.com.
Visit this group at https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.

[Paul Siess]

Thanks Brian. When you say that is what you do...which one? Suppress the event selectively, or set External_NET !$HOME_NET?

[Steven J]

If I read correctly, EXTERNAL_NET is a global variable which we can use in a Rule preface.

e.g. alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any ...

If so, then when we change the default value for this global variable, we should really look through ALL rule definition headers to ensure this value does not negatively change the way each rule is administered.

Another point worth considering is, do we have sensors that also monitor internal->internal traffic effectively or employ other IDS/IPS technology to monitor our internal traffic?  What happens if a malicious actor does slip through, does this Global setting impede our visibility into where they pivot to inside our network?

Remember,
Suppressing events in /etc/nsm/rules/threshold.conf does not prevent them from being recorded in the db, it only filters them from being displayed in Squert and Sguil. 

Thresholding also looks at only 1 of Source or Destination IP, not both.

We could use bpf to prevent things from being recorded to the db, but this too needs to be implemented in a way that isn't too over reaching.  The advantage to using bpf is we can filter these events based on a specific Source and or Destination, IP and/or Port.

We could also tweak the rule itself to accommodate our specific need, which may be preferable to making a global change that will impact many other rules in ways we aren't expecting.

Sjm

[Brian Dorr]

Steven,

 

The default value is any. So you really didn’t effect anything. By saying EXTERNAL_NET= !#HOME_NET , whatever you define under the home_net variable is trusted. For instance, I have multiple interfaces off my firewall, but they are still trusted any interfaces. If it connects to another firewall via the WAN port, which is usually untrusted, then it is a false positive. Once I changed my variable, It drastically reduced my false positives. Point being, whatever is not your HOME or Private network, i.e. coming from the Internet is untrusted, which you have effectively achieved by saying this. You can also threshold as you said, but it is worth investigating the alert because for example, anytime I update my iphone or MAC, I get an alert because it Is downloading an update file which sets of Security Onion. It is not malicious, and it will happen quite often. So, you can threshold or disable the rule. Depends on what is normal baseline traffic in your environment. Thanks for sharing a well thought out response.

 

As far as internal traffic goes, you will catch internal traffic if you have enough sensors to capture it. This is a strategic process, and it takes yo understanding how layer 2 and layer 3 works, and how traffic is routed through the network. A lot of the time, you have to place your sensors where you will get the best bang for your buck. If you are fortunate to have the budget to acquire multiple sensors than it may not be an issue, if you are not as fortunate, then it will take strategic placement and utilizing other tools in tandem such as endpoint protection where you will have to correlate data and perform analysis.

 

He didn’t say how many sensors he had, maybe if he discloses that, there is input that can be provided, but without a network map that defines the gateways and how traffic is routed, it will be difficult to advise.

 

Brian

[Wes Lambert]

Hi Paul,

You may consider using /etc/nsm/pulledpork/modifysid.conf and setting a value(s) for DNS_SERVERS in snort.conf/suricata.yaml (running rule-update after modifying modifysid.conf and restarting Snort/Suricata after making changes to the config file).

For the modify, you could replace $EXTERNAL_NET with !$DNS_SERVERS.

(ex. !$DNS_SERVERS -> $HOME_NET )

In modifysid.conf:

2009702 "\$EXTERNAL_NET" "!$DNS_SERVERS";

and the resultant rule after running rule-update should look like:

alert udp !$DNS_SERVERS any -> $HOME_NET 53 (msg:"ET POLICY DNS Update From External net"; byte_test:1,!&,128,2; byte_test:1,!&,64,2; byte_test:1,&,32,2; byte_test:1,!&,16,2; byte_test:1,&,8,2; reference:url,doc.emergingthreats.net/2009702; classtype:policy-violation; sid:2009702; rev:5; metadata:created_at 2010_07_30, updated_at 2010_07_30;)

This should be more efficient than suppressing an alert, and should only alert on non-defined DNS servers to your home net.

Thanks,

Wes

--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
To post to this group, send email to securit...@googlegroups.com.
Visit this group at https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.

--

https://twitter.com/therealwlambert

https://securityonion.net/

[Steven J]

Thank you Wes, I needed this too :-)

[Kevin Branch]

Just to clarify, each "suppress" line in threshold conf completely prevents a certain rule from firing when a given source/destination IP/subnet is involved.  Alerts suppressed this way are not written to any db.  Besides specifying a by_src or by_dst IP address you can alternatively specify a source or destination network to in your suppress line.

In cases where you need to suppress a rule based on a combination of both source and destination IP/subnet, that is when I generally build a pass rule in /etc/nsm/rules/local.rules.  If I just have several by_src IPs or by_dst IPs to specify I usually copy and paste the suppress line for each individual IP gets its own line.

Kevin

[Brian Dorr]

Wes,

That would not hit if a client request is made to the DNS server. It would only trigger if the Specified DNS Server made a request to itself or home net. I would tune the rule from anything on HOME_NET not querying the $DNS_SERVERS and if there is a DMZ an additional rule for the Internal DNS_SERVERS not querying the specified upstream servers. This will help identify anomalies in DNS request and assist with further rule tuning. I do agree with specifying your actual DNS_SERVERS along with the suggested EXTERNAL_NET= !HOME_NET Which reduces a lot of false positives for more specific rule tuning. Correct me if wrong 

[Steven J]

Brian, do we care more about our users polling a DNS IP we've included in $DNS_SERVERS, or our users getting a response

 from an IP that isn't?

[Brian Dorr]

I do care about dns queries not being sent to the dns server, but I also care about replies as well. I wouldn’t take away what you suggested, just add to.

If it wasn’t recieved that way I apologize. Just adding to 

[Brian Dorr]

I see why, I suggested a change to the rule, I meant add what I was suggesting in addition, that’s my fault

[Steven J]

alert udp !$DNS_SERVERS any -> $HOME_NET 53

to me says,
if udp traffic comes in from any IP not on the trusted_dns_list on any port,

going to any Internal IP on port 53,

treat it as potentially untrusted ingress dns traffic.

My prior post thinks that a user making a dns request isn't in itself a security risk, though in proper context it could be an additional ioc.

However, receiving a DNS response from an IP not listed as a trusted DNS server would be worth a look.

[Brian Dorr]

Yes but what if the client is querying something other than the DNS server to begin with? If it is, something is wrong with that because all hosts should be pointed to the dns servers which may indicate just like your rule in the same sense dns poisoning. It would also tell you if someone is trying to bypass your dns servers as well. 

[Paul Siess]

Thanks Wes. I took your suggestion and reversed it. I was getting false positives when endpoints on HOME_NET sent DNS updates to DNS servers on HOME_NET. So, I changed the entry in modifysid.conf to:

2009702 "\$HOME_NET" "!$DNS_SERVERS";

That has successfully filtered out the valid DNS update traffic between clients and DNS servers.