All right, it's time to hop into the lab for our first demo of the course.
In this one,
we're going to practice writing some network traffic signatures and
then detail each of the components of them to identify what we're
trying to do and how we can accomplish it.
Then we'll validate them and see what the outputs look like when we get a match.
All right, and here we are into the lab,
or in my Zeek environment, and remember,
this course assumes that you have a basic
understanding of Zeek and Zeek control.
So if you don't, please check out my course,
Getting Started with Zeek or check out the Zeek documentation to be
able to install it and get it configured and get it up and running
so you can follow along in this demo.
So what we want to do here is create two signatures to help us
ensure that we can detect specific network traffic,
and these signatures are going to be pretty basic.
So the first thing that we're going to do is
navigate to my local site directory,
and we're going to hang out here for a little while.
Now, as you can see,
I have some logs in here with two signatures already created.
So we're going to look at this telnet.sig first and break it down,
and then we'll go into the http.sig and detail that as well.
So if we're looking at this telnet.sig,
we have a signature statement saying that this is the signature that follows,
and then we have the name of the actual signature,
which is just telnet.
Now, as you can see here, I'm using a couple of the header conditions,
so we have the IP protocol, which is going to be TCP,
and then the destination port, which is 23.
These are the only conditions that I'm using in this particular signature.
And this is just a simple detection for saying,
hey, anybody that is using telnet, let's generate a notification.
And so this event right here is what's telling Zeek what this
signature's going to do after it matches.
So in this case we're going to raise an event,
and the message of the event's going to ask why are you even doing this?
Now you can have this as anything.
You can say telnet protocol detected,
or you can have instructions on what the SOC analyst might
have to do in this situation or who to contact in the event
something like this happens.
We can put any sort of string in here,
and we'll show you in the next clip where this gets raised and where we
can look in order to see the event actually happening.
So very basic signature, IP protocol, destination port, and that's it.
Now let's exit this one and go into the HTTP one.
And now that we're in here, as you can see,
we have the two header conditions as well.
We have the IP protocol, which is TCP again,
and the destination port, which is port 80.
But now we have a payload in here as well,
and this payload condition is actually a content condition.
So we're using regex here to look at the payload of the HTTP request,
and we're looking for anything that has the database in there.
And so if we're talking about trying to detect certain signatures,
this is an example of potentially protecting critical asset data.
So if we have a server in here that we're trying to
protect with critical data on it,
maybe we want to make sure that nobody tries to web
into a database or anything like that.
Now hopefully the databases wouldn't be available via HTTP,
but this is just an example of this kind of detection.
So we're looking inside of the payload at the URI itself,
and if anything says database in that string,
then it's going to raise this event.
And to make it even more specific, let's say this is on our server 30.11.
So, what we'll do is, we'll do the destination IP here and make it 30.11,
not 30.7.
All right, and now that that's created, we should be good to save this.
Now when we're talking about the HTTP analyzer and conditions surrounding that,
we can have different HTTP types in the mix.
So we can look at specific request types like GET or POST,
we can look at HTTP responses or actual requests,
and stuff like that.
So there's a lot of capabilities in analyzing HTTP within Zeek.
For here, we're just going to use the payload.
Let's save this and exit it.
Now to actually activate these, we need to modify our local script,
and we're not going to go into the details of the actual script itself yet,
but we'll add a couple fields here just to make sure that the signature works.
So next we're going to nano that local.zeek file,
and this is our local site script.
I'm going to scroll down to the bottom. I like loading my new packages
and everything at the bottom. That way it just breaks it away from the
built‑in stuff that Zeek comes with.
So let's comment this and say this is for Globomantics
custom signatures. Keep it standardized.
All right, now we have to load two scripts or import them into this script in
order to be able to activate the signatures that we just did.
And those two are the notice framework and the signatures framework scripts.
The notice framework import allows us to be able to use it for notifications
and stuff like that, and we'll cover that in the next module.
This main signatures one is a script that Zeek comes with
that allows us to use its built‑in capabilities for the
notice framework for signatures.
So once the signature triggers, this main signatures script is going to
tell it to send to the notice framework and log the match.
Now we actually have to load our signatures themselves, and we do
this by using the load‑sigs command in here.
These scripts can be very customized,
remember. The signatures can be customized, and you can use
combinations of them to make this system really robust.
And these are just those two basic signatures that we used, but
combining them with the rest of Zeek's frameworks can really help us use
these signature‑based IDS capabilities alongside of all of other Zeek's
behavioral and analysis capabilities.
All right, now that this is saved,
what we have to do next is just go ahead and deploy it. And
in the next clip, we'll test it out and validate that it's
actually working as expected.
So to deploy it,
we're going to use the Zeek control command deploy, (Working) and there we
go. As you can see, the signature name was the error.
So modifying that allowed Zeek to actually deploy the new
configurations and get the signatures going.