WEBVTT

00:00:01.370 --> 00:00:03.050
[Autogenerated] Welcome back to the course.

00:00:03.540 --> 00:00:08.510
In the previous module we covered a few of the basic ways that we can expand

00:00:08.510 --> 00:00:12.450
snorts capabilities through plugins integrations and add ons.

00:00:13.020 --> 00:00:16.660
We'll take that all a step further in this module and discuss

00:00:16.660 --> 00:00:20.420
some nuances around visualizing the data as well as optimizing

00:00:20.420 --> 00:00:24.660
snort to start this conversation off.

00:00:24.680 --> 00:00:27.740
The first pieces that allow us to really customize and

00:00:27.740 --> 00:00:30.140
expand Snort is the output module.

00:00:31.290 --> 00:00:36.470
This module gives us the ability to well output the data in some way.

00:00:37.530 --> 00:00:39.510
Using the various modules here,

00:00:39.870 --> 00:00:45.150
we can customize the formatting of the alerts and logs generated by the tool.

00:00:46.380 --> 00:00:49.610
This occurs after the pre processors and detection engines

00:00:49.620 --> 00:00:54.560
work their magic as you can see here there are several

00:00:54.560 --> 00:00:56.560
different modules available for this.

00:00:57.260 --> 00:01:01.610
We have the ability to generate syslog output writing alerts to a

00:01:01.610 --> 00:01:06.200
file either fully or using the fast method TCP dump,

00:01:06.390 --> 00:01:08.330
CSV and a few more.

00:01:09.390 --> 00:01:12.440
Let's take a look at the syslog alerting for snort really quick

00:01:13.060 --> 00:01:17.500
like typical syslog you can customize the logging facility code

00:01:17.590 --> 00:01:19.670
and priority for the log messages.

00:01:20.310 --> 00:01:24.070
Here's an example of how to configure this Here.

00:01:24.270 --> 00:01:27.750
We have an alert configuration to send the syslog to our

00:01:27.750 --> 00:01:32.310
elastic stack over ports 30 35 14 that's it.

00:01:32.930 --> 00:01:36.640
As you can see we're calling the output module for alert.

00:01:36.650 --> 00:01:43.230
Underscore syslog so snore knows which one to spin up the alert fast and alert.

00:01:43.230 --> 00:01:46.720
Full modules give you the ability to control how much data

00:01:46.720 --> 00:01:49.180
is logged and how efficiently as well.

00:01:50.300 --> 00:01:53.280
The fast option doesn't write the full packet header

00:01:53.670 --> 00:01:57.110
and it only writes to one file, making it more efficient.

00:01:58.140 --> 00:02:01.120
The full alert module does in fact write the full

00:02:01.120 --> 00:02:03.890
packet headers using this method,

00:02:03.950 --> 00:02:07.160
Snort may have a performance impact unless using it with

00:02:07.160 --> 00:02:11.110
extremely light traffic but with this you get a lot of

00:02:11.120 --> 00:02:13.280
extra information in your alerts.

00:02:13.770 --> 00:02:15.040
It's a tough balance.

00:02:15.950 --> 00:02:17.680
Once you get the output set up,

00:02:17.690 --> 00:02:22.900
you can ingest the data into a sim or other tool without any normalization,

00:02:22.910 --> 00:02:26.160
like using log stash filters to add and modify fields.

00:02:26.390 --> 00:02:30.290
Your data might not align with the sims data standards.

00:02:30.510 --> 00:02:33.130
Normalization is crucial however,

00:02:33.130 --> 00:02:36.410
you decide to do So here's an example of a general

00:02:36.410 --> 00:02:38.140
search for the data from Snort,

00:02:38.350 --> 00:02:43.120
as you can see the fields give us a lot of information for brevity.

00:02:43.130 --> 00:02:47.190
You can't see them all, but we'll explore those in a real time in a little bit.

00:02:47.950 --> 00:02:51.680
We can also see and control the fields in the way they're presented

00:02:51.680 --> 00:02:56.320
from within Kibana this is a nice feature in the index pattern that

00:02:56.320 --> 00:02:58.620
expands the usage of the Snort data.

00:02:59.150 --> 00:03:03.080
You can modify the format and the labels for each one within here.

00:03:03.440 --> 00:03:08.460
So they align with the use cases that you're needing the data for for example,

00:03:08.670 --> 00:03:13.460
if our geolocation services were based on destination dot IP but we had

00:03:13.460 --> 00:03:15.660
an event come in with a different field name for it,

00:03:16.190 --> 00:03:18.080
then we would want to rename that field