-: So in the auditing lesson,
I mentioned logs and how they're very tied together.
In this lesson, we're going to focus on logs specifically.
Now, logs are simply data files that contain
the accounting and audit trails
for actions performed by a user
on the computer or on the network.
That's why logs are really helpful
when we're doing auditing because it tells
us exactly what has been done and what has not been done.
Now, on the screen here,
you can see a listing of log files
that exist on a Lynx System
and they're stored in the /var/log directory.
Now, you can see there are logs
for the kernels actions, the SYSLOG server,
samba file shares and much more.
You don't need to know all of these
specific log files for the exam.
This is just an example, to give you an experience
and see that there are logs on a Lynx System.
If you're looking for the logs on a Lynx System,
check the /var/log directory.
Now when we talk about this on a Windows System,
there are three types of logs
that you have to be familiar with.
There are Security, System and Application logs
and all three of those should be audited
when you're looking at a Windows System.
Now, Security Logs are logs for events
such as successful and unsuccessful
user logons to the system.
You might get a question on the exam that asks you
"If you are trying to find when a user
"was successfully logged onto a system,
"which log would you look at?"
And they'll ask you Security, Application or System log
and you have to know that it's a Security log.
Now if we look at a System Log for instance,
these are logs that have events
such as a system shutdown or driver failure.
So if you're trying to investigate why that computer
or server was shut down at midnight,
you can go into the System Log and hopefully find out.
Now if you're having a problem with an application,
you're going to look at the Application Logs.
Application Logs are going to log the events
for the operating system and third-party applications
and so those are the three types of logs
you need to be aware of inside of Windows.
Now in Windows, if you want to view these log files
you're going to use the Event Viewer.
Some logs like the System, Security and the Application logs
are going to exists on both work stations and servers.
If you're on a service though,
there's a lot of other logs that are going to exist too
Things like,
the Distributed File System Replication Services,
DNS servers, DHCP Servers,
Directory service logs and many many others.
All of these can be accessed from the Event Viewer,
but the Event Viewer isn't the most
efficient way to view them.
In fact, I much prefer a SYSLOG Server.
This will allow you to consolidate
all of the logs into a single repository
and then you can use a SYSLOG Client
to read through them and help cor alate them.
So if I need to cor alate an issue
with the DHCP and the DNS Server,
being able to do that through
the SYSLOG Server is much more efficient.
SYSLOG is simply a standardized format
for computer message logging,
that allows the separation of the software
that generates the message, the system that stores them
and the software that reports and analyzes them.
What does that really all mean?
Well, when it comes to SYSLOG Servers,
I can actually have different servers,
around the world, all sending their log files
back to a single logging server.
So the DNS Server, the DHCP Server,
the authentication server and your client work station
can all send their logs back
to a centralized monitoring system,
known as a SYSLOG Server.
It'll collect all those logs from across the enterprise,
cor alate them in the central repository
and make it so that I can actually
look up all of those things
based off of a SYSLOG client.
By taking apart the message format,
the person who's sending the message
and the client that reads those messages,
it allows us to have a lot more capability
than looking at the single event viewer
on a single Windows server
and having to log into each server to do that.
SYSLOG does this by sending all of that data
back over UDP using port 5-1-4.
And you might remember that
from our protocol lesson earlier in the course.