Welcome back.
We've spent the entire course building up our Zeek scripting
knowledge, and now it's time to put it all together.
In the previous module,
we went over some basic tuning and optimization practices that we can
use to help customize the tool for your environment.
In this one, we'll build a script to detect large file downloads to help
us identify potential data hoarding concerns. Before we get into the lab
and check out the script to build and test,
there's a few additional resources and bits of information that's very
useful in order to help you build your own scripts,
the first of which is the Zeek blog.
They have some interesting articles and resources in there and
give nice hints about some of the best practices.
For example, this post here tells us the seven dos and don'ts for scripting.
It mentions things like creating your own namespace and making sure that
you're explicit in your intentions. Check this out and see if there's
anything in here that helps you in your endeavors.
The next resource is a tool that was built in order to teach scripting.
It's here at the address try.zeke.org and even gives you a demo
environment to practice running scripts on.
Now that I mention it,
I could've taught almost the entire course from within here.
Well, maybe not the whole thing,
but it's a really good tool that helps explain the basics
of scripting and shows you real examples of how to use the
different aspects of it all.
The script reference, again, is the go‑to resource.
It's awesome in the sense that it explains so much about the Zeek
scripting engine and how it processes information.
I refer to it all the time when I'm building Zeek scripts. On top of
that, use the Zeek system as a reference as well.
Look at the protocol scripts to see how the events are processed and handled.
Look at the BiFs to see what you can use and how. Look at the
built‑in policy scripts for ideas on how to handle certain tasks or
events. Use what's already here and available.
Remember the three different script sections that we had
talked about previously in the course?
Well,
we're going to be highlighting those again in the
coming demo to finish up the course.
We have the three different sections, the base level,
the second indentation level using export, and the
third level with the event handlers.
These three sections are all going to come together to
give your script its full functionality.
In preparation for this demo, let's go over what the use case is.
Kat and Chris needed to identify a way to track large HTTP
connections with customizable thresholds for the connection time
and the size of the data transferred.
This will help them identify any large transfers that occur in their
environment for potential investigation and correlation with other
events that could indicate malicious activity.
The use of the HTTP protocol can also be interchanged with other
protocols to track large data transfers over SSH,
FTP, and other protocols, so the script can help with those as well.
This is going to be a relatively small script,
but effective in helping them track the conversations
that involve large amounts of data.