Time
1 hour 24 minutes
Difficulty
Beginner
CEU/CPE
1

Video Description

In this final segment, we look at another central Zeek component, the attribute. Attributes provide built-in features that, like directives, declarations and types, make some of the more complex network traffic analysis tasks possible in Zeek. At the conclusion of this segment you will have a new, foundational understanding of many of Zeek's core concepts and a head-start on becoming more proficient with the software.

Video Transcription

00:00
in this section, I'm going to dive a little deeper in the attributes and bro and how and why they're used.
00:07
Many of the topics we discussed during this course involved attributes in some way or another.
00:12
In the prologue section, we talked about the log attributes, and I've mentioned the read F attributes on multiple occasions.
00:18
In addition to those two, there are 19 other attributes made available by Bro,
00:23
and this segment will review a few of the commonly used in more detail
00:28
attributes. Air specified. When variables Constance and types are declared,
00:32
it could be used to enable and configure options that are supported by various components of the language. For example, handlers, containers and records all have attributes specific to those types.
00:44
The 1st 2 attributes shown here applied of Variables and Constance when they're declared.
00:49
These attributes essentially set flags on those variables that tell bro that they should receive some special handling.
00:56
We've discussed the Read F attributes many times in this course.
00:59
This attribute is required in order for the reader declaration to be used.
01:03
Variables and Constance, with the read F Attributes set, are meant to make aspects of a script user manageable.
01:08
In other words, they exposed settings and values that can be tweaked by a bro user
01:14
without having them modify the script directly.
01:18
The synchronized attribute also applies to Variables and Constance, but specifically effects whether or not these values air sink across. Cluster notes
01:26
using the synchronized attributes Bruno's to copy changes to a variable toe. Other notes in the cluster.
01:32
This enables features like one work of becoming aware of traffic analyzed by other workers.
01:38
This functionality is vital to being able to reconstruct network and attack activity that is inspected by more than one cluster. Note.
01:45
The proxy note handles the responsibility of synchronizing these values among cluster members.
01:51
The priority attributes only applies to hook and event handlers
01:55
as discussed in the event segment, this attribute influences the execution order of handlers.
02:00
Priority Value is assigned imager and typically falls in the range of negative 10 through positive 10.
02:05
Although that's not a hard minimum or maximum,
02:08
the higher the priority number there earlier. The execution priority.
02:13
When writing grow shrimp, you should be aware of the priority of other handlers for events you're working with,
02:17
in particular, if you're using a value that is populated by a higher priority handler.
02:23
Connection State Removed is an example of an event that has many handlers.
02:28
Some of its lower priority handlers actually work with values in the connection record that are populated by higher priority handlers.
02:36
When you're working with the record argument, oven event in a field value hasn't been populated, but you think it should have been
02:43
try a lower priority handler. It's very possible the value you need just hasn't been set yet.
02:51
Now I'll describe a few of the attributes that affect the behavior of fields of a record type.
02:55
As I mentioned previously, records are often used as a container of information that describes a network event such as a TCP connection http Client server exchange or D. N s transaction
03:07
for protocol fields and other metadata that may be missing from the exchange
03:13
record field support The optional attributes.
03:16
The optional attribute tells Bro that a specified record field can be empty when the record instances created.
03:23
An example. Is the http refer field of the http info record.
03:29
The refer field is not always guaranteed to be included in a Web request.
03:34
In these situations, bro won't throw in error if it's not populated and will simply omit the refer field value from a log event if it's missing.
03:43
The default attributes is an alternative to the optional attributes.
03:46
Setting the default attributes allows you to specify a value the field will be initialized with in every instance.
03:53
Unlike optional field, with the default attributes is guaranteed to have a value, but that value can be overwritten or changed later.
04:00
Common use for default is numeric fields that contain account or length value that describes a network transaction in some way.
04:08
An example is the request body length and response body length fields of the http info record.
04:15
Both of these fields habit of fault value of zero, which is assumed until bro learns otherwise.
04:20
The last record field attributes I want to mention is law.
04:25
The log attributes determines which record field will be included in the log stream if the record is provided to the logging frame, where
04:31
every field that shows up in bro logs has the log attributes set when it's declared.
04:36
If you're ever wondering why I feel it is missing from a long stream,
04:40
check the presence of the log attributes first
04:44
for a final example, I'm going to revisit the http monitoring use case
04:49
in this example, let's say I've shifted my attention to monitoring my internal Web clients.
04:54
Specifically, I want to look for signs of compromise or the use of unauthorized software.
04:59
And one way to do that is to look for changes in the user agent string and used by each host.
05:03
There are a lot of reasons that this could happen,
05:06
including a user having and using more than one Web browser.
05:11
But with some quick review, an analyst can determine if this change in user agent string is something that needs to be looked into. Further
05:18
broke provides a several mechanisms to make such a task possible, and I'll use some of the attributes and features I've discussed to illustrate one way to solve this problem
05:28
at a high level. I want to create a table that tracks user agents used by each one of my monitored internal hosts.
05:34
In the event I see a new user agent, I wanna add that user agent to my running list and love the event to a separate log file just for tracking these events
05:45
to get started, I'll use the module declaration to specify a new name, Space for my script.
05:50
Next, the Export Declaration.
05:54
Within my export block, I'm gonna use the read F Declaration to add my log i d to Bro's list of law guides.
06:00
This statement uses a global log variable that is automatically created by Bro and adds that to the idea Nam declared by the log module.
06:09
Next, I declare the table I would use to track the I P addresses and their user agent strings.
06:14
As you can see here, this will be a table where the keys are ADDers
06:17
and the value or yield is a set of strings
06:21
to allow me to immediately work with my table inside of the vent handlers. I'll include the curly braces here to initialize. This table is empty.
06:30
I've also defined two attributes for this table container that had discussed earlier in the segment.
06:36
The first create expire is set toe one day, and this means bro will remove I P addresses. I added this table after 24 hours.
06:45
The second attributes synchronized is another. We've just seen
06:48
this tale tells Bro to synchronize changes to this table across the cluster nodes. Most importantly, the workers manager and longer.
06:58
Next, I need to define the info record I'll use to write entries to the log file,
07:02
since this law extreme is for a special purpose on include some field that will help me determine if the user agent change is something that needs to be investigated. More
07:12
specifically, I'll include the T S u I. D of the connection where I saw the change,
07:16
the originating host for which I'm tracking the changes.
07:20
The Web host you are I as well as the new user Agent String I observed. And also I'll include a running count of how many user agents strings I've seen for this particular host.
07:31
As I've mentioned previously, it's critical that I include the log attributes for all of the fields I want to include in the log stream.
07:39
As you can see here, I've also included the optional attributes for the fields on my info record,
07:44
just in case I run into instances where a field isn't available when I create the record. Instance.
07:49
It's not totally necessary in this case, but it's a good practice to get into
07:54
the final step in the export block is to declare a global event that will be executed every time an event has written to this log file.
08:01
This is the exact same thing as the log http event that we've seen multiple times throughout the course.
08:07
Next, I've declared a new event handler for the bro underscore And Net event,
08:11
as you might have expected, this is well, actually create the law. Extreme.
08:15
As shown here, I passed the log i d and an inline nameless record. Instance that log modules create stream function.
08:22
The final step is to handle the log http event
08:26
from the http and module and grab the data. We need to track and log these events to the file,
08:31
bro. Generates the log. Http. Event Every time it writes in new transaction to the http log stream,
08:39
I can use a handler for this event to grab the information I need from a given web request
08:45
inside my handler here for simplicity and clarity, I've declared a local variable called a ridge underscore H that contains the adder fromthe connections originator I p address.
08:56
Next, I'll start an if statement which contains two condition ALS.
08:58
The first is a call to is local adder function of the site module
09:03
to see if the originating host I P address is a local address or not.
09:07
The second conditional
09:09
checks to make sure the user agent field has been initialized in the record instance
09:15
inside of the if statements body have to find another if statement, to check to see if the originating host is not in my table already.
09:22
If it's not, I add it, using the assignment operator the equal sign and create an empty set container.
09:28
Next, I add the new user agent value to the set.
09:33
The other possible condition is that the I P address has already been added to my table.
09:37
And if that's the case, then I want to know if I've already seen the user Agent string before.
09:41
I do this again by using the knot in operator
09:46
if the user agent string is not in the list. I used the ad statement to add the new value to the container,
09:52
and it called tow law, right to write the entry to the Lok file
09:56
using calls. The law right function, as I've done here, will ensure that I love every time the user agent string is discovered for a given host
10:03
by including the user agent count in the log event. I can watch the list for each host grow over time
10:11
to find the number of user agent strings in the list. I simply used the double pipe operator to measure the length of the set as shown here,
10:18
and that's it. Now when I run, this script broke produces a long stream containing entries. For each time my script discovers a new user agent string for each of the I P addresses I'm monitoring in my environment.
10:31
The expected behaviour is that this script will write a bunch of log entries early on as it discovers what each host is using.
10:37
But eventually it'll create a baseline of sorts, and changes to that baseline are often indicators of more significant activity taking place, and they should be looked into further.
10:48
Now I'll summarize what we covered in this section.
10:52
I mentioned several types of attributes provided by the Bro programming language and broke those down into four categories variable and constant attributes, Handler attributes, record field attributes and container attributes.
11:05
I described how the read F attributes can be used to control if variables and Constance can be modified by other scripts.
11:13
Synchronized, on the other hand, tells Bro to copy changes to specified variables.
11:18
Two other nodes in the cluster, ensuring all nodes. Maintain an update copy of the data.
11:22
Next, I discussed several attributes related to record fields.
11:26
Optional determines whether or not a field is required when instances initialized
11:31
default sets a built in initialization value for a given field and Log tells bro that it should include the specified field in the log stream.
11:41
Bro also has attributes for determining how long elements remain in its container types,
11:46
most notably it sets and tables.
11:48
These attributes create
11:50
right and read expire. All provide functionality around managing how long values remain in a container.
11:56
Bro handles the heavy lifting of removing elements from these containers, based on which of these attributes to use and how long of an interval you specify as an argument.
12:07
In our final example, I demonstrated the use of several of these attributes and other language features in a custom script that creates a new law extreme to track the discovery of new user agent strings in use by host on the network and for your reference, I've provided a link to the script in the resource is section

Intro to Zeek Scripting with Bricata

The goal of this course is to provide you with an introduction to Zeek (formerly Bro) the application and the programming language. While the logs Zeek produces natively can be extremely useful, its full value is realized through its scripting interface.

Instructed By

Instructor Profile Image
Bricata
Instructor
Instructor Profile Image
Adam Pumphrey
CEO and Principal Consultant at Nimbus LLC
Instructor