2 hours 5 minutes
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 this information will lead you to a much better analysis.
See this request?
This is on Lee the requested file for a line of log.
It looks normal, right?
A get request to this PHP page. But
what if our server doesn't run PHP?
Why would someone be requesting this page? What a typical user access this page
analyzing now the full log of this request. You can see that the several responses 400 or 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 a knock analyst, everything would look fine,
But for a sock analyst, this log is suspicious.
Since you know the application, you know, PHP is not on this Web server. So you could say that this request is malicious
but that there is no risk to it.
The classifications of this event depends on the company policies.
It could be classified as a false positive for a vulnerability scan.
Sometimes it will happen that we will not have enough time to analyze the locks.
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 era. Log to
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 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.
Then 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 remote sis log 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.
So you need to ask for the correct website locks.
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?
We have two different client I P addresses.
Both Web server answers are 200.
The first log line
already looks suspicious.
The first line method is head and the second one is he get
you have the date in time So
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 surfer, 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 deleted 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 times. Um,
it's better when the auto Web server logs at the same time, so
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 law.
Can you tell why it's incomplete
in this log? You have the time, but you don't have to date
this. I P address cannot be from our client because it's a local host i p address, although it can be the Web server I p address
since we have the time in the beginning of the line and the Web server IP address.
This log looks like a nice slog, but
we don't have the client I p address the user agent or the refer.
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 asked them to configure it. Better
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 to value
here. Even the hyphen is missing, so 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. You won't extract incorrect information.
For example, in the first log line here, you have to I p addresses. One is from the client and one is from the Web server
Maybe this log is from Microsoft, I s. But it could also be from a different party. Or it could be from N g i N X law configuration.
The second line is from Apache again this books like Apache Order N G I N X.
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.
And finally, we'll talk about something that's not on Lee related to the Web. Server locks,
not documenting all your findings, is not only related to the Web server log analysis, but also to handling security incidents.
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.
Creator. 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 questions.
Is this information true or false? Onley Web browsers Consent http Request to the Web servers
This information is false.
As we talked about in this video. There's a lot of software they can craft. Http requests like Curl tell Net w Get and programming languages
for the next question to note whether the log field could be crafted or not.
Take your time to answer and positive video if you'd like.
Here is the answer.
all the log feels related to the clients can be manipulated in the fields generated by the Web. Server cannot be manipulated by the client.
For example, the date and time is based in the Web servers operational system. Time
for the last question.
Consider the logs below.
Can you tell which fields are missing?
You can pause a video if you want.
In the first logline. We don't have the I P address, so it's missing the client I P 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 Onley have the method and the http version
the requested file is missing.
The minimum requested file is the slash
In this video, we started talking about the differences between knock and sock 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 one is now finished.
We will start module to with a brief review covering the attacks that target Web applications
and discussing some u R L components.