WEBVTT

00:00:00.420 --> 00:00:00.830
[Autogenerated] Yeah.

00:00:01.520 --> 00:00:05.390
So first up is the HTTP inspect pre processor.

00:00:06.190 --> 00:00:10.150
This pre processor is a really useful one that helps us understand

00:00:10.160 --> 00:00:14.650
all of the http and https traffic that snort sees.

00:00:15.450 --> 00:00:18.830
This inspector is crucial to snorts functionality around detecting

00:00:18.830 --> 00:00:21.390
potentially malicious traffic from these streams.

00:00:22.460 --> 00:00:26.290
This inspector is able to detect many pieces of the

00:00:26.300 --> 00:00:31.190
HTTP message including headers, trailers and the request line.

00:00:32.220 --> 00:00:35.900
Each of these sections allows you to see and understand a

00:00:35.900 --> 00:00:37.680
different part of the conversation.

00:00:38.690 --> 00:00:40.890
For example, this can detect the U.

00:00:40.890 --> 00:00:40.970
R.

00:00:40.970 --> 00:00:41.440
I.

00:00:41.580 --> 00:00:45.370
Or uniform resource indicator from the information within the packets.

00:00:45.940 --> 00:00:49.170
This is helpful to snort operations not only because it

00:00:49.180 --> 00:00:53.060
increases the visibility but because it allows you to write

00:00:53.060 --> 00:00:55.430
rules specifically for this data.

00:00:55.430 --> 00:00:56.330
As an example,

00:00:57.050 --> 00:01:00.730
this pre processor helps to normalize the header fields as well

00:01:01.370 --> 00:01:05.099
except for the TCP ports when it comes to the U.

00:01:05.099 --> 00:01:05.180
R.

00:01:05.180 --> 00:01:05.650
I.

00:01:05.770 --> 00:01:09.890
There are four different types that it can detect and can dissect

00:01:09.900 --> 00:01:12.340
them to provide information like the ports,

00:01:12.670 --> 00:01:17.320
the scheme, the host and the query using this.

00:01:17.330 --> 00:01:20.630
You can alert on a few sections of the HTTP message.

00:01:21.360 --> 00:01:23.930
You can do things like control the amount of bytes that

00:01:23.930 --> 00:01:27.900
are red and processed from the bodies, customize how you decode the U.

00:01:27.900 --> 00:01:27.990
R.

00:01:27.990 --> 00:01:32.390
I and use javascript for detection and normalization.

00:01:33.330 --> 00:01:38.400
There's many rules that are available to make use of this H G D p pre processor.

00:01:39.190 --> 00:01:44.300
If you want to explore them, check out did 1 19 and explore some of these rules.

00:01:44.310 --> 00:01:46.410
Here's a few examples of them.

00:01:46.460 --> 00:01:47.620
1 19.

00:01:47.620 --> 00:01:53.940
Kotlin 19 is analyzing the http header for a length that exceeds 40 96.

00:01:53.940 --> 00:01:57.510
bytes 1 1933 detects when the U.

00:01:57.510 --> 00:01:57.590
R.

00:01:57.590 --> 00:02:01.960
I may be malformed due to a space that's not encoded properly in it.

00:02:03.160 --> 00:02:07.590
And another example here is when an inspect header is sent

00:02:07.590 --> 00:02:09.910
without an actual message body attached.

00:02:10.259 --> 00:02:14.590
All of these make use of this pre processors analysis of the data and

00:02:14.590 --> 00:02:19.520
its ability to dissect those sections take a look at the options for

00:02:19.520 --> 00:02:23.820
the http inspect pre processor using the differences between the

00:02:23.820 --> 00:02:27.710
balance security and connectivity default policy and the connectivity

00:02:27.710 --> 00:02:29.720
over security default policy.

00:02:30.350 --> 00:02:31.970
The differences aren't a lot,

00:02:32.260 --> 00:02:35.620
but the one that favors connectivity over security turns

00:02:35.620 --> 00:02:37.690
off two of the inspection plugins for it.

00:02:38.580 --> 00:02:41.890
Both of them have the same request and response depth settings

00:02:41.890 --> 00:02:46.610
though this connectivity over security one won't unzip or

00:02:46.610 --> 00:02:51.090
decompress the files seen before inspecting them and they won't

00:02:51.090 --> 00:02:53.480
normalize the utF eight sequences in the U.

00:02:53.480 --> 00:02:53.680
R.

00:02:53.680 --> 00:02:53.980
I.

00:02:54.670 --> 00:02:58.480
This will reduce your visibility a little bit After seeing

00:02:58.480 --> 00:03:00.360
these differences in the configurations,

00:03:00.690 --> 00:03:03.560
we can determine that the pre processors are used in

00:03:03.560 --> 00:03:05.530
different ways based on the policies.

00:03:06.410 --> 00:03:11.650
This means that you have extremely granular control over how snort functions,

00:03:12.280 --> 00:03:15.650
understanding this tuning and rule management become

00:03:15.650 --> 00:03:18.370
critical pieces of the snort workflow.

00:03:19.060 --> 00:03:19.920
Also,

00:03:20.140 --> 00:03:24.130
we have to be conscious of the use cases so that we can configure the pre

00:03:24.130 --> 00:03:27.070
processors in rules to ensure that they're successful