Other Log Sources Part 1

00:00

hello and welcome back to the course, identifying Web attacks through logs.

00:05

In the last video, we talked about cross site scripting request forgery.

00:09

In this video, we'll see some other sources of locks.

00:12

Let's start with a learning objectives of this video.

00:15

The learning objectives of this video are toe learn about other sources of Long's that could help to identify attacks and some of the network attacks that can affect Web applications.

00:25

Here we have some examples of other sources of logs,

00:28

packets, the firewall network, bandwidth usage, CPU and memory usage and intrusion prevention system and Web application firewalls.

00:39

Do you remember this picture

00:41

here? We have a topology of infrastructure that could support a Web application.

00:45

Remember that all these components consent information in the form of logs or graphs and can help in identifying the attack.

00:54

Let's talk about two attacks

00:56

S y n Flood and http Flood.

00:59

The first is a network attack. In the second is a Web application attack.

01:03

Both types of flood attacks. Try the same thing

01:06

to consume all the network or the Web server Resource is,

01:08

if this happens, it can cause a delay of service in the Web applications

01:12

and s y in flood can happen because of the three way handshake.

01:17

The component received the S y N, and you try to complete the three way handshake,

01:21

but it will never happen,

01:22

So the connection is just not established.

01:26

All these connection attempts will be on the server or network equipment memory,

01:29

more requests,

01:30

more memory consumed.

01:33

So the component gets flooded by connection attempts

01:37

for the http flood. The three way handshake is completed, but the Web server will receive a lot of requests.

01:42

Depending on the size of the servers and the number of the requests,

01:46

the Web application can be impacted.

01:49

That's why it's important to understand these types of attacks.

01:53

Now,

01:55

let's analyze some locks.

01:57

Check this log. Can you identify any key components? Is it similar to the Web application logs?

02:02

Here we have an example of a firewall log. This is a firewall for our lab.

02:07

The firewall is a component that handles network connections, so it's log is gonna be a little different from the Web servers.

02:14

Let's analyze this log together.

02:15

First. You have the date and time, followed by an I P address.

02:20

In this case, it's the i p address of the firewall

02:23

after you have some numbers. In a word, TCP

02:27

remember, we have UDP and TCP connections.

02:30

In this case, it's a TCP connection.

02:35

You have another number and one I p. Address

02:38

this I p address is from the source computer. In our case, the attacker

02:42

The second i p address is the Web server address.

02:46

The number 80 is the http port.

02:47

It could be 443 for https

02:52

and you have a s.

02:53

This s letter is the identifier of the S y n flag from TCP.

02:58

If you were to check the other lines, you would see that these fields that we talked about would be the same.

03:05

Depending on the firewall and the web server capacity,

03:07

they can handle a lot of connections, sometimes thousands of connections in the same second,

03:13

depending on the environment.

03:15

The entire ER therefore might need to generate a lot of connections. But the behavior will be the same.

03:20

An uncommon number of connections from the same IP Onley sending the s y n flag.

03:24

Can you think in one of the attacks that we saw that is similar to this one?

03:29

Is there

03:30

behavior Similar.

03:32

One of the attacks is the brute force Attack.

03:36

The S Y in flood is like a brute force attack. But the objective is to make the application unavailable.

03:43

One more thing.

03:44

Do you remember our questions of who? What, and when

03:47

we'll hear the fields can help in answering these questions.

03:51

Date and time I p addresses and the what is the connection?

03:54

TCP port 80 with the S y n flag.

04:00

Now

04:00

let's talk about the Web server.

04:02

Which laws will be shown on the Web server?

04:05

In this case, we won't have any log from the Web server.

04:09

Remember that we restart the Web server log after the TCP through a handshake, and the S y N flood will not establish the connection. So

04:15

no, http requests

04:17

Do you remember that the TCP connection is a job of the operational system?

04:23

Normally, the operational systems have a command to check the connections.

04:28

This command is net stat.

04:30

It will show the status of the connections

04:33

if you check the result of the net step commands during an S y n flood a tag.

04:38

Will you see a lot of S Y N requests?

04:42

It will say that it received the S y n like in this picture.

04:46

You can see in this picture that we have the Web server. I peep. And the http port 80 and another i p with a lot of different ports.

04:53

This means that the operational system is waiting for the other side to complete the connection.

05:00

Now we will see http Flood and compare it with an S y n flood attack.

05:06

Again, we have the firewall logs. We have the same components

05:11

date and Time firewall I p Source I p server I p and deport 80.

05:17

We also have the letter s. But in this case, we have a difference.

05:21

We have a s slash a c k. Within. Okay.

05:26

This means that the TCP through a handshake was completed.

05:30

So since we have the connection, let's check the web server logs.

05:34

Now check this Web server log.

05:38

Try to identify a malicious behavior.

05:40

If you want to pause the video for a while, that's okay.

05:44

Let's analyze the web server logs together. We have the Web server I P. Date and time. Http Method. The requested file http version

05:54

status, code size and the user agent

06:00

the Web server log is okay. The point here is the number of requests and the many errors.

06:05

If you check the requested files, it doesn't make sense. A large number that results in an error.

06:11

Http. Status code 400 means bad request.

06:15

Why would someone send a lot of errors? Usually users get upset with errors.

06:21

Well,

06:23

here we have the same source. A lot of errors

06:25

and a small period of time and some random requested files.

06:30

In this case, we haven't. Http, Flood and again, depending on the size of the Web server, the attacker might need a lot of request to get the Web server and the web application down

06:40

in this example. We have the era the 400.

06:43

But http flood can result in another status code like 500 or 200.

06:47

It all depends on the requests.

06:50

Basically, the most important factor is the number of the requests.

06:55

If you notice that there is a higher number of requests more than normal,

07:00

maybe you have a flood.

07:02

So what do you think will happen if we use the nets that command during an http flood?

07:09

Well,

07:10

here's result.

07:12

We should have ah, lot of lines, but

07:14

now we have the word established.

07:15

That means that the TCP connection was established. That's why we have the Web server locks

07:21

on the previous slide. We said that flood attacks try to consume all the resource is of the machine.

07:28

Well, here we can see the CPU usage from the firewall.

07:31

You can see on both graphs that the CPU usage percentage raised a lot and really fast. In the first graph, we have a few moments of high CPU usage. In the second graph, we have the same two periods of high CPU usage.

07:46

But we can see another increase in the CPU usage

07:49

during the period of high CPU usage. Since the Web servers after the firewall, the Web application was down.

07:57

This means that the denial of service attack was successful.

08:00

We can see the same behavior on the network band with graph. It goes from kilobits two megabits.

08:07

So

08:07

let me show you some directions To identify the flood attacks,

08:11

watch out for send requests many requests from the same source in a small period of time, a rapid increase of CPU, or bandwidth usage. Many seen requests without establishing through a handshake,

08:22

uncommon or random requests on the Web server log. Or if your Web application is simply slow or stop toe work,

08:31

don't forget to check the user agent,

08:33

since you need to send a lot of corrected http packets,

08:37

it's better to use auto.

08:39

Also, remember, the attacker can change the user agent.