WEBVTT 00:00:02.453 --> 00:00:03.653 As I stated earlier, 00:00:03.653 --> 00:00:07.453 Zeek uses its scripting to define and analyze policies based 00:00:07.453 --> 00:00:10.453 on events that it's seen in the network. 00:00:10.453 --> 00:00:13.153 This isn't the only way that it can detect 00:00:13.153 --> 00:00:15.453 abnormalities or threats in the network though. 00:00:15.453 --> 00:00:18.453 Similar to other intrusion detection system type tools, 00:00:18.453 --> 00:00:23.453 it can use signatures to detect threats based on the predefined signatures. 00:00:23.453 --> 00:00:27.453 Let's talk about this for a little while. 00:00:27.453 --> 00:00:31.119 The signature framework adds to Zeek's capabilities by giving us a 00:00:31.119 --> 00:00:34.453 more traditional signature analysis capability. 00:00:34.453 --> 00:00:40.453 It's by far not the most desired way to utilize Zeek, but it can be beneficial. 00:00:40.453 --> 00:00:42.739 It's still a part of the overall Zeek language and 00:00:42.739 --> 00:00:47.453 plays a part in its functionality, so that's why we're covering it here. 00:00:47.453 --> 00:00:49.453 Using the signature framework, 00:00:49.453 --> 00:00:53.119 we're able to write specific criteria for the events to 00:00:53.119 --> 00:00:56.453 match on and send messages as a result. 00:00:56.453 --> 00:00:59.453 From a security perspective, this is great. 00:00:59.453 --> 00:01:04.564 We can use this portion of Zeek more like a normal IDS and have Zeek raise an 00:01:04.564 --> 00:01:08.453 event whenever that signature that we build is matched. 00:01:08.453 --> 00:01:11.703 The nice thing about this is that we can make these signatures 00:01:11.703 --> 00:01:15.453 as simple or as complicated as we'd like. 00:01:15.453 --> 00:01:19.453 So let's take a look at this example signature that I made really quick. 00:01:19.453 --> 00:01:23.145 What it's looking for is our device is reaching out on port 00:01:23.145 --> 00:01:27.453 53 to our DMZ server handling DNS queries. 00:01:27.453 --> 00:01:33.453 I don't know why, but I love using DNS as an example for many things. 00:01:33.453 --> 00:01:37.053 It's because it's very easy to misconfigure devices or forget 00:01:37.053 --> 00:01:39.453 to program the DNS servers for some devices, 00:01:39.453 --> 00:01:42.453 so we always see activity like this. 00:01:42.453 --> 00:01:47.453 You can also write a rule to look for matches that reach out to DNS servers 00:01:47.453 --> 00:01:51.453 that aren't yours to detect this type of misconfiguration. 00:01:51.453 --> 00:01:56.453 So anyway, here I'm looking for this particular activity to match. 00:01:56.453 --> 00:02:00.453 If all of this criteria is matched, an event will be raised. 00:02:00.453 --> 00:02:04.453 If not all of them are matched, then nothing happens. 00:02:04.453 --> 00:02:04.953 Remember, 00:02:04.953 --> 00:02:08.786 these signatures are completely separate from the rest 00:02:08.786 --> 00:02:11.453 of the Zeek scripts and analysis. 00:02:11.453 --> 00:02:14.453 The signature framework uses conditions to match values, 00:02:14.453 --> 00:02:17.453 like I showed you with my example just now. 00:02:17.453 --> 00:02:21.453 There are a few different types of conditions that we can 00:02:21.453 --> 00:02:26.453 match on with a signature framework, one of which is the header condition. 00:02:26.453 --> 00:02:28.453 If you think about how a datagram is structured, 00:02:28.453 --> 00:02:32.453 at layer 3 we have our packet headers. 00:02:32.453 --> 00:02:35.453 These give us the information such as source and destination 00:02:35.453 --> 00:02:39.453 IP and the protocols that are being used. 00:02:39.453 --> 00:02:42.953 We also have the content conditions that we can tag in the 00:02:42.953 --> 00:02:45.453 signature rule that we build to give us some flexibility 00:02:45.453 --> 00:02:47.453 with what we're learning on. 00:02:47.453 --> 00:02:50.786 The content conditions use regex to match the content that 00:02:50.786 --> 00:02:53.453 we want an event to be generated with. 00:02:53.453 --> 00:02:58.998 We can match strings either in the raw payload data that we see in a packet or 00:02:58.998 --> 00:03:03.453 in an analyzer-specific content such as protocol analyzers. 00:03:03.453 --> 00:03:04.653 Using something like this, 00:03:04.653 --> 00:03:09.578 we can match against the criteria in something like HTTP request, 00:03:09.578 --> 00:03:11.453 as an example. 00:03:11.453 --> 00:03:14.953 Something cool about the signature framework is that it also allows 00:03:14.953 --> 00:03:19.653 us to define conditions matching other signatures and to flag only 00:03:19.653 --> 00:03:21.453 if it matches that other signature, 00:03:21.453 --> 00:03:24.953 these are called dependency conditions and require a 00:03:24.953 --> 00:03:28.453 signature ID to match this signature to. 00:03:28.453 --> 00:03:31.453 We can also match context conditions that use other portions of Zeek 00:03:31.453 --> 00:03:35.453 to help us compare the signature to other things. 00:03:35.453 --> 00:03:39.453 This really adds to the flexibility of not only Zeek itself, 00:03:39.453 --> 00:03:43.453 but the usefulness of the signature framework. 00:03:43.453 --> 00:03:43.897 Really quick, 00:03:43.897 --> 00:03:47.453 before we move on into the scripting that Zeek uses and dig into that language, 00:03:47.453 --> 00:03:51.453 there are two actions that are available for us to use 00:03:51.453 --> 00:03:53.453 with the Zeek signature framework. 00:03:53.453 --> 00:03:58.453 One is the event action, and the other is the enable action. 00:03:58.453 --> 00:04:01.881 The event action raises an event and takes some sort of 00:04:01.881 --> 00:04:04.053 predefined action based on that event, 00:04:04.053 --> 00:04:07.253 whether it generates a log message or does something more 00:04:07.253 --> 00:04:11.453 advanced like send an email alert via a plugin. 00:04:11.453 --> 00:04:14.453 The other action is the enable action. 00:04:14.453 --> 00:04:19.786 This gives Zeek the capability to activate a specific analyzer 00:04:19.786 --> 00:04:23.453 dynamically and as needed based upon an event. 00:04:23.453 --> 00:04:27.453 There's a lot of integration that can be done here. 00:04:27.453 --> 00:04:30.578 We're about to hop in the lab really quick to demonstrate my 00:04:30.578 --> 00:04:34.453 example of a signature rule that can be created. 00:04:34.453 --> 00:04:37.453 We're going to jump into the signature framework and show a 00:04:37.453 --> 00:04:41.253 signature I created about looking at traffic going out from our 00:04:41.253 --> 00:04:44.453 internal DNS server to our DMZ DNS server. 00:04:44.453 --> 00:04:46.453 This isn't a security risk, 00:04:46.453 --> 00:04:49.342 but it's going to help me identify how often my internal 00:04:49.342 --> 00:04:52.453 DNS needs to perform its own lookups. 00:04:52.453 --> 00:04:54.453 We'll check out the contents of the script, 00:04:54.453 --> 00:04:58.453 talk about how it works, and how to use it. 00:04:58.453 --> 00:04:58.675 Then, 00:04:58.675 --> 00:05:03.253 we'll see if we can test it out and get a message generated by my 00:05:03.253 --> 00:05:06.453 internal DNS server reaching out to that DMZ one. 00:05:06.453 --> 00:05:10.453 Let's hop in there. 00:05:10.453 --> 00:05:11.619 So now that we're in the lab, 00:05:11.619 --> 00:05:15.453 I'm going to show you the signature that I created really quick. 00:05:15.453 --> 00:05:19.271 It's super simple and you can play around with this in your lab 00:05:19.271 --> 00:05:21.453 instance and tweak the fields as you like. 00:05:21.453 --> 00:05:25.453 I have everything set up in the temp folder just for ease. 00:05:25.453 --> 00:05:28.453 As you can see, we have the DNS.sig file, 00:05:28.453 --> 00:05:30.853 which is where our signature is, 00:05:30.853 --> 00:05:33.907 and the test.pcap file that I'm going to be using to run 00:05:33.907 --> 00:05:37.453 through the signature to detect information. 00:05:37.453 --> 00:05:40.998 You can take a pcap of your own network if you want and upload it 00:05:40.998 --> 00:05:43.881 to your Zeek virtual machine on your own so you can see the 00:05:43.881 --> 00:05:46.453 signature interact with your own environment. 00:05:46.453 --> 00:05:49.453 Pulling up the signature, I have the name of it, 00:05:49.453 --> 00:05:52.453 which is also the signature ID here. 00:05:52.453 --> 00:05:56.453 I have it looking for the header field of the destination IP, 00:05:56.453 --> 00:06:00.453 and I want it to be the 10.75 address. 00:06:00.453 --> 00:06:02.453 You'll have to change this information depending on 00:06:02.453 --> 00:06:04.453 your environment setup though. 00:06:04.453 --> 00:06:08.453 Here, I have it generating an event of WrongDNS server, 00:06:08.453 --> 00:06:11.453 but we're going to change this a little bit. 00:06:11.453 --> 00:06:12.024 Using VI, 00:06:12.024 --> 00:06:16.078 I'm going to hop in and edit this signature to change the 00:06:16.078 --> 00:06:18.453 ID and event that it corresponds to. 00:06:18.453 --> 00:06:18.828 Remember, 00:06:18.828 --> 00:06:23.053 you can have multiple fields tagged here from the other header 00:06:23.053 --> 00:06:25.453 fields to regex statements looking in the payloads. 00:06:25.453 --> 00:06:29.453 I only have one header field here for simplicity. 00:06:29.453 --> 00:06:34.453 Now I'm going to save it so we can run it through the Zeek signature. 00:06:34.453 --> 00:06:37.786 I'm only invoking an instance of Zeek to run this particular 00:06:37.786 --> 00:06:41.453 pcap through the Zeek signature that I created. 00:06:41.453 --> 00:06:44.653 I'm not sticking it in the necessary folders to have it 00:06:44.653 --> 00:06:47.453 automagically alert based on the traffic seen. 00:06:47.453 --> 00:06:56.453 To be able to do this, I'm going to use the command zeek -r test.pcap -s DNS.sig, 00:06:56.453 --> 00:07:01.453 and that will ensure that we're running it through that signature rule. 00:07:01.453 --> 00:07:05.453 After that's done, we can see that we have a lot of log files here. 00:07:05.453 --> 00:07:10.453 This is because we invoked a Zeek instance from within this particular folder. 00:07:10.453 --> 00:07:13.453 When looking for signatures, by default, 00:07:13.453 --> 00:07:17.453 Zeek adds any matches to this signature.log file. 00:07:17.453 --> 00:07:20.953 It doesn't use any signatures by default with the exception of 00:07:20.953 --> 00:07:23.453 some that are built into the default scripts, 00:07:23.453 --> 00:07:27.453 so this is a customization that you'll have to do if you want this capability. 00:07:27.453 --> 00:07:31.119 This log file will be with all of the other ones in the 00:07:31.119 --> 00:07:33.453 Zeek log folder that we saw previously. 00:07:33.453 --> 00:07:37.453 So here, I'm going to pull it up, and look at that, 00:07:37.453 --> 00:07:40.453 I have four matches from the pcap. 00:07:40.453 --> 00:07:46.119 My 30.11 machine was reaching out to the 10.75 server over port 53, 00:07:46.119 --> 00:07:49.453 which is the standard DNS port. 00:07:49.453 --> 00:07:53.453 We also have the DNS server event that we had in the signature file, 00:07:53.453 --> 00:07:56.453 as well as the signature ID here. 00:07:56.453 --> 00:07:58.453 This is pretty cool. 00:07:58.453 --> 00:08:00.453 You can play around with more complex rules, 00:08:00.453 --> 00:08:05.453 inspecting payloads as well, so this is fairly robust. 00:08:05.453 --> 00:08:09.203 One thing to note though is that Zeek currently is first match 00:08:09.203 --> 00:08:12.453 wins for the header fields within the signature, 00:08:12.453 --> 00:08:15.453 so if you're looking at multiple types of header fields, 00:08:15.453 --> 00:08:20.453 let's say port number and IP, whichever one gets the first match wins. 00:08:20.453 --> 00:08:31.453 Let's move into the next clip and learn more about scripts.