>> Now that we know about web server logs,
we can talk about web server software.
The first web server we will review will be Apache.
Apache is an open-source web server software
that's maintained by the Apache Foundation.
The different locations of logs in
Linux and Windows can be seen here.
Httpd.com is the file
where you can set the logs configuration,
including the logs format.
This right here is the default log format.
You can find more details on the Apache web page.
Now, let's try to understand the log fields on
the Apache web server log.
Here we have all the key fields, client IP,
RFC1413, userid,
date and time, method, and so on.
It's the same format as the previous example,
but with different values on the fields.
Remember, the hyphen means
no information for that field.
Now, let's analyze these next two log lines.
To answer our questions of who, when, and what,
we'll use this table to help us
>> identify the key fields.
>> Here are the results for the first line.
All the key fields are present.
Now, let me show you the results for the second line.
We now have the answer for who, when, and what,
and in addition, we have the referer
>> and the user agent.
>> After reviewing the Apache web server,
let's talk about Nginx logs.
Nginx is very similar to Apache.
Here is the default location of its logs.
Also, the default configuration
for Nginx includes logging.
Nginx.com contains the log configuration
for both Linux and Windows,
including the log format.
Now, let's try and understand this next Nginx log line.
A good thing is Nginx logs
look a lot like the Apache logs.
Basically, we have the same fields.
Client IP, RFC1413, userid,
date and time, method,
requested file, HTTP version and so on.
However, despite the two looking similar,
it's always better to just practice.
Let's analyze the two lines of log from Nginx.
Here, the result of the first line
is followed by the referer and user agent.
Remember, the hyphen
means no information for that field.
In this line, we don't have the referer.
Here is the result for the second line
with the referer and user agent.
Now, we can answer the who,
when, and what.
Our next web server will be Microsoft IIS.
Microsoft IIS is a little different from the other two,
but this won't be a problem.
Here is the default log location.
Other web server configurations,
including logging are made on the IIS Manager,
a graphical user interface.
Just to note, the log options
for IIS will look like this.
Even if the log looks a little different,
it should contain all the needed log fields.
Let's try to understand the IIS logs.
Here we have an example of an IIS log.
First, we have the date and time.
Next is the web server IP
address followed by the HTTP method.
We have the requested file followed by
a specific space for URI query.
The server port is 80,
so it should be an HTTP request.
Remember, 80 is common to HTTP
and 443 is common to HTTPS.
Next, the username,
which is the same as userid, client IP address,
user agent, referer, status code,
sub-status code, Windows-related field,
and the time taken to answer the request.
We have many fields,
but more importantly, we have all the needed fields.
Now, let's analyze two lines of log from IIS.
We need to change our table just a little bit.
Filling in the table, we see
the result not so different from Apache and Nginx.
The second line, if you
want to try, pause the video and answer.
Here are the results of the second line.
One of the differences is the server port.
It is possible to add this field in Apache and Nginx.
It's also possible to have two different log lines,
one to TCP port 80 and another to TCP port 443.
Now, I'd like to point out
>> that access log files are not
>> the only log files that can be
used to analyze the web server.
There are other log files.
One good example is the error log file.
It's like debugging information.
All web server software contains an error log file.
Here are some examples of locations
for Nginx, Apache, and IIS.
Check the web server page to look for
more information about error logs.
Here is the address for the error log in Apache.
To make things more clear, here
are two logs from the web server.
The first is an error log and the
second is a related access log.
Both logs are generated by the same request.
The access log line will have the client requests and
the error log line will have
the debug information for the request.
You can find similar information in
both logs like client IP address,
the requested file, and the method.
If you don't have enough information
>> from the access log,
>> you can always look for the error log,
and it can be really helpful when doing analysis.
For the first post assessment question.
Which fields below are examples of
key information provided by web server logs?
You can pause the video if you'd like.
The answer is a, c, e,
and g. Here are the descriptions of each option.
For the next question,
extract the key information from
the logs below and fill in the table.
Here you have the answer and you can see our questions,
who, when, and what.
In addition, it's important to identify
which web server generated these logs.
The first log is from IIS.
The second one looks like a log from Apache or Nginx.
To solve this question,
it's better to ask the server admin.
In this case, the log is from an Nginx server.
It's common for a company to have
many different types of web servers.
In the same company, you can find Apache,
Nginx, and IIS.
That's why it's important to know
many web server options.
Even if the software is different,
you're looking for the same information. Video summary.
In this video, we started defining
what logs are and why they're important.
Afterwards, we explained the fields for
the web application or web server log.
Finally, we went through Apache, Nginx,
and IIS logs to learn how to get
the key information in the log fields.
Finally, we discussed
error logs and how they can help us with log analysis.
In the next video, you'll see
some consideration about log analysis.
We'll talk about fake requests,
the differences between NOC and SOC analysis,
and we'll discuss some mistakes that can
occur during web log analysis.