WEBVTT

1
00:00.000 --> 00:00.830 align:middle line:84%


2
00:00.830 --> 00:02.600 align:middle line:90%
A big part of
network management is

3
00:02.600 --> 00:05.240 align:middle line:90%
that when something goes
bad or not performing

4
00:05.240 --> 00:07.130 align:middle line:90%
well, we need to find
out what happened.

5
00:07.130 --> 00:09.533 align:middle line:90%
And a big part of that
is to use logging.

6
00:09.533 --> 00:12.200 align:middle line:90%
So in this video, we're going to
take a deeper look at the world

7
00:12.200 --> 00:13.955 align:middle line:84%
of syslog on our networks.

8
00:13.955 --> 00:15.830 align:middle line:90%
And regarding syslog,
let's go ahead and talk

9
00:15.830 --> 00:17.810 align:middle line:84%
about what can be logged.

10
00:17.810 --> 00:21.240 align:middle line:90%
Now with syslog, we could be
logging events on the device.

11
00:21.240 --> 00:23.600 align:middle line:90%
So routers, next
generation firewalls,

12
00:23.600 --> 00:26.120 align:middle line:90%
switches, and so
forth, what's going on,

13
00:26.120 --> 00:29.030 align:middle line:90%
what events are happening, and
based on our logging levels

14
00:29.030 --> 00:31.220 align:middle line:90%
and what's currently
set, a log in permission
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

14
00:29.030 --> 00:31.220 align:middle line:90%
and what's currently
set, a log in permission

15
00:31.220 --> 00:33.830 align:middle line:90%
can be stored locally
or sent to syslog server

16
00:33.830 --> 00:35.880 align:middle line:90%
to give us information
regarding what's going on.

17
00:35.880 --> 00:38.340 align:middle line:90%
Another element that's
pretty important is commands.

18
00:38.340 --> 00:40.215 align:middle line:90%
So if we have commands
that are being issued,

19
00:40.215 --> 00:42.600 align:middle line:90%
we could track that all with
AAA, with the accounting,

20
00:42.600 --> 00:45.870 align:middle line:90%
but we can also track what's
going on using syslog as well.

21
00:45.870 --> 00:48.050 align:middle line:90%
Another important aspect
regarding syslog is where.

22
00:48.050 --> 00:51.720 align:middle line:90%
Where do we want these
messages to go and be stored?

23
00:51.720 --> 00:53.720 align:middle line:90%
So here in router one,
if you do a show logging,

24
00:53.720 --> 00:56.220 align:middle line:90%
it will tell us the story of
what's currently configured.

25
00:56.220 --> 00:58.130 align:middle line:90%
So this indicates that,
for console logging,

26
00:58.130 --> 01:01.550 align:middle line:90%
for any individuals who are
connected to line console zero,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

26
00:58.130 --> 01:01.550 align:middle line:90%
for any individuals who are
connected to line console zero,

27
01:01.550 --> 01:04.370 align:middle line:90%
we're doing level seven,
debug level, meaning

28
01:04.370 --> 01:07.490 align:middle line:90%
all messages are going to be
sent by default to the console.

29
01:07.490 --> 01:09.470 align:middle line:90%
Then we have monitor
logging, which

30
01:09.470 --> 01:12.260 align:middle line:90%
is also at level
debugging, so level seven.

31
01:12.260 --> 01:16.040 align:middle line:90%
So if somebody does a remote
connection with SSH or Telnet,

32
01:16.040 --> 01:18.530 align:middle line:90%
they'd want to do a terminal
space monitor so they would

33
01:18.530 --> 01:20.175 align:middle line:84%
indeed see those messages.

34
01:20.175 --> 01:21.800 align:middle line:90%
But the system is
willing to send them,

35
01:21.800 --> 01:23.150 align:middle line:84%
if the client wants them.

36
01:23.150 --> 01:25.980 align:middle line:90%
We're also doing level
seven logging to the buffer.

37
01:25.980 --> 01:28.580 align:middle line:90%
That's the memory
on this device.

38
01:28.580 --> 01:32.030 align:middle line:90%
And we're currently not sending
the log to any syslog server.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

38
01:28.580 --> 01:32.030 align:middle line:90%
And we're currently not sending
the log to any syslog server.

39
01:32.030 --> 01:38.220 align:middle line:90%
So to do that, we do logging
host, and we'll get a 2.2.2.2.

40
01:38.220 --> 01:39.290 align:middle line:84%
And that's great.

41
01:39.290 --> 01:40.700 align:middle line:90%
And one of the elements
we'd want to control,

42
01:40.700 --> 01:42.117 align:middle line:90%
if this is the
syslog server, we'd

43
01:42.117 --> 01:44.930 align:middle line:90%
want to tell it to go
ahead and only allow

44
01:44.930 --> 01:47.790 align:middle line:90%
syslog traffic on that
port from certain hosts

45
01:47.790 --> 01:49.370 align:middle line:84%
that's expecting messages from.

46
01:49.370 --> 01:52.430 align:middle line:90%
And that helps protect against
an attacker flooding our syslog

47
01:52.430 --> 01:53.010 align:middle line:84%
server.

48
01:53.010 --> 01:56.480 align:middle line:90%
So on R1, if we wanted to use
a command like logging source

49
01:56.480 --> 01:59.222 align:middle line:90%
interface, and said
loopback zero--

50
01:59.222 --> 02:00.680 align:middle line:90%
so that way, what
we could do is we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

50
01:59.222 --> 02:00.680 align:middle line:90%
so that way, what
we could do is we

51
02:00.680 --> 02:03.470 align:middle line:90%
can specify near the syslog
destination server and access

52
02:03.470 --> 02:06.740 align:middle line:90%
control list, it's only
permitting syslog traffic

53
02:06.740 --> 02:07.975 align:middle line:84%
from our known hosts.

54
02:07.975 --> 02:09.350 align:middle line:90%
And that way, the
malicious actor

55
02:09.350 --> 02:12.830 align:middle line:90%
can't sneak in or start flooding
our syslog server with a bunch

56
02:12.830 --> 02:14.540 align:middle line:84%
of bogus syslog messages.

57
02:14.540 --> 02:17.090 align:middle line:90%
And I guess I should say,
unless he's spoofs our source

58
02:17.090 --> 02:18.485 align:middle line:84%
address of our devices.

59
02:18.485 --> 02:20.360 align:middle line:90%
And then they would go
in because it was just

60
02:20.360 --> 02:23.420 align:middle line:90%
matching based on the source
address and the ports that

61
02:23.420 --> 02:24.440 align:middle line:84%
would be allowed in.

62
02:24.440 --> 02:26.390 align:middle line:90%
Another thing about
syslog is that if we

63
02:26.390 --> 02:29.750 align:middle line:90%
are sending over a data
or to a syslog server,

64
02:29.750 --> 02:32.030 align:middle line:90%
the admins will normally
have access to this.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

64
02:29.750 --> 02:32.030 align:middle line:90%
the admins will normally
have access to this.

65
02:32.030 --> 02:34.850 align:middle line:90%
It'd be ideal to have a second
system with those copies

66
02:34.850 --> 02:37.160 align:middle line:90%
of those records
that is read only

67
02:37.160 --> 02:38.850 align:middle line:90%
from the perspective
of the admins.

68
02:38.850 --> 02:42.050 align:middle line:90%
And that way, if we
have a malicious player,

69
02:42.050 --> 02:44.450 align:middle line:90%
all that information
is stored, the copies,

70
02:44.450 --> 02:46.230 align:middle line:84%
on this read only version.

71
02:46.230 --> 02:48.560 align:middle line:90%
So the system admins
actually can't go in,

72
02:48.560 --> 02:50.270 align:middle line:90%
if they're trying to
cover something up.

73
02:50.270 --> 02:51.920 align:middle line:90%
They can't go in
and erase something

74
02:51.920 --> 02:55.010 align:middle line:90%
because they have limited access
to this read only copy here.

75
02:55.010 --> 02:57.530 align:middle line:90%
And then when we do our audits
or need to go in and look,

76
02:57.530 --> 03:00.950 align:middle line:90%
we can use the read only
copy for a untainted version
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

76
02:57.530 --> 03:00.950 align:middle line:90%
we can use the read only
copy for a untainted version

77
03:00.950 --> 03:02.390 align:middle line:84%
of the syslog.

78
03:02.390 --> 03:04.700 align:middle line:90%
Another important
aspect regarding logging

79
03:04.700 --> 03:05.810 align:middle line:84%
is timestamps.

80
03:05.810 --> 03:08.510 align:middle line:90%
So the command
service timestamps,

81
03:08.510 --> 03:11.690 align:middle line:90%
and we can do it for
logging and debugging.

82
03:11.690 --> 03:13.730 align:middle line:90%
And then we can specify
what we want to include.

83
03:13.730 --> 03:15.510 align:middle line:90%
And datetime is
preferable because uptime

84
03:15.510 --> 03:17.540 align:middle line:90%
is just how long had
this device been running,

85
03:17.540 --> 03:20.160 align:middle line:84%
so we include the date and time.

86
03:20.160 --> 03:21.620 align:middle line:90%
We can say, I show
the time zone,

87
03:21.620 --> 03:23.590 align:middle line:90%
if it's set that we
can see what it is.

88
03:23.590 --> 03:24.780 align:middle line:84%
We can specify local time.

89
03:24.780 --> 03:26.870 align:middle line:84%
That's the offset from UTC.

90
03:26.870 --> 03:30.270 align:middle line:90%
We can include the year, and we
can also include milliseconds,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

90
03:26.870 --> 03:30.270 align:middle line:90%
We can include the year, and we
can also include milliseconds,

91
03:30.270 --> 03:31.470 align:middle line:84%
if that's important.

92
03:31.470 --> 03:33.830 align:middle line:90%
So there's a few options
there regarding the timestamps

93
03:33.830 --> 03:35.660 align:middle line:90%
that we can put
on those messages.

94
03:35.660 --> 03:38.930 align:middle line:90%
And enterprise-wide, we want to
agree on what we plan on doing.

95
03:38.930 --> 03:42.440 align:middle line:90%
Maybe just leave it all UTC, and
that way it's all based on UTC,

96
03:42.440 --> 03:43.850 align:middle line:84%
no matter where that device is.

97
03:43.850 --> 03:45.470 align:middle line:90%
And then they're
collected and sorted.

98
03:45.470 --> 03:47.762 align:middle line:90%
So if you're using a tool
like Splunk or something else

99
03:47.762 --> 03:50.535 align:middle line:90%
to dig through your mountain
of syslog log records,

100
03:50.535 --> 03:52.160 align:middle line:90%
you can at least have
some confirmation

101
03:52.160 --> 03:54.530 align:middle line:90%
that the date and
timestamps are consistent.

102
03:54.530 --> 03:56.750 align:middle line:90%
Now another aspect that
we'd also want to do

103
03:56.750 --> 03:59.630 align:middle line:90%
is network time protocol,
and that way we're

104
03:59.630 --> 04:02.660 align:middle line:90%
confirming that the timestamps
that a router or switch is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

104
03:59.630 --> 04:02.660 align:middle line:90%
confirming that the timestamps
that a router or switch is

105
04:02.660 --> 04:05.990 align:middle line:90%
placing on those syslog
messages is accurate

106
04:05.990 --> 04:08.210 align:middle line:84%
because it's running NTP.

107
04:08.210 --> 04:11.120 align:middle line:90%
So this command here, service
timestamps log, is for logging.

108
04:11.120 --> 04:16.050 align:middle line:90%
And the other option we could
also do is for debug messages.

109
04:16.050 --> 04:19.430 align:middle line:90%
So service timestamps, debug,
and I just abbreviated it

110
04:19.430 --> 04:21.019 align:middle line:90%
right there, but
that's how we control

111
04:21.019 --> 04:23.930 align:middle line:90%
the timestamps on log messages
and also debug messages.

112
04:23.930 --> 04:28.467 align:middle line:90%
Now as far as time goes,
let's do a show NTP status.

113
04:28.467 --> 04:30.050 align:middle line:90%
I think I have NTP
configured on this.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

113
04:28.467 --> 04:30.050 align:middle line:90%
I think I have NTP
configured on this.

114
04:30.050 --> 04:30.620 align:middle line:84%
Yeah.

115
04:30.620 --> 04:33.170 align:middle line:90%
So we'd want to make sure
that we have NTP set up,

116
04:33.170 --> 04:36.170 align:middle line:90%
and that we're synchronized,
and that way our timestamps

117
04:36.170 --> 04:37.710 align:middle line:84%
are going to be accurate.

118
04:37.710 --> 04:39.890 align:middle line:90%
So currently I said
service timestamps log,

119
04:39.890 --> 04:42.080 align:middle line:90%
datetime show time
zone, and here we go.

120
04:42.080 --> 04:44.270 align:middle line:84%
November 20, that's today.

121
04:44.270 --> 04:45.950 align:middle line:84%
And here is the current time.

122
04:45.950 --> 04:47.000 align:middle line:84%
That is true.

123
04:47.000 --> 04:50.690 align:middle line:90%
And it's PST, and then it's
followed by the actual log

124
04:50.690 --> 04:52.050 align:middle line:84%
message itself.

125
04:52.050 --> 04:53.870 align:middle line:90%
So as we can see,
having the correct time

126
04:53.870 --> 04:56.480 align:middle line:90%
on our local devices is
important for a lot of reasons,

127
04:56.480 --> 04:57.230 align:middle line:84%
including logging.

128
04:57.230 --> 04:59.720 align:middle line:90%
So in the next video,
I'd like to chat with you

129
04:59.720 --> 05:02.170 align:middle line:90%
about the internet's
most popular way
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

129
04:59.720 --> 05:02.170 align:middle line:90%
about the internet's
most popular way

130
05:02.170 --> 05:04.300 align:middle line:90%
of making sure a device
has the correct time.

131
05:04.300 --> 05:05.770 align:middle line:90%
And in a secure
environment, we'd

132
05:05.770 --> 05:08.115 align:middle line:90%
want to do NTP with
some access control

133
05:08.115 --> 05:09.910 align:middle line:84%
lists and authentication.

134
05:09.910 --> 05:12.200 align:middle line:90%
We'll take a look at both
of those in the next video.

135
05:12.200 --> 05:14.360 align:middle line:90%
So I'll see you there
in just a moment.

136
05:14.360 --> 05:16.810 align:middle line:90%
Meanwhile, I hope this has
been informative for you,

137
05:16.810 --> 05:20.040 align:middle line:90%
and I'd like to thank
you for viewing.