WEBVTT

00:00.000 --> 00:02.610
>> Hello, and welcome
back to the course,

00:02.610 --> 00:05.160
identifying web
attacks through logs.

00:05.160 --> 00:06.960
In the last video,
we talked about

00:06.960 --> 00:09.105
cross-site scripting
request forgery.

00:09.105 --> 00:12.255
In this video, we'll see
some other sources of logs.

00:12.255 --> 00:15.000
Let's start with the learning
objectives of this video.

00:15.000 --> 00:17.310
The learning objectives
of this video are to

00:17.310 --> 00:19.260
learn about other sources
of logs that can help

00:19.260 --> 00:21.030
to identify attacks and some of

00:21.030 --> 00:24.660
the network attacks that can
affect web applications.

00:24.660 --> 00:27.330
Here we have some examples
of other sources of

00:27.330 --> 00:30.510
logs, packets, the firewall,

00:30.510 --> 00:33.675
network bandwidth usage,
CPU and memory usage,

00:33.675 --> 00:35.280
and intrusion prevention system,

00:35.280 --> 00:38.010
and web application firewalls.

00:38.270 --> 00:41.020
Do you remember this picture?

00:41.020 --> 00:42.590
Here, we have a topology of

00:42.590 --> 00:45.230
infrastructure that can
support a web application.

00:45.230 --> 00:46.760
Remember that all of

00:46.760 --> 00:48.350
these components can
send information in

00:48.350 --> 00:49.970
the form of logs or graphs and

00:49.970 --> 00:52.680
can help in identifying
the attack.

00:53.180 --> 00:56.340
Let's talk about two attacks,

00:56.340 --> 00:59.175
SYN flood and HTTP flood.

00:59.175 --> 01:01.160
The first is a network
attack and the

01:01.160 --> 01:03.275
second is a web
application attacks.

01:03.275 --> 01:05.870
Both types of flood attacks
try the same thing,

01:05.870 --> 01:09.200
to consume all the network
or the web server resources.

01:09.200 --> 01:10.880
If this happens, it can cause

01:10.880 --> 01:13.190
a delay of service in
a web applications.

01:13.190 --> 01:14.780
An SYN flood can

01:14.780 --> 01:16.790
happen because of the
three-way handshake.

01:16.790 --> 01:18.710
The component receives the SYN

01:18.710 --> 01:20.960
and you try to complete
the three-way handshake,

01:20.960 --> 01:22.775
but it'll never happen.

01:22.775 --> 01:25.540
The connection is
just not established.

01:25.540 --> 01:27.410
All these connection
attempts will be on

01:27.410 --> 01:29.450
the server or network
equipment memory.

01:29.450 --> 01:32.795
More requests, more
memory consumed.

01:32.795 --> 01:36.535
The component gets flooded
by connection attempts.

01:36.535 --> 01:38.860
For the HTTP flood,

01:38.860 --> 01:40.565
the three-way handshake
is completed,

01:40.565 --> 01:43.480
but the web server will
receive a lot of requests.

01:43.480 --> 01:45.170
Depending on the
size of the servers

01:45.170 --> 01:46.805
and the number of the requests,

01:46.805 --> 01:49.220
the web application
can be impacted.

01:49.220 --> 01:50.600
That's why it's important to

01:50.600 --> 01:53.310
understand these
types of attacks.

01:53.450 --> 01:58.530
Now, let's analyze some
logs. Check this log.

01:58.530 --> 02:00.410
Can you identify
any key components?

02:00.410 --> 02:03.440
Is it similar to the
web application logs?

02:03.440 --> 02:06.260
Here we have an example
of a firewall log.

02:06.260 --> 02:08.480
This is a firewall for our lab.

02:08.480 --> 02:10.040
The firewall is a component

02:10.040 --> 02:11.460
that handles network
connections.

02:11.460 --> 02:12.500
Its log is going to be a little

02:12.500 --> 02:14.210
different from the web servers.

02:14.210 --> 02:16.445
Let's analyze this log together.

02:16.445 --> 02:18.080
First, you have the date and

02:18.080 --> 02:20.285
time followed by an IP address.

02:20.285 --> 02:23.470
In this case, it's the IP
address of the firewall.

02:23.470 --> 02:27.500
After, you have some
numbers and a word, TCP.

02:27.500 --> 02:31.550
Remember, we have UDP
and TCP connections.

02:31.550 --> 02:34.670
In this case, it's
a TCP connection.

02:34.670 --> 02:38.165
You have another number
and one IP address.

02:38.165 --> 02:40.610
This IP address is from
the source computer,

02:40.610 --> 02:42.155
in our case, the attacker.

02:42.155 --> 02:45.620
The second IP address is
the web server address.

02:45.620 --> 02:48.555
The number 80 is the HTTP port.

02:48.555 --> 02:51.870
It could be 443 for HTTPS,

02:51.870 --> 02:54.260
and you have a S.

02:54.260 --> 02:56.480
This S letter is the
identifier of the

02:56.480 --> 02:58.519
>> SYN flag from TCP.

02:58.519 --> 03:00.080
>> If you were to
check the other lines,

03:00.080 --> 03:01.550
you would see that these fields

03:01.550 --> 03:04.020
that we talked about
would be the same.

03:04.780 --> 03:08.510
Depending on the firewall
and the web server capacity,

03:08.510 --> 03:10.460
they can handle a
lot of connections,

03:10.460 --> 03:13.360
sometimes thousands of
connections in the same second.

03:13.360 --> 03:15.135
Depending on environment,

03:15.135 --> 03:16.700
the attacker therefore might

03:16.700 --> 03:18.380
need to generate a
lot of connections,

03:18.380 --> 03:20.040
but the behavior
will be the same,

03:20.040 --> 03:21.920
an uncommon number
of connections from

03:21.920 --> 03:25.325
the same IP only
sending the SYN flag.

03:25.325 --> 03:27.500
Can you think in one
of the attacks that

03:27.500 --> 03:29.570
we saw that is
similar to this one,

03:29.570 --> 03:32.660
is their behavior similar?

03:32.660 --> 03:36.265
One of the attacks is
the brute force attack.

03:36.265 --> 03:39.200
The SYN flood is like
a brute force attack,

03:39.200 --> 03:41.330
but the objective is to
make the application

03:41.330 --> 03:43.940
unavailable. One more thing.

03:43.940 --> 03:48.040
Do you remember our questions
of who, what, and when?

03:48.040 --> 03:49.580
Well, here, the fields can

03:49.580 --> 03:51.290
help in answering
these questions,

03:51.290 --> 03:52.910
date and time, IP

03:52.910 --> 03:55.115
addresses and the what
is the connection?

03:55.115 --> 03:59.400
TCP port 80 with the SYN flag.

03:59.600 --> 04:03.330
Now, let's talk about
the web server.

04:03.330 --> 04:05.895
Which logs will be shown
on the web server?

04:05.895 --> 04:09.020
In this case, we won't have
any logs in the web server.

04:09.020 --> 04:11.600
Remember that we restart
the web server log after

04:11.600 --> 04:13.400
the TCP through a handshake

04:13.400 --> 04:15.635
and the SYN flood will not
establish the connection,

04:15.635 --> 04:18.529
so no HTTP requests.

04:18.529 --> 04:20.540
Do you remember that
the TCP connection

04:20.540 --> 04:22.685
is a job of the
operational system?

04:22.685 --> 04:24.800
Normally, the
operational systems have

04:24.800 --> 04:27.510
a command to check
the connections.

04:27.520 --> 04:31.040
This command is netstat,

04:31.040 --> 04:33.780
it'll show the status
of the connections.

04:33.780 --> 04:35.560
If you check the result of

04:35.560 --> 04:38.410
the netstat commands during
an SYN flood attack,

04:38.410 --> 04:41.795
will you see a lot
of SYN requests?

04:41.795 --> 04:43.835
It will say that it received

04:43.835 --> 04:46.015
the SYN, like in this picture.

04:46.015 --> 04:47.650
You can see in this
picture that we

04:47.650 --> 04:49.090
have the web server IP and

04:49.090 --> 04:50.890
the HTTP port 80 and

04:50.890 --> 04:53.405
another IP with a lot
of different ports.

04:53.405 --> 04:55.855
This means that the
operational system

04:55.855 --> 04:57.310
is waiting for the other side to

04:57.310 --> 04:59.180
>> complete the connection.

04:59.849 --> 05:02.020
>> Now we will see

05:02.020 --> 05:06.560
HTTP flood and compare it
with an SYN flood attack.

05:06.680 --> 05:10.230
Again, we have the
firewall logs,

05:10.230 --> 05:11.815
we have the same components,

05:11.815 --> 05:14.170
date and time, firewall IP,

05:14.170 --> 05:17.765
source IP, server
IP, and the port 80.

05:17.765 --> 05:20.030
We also have the letter S,

05:20.030 --> 05:22.430
but in this case, we
have a difference.

05:22.430 --> 05:26.170
We have an S slash
ACK was an OK.

05:26.170 --> 05:28.265
This means that the TCP

05:28.265 --> 05:30.530
through a handshake
was completed.

05:30.530 --> 05:32.240
Since we have the connection,

05:32.240 --> 05:35.110
let's check the web server logs.

05:35.110 --> 05:38.040
Now, check this web server log,

05:38.040 --> 05:40.385
try to identify a
malicious behavior.

05:40.385 --> 05:42.200
If you want to pause
the video for a while,

05:42.200 --> 05:43.920
>> that's okay.

05:43.989 --> 05:47.075
>> Let's analyze the web
server logs together.

05:47.075 --> 05:48.890
We have the web server IP,

05:48.890 --> 05:51.290
date and time, HTTP method,

05:51.290 --> 05:54.200
the requested file,
HTTP version,

05:54.200 --> 05:56.555
status code, size,

05:56.555 --> 05:58.920
and the user agent.

05:59.990 --> 06:02.610
The web server log is okay.

06:02.610 --> 06:04.070
The point here is the number of

06:04.070 --> 06:06.230
requests and the many errors.

06:06.230 --> 06:08.180
If you kept the requested files,

06:08.180 --> 06:09.260
it doesn't make sense,

06:09.260 --> 06:11.530
a large number that
results in an error.

06:11.530 --> 06:15.600
HTTP status code 400
means bad request.

06:15.600 --> 06:18.045
Why would someone
send a lot of errors?

06:18.045 --> 06:21.160
Usually, users get
upset with errors.

06:21.200 --> 06:25.595
Well, here we have the same
source, a lot of errors,

06:25.595 --> 06:27.170
and a small period of time,

06:27.170 --> 06:30.295
and some random requested files.

06:30.295 --> 06:33.000
In this case, we
have an HTTP flood.

06:33.000 --> 06:35.390
Again, depending on the
size of the web server,

06:35.390 --> 06:37.550
the attacker might need
a lot of requests to

06:37.550 --> 06:40.220
get the web server and
the web application down.

06:40.220 --> 06:43.420
In this example, we have
the error, the 400,

06:43.420 --> 06:45.710
but HTTP flood can result in

06:45.710 --> 06:48.760
another status code
like 500 or 200,

06:48.760 --> 06:51.185
it all depends on the requests.

06:51.185 --> 06:53.555
Basically, the most
important factor

06:53.555 --> 06:55.640
is the number of the requests.

06:55.640 --> 06:57.770
If you notice that
there is a higher

06:57.770 --> 06:58.864
>> number of requests,

06:58.864 --> 07:02.560
>> more than normal,
maybe you have a flood.

07:02.560 --> 07:04.700
What do you think
will happen if we use

07:04.700 --> 07:08.220
the netstat command
during an HTTP flood?

07:08.240 --> 07:11.595
Well, here's result.

07:11.595 --> 07:13.790
We should have a lot of lines,

07:13.790 --> 07:16.505
but now we have the
word established.

07:16.505 --> 07:19.715
That means that the TCP
connection was established.

07:19.715 --> 07:22.280
That's why we have
the web server logs.

07:22.280 --> 07:24.890
On the previous slide, we
said that flood attacks try

07:24.890 --> 07:27.695
to consume all the
resources of the machine.

07:27.695 --> 07:32.420
Well, here we can see the
CPU usage from the firewall.

07:32.420 --> 07:34.580
You can see on both graphs that

07:34.580 --> 07:38.510
the CPU usage percentage
raised a lot and really fast.

07:38.510 --> 07:39.860
In the first graph,

07:39.860 --> 07:42.335
we have a few moments
of high CPU usage.

07:42.335 --> 07:43.655
In the second graph, we have

07:43.655 --> 07:46.240
the same two periods
of high CPU usage,

07:46.240 --> 07:50.075
but we can see another
increase in the CPU usage.

07:50.075 --> 07:52.940
During the period
of high CPU usage,

07:52.940 --> 07:55.040
since the web server's
after the firewall,

07:55.040 --> 07:57.095
the web application was down.

07:57.095 --> 07:58.850
This means that the denial of

07:58.850 --> 08:00.830
service attack was successful.

08:00.830 --> 08:02.330
We can see the same behavior

08:02.330 --> 08:03.725
on the network bandwidth graph,

08:03.725 --> 08:07.200
it goes from kilobits
to megabits.

08:07.720 --> 08:10.070
Let me show you some directions

08:10.070 --> 08:12.200
to identify the flood attacks.

08:12.200 --> 08:14.235
Watch out for send requests.

08:14.235 --> 08:15.690
Many requests from
the same source

08:15.690 --> 08:17.120
in small period of time,

08:17.120 --> 08:20.060
a rapid increase of CPU
or bandwidth usage,

08:20.060 --> 08:21.980
many seen requests without

08:21.980 --> 08:23.675
establishing through
a handshake,

08:23.675 --> 08:27.140
uncommon or random requests
on the web server log,

08:27.140 --> 08:28.700
or if your web application is

08:28.700 --> 08:31.210
simply slow or stop to work.

08:31.210 --> 08:33.840
Don't forget to check
the user agent.

08:33.840 --> 08:37.250
Since you need to send a lot
of corrected HTTP packets,

08:37.250 --> 08:38.825
it's better to use auto.

08:38.825 --> 08:43.510
Also remember, the attacker
can change the user agent.

08:43.510 --> 08:47.130
This lesson continues
in the next video.