>> Hello everyone and welcome back to the course,
identifying web attacks through logs.
In the last video, we talked about HTTP and TCP IP.
In this video, we'll start talking
>> about web server logs.
>> The learning objectives of this video are
to understand the importance of logs.
Understand the web server log
information, review Apache,
Ngix, and IIS log structures,
and perform some initial log analysis.
This is a course about logs,
but what are logs?
Why are logs so important?
One of the definitions of a log is a piece of wood,
but that definition doesn't really
make sense in our context.
In our course, we will use the second definition that
says that a log is a full written record of an event.
The web server will be in charge
>> of generating this log.
>> Now we know the definition of a log,
but we still need to know why they're so important.
Suppose you're SOC analyst and you receive
a call from a user saying
that their computer is acting weird.
If you don't have the logs,
you'd need to go to the user's
computer and check it manually,
and it might be too late.
But if you have the logs,
you'll be able to tell the user that
everything is okay because you've
checked the logs and they say that
anti-malware has removed the malicious software.
In some cases, you can have the web access log itself
tell the user that they visited
a malicious website and had been infected.
The more logs you have,
the more information you'll have.
That's why logs are so important.
Also, the logs will help you to understand
your infrastructure and applications
so it can monitor them.
It'll also help you in things like troubleshooting.
Logs are so important that
OWASP Top 10 projects included
lack of logging as a vulnerability on the 2017 version.
If you don't know what OWASP is, don't worry.
We'll talk about it later. Logs can help you a lot.
If you work or are planning to work as a SOC analyst,
it's important to know what you need to protect
because you can't protect what you don't know you have.
Since the log is a record, we need to store it.
There are two basic ways to do
this, locally and remotely.
Locally speaking, you'd save
all the logs in the same place they were generated.
Remote storage is used when you need
to send the log to another place,
maybe because you can't store it
locally or you just want another copy.
Remote logging is useful because you
can have other logs in the same place.
If you have many servers,
it will help you to have
>> all the logs in the same place.
>> Now, let's start talking about
web applications or web server logs.
Most of the time, we can split
the information by answering a couple of questions.
Who did the action,
when was the action performed,
and what was the action?
Most of the attacks will be detected here.
This is a really simple web server log.
We can easily find in the log what happened.
The IP address and username is the who,
date and time is the when,
and the request is the what.
Now, one more example,
it's important to know
>> that empty fields aren't allowed.
>> It's normal to see a hyphen.
The hyphen means no information for that field.
Let's analyze our log example.
First, we have the IP address.
The next field is related to RFC 1413.
But this field isn't really common on the logs.
It depends on the web server and web application.
The next field is the user ID,
followed by date and time.
The date and time format depends on
the configuration of the web server's logging.
The next field contains main information.
The HTTP method used by the client,
the file requested by the client,
and the HTTP version.
After we have the status code,
the sizing bytes of the answer,
the refer, and the user agent.
Just to note, this was an Apache
>> web server log example.
>> Now that I know the log fields,
well, what can I do with them?
We always need to answer the three questions,
who, when, and what.
The log will help us with this.
Let's check what information each field can tell us.
Source IP and user ID would say who,
date and time, when,
and all the others will explain what happened.
Just to clarify, here is the info for each field.
Logs are used to rebuild
>> the user's behavior or actions.
>> This log would say to us,
the user with IP 10.3.89.4 was
on the login webpage and
accessed another webpage appini.html.
The user sent a GET using Mozilla Firefox in June,
close to 07:00 PM,
and the web server answered with a 200.
So no errors.
RFC 1413 would say the user who made
the request is asking for help identifying
who did the action and when it's used,
it really looks like user ID information.
As we said before, it's
hard to see a web server using this field.
Here are some more examples.
Take some time and analyze these web server logs.
First, we have the source IP address.
After, we have the date and time,
followed by the user request and the user agent.
You can see in this last line that
almost all the log fields are
important and useful during the analysis.
Now, the only thing
missing is the answer to the questions,
who, when, and what.
Here we have the who.
We only have the information
about the client's IP address.
The date is the answer of the when question.
All the other information
is the answer to the what question.
This slide shows a review of
the important log fields and their descriptions.
It's important to understand the log fields
because they will help you to analyze web server logs,
spend some time and take notes if you want.
A good place to get more information
is on the Apache website.
This lesson continues in the next video.