>> To continue on this lesson,
we'll discuss some issues and mistakes that are
common during logging access.
The first mistake is not knowing your application.
It's hard to identify if a request is an attack if
you don't know at least a little bit
about your web application.
Knowing the application means
knowing the programming language,
the technology behind the web server software,
or any other information related
>> to the web application.
>> All of this information will lead you
to a much better analysis.
See this request.
This is only the requested file for a line of law.
It looks normal. I get request to this PHP page,
but what if our server doesn't run PHP?
Why would someone be requesting this page?
Will a typical user access this page?
Analyzing now the full log of this request,
you can see that the server response is 404, not found.
This is expected behavior since
the application doesn't have PHP.
If you look for more information about this request,
it'll show that this is a common request for
WordPress deployment and there are
some vulnerabilities related to this web-page.
As expected, this application does not run WordPress.
If you were not analyst,
everything will look fine.
But for a SOC analyst,
this log is suspicious.
Since you know the application,
you know PHP is not on this web server,
so you can say that this request is malicious,
but that there is no risk to it.
The classification of this event
depends on the company policies.
It can be classified as a false
positive or a vulnerability scan.
Sometimes it will happen that we will not
have enough time to analyze the logs.
Maybe your boss wants a fast answer
and maybe you forget to check all the logs.
More logs equals more information.
One of the important points is to confirm that
you have enough information to analyze your logs.
Remember to ask for all the logs,
ask for the error log too.
Another example is that maybe
you just have a small period of logs available,
or if you're the web server administrator,
maybe you received the wrong logs.
Maybe someone modified the logs.
One example where that happened before was I asked
the web server administrator for the logs
inside the default log folder.
I only received a small amount of logs though.
Afterwards, I spoke with
the server administrator and he
told me that in the company,
they changed the log Start folder.
I requested the logs from
the correct folder and
received the correct amount of logs.
Some important questions.
Do I have all the logs? Is it a busy server?
A busy web server will have more logs.
Could it be possible that someone changed the logs?
Sending the log to a remote syslog server
can reduce this risk.
Always check if the logs are the correct ones,
like in the example of the different Start folder.
Another thing that can happen is that
the web server has more than one website,
and each website can have its own logs.
You need to ask for the correct website logs.
Here's a little example.
Suppose you receive a log portion to analyze.
During your analysis, you see these two logs.
Can you identify something wrong with these logs?
Let's analyze. We have two different
>> client IP addresses.
>> Both web server answers are 200.
The first logline already looks suspicious.
The first line method is HEAD
and the second one is a GET.
You have the date and time, so what's wrong?
Well, if you take a better look at the date and time,
you'll find something is weird.
The time between the two lines is more than one hour.
If it's a busy server,
>> it's a little hard to believe that
>> the web server didn't receive
a request for more than one hour.
There are many reasons this might have happened;
a server admin error,
this just isn't a busy server,
someone debated the logs,
the logs were moved to another file, and so on.
Another important thing to remember regarding the date
and time is to check the time zone.
It's better when the auto web
server logs have the same time's up
>> but, this is not always true.
>> You always need to confirm that the logs you have
are enough and that they are the correct ones.
But it is also possible that
you might not have any logs to analyze,
or maybe you have the logs,
but the logs are incomplete or
the log configurations are incorrect.
As another example, check this log.
Can you tell why it's incomplete?
In this log, you have the time,
but you don't have the date.
This IP address cannot be from
our client because it's a local host IP address,
although it can be the web server IP address.
Since we have the time in the beginning of
the line and the web server IP address,
this log looks like an IIS log,
but we don't have the client IP address,
the user agent or the referrer.
Even if the log looks good,
incomplete logs would make
the investigation really hard and inconclusive.
If you get a log like this,
go to the web server administrator and
ask them to configure it better.
To summarize, we only
have two of the seven fields that we'd like to see.
This is different from the hyphen.
When we have the hyphen, we have
the field but we don't have the value.
Here, even the hyphen is missing.
We don't even have the field, it's really missing.
Another problem that can happen
is simply extracting the wrong information.
If you understand the log,
you won't extract incorrect information.
For example, in the first logline here,
you have two IP addresses.
One is from the client and one is from the web server.
Maybe this log is from Microsoft IIS,
but it could also be from a different party,
or it could be from NGINX log configuration.
The second line is from Apache.
Again, this looks like Apache order NGINX.
If we extract more information from this log,
the conclusion of our analysis could be wrong.
If you have any doubts about the web server logs,
talk with your web server administrator.
Finally, we'll talk about something that's
not only related to the web server logs.
Not documenting all your findings is not
only related to the web server log analysis,
but also to handling security incidence.
You can use whatever you prefer,
whether that may be a text editor,
mind maps, notebooks or whatever.
I like notebooks for two reasons.
First, when you write something,
it's easier to memorize.
Second, you know all the information is in one place.
Most of the time I start using a notebook,
which helps later in a text editor.
It's up to you to see which one works better for you.
Create your document so you can use
it to most efficiently answer most of the questions,
and at least say who, what, and when.
Post-assessment question.
Is this information true or false?
Only web browsers can send
HTTP requests to the web servers.
This information is false.
As we talked about in this video,
there's a lot of software that can craft
HTTP requests like cURL,
Telnet, Wget, and programming languages.
For the next question, to note
whether the log field can be crafted or not.
Take your time to answer and
pause the video if you'd like.
Here is the answer. Remember, all the log fields
related to the clients can be manipulated,
and the fields generated by the web server
cannot be manipulated by the client.
For example, the date and time is based in
the web server's operational system time.
For the last question,
consider the logs below.
Can you tell which fields are missing?
You can pause the video if you want.
In the first logline,
we don't have the IP address,
so it's missing the client IP address.
In the second line, we don't
have the date and time information.
Can you find what's missing in the last line?
The last line is tricky,
but if you take a closer look at the requested file,
you'll see we only have the
>> method and the HTTP version.
>> The requested file is missing.
The minimum requested file is the slash. Video summary.
In this video, we started talking about
the differences between NOC and SOC analysis.
After we discussed fake requests and
crafted HTTP requests,
at the end, we gave some examples of issues and
common mistakes that can occur during the log analysis.
Module 1 is now finished.
We will start Module 2 with
a brief review covering the attacks that target
web applications and discussing some URL components.