>> Hello, and welcome back to the course,
identifying web attacks through logs.
In the last video, we talked about
cross-site scripting request forgery.
In this video, we'll see some other sources of logs.
Let's start with the learning objectives of this video.
The learning objectives of this video are to
learn about other sources of logs that can help
to identify attacks and some of
the network attacks that can affect web applications.
Here we have some examples of other sources of
logs, packets, the firewall,
network bandwidth usage, CPU and memory usage,
and intrusion prevention system,
and web application firewalls.
Do you remember this picture?
Here, we have a topology of
infrastructure that can support a web application.
Remember that all of
these components can send information in
the form of logs or graphs and
can help in identifying the attack.
Let's talk about two attacks,
SYN flood and HTTP flood.
The first is a network attack and the
second is a web application attacks.
Both types of flood attacks try the same thing,
to consume all the network or the web server resources.
If this happens, it can cause
a delay of service in a web applications.
An SYN flood can
happen because of the three-way handshake.
The component receives the SYN
and you try to complete the three-way handshake,
but it'll never happen.
The connection is just not established.
All these connection attempts will be on
the server or network equipment memory.
More requests, more memory consumed.
The component gets flooded by connection attempts.
For the HTTP flood,
the three-way handshake is completed,
but the web server will receive a lot of requests.
Depending on the size of the servers
and the number of the requests,
the web application can be impacted.
That's why it's important to
understand these types of attacks.
Now, let's analyze some logs. Check this log.
Can you identify any key components?
Is it similar to the web application logs?
Here we have an example of a firewall log.
This is a firewall for our lab.
The firewall is a component
that handles network connections.
Its log is going to be a little
different from the web servers.
Let's analyze this log together.
First, you have the date and
time followed by an IP address.
In this case, it's the IP address of the firewall.
After, you have some numbers and a word, TCP.
Remember, we have UDP and TCP connections.
In this case, it's a TCP connection.
You have another number and one IP address.
This IP address is from the source computer,
in our case, the attacker.
The second IP address is the web server address.
The number 80 is the HTTP port.
It could be 443 for HTTPS,
and you have a S.
This S letter is the identifier of the
>> SYN flag from TCP.
>> If you were to check the other lines,
you would see that these fields
that we talked about would be the same.
Depending on the firewall and the web server capacity,
they can handle a lot of connections,
sometimes thousands of connections in the same second.
Depending on environment,
the attacker therefore might
need to generate a lot of connections,
but the behavior will be the same,
an uncommon number of connections from
the same IP only sending the SYN flag.
Can you think in one of the attacks that
we saw that is similar to this one,
is their behavior similar?
One of the attacks is the brute force attack.
The SYN flood is like a brute force attack,
but the objective is to make the application
unavailable. One more thing.
Do you remember our questions of who, what, and when?
Well, here, the fields can
help in answering these questions,
date and time, IP
addresses and the what is the connection?
TCP port 80 with the SYN flag.
Now, let's talk about the web server.
Which logs will be shown on the web server?
In this case, we won't have any logs in the web server.
Remember that we restart the web server log after
the TCP through a handshake
and the SYN flood will not establish the connection,
so no HTTP requests.
Do you remember that the TCP connection
is a job of the operational system?
Normally, the operational systems have
a command to check the connections.
This command is netstat,
it'll show the status of the connections.
If you check the result of
the netstat commands during an SYN flood attack,
will you see a lot of SYN requests?
It will say that it received
the SYN, like in this picture.
You can see in this picture that we
have the web server IP and
the HTTP port 80 and
another IP with a lot of different ports.
This means that the operational system
is waiting for the other side to
>> complete the connection.
>> Now we will see
HTTP flood and compare it with an SYN flood attack.
Again, we have the firewall logs,
we have the same components,
date and time, firewall IP,
source IP, server IP, and the port 80.
We also have the letter S,
but in this case, we have a difference.
We have an S slash ACK was an OK.
This means that the TCP
through a handshake was completed.
Since we have the connection,
let's check the web server logs.
Now, check this web server log,
try to identify a malicious behavior.
If you want to pause the video for a while,
>> that's okay.
>> Let's analyze the web server logs together.
We have the web server IP,
date and time, HTTP method,
the requested file, HTTP version,
status code, size,
and the user agent.
The web server log is okay.
The point here is the number of
requests and the many errors.
If you kept the requested files,
it doesn't make sense,
a large number that results in an error.
HTTP status code 400 means bad request.
Why would someone send a lot of errors?
Usually, users get upset with errors.
Well, here we have the same source, a lot of errors,
and a small period of time,
and some random requested files.
In this case, we have an HTTP flood.
Again, depending on the size of the web server,
the attacker might need a lot of requests to
get the web server and the web application down.
In this example, we have the error, the 400,
but HTTP flood can result in
another status code like 500 or 200,
it all depends on the requests.
Basically, the most important factor
is the number of the requests.
If you notice that there is a higher
>> number of requests,
>> more than normal, maybe you have a flood.
What do you think will happen if we use
the netstat command during an HTTP flood?
Well, here's result.
We should have a lot of lines,
but now we have the word established.
That means that the TCP connection was established.
That's why we have the web server logs.
On the previous slide, we said that flood attacks try
to consume all the resources of the machine.
Well, here we can see the CPU usage from the firewall.
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,
but we can see another increase in the CPU usage.
During the period of high CPU usage,
since the web server's after the firewall,
the web application was down.
This means that the denial of
service attack was successful.
We can see the same behavior
on the network bandwidth graph,
it goes from kilobits to megabits.
Let me show you some directions
to identify the flood attacks.
Watch out for send requests.
Many requests from the same source
in small period of time,
a rapid increase of CPU or bandwidth usage,
many seen requests without
establishing through a handshake,
uncommon or random requests on the web server log,
or if your web application is
simply slow or stop to work.
Don't forget to check the user agent.
Since you need to send a lot of corrected HTTP packets,
it's better to use auto.
Also remember, the attacker can change the user agent.
This lesson continues in the next video.