A big part of network management is
that when something goes bad or not performing
well, we need to find out what happened.
And a big part of that is to use logging.
So in this video, we're going to take a deeper look at the world
of syslog on our networks.
And regarding syslog, let's go ahead and talk
about what can be logged.
Now with syslog, we could be logging events on the device.
So routers, next generation firewalls,
switches, and so forth, what's going on,
what events are happening, and based on our logging levels
and what's currently set, a log in permission WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and what's currently set, a log in permission
can be stored locally or sent to syslog server
to give us information regarding what's going on.
Another element that's pretty important is commands.
So if we have commands that are being issued,
we could track that all with AAA, with the accounting,
but we can also track what's going on using syslog as well.
Another important aspect regarding syslog is where.
Where do we want these messages to go and be stored?
So here in router one, if you do a show logging,
it will tell us the story of what's currently configured.
So this indicates that, for console logging,
for any individuals who are connected to line console zero, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for any individuals who are connected to line console zero,
we're doing level seven, debug level, meaning
all messages are going to be sent by default to the console.
Then we have monitor logging, which
is also at level debugging, so level seven.
So if somebody does a remote connection with SSH or Telnet,
they'd want to do a terminal space monitor so they would
indeed see those messages.
But the system is willing to send them,
if the client wants them.
We're also doing level seven logging to the buffer.
That's the memory on this device.
And we're currently not sending the log to any syslog server. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we're currently not sending the log to any syslog server.
So to do that, we do logging host, and we'll get a 2.2.2.2.
And that's great.
And one of the elements we'd want to control,
if this is the syslog server, we'd
want to tell it to go ahead and only allow
syslog traffic on that port from certain hosts
that's expecting messages from.
And that helps protect against an attacker flooding our syslog
server.
So on R1, if we wanted to use a command like logging source
interface, and said loopback zero--
so that way, what we could do is we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so that way, what we could do is we
can specify near the syslog destination server and access
control list, it's only permitting syslog traffic
from our known hosts.
And that way, the malicious actor
can't sneak in or start flooding our syslog server with a bunch
of bogus syslog messages.
And I guess I should say, unless he's spoofs our source
address of our devices.
And then they would go in because it was just
matching based on the source address and the ports that
would be allowed in.
Another thing about syslog is that if we
are sending over a data or to a syslog server,
the admins will normally have access to this. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the admins will normally have access to this.
It'd be ideal to have a second system with those copies
of those records that is read only
from the perspective of the admins.
And that way, if we have a malicious player,
all that information is stored, the copies,
on this read only version.
So the system admins actually can't go in,
if they're trying to cover something up.
They can't go in and erase something
because they have limited access to this read only copy here.
And then when we do our audits or need to go in and look,
we can use the read only copy for a untainted version WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we can use the read only copy for a untainted version
of the syslog.
Another important aspect regarding logging
is timestamps.
So the command service timestamps,
and we can do it for logging and debugging.
And then we can specify what we want to include.
And datetime is preferable because uptime
is just how long had this device been running,
so we include the date and time.
We can say, I show the time zone,
if it's set that we can see what it is.
We can specify local time.
That's the offset from UTC.
We can include the year, and we can also include milliseconds, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We can include the year, and we can also include milliseconds,
if that's important.
So there's a few options there regarding the timestamps
that we can put on those messages.
And enterprise-wide, we want to agree on what we plan on doing.
Maybe just leave it all UTC, and that way it's all based on UTC,
no matter where that device is.
And then they're collected and sorted.
So if you're using a tool like Splunk or something else
to dig through your mountain of syslog log records,
you can at least have some confirmation
that the date and timestamps are consistent.
Now another aspect that we'd also want to do
is network time protocol, and that way we're
confirming that the timestamps that a router or switch is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
confirming that the timestamps that a router or switch is
placing on those syslog messages is accurate
because it's running NTP.
So this command here, service timestamps log, is for logging.
And the other option we could also do is for debug messages.
So service timestamps, debug, and I just abbreviated it
right there, but that's how we control
the timestamps on log messages and also debug messages.
Now as far as time goes, let's do a show NTP status.
I think I have NTP configured on this. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I think I have NTP configured on this.
Yeah.
So we'd want to make sure that we have NTP set up,
and that we're synchronized, and that way our timestamps
are going to be accurate.
So currently I said service timestamps log,
datetime show time zone, and here we go.
November 20, that's today.
And here is the current time.
That is true.
And it's PST, and then it's followed by the actual log
message itself.
So as we can see, having the correct time
on our local devices is important for a lot of reasons,
including logging.
So in the next video, I'd like to chat with you
about the internet's most popular way WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
about the internet's most popular way
of making sure a device has the correct time.
And in a secure environment, we'd
want to do NTP with some access control
lists and authentication.
We'll take a look at both of those in the next video.
So I'll see you there in just a moment.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing.