In this demo,
I will show you how to create a DNS baseline that can
be used for continuous monitoring.
We will start by looking at a few of the available Zeek
DNS fields in the Globomantics dataset.
Then,
we will move into creating a baseline of authorized DNS servers and domains.
I will use the Watcher service to create two alerts.
The first will be for detecting unauthorized Globomantics subdomains,
and the second will be an alert for systems using unapproved DNS servers.
In the last part of the demo,
I will show you the type of data returned when an alert is triggered.
Let's head to the Kibana web UI.
Okay, so we're back in Kibana.
Let's take a look at a few of the interesting DNS fields available to us.
I've already filtered the data using the DNS log.
This is a good best practice,
so you're only looking at the relevant portions of the data as you work.
You also get the added benefit of using less CPU resources.
If I select the dns.question.registered_domain field,
we can get an idea of the top five domains and the volume in the dataset.
Next up, we have the dns.question.subdomain field,
and that will give us similar information,
but from the subdomain perspective.
We will be using this field later in this lesson to
baseline the Globomantics subdomains.
Before we move on, I'm going to scope the data to only the Globomantics subnet,
and then we will look at the destination IP field,
which represents the DNS server being used to answer queries.
It will show us the distribution and top values present in the dataset.
The IP address that you see here should be well known and documented.
If they are not,
then I would recommend doing some research to identify
why a third party DNS server is in use.
Now, we need to pivot to a visualization and then format the data into a table,
so we can see all the values.
Remember,
you can always export the list as a CSV and then use that as a
baseline once they have all been verified.
I do want to take a moment to highlight that in this list,
there are two IP addresses that are not DNS servers.
You may see a similar situation on your own network.
The 192.168.28.255 should stand out to any network tech as a broadcast address.
So, can you guess why this would show up in the list?
I'll let you think about that for a few seconds.
The other odd IP address in this list is 192.168.27.31
from the Globomantics user subnet.
The subnet mask is a /27, so that would make the .31 also a broadcast address.
If you figured it out already, great job.
For anyone else, this is the result of a NetBIOS DNS lookup.
I wouldn't add these to the asset list of DNS servers,
but I would document it,
so anyone else looking at the data will quickly understand what is happening.
We now have our DNS baseline of three servers and those should be the
only servers servicing DNS requests on our network.
I'm going to switch back to the Discover view,
and we will look at the subdomains under globomantics.com.
I have already populated the search so that it filters out
everything except for the domain we need.
If we follow the same procedure we did with the DNS servers,
we can visualize the DNS question subdomain field and
change the default chart into a data table.
This list is significantly longer and would benefit from the CSV export.
You would take that list and validate it against your asset list,
and once validated, it can be used to detect when new subdomains are introduced.
Part of the change management process should be to update this baseline.
Okay, let's roll up our sleeves and jump into the Dev Tools once again.
I will show you my approach to creating the Watcher alert.
The first thing I do is to create a valid search that
achieves the goals I want from the alert.
Once I know the search works,
I just copy and paste it into the body of the Watcher configuration.
What you see on the screen is a search that looks for queries that do
not contain a documented DNS server or IP exception,
such as the broadcast address.
The latter portion of the config eliminates the upstream
DNS server queries and a test system.
I will execute the search multiple times to show how I confirm that I
have included all the DNS servers in my baseline.
I'm looking for the contents of the destination IP and
then updating the corresponding value.
Keep in mind I'm only showing you this way so you can see the process,
but you would just add all the IP addresses at one time.
If all of this is a bit overwhelming,
Elasticsearch documentation is free and highly recommended.
You should also have a copy of all the Watcher
configurations in the course assets.
If not,
you can always reach out to me via email or Twitter and I can send you a copy.
All right,
here is the completed search, and notice there are no longer any results.
Now we can copy it to the body of a Watcher config.
The process is the same as we did back in the SSL certificate
alerts. We create a watch name and then send it to the Watcher API.
Then we must tell Watcher to execute it.
The interval and throttle can be adjusted after testing.
When the Watcher alert is executed,
you get immediate feedback. Notice that the
execution state is currently not needed.
This is because there are no DNS servers in the dataset
that violate the policy we have in place.
If a system on the network was misconfigured in the future or malicious
software tried to use a third party DNS in order to avoid login,
then this alert would trigger. I'm going to jump into one of the
Globomantics servers and use a DNS tool that will allow me to trigger this
alert, and then we will look at the data it produces.
I'm currently remotely connected to one of the Globomantics systems in
the server subnet. There is a Watcher alert created to detect the use of
any DNS server that is not in our baseline.
I will use a DNS tool called dig to query www.globomantics.com, using
one of the well known google public DNS servers.
Then we will go back to Kibana Dev Tools UI and see if the alert triggered.
Let's check on the status of our Watcher alert.
Keep an eye on the execution state. Awesome.
It appears the test was successful.
The security team should have an email in their inbox with
the IP address of the offending DNS server.
The Zeek DNS logs will also have the system I used to make the DNS request,
which is good news for defenders.
Okay, now if I execute the watch again, we can take a
look at the data from the alert.
We can also search using Kibana, but this way is more exciting.
I'm going to scroll through the results looking for the destination IP.
Remember, clients send their DNS requests to a DNS server, so our test
case should show the DNS IP we used in the destination field. Just a
little bit further, and voila, there it is.
We have confirmed our alert works as advertised.
If you decide to remove the Watcher alert,
you can use the deactivate API call and the
appropriate Watcher name that was created.
I will wrap up this lesson by showing you the completed alert for
monitoring Globomantics subdomains for unauthorized additions.
By now, you've most likely noticed that there is a general template to the
Watcher alerts, and the portion that changes is the search input. In this
Watcher search, I am only looking at the queries in the dataset that have
globomantics.com as the parent domain.
I have placed a few subdomains here as an example,
but if you remember from earlier,
there were about 11,000 subdomains when I did the visualization. The
reason for that will be covered in the next module.