-: In this lesson
we're going to focus on monitoring and auditing.
Let's begin with monitoring first.
When we talk about monitoring,
one of the main jobs of a security analyst
is really to monitor the network.
We are like detectives.
We're trying to root out anything
that doesn't appear quite right
and this can be done manually or through an automated means.
Now, syslog is a protocol for enabling different appliances
and software applications to transmit their logs
or event records to a centralized server.
Now syslog is going to follow a standard client server model.
And this is the defacto standard for logging of events
from distributed systems across a network.
You are going to see syslog in use in so many of the systems
that you're going to work on in a daily basis.
Now syslog runs on most operating systems
and on most networking equipment.
So whether you're using a Cisco router
or you're using a Windows machine or a Linux server,
all of them can use syslog.
Now, when we send these messages back,
what does a syslog message look like?
Well, a syslog message is going to contain a couple of things.
It contains a PRI code, which is a priority code.
It contains a header and it contains a message portion.
Let's talk about each of these.
First, we have this PRI code, this priority,
and this is going to be calculated based on the facility
and the severity level of the data.
Next, we have a header
and the header's going to contain the timestamp
of the event and the host name.
So we know where it came from and what time it was.
And finally, we have the message portion,
which contains the source process of the event
and the related content, basically what data happened
and what do you want to tell us about?
And that's the idea here with the message portion.
This is the meat and potatoes of this message.
Now, when we dealt with syslog,
there's a couple of drawbacks to it in the original version.
The original protocol relied on UDP.
Now this can cause delivery issues with congested networks
because UDP is a fire and forget protocol.
It sends it and doesn't wait
for response and acknowledgement.
And so it just assumes it got there.
If you have a congested network,
you can have data that is being dropped
and therefore your information is not going to get
to the log server and not be logged.
In the early days, this may have been okay,
because people assumed everyone
on your network was trustworthy,
but these days we don't want that.
We want to make sure our data gets there.
So we're going to have to come up with a solution for this.
The second thing is that there is not
very many basic security controls.
There wasn't anything like encryption or authentication
included by default with syslog.
And this again was another drawback.
So in modern implementations of syslog,
we've corrected these things.
Now due to these security issues,
our newer syslog implementations have added lots
of different features and capabilities.
And we're going to talk about a couple of them here.
First newer implementations use TCP
for consistent delivery.
This way, if the network gets congested
and that message can't get there,
it will re-deliver it over and over again
because it's using TCP.
The second improvement, newer implementations,
can use TLS, or transport layer security,
to encrypt your messages being sent to servers.
That way that data in transit
can't be read by somebody else on the network.
It can only be read by the endpoint who sent it
and the server who's receiving it.
The third thing
is that newer implementations also use MD5 and SHA1
to provide authentication and integrity.
This way the messages can have message authentication
and integrity as they're transiting your network
to make sure they're not being messed with by anybody else.
Again, lots of other features.
I'm not focusing too much on this set though
because really the three big ones that we care about is
we've moved to TCP for a consistent delivery.
We have moved to TLS for encryption,
and we started using MD5 and SHA1
for authentication and integrity.
Now this newer version of the server
is usually called syslog-ng, for syslog next generation,
or rsyslog.
Now the final thing I want to mention about syslog
is that syslog is often used to mean three things.
It can refer to the protocol that we send the data over.
It can refer to the server as in a syslog server,
or it can refer to the log entries themself,
as in syslog data.
People will often just say syslog
and they mean all three, or any of these three,
depending on the context.
So just be careful about that
as you hear people talking in the industry
to make sure you understand which one
of the three they're talking about
SNMP is our next one.
SNMP is the Simple Network Management Protocol.
It's a TCP protocol that aids in the monitoring
of network attached devices and computers.
SNMP is incorporated into network management
and monitoring systems and it's heavily used
in the concept of management and monitoring.
SNMP is broken down into three components.
There's the managed devices, the agent,
and the network management systems themself.
We talk about managed devices.
This is computers and other network attached devices
that are monitored through the use of agents
by a network management system.
Agents are software that's loaded onto a managed device.
And this allows us to redirect information
to the network management system
that's going to do the monitoring.
And a network management system, or NMS,
is the software that's run on one or more servers
that controls the monitoring
of all of the network-attached devices and computers
across the network.
SNMP is the glue that makes all three of these
talk to each other, using that SNMP protocol.
So what does this all look like inside the network?
Well, here on the screen, you can see a brief diagram.
We have on the left, our network management station,
or our NMS, which is part of our network management system.
This is going to act as our manager
and it's going to send and receive messages
to all of the managed devices across the network,
your routers, your switches, and your servers, right?
Now, when it wants information,
it's going to send a get request,
and then those devices will send information back
using a set request.
Now there's also something called a trap request,
which is going to receive unsolicited information
from those management devices,
where they just send information as needed
at periodic intervals.
So when you conduct all this network management using SNMP,
you have two options where the data can be sent.
You can send it over the network that you're using,
which is known as in-band communication,
or you can send it out-of-band.
Now, when you do in-band,
that means you're going to send this management data
over the same network that's carrying
your corporate information and normal data.
This is cheaper, easier, but it is less secure.
Now to be more secure,
you should create an out-of-band network.
This is a secondary network
where all of the management occurs,
but you still have that primary in-band network
where all of the data that the users is going to get
is going to occur.
Management should always be conducted
on an out-of-band network because it increases security
and takes that management function out of the place
where users can touch it or see it.