In this lesson,
we're going to discuss how we conduct network logging
inside of our networks.
Now, all of our network devices are going to generate logs
based on the information, events, warnings, alerts,
and other critical data that they generate.
If you have a very small network, it's pretty easy
for you to log into a network device
and review the logs individually or manually.
But if you're like me
and you start working on large enterprise networks,
this is impossible.
For example, one of the networks I previously worked on
had thousands of network switches and hundreds of routers.
There is no way I could possibly log
into each and every one of them
and review those log files individually each and every day.
So instead, we use something known as Syslog.
Syslog is a protocol that's used
to send these logs to a centralized server.
This becomes the easiest way
for us to gather all the logs
across all our routers and switches,
and bring them back to a central point
where we can analyze and review them.
All of our routers, our switches, our servers,
and all of our other devices can be configured
to send their own logs back to the centralized server
to make our jobs easier and more efficient if we use Syslog.
These centralized servers are known as syslog servers,
or you could have a SIM,
which is a Security Information Management system,
or a SEM, a Security Event Management system,
or the new combination of the two known as a SIEM,
a Security Information and Event Management system.
These days, most people have moved to a SIEM,
because it combines the functionality
of all these other types
of logging and analysis systems into one device.
By sending all of your logs to the centralized server,
it allows you as an administrator or analyst
to normalize and correlate the events
in order to see trends over time.
For example, if I see someone's conducting a ping sweep
on my firewall, that's really not that big of a deal,
but if I see that is coming within a few minutes
of that sweep, and I see from the same IP address,
somebody's trying to connect to my servers or my clients,
that may be a concern
that could be flagged for investigation,
because maybe they were preparing the environment
by seeing what ports were open
and now they're launching an attack.
When you configure your syslog server,
your SIM, your SEM or your SIEM,
there are two primary components you have to have.
You have to have a client, and you have to have a server.
Now, a client is just the device
that's going to send the log information to the syslog server.
This can be a router, a switch, a firewall, a web server,
or any other type of device.
Then you have a server, and this is going to receive
and store all those logs from all the different clients.
Each client can be configured to send logs
to the server based on different severity levels
of the information they contain.
Now, when it does this, it's going to send the data
over port 514 using UDP, the user datagram protocol.
Now, syslog has eight different severity levels.
The severity levels start at zero
and they count upward to seven,
so zero is going to be the most severe,
and seven is going to be the least severe or the most benign.
Now, level zero is going to be used for emergencies
and it's going to be considered the most severe condition,
because the system has now become unstable.
With level one, we're going to have an alert condition,
and this means there's a condition
that should be corrected immediately.
Level two is used for a critical condition,
and it means there is a failure
in the system's primary application
and it requires somebody's immediate attention.
With level three, we have an error condition,
and it means that something is happening to the system
that's preventing it from functioning properly.
Now, for example,
your file system storage may have reached its limits
and now the system can't write the data,
and so it's generating a write error
when it tries to save that log information,
and that could generate an error condition.
Now, level four is going to be used for warning conditions,
and it can indicate that an error is going to occur
if action isn't taken soon.
For example,
let's say your file system only has two gigabytes
of space remaining, so you need to free up more space
before you start to write errors.
This can send an alert,
and this would be known as a warning condition,
because you're running out of disk space.
Now, level five is used for notice conditions,
and that means these are events that are unusual,
but they're not exactly error conditions.
Level six is for information conditions,
and this is going to be a normal operational message
that requires no action.
For example, you might see in your logs
that an application has started or paused
or ended successfully.
These are all informational logs.
Level seven is going to be used for debugging conditions,
and it's just information that's useful to developers
as they're debugging their networks and their applications.
Now, as a network or system administrator,
it's your responsibility
to determine what levels should be logged
and how long you want to keep those logs
inside your syslog server or your SIEM.
Now, while we would love to keep everything forever,
for most of us, that's just not practical,
because we'll eventually run out of hard disk space,
so some administrators will limit what they log
and they decide to only log things
from level zero to level five,
and they'll ignore the informational or debugging logs.
This all depends on your organization
and the policies you're going to set forth
inside your business.
All right, we've talked a lot about logs so far in Syslog,
but we haven't really looked at one yet,
so let's pull up a log and take a look inside.
Here's an example from a syslog server.
Here we have the date, the time, the location,
and then we have the log level,
and you can see things like alerts, emergency, error,
warning, notice, informational, and things like that.
Then you have the machine or the host name
and the IP in the next column,
so you know what machine did the reporting of this error
or information or warning.
Then you have the actual text of the log message itself.
This will say things like, "This is a test message,"
or "This is an error and here's the error I had."
By having this information and understanding what it is
as an analyst or administrator, you can start going back
and figuring out what caused the incident
and what really occurred.
Now for the exam, what do you need to know about Syslog?
Well, you need to understand the eight different levels.
You may get a question that says,
"What is level number three in syslog?"
And you need to say, "That's an error message."
All right, let's go ahead
and talk a little bit more about logs.
Remember, a syslog server is all just a big collection
of all the different logs from all the different servers
and clients and network devices we have.
Now, when it comes to network device logs,
we can review these inside the syslog server
as well as by looking
at our traffic logs and our audit logs.
Now, when it comes to network traffic logs,
these are going to contain information
about traffic flows within your network.
For example, if you collect network traffic logs
from your router or your firewall,
you're going to see a list of every connection
that's been made to and from your network.
For example, you can see the source IP, the source port,
the destination IP, the destination port,
as well as the MAC address of the client,
the time it took to occur,
the length of the packet, and even it's time to live.
Then you can analyze these traffic flows
to determine if this is normal traffic for you
and something you'd expect to see in your baseline,
or is this something that's abnormal
and needs to be investigated further.
For example, if you knew
that in a given day you're used to seeing about a gigabyte
of data leaving your network over port 443,
but today you saw 10 gigabytes
of data was leaving your network,
that is something you need to worry about.
So you might take a look at that
and see, have you been hacked?
Is somebody stealing all your data?
Now, does it mean that's happening?
Well, not necessarily, but we do know it's abnormal,
because we expect to see somewhere around one,
and right now we're seeing around 10,
so we need to investigate that closer
and dive into those network traffic logs
to see what's happening.
Let's say, for example, that happened in my company,
I would want to investigate that.
Now, most likely what I'll find is
that my video editor was uploading all
of our videos to cloud-based servers,
because 10 gigabytes of data is only
about an hour or two of video for our courses.
Now she might edit all week
and then on Friday upload all that data,
and that's why we're seeing that big spike on Friday.
Similarly, if you see traffic that you're not expecting,
like somebody sending data over some port
that you're not using like port 21 for FTP,
but you don't have an FTP server, this could be something
that's abnormal and suspicious as well.
The key to understanding your network traffic logs is
understanding what normal looks like,
and so you have to understand what normal is
in your baseline, so you can then determine what is abnormal
and what needs to be looked at much more closely
as you do investigations.
Also, when you're looking at your traffic logs,
this can help you during your troubleshooting efforts.
For example, you might see that you're trying to send data
to a particular IP address,
but it's stopping in a particular router
or firewall within your network.
By investigating this in the traffic logs,
you can determine why this blockage is occurring.
Now the second type
of network device log we need to talk about is an audit log.
Now, an audit log or audit trail is a record
of all the events and changes
that have happened on that device.
Every IT device keeps a log based on the events.
An audit log is typically going to contain a sequence
of events for a particular activity.
In a network device,
this would be something like a configuration change
that you made to that system.
So let's say for example, you came into work
and you found that somebody changed a configuration
on your border gateway router.
Now you could log in and see who made that change
and exactly what changes were made
by reviewing that audit log for the device.
For your convenience,
these audit logs can be sent over Syslog
to that centralized server
for review and analysis as well.
Now, when it comes to servers and clients,
we're usually going to be using Windows machines
in enterprise networks.
For Windows,
there are three main types of logs you can also collect.
These are application logs, security logs, and system logs.
To view these logs, you can open your event viewer
on a Window system and access the different types of logs.
The first one is an application log.
In Windows, this contains information
about the software running on your client or server.
Now, there are three severity levels
in a Windows application log.
We have informational, warning, or error.
For example, if you have Microsoft Word
and it crashes on you, you can go check the application log
and figure out why it keeps crashing.
Our second one we have is the security log.
The security log contains information
about the security of your client or server.
This is going to have things like successful
and failed login attempts,
other pertinent security information.
This will also show you if an audit success
or audit failure occurred for those logs.
Now the third one we have is a system log.
The system log contains all the information
about the operating system itself.
There are three severity codes here.
Just like the application log,
we're still going to have informational, warning, and error.
In this example, there are four errors
and the rest were informational items.
Errors are notated by that red exclamation mark,
whereas if you see the warning,
it's going to be a yellow triangle,
and information is a white circle
with a blue I inside of it.