>> Hello all, let's continue our lesson.
In this video, we'll talk about two log sources.
The first is IPS or IDS,
and the other log source is Web Application Firewall.
Let's talk about IPS and IDS.
Both detect attacks while IPS,
which means intrusion prevention system,
can detect and block the attacks.
IDS or Intrusion Detection System
only detects the attack.
Both work in the same way,
but IPS is between
the communication so it can block the attack.
IDS only listens to the traffic.
Since IDS is not between the source
>> and the destination,
>> it cannot block the attack.
Now, maybe you're thinking,
why should I use IDS?
IPS can block and IDS
cannot block so it's better to use an IPS.
IPS is a component.
In some environments, it's actually not allowed to
use IPS because it can delay the communication.
But it's still important for detecting attacks.
As soon as the IDS detects the attack,
it can send the alert to a SOC analyst
or to a network component.
It's better to have at least an IDS than nothing.
Snort is an open source software that can
be used as IPS or IDS.
Let's analyze some Snort logs.
Some information is easy to identify.
You can easily identify
some attacks, cross-site scripting,
brute force, SQL injection,
vulnerability, and malicious user agents.
You can also identify some well-known fields
like date and time and
the source and destination IP address.
There are many other IPS and IDS softwares.
Each will have its logs, but with most of them,
>> you're given information about the attack
>> and you have the key fields.
>> It's important to know
>> that another IPS-like log source,
>> can help you to identify the web attack.
As you can see, it can
identify which attack was performed.
It can make the life of a SOC analyst much easier.
Next, let's talk about the Web Application Firewall.
IPS and IDS analyze all types of traffic
and Web Application Firewalls
analyze the Web Application Traffic.
That's why IPS and IDS is more related to the network
and Web Application Firewall is
more related to web applications.
Like IPS and IDS,
a Web Application Firewall can be
deployed in the middle of the communication.
Because of that,
>> it has the capability to block the attack.
>> But like IDS,
it can also be made to only detect the attacks.
There is an open-source web application file
called ModSecurity.
Let's see the Web Application Firewall Logs.
It's a big log.
>> But don't be scared.
>> Spend some time analyzing this log.
Look for some known fields or
any information that you think is important.
If you want, pause the video.
>> Later, we'll analyze this log together.
>> But first, you can see ModSecurity,
>> and it says that there is a warning.
>> I hope that you find it in this part of the log.
Do you remember this attack?
Now check the web application conclusion.
Web attack/file injection and, of course,
the well-known fields like date and time,
the client IP or the attacker.
Here's our server IP address and the web page;
again, the basic information is
all here, even a conclusion.
This looks like a file injection attack.
To make things more clear, let me show you
the web server log of this attack.
All the fields are here,
IP address, date and time, URL,
the requested file, the HTTP status code,
and the user agent.
Just looking at the Web Application Firewall Log,
you can get the attack or
the possible attack almost with the same information,
but with a conclusion.
Let's see one more example.
Here, we have an SQL attack.
The log is similar, we have date and time,
the IP address and so on.
Here is the related Web Server Log.
We have IP address,
date and time, and other information.
On the previous slide, we had the get method,
here we have the post method.
Remember that we talked about post method and that
the web server will not log the payload contents.
That's why we can't see the
SQL injection in the web server log.
But since the web application file
reads the entire packet,
it can identify the attacks that use post requests.
Some considerations about IPS, IDS, and WAF.
They helped to identify attacks
>> and protect against them.
>> Both work with signatures and usually
they already have some built-in signatures.
Because the web applications are different,
you do need to make some adjustments after deployment.
Like any other security tool,
they can be bypassed and they can cause
some availability issues because of the false positive.
We used Version 4 of the IP protocol in
this course and maybe you heard about IP Version 6.
This will not change our log analysis
because HTTP is a top layer protocol,
IP is a lower protocol.
This means that HTTP can use either IPv4 or IPv6.
This is also true for TCP.
The only difference will be in the IP fields.
Basically, the IPv4 address is 32 bits,
and IPv6, is a little bigger, 128 bits,
>> for its address.
>> To make things more clear,
here's an example of a log with IPv6.
See?
>> The only difference is the IP address.
>> You can analyze IPv4 and IPv6 servers.
To finish, a post-assessment question.
Analyze the log below and identify
the key fields and the possible attack.
The attacks are easy to identify.
The first is a cross-site scripting attack
and the second and SQL injection.
For the fields, we have IP address,
date and time,
URL, and so on.
Now, the video summary.
In today's video,
>> we talked about other sources of logs.
>> We now understand two types of attacks,
SYN and HTTP flood.
We also analyzed two types of logs, IPS/IDS,
and Web Applications Firewall.
>> Another conclusion.
>> Even if we have different log sources,
many of the same components can be found.
As soon as you know how to analyze one type of log,
you can analyze other logs too.
Maybe you have some doubts, but that's normal.
Always try to find the important fields in each log.
For our next video, we will have our course summary.