WEBVTT

1
00:00.000 --> 00:03.990
Now, once the 40 analyzer has received the logs and taken a moment or two to

2
00:03.990 --> 00:05.600
insert them into the SQL database,

3
00:05.600 --> 00:09.150
we can at that moment take advantage of another feature inside of 40 Analyzer

4
00:09.150 --> 00:10.320
called "Forty View".

5
00:10.320 --> 00:14.000
So over the past week or so, I've been sending log information from these four

6
00:14.000 --> 00:14.880
firewalls,

7
00:14.880 --> 00:19.040
and they're all going to the root administrative domain on the 40 Analyzer.

8
00:19.040 --> 00:22.820
So because the logs are sitting there and have been injected into the SQL

9
00:22.820 --> 00:23.520
database,

10
00:23.520 --> 00:26.560
let's head over to the 40 Analyzer and take a look at how we can leverage

11
00:26.560 --> 00:31.080
for the view. So here is the 40 Analyzer. Now, since the last video, I actually
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

11
00:26.560 --> 00:31.080
for the view. So here is the 40 Analyzer. Now, since the last video, I actually

12
00:31.080 --> 00:32.080
had to sleep.

13
00:32.080 --> 00:36.420
So this is the next day. So we have some more logs that have also been sent to

14
00:36.420 --> 00:37.600
the 40 Analyzer,

15
00:37.600 --> 00:41.820
and the 40 Analyzer has been up for an hour and 16 minutes. Also, let me just

16
00:41.820 --> 00:42.720
log off for a moment.

17
00:42.720 --> 00:47.110
I'll log back in, supply the password, click "Log In", and because we set up

18
00:47.110 --> 00:48.320
administrative domains,

19
00:48.320 --> 00:51.630
it's also going to prompt me right here regarding which administrative domain I

20
00:51.630 --> 00:52.400
want to jump into.

21
00:52.400 --> 00:55.950
So we want to go to the root "ADOM", because that's where our four 48 firewalls

22
00:55.950 --> 00:57.200
are. So we'll click here

23
00:57.200 --> 01:00.640
on the root administrative domain, and away we go. Now, in the previous video,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

23
00:57.200 --> 01:00.640
on the root administrative domain, and away we go. Now, in the previous video,

24
01:00.640 --> 01:01.680
we focused on the logs,

25
01:01.680 --> 01:05.540
and did that. We went to the "Log View" section, went to "Logs", and then we

26
01:05.540 --> 01:06.800
worked with the logs from here.

27
01:06.800 --> 01:11.040
So if we go to "Fortnite Logs", then we have "Logs for Traffic", "Logs for

28
01:11.040 --> 01:12.800
Security", and also "Logs for

29
01:12.800 --> 01:17.000
Events". And because 40 Analyzer has now added all that log information into

30
01:17.000 --> 01:18.000
the SQL database,

31
01:18.000 --> 01:21.530
we can now take advantage of this other option right here called "Forty View".

32
01:21.530 --> 01:21.920
Now, here in the

33
01:21.920 --> 01:25.680
"Forty View", before the line here, these one, two, three, four, five, six at

34
01:25.680 --> 01:26.320
the moment with this

35
01:26.320 --> 01:31.520
version of 40 Analyzer, these are all considered to be "Forty View" dashboards.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

35
01:26.320 --> 01:31.520
version of 40 Analyzer, these are all considered to be "Forty View" dashboards.

36
01:31.520 --> 01:32.240
And then below the

37
01:32.240 --> 01:35.920
line, these are referred to as "Forty View" monitors. So under "Forty View", if

38
01:35.920 --> 01:37.120
we click on "Threats", at the

39
01:37.120 --> 01:40.340
top left, we'll go ahead and start off with "Top Threats". And then we can

40
01:40.340 --> 01:41.840
specify our time frame. So for

41
01:41.840 --> 01:45.680
the last two weeks, and currently we have all devices selected, we can also

42
01:45.680 --> 01:46.800
limit the time frame

43
01:46.800 --> 01:49.790
here, we can also limit the devices we're looking at, but I'm going to leave it

44
01:49.790 --> 01:50.960
set for two weeks

45
01:50.960 --> 01:54.790
at all devices. So here, we're showing that time frame, the last two weeks, and

46
01:54.790 --> 01:56.080
we have color-coded for

47
01:56.080 --> 02:00.080
"Top Threats", we're getting low, medium, high, and critical. And then below,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

47
01:56.080 --> 02:00.080
"Top Threats", we're getting low, medium, high, and critical. And then below,

48
02:00.080 --> 02:01.360
we can sort based on

49
02:01.360 --> 02:04.720
the columns. So we want to sort based on the threat level, we can click here,

50
02:04.720 --> 02:05.440
and that's sorting on

51
02:05.440 --> 02:09.850
the threat level. We'll click again, it'll do the inverse sorting, showing the

52
02:09.850 --> 02:10.560
critical levels at

53
02:10.560 --> 02:14.640
the top, then high, then medium, and then low. We also can sort on the threat

54
02:14.640 --> 02:15.600
or the threat type.

55
02:15.600 --> 02:19.120
So if we click here on "Threat Type" and for threats where there's a CVE ID

56
02:19.120 --> 02:19.840
associated with it,

57
02:19.840 --> 02:23.710
we could also sort based on CVE ID. And then here in the gear, if we want to

58
02:23.710 --> 02:24.560
remove columns that we

59
02:24.560 --> 02:27.130
don't need to see, we can click on the gear. And then from here, we can choose

60
02:27.130 --> 02:27.840
the columns that

61
02:27.840 --> 02:31.330
show up in this table. And then just like most things in "40 Analyzer", if we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

61
02:27.840 --> 02:31.330
show up in this table. And then just like most things in "40 Analyzer", if we

62
02:31.330 --> 02:32.240
want to investigate

63
02:32.240 --> 02:34.990
something further, we can go ahead and double click on it. So here's the dark

64
02:34.990 --> 02:35.520
side threats,

65
02:35.520 --> 02:39.030
we'll double click on that. And the blue here represents "Pass", which means we

66
02:39.030 --> 02:39.680
forwarded the

67
02:39.680 --> 02:42.980
traffic. So if we wanted to look at that further, if we double click on that

68
02:42.980 --> 02:43.840
entry, what it's actually

69
02:43.840 --> 02:47.090
doing in the background is taking us to Log View right here without physically

70
02:47.090 --> 02:47.920
taking this to Log View,

71
02:47.920 --> 02:52.610
but showing us the Log View based on this filter, where a threat equals dark

72
02:52.610 --> 02:52.640
side,

73
02:52.640 --> 02:57.440
with no username specified, and the source IP address is 10300103. So because

74
02:57.440 --> 02:58.240
the threat level is

75
02:58.240 --> 03:01.560
critical, we might want to dig deeper and find out what's going on with this
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

75
02:58.240 --> 03:01.560
critical, we might want to dig deeper and find out what's going on with this

76
03:01.560 --> 03:02.880
Linux client going

77
03:02.880 --> 03:05.840
to that IP address. So if we can just double click on one of these, that'll

78
03:05.840 --> 03:06.560
show us the details,

79
03:06.560 --> 03:10.040
so scroll down, take a look. So if we look at the details and scroll down, the

80
03:10.040 --> 03:11.920
source is this IP

81
03:11.920 --> 03:18.030
address 10.30.0.103, coming in on V30 interface, and it's coming in on HQ

82
03:18.030 --> 03:20.080
firewall three, it has the name

83
03:20.080 --> 03:26.070
of Linux client for that device. The source port is 40,208, and the destination

84
03:26.070 --> 03:27.360
is going to

85
03:27.360 --> 03:32.560
this IP address 185 105 119, which is associated with the Russian Federation,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

85
03:27.360 --> 03:32.560
this IP address 185 105 119, which is associated with the Russian Federation,

86
03:32.560 --> 03:33.120
and the destination

87
03:33.120 --> 03:37.560
port is 443. And that traffic was allowed to go through. So there's the threat

88
03:37.560 --> 03:38.560
name, dark side,

89
03:38.560 --> 03:41.050
and if we scroll down here, some additional details, we're getting when it

90
03:41.050 --> 03:41.920
happened and where it was

91
03:41.920 --> 03:45.780
going. And here showing the actual policy firewall three into out to allow that

92
03:45.780 --> 03:46.960
traffic to flow. So

93
03:46.960 --> 03:50.140
one other thing we could do here is we could actually go and check on that

94
03:50.140 --> 03:51.600
firewall to verify

95
03:51.600 --> 03:55.220
that indeed that traffic is being allowed, because this information here is

96
03:55.220 --> 03:56.480
applying all the data we

97
03:56.480 --> 03:59.660
need to actually test it. So let's head over to firewall three for a moment. So

98
03:59.660 --> 04:00.320
here's firewall
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

98
03:59.660 --> 04:00.320
here's firewall

99
04:00.320 --> 04:04.440
three. And if we go down to policy and objects and firewall policy and click

100
04:04.440 --> 04:05.840
here on policy match,

101
04:05.840 --> 04:10.830
we could simulate generate that traffic. So the incoming interface was V 30. In

102
04:10.830 --> 04:10.960
fact,

103
04:10.960 --> 04:14.800
let me go take a peek again at 40 analyzers just to confirm. So the incoming

104
04:14.800 --> 04:16.080
interface was coming in

105
04:16.080 --> 04:20.150
on V 30. This is the source IP address. And for the destination, it was going

106
04:20.150 --> 04:21.200
to this IP address,

107
04:21.200 --> 04:25.460
and the egress or outbound interface was V 123. And the destination port was

108
04:25.460 --> 04:26.720
443. Let's go back

109
04:26.720 --> 04:31.710
to make sure the source port 40 208. And it's also showing here a policy ID of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
04:26.720 --> 04:31.710
to make sure the source port 40 208. And it's also showing here a policy ID of

110
04:31.710 --> 04:32.720
one. So with that

111
04:32.720 --> 04:36.870
information, let's go back to firewall three. So here's firewall three under

112
04:36.870 --> 04:37.840
firewall policy,

113
04:37.840 --> 04:41.500
little policy match. So for the protocol, it's supposed to say HTTPS for the

114
04:41.500 --> 04:42.320
source IP address,

115
04:42.320 --> 04:48.450
that was 10 30 dot 0, 103. But the source port is 40,208, which for a TCP

116
04:48.450 --> 04:50.400
session, the source port is

117
04:50.400 --> 04:53.940
usually used to random high number port available on the computer. And based on

118
04:53.940 --> 04:54.800
the logs and using

119
04:54.800 --> 04:58.710
the same exact port, and the destination address is that IP address in Russia,

120
04:58.710 --> 04:59.360
which if I look at my

121
04:59.360 --> 05:06.430
notes, because I wrote it down is 185 105, 109 dot 19. And the destination port
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

121
04:59.360 --> 05:06.430
notes, because I wrote it down is 185 105, 109 dot 19. And the destination port

122
05:06.430 --> 05:07.680
is 443. And it picked

123
05:07.680 --> 05:11.660
that because that's the default destination port for HTTPS. So we selected HTTP

124
05:11.660 --> 05:12.480
, it would use the

125
05:12.480 --> 05:17.340
default part for HTTP, which is 80. So we'll go back to HTTPS, that looks good.

126
05:17.340 --> 05:18.400
And just want to do a

127
05:18.400 --> 05:23.160
fine matching policy. And sure enough, there is the policy firewall three and

128
05:23.160 --> 05:24.160
out, including the

129
05:24.160 --> 05:27.690
policy ID number of one. And indeed, this firewall is allowing that traffic to

130
05:27.690 --> 05:28.560
go out. So that would

131
05:28.560 --> 05:31.750
be something to look into as far as, okay, why don't we have a security policy
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

131
05:28.560 --> 05:31.750
be something to look into as far as, okay, why don't we have a security policy

132
05:31.750 --> 05:32.160
in place,

133
05:32.160 --> 05:36.990
somewhere between this PC PC three and the internet, which is denying that

134
05:36.990 --> 05:38.640
traffic. So we could be

135
05:38.640 --> 05:41.950
implementing policy here on far well three or here on far well one to make sure

136
05:41.950 --> 05:42.560
that traffic

137
05:42.560 --> 05:46.180
never goes out to close that. And let's go back to the 40 analyzer. So if we

138
05:46.180 --> 05:46.960
noticed that some of

139
05:46.960 --> 05:50.790
that traffic had gone out and reached that device, we'd also want to do further

140
05:50.790 --> 05:51.520
investigation,

141
05:51.520 --> 05:55.360
either regarding this destination IP address, or the source client, or if we

142
05:55.360 --> 05:56.240
had user authentication

143
05:56.240 --> 05:59.520
set up for the source user. And again, by drilling down, we're starting here

144
05:59.520 --> 06:00.880
under 40 view with threats
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

144
05:59.520 --> 06:00.880
under 40 view with threats

145
06:00.880 --> 06:04.300
with top threats, it's actually showing us the log view information here,

146
06:04.300 --> 06:05.040
including using this

147
06:05.040 --> 06:07.930
filter, so that we don't have to go back to log view separately and start

148
06:07.930 --> 06:08.960
digging there. We can

149
06:08.960 --> 06:12.370
just go ahead and see it right here. So I go ahead and close that filter, just

150
06:12.370 --> 06:13.280
taking this back to

151
06:13.280 --> 06:17.530
the top threats and 40 view looking for the threat dark side. And we can remove

152
06:17.530 --> 06:18.720
that filter as well,

153
06:18.720 --> 06:21.600
just by clicking here to remove that filter. So then we're going to go back to

154
06:21.600 --> 06:22.080
top threats,

155
06:22.080 --> 06:25.010
we can click here on top threats or just click on the top tile for top threats

156
06:25.010 --> 06:26.160
either way. Also,

157
06:26.160 --> 06:29.950
in this version of 40 analyzer, if we click on this icon right here, it'll put

158
06:29.950 --> 06:30.880
those top threats,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

158
06:29.950 --> 06:30.880
those top threats,

159
06:30.880 --> 06:34.320
threat map indicators of compromise on the left hand side, who want to move

160
06:34.320 --> 06:35.120
them back to the top,

161
06:35.120 --> 06:38.450
we click here on toggle horizontal menu, puts them back on the top, either way

162
06:38.450 --> 06:39.040
is great. So

163
06:39.040 --> 06:42.640
here in our 40 view threats, next to top notes, we have a threat map. In fact,

164
06:42.640 --> 06:43.200
there's a lot of

165
06:43.200 --> 06:46.820
different map options available in 40 view. There's also indicators of

166
06:46.820 --> 06:48.000
compromise. So let me go

167
06:48.000 --> 06:52.430
ahead and specify the last 30 days. And here showing us indicator of compromise

168
06:52.430 --> 06:54.160
regarding AD-user

169
06:54.160 --> 06:58.120
three and this source IP address. So let me go ahead and minimize this left

170
06:58.120 --> 06:59.120
hand side here by

171
06:59.120 --> 07:01.950
clicking on the little hamburger menu that'll push it over here on the left.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

171
06:59.120 --> 07:01.950
clicking on the little hamburger menu that'll push it over here on the left.

172
07:01.950 --> 07:02.480
Then once again,

173
07:02.480 --> 07:06.130
if we want to remove or add columns, we can go ahead and do so right here to

174
07:06.130 --> 07:06.960
control which columns

175
07:06.960 --> 07:11.090
are showing up. All right, so for this AD user three, let's go ahead and double

176
07:11.090 --> 07:12.480
click on source

177
07:12.480 --> 07:16.230
user IP. So now the source user IP is AD-user three, and showing us the

178
07:16.230 --> 07:17.440
operating system,

179
07:17.440 --> 07:21.920
the log types, traffic, web filter, and attack, including security actions and

180
07:21.920 --> 07:22.400
the verdict,

181
07:22.400 --> 07:26.200
which indicates that this device may be infected. So also showing this here who

182
07:26.200 --> 07:27.040
's reporting that,

183
07:27.040 --> 07:31.110
it's HQ firewall one, which has effectively this serial number. Then if we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

183
07:27.040 --> 07:31.110
it's HQ firewall one, which has effectively this serial number. Then if we

184
07:31.110 --> 07:31.520
double click,

185
07:31.520 --> 07:34.630
it'll go ahead and give us more details regarding that log. Here it's

186
07:34.630 --> 07:35.920
indicating that that outbound

187
07:35.920 --> 07:39.750
traffic is part of a botnet command and control communications very likely

188
07:39.750 --> 07:41.280
because of an IP address

189
07:41.280 --> 07:44.870
associated with command and control networks, showing us the source information

190
07:44.870 --> 07:45.600
, including the

191
07:45.600 --> 07:50.230
user AD-user three, the source address of AD-user three, the incoming port that

192
07:50.230 --> 07:51.120
traffic came in on

193
07:51.120 --> 07:54.400
on firewall one. If we scroll down, here's the destination of France and the e

194
07:54.400 --> 07:55.120
gress are outbound

195
07:55.120 --> 07:59.140
interface and the destination port, which implies it was trying to use HTTP as

196
07:59.140 --> 08:00.160
shown right here in
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

196
07:59.140 --> 08:00.160
shown right here in

197
08:00.160 --> 08:03.360
the service field. So if we scroll down, the action was detected. So the

198
08:03.360 --> 08:04.480
firewall knows about it,

199
08:04.480 --> 08:09.320
but unfortunately that traffic was allowed because of the profile called all

200
08:09.320 --> 08:10.560
default pass,

201
08:10.560 --> 08:14.000
which must be in monitor only mode for that type of threat because it saw it,

202
08:14.000 --> 08:14.960
but it didn't stop it.

203
08:14.960 --> 08:18.110
Then here's the attack name and where the traffic was going. So effectively you

204
08:18.110 --> 08:19.040
're going out to that

205
08:19.040 --> 08:22.320
command and control network address. Here's a hyperlink for more information.

206
08:22.320 --> 08:22.960
There's the event

207
08:22.960 --> 08:26.390
type. It's also showing us how that user was authenticated and other details

208
08:26.390 --> 08:27.280
about that outbound

209
08:27.280 --> 08:31.100
session. So again, once we drill down here, starting from four to view, it's
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

209
08:27.280 --> 08:31.100
session. So again, once we drill down here, starting from four to view, it's

210
08:31.100 --> 08:32.160
actually taking us as we

211
08:32.160 --> 08:35.560
drill down to the details based on the logs. So let me expand the left hand

212
08:35.560 --> 08:36.800
side again and let's do a

213
08:36.800 --> 08:39.690
quick peek at a few other options here in four to view. So we go to traffic, we

214
08:39.690 --> 08:40.800
're effectively looking

215
08:40.800 --> 08:45.710
at the traffic logs imported or looking through the lens of four to view with

216
08:45.710 --> 08:46.640
these pre-built

217
08:46.640 --> 08:50.900
outputs. Also be aware that if you just power up your 40 analyzer, some of

218
08:50.900 --> 08:52.160
these options may not be

219
08:52.160 --> 08:55.310
available yet. They may be grayed out until that traffic has been received from

220
08:55.310 --> 08:56.240
the 40 gates and

221
08:56.240 --> 09:00.540
actually put into the SQL database. So here we're seeing based on color coding,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

221
08:56.240 --> 09:00.540
actually put into the SQL database. So here we're seeing based on color coding,

222
09:00.540 --> 09:02.240
block versus pass.

223
09:02.240 --> 09:05.400
So that's the traffic that was allowed through. And that's the traffic that was

224
09:05.400 --> 09:06.240
blocked. And again,

225
09:06.240 --> 09:09.870
we can drill down anywhere we need to. So here for 80 user seven, if we double

226
09:09.870 --> 09:10.720
click, we're drilling

227
09:10.720 --> 09:14.280
down with that filter in place effectively. And now everything here is filter

228
09:14.280 --> 09:15.200
showing just that

229
09:15.200 --> 09:19.920
user and the source address of 10700107. Then we have sort based on the number

230
09:19.920 --> 09:20.320
of bytes

231
09:20.320 --> 09:24.100
sent and received, we can click on that column. And it looks like this is a

232
09:24.100 --> 09:25.040
pretty heavy duty

233
09:25.040 --> 09:28.340
Netflix user based on the quantity of traffic. As far as the sessions are

234
09:28.340 --> 09:29.920
concerned, the biggest

235
09:29.920 --> 09:33.740
number of sessions were DNS requests. So across the top here for the 40 view
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

235
09:29.920 --> 09:33.740
number of sessions were DNS requests. So across the top here for the 40 view

236
09:33.740 --> 09:34.800
traffic, we have top

237
09:34.800 --> 09:38.640
sources, top source addresses, top destinations, we'll just take a peek at a

238
09:38.640 --> 09:39.840
few of these. And that

239
09:39.840 --> 09:43.420
way can help us build a baseline of what normal looks like. So if we look at

240
09:43.420 --> 09:44.000
sessions, let me

241
09:44.000 --> 09:48.160
sort based on sessions, most of the sessions that are being reported into this

242
09:48.160 --> 09:49.120
40 analyzer,

243
09:49.120 --> 09:52.350
and again, this is from all devices over the past week, in fact, let me go

244
09:52.350 --> 09:53.920
ahead and say last

245
09:53.920 --> 09:58.880
two weeks, most of the sessions are DNS requests going out to 8888. And now I

246
09:58.880 --> 09:59.520
have others going

247
09:59.520 --> 10:04.090
out to these two addresses. And I think these are the two fordnet based DNS
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

247
09:59.520 --> 10:04.090
out to these two addresses. And I think these are the two fordnet based DNS

248
10:04.090 --> 10:05.040
servers to verify

249
10:05.040 --> 10:08.100
that we could double click on it, take a closer look at what's really going on.

250
10:08.100 --> 10:09.920
So TCP 853,

251
10:09.920 --> 10:15.040
and that is for DNS over TLS. So some of our clients are using DNS over TLS for

252
10:15.040 --> 10:15.680
secure DNS

253
10:15.680 --> 10:19.330
requests, we double click on that, it'll go ahead and take us to the log view

254
10:19.330 --> 10:20.400
with that filter in

255
10:20.400 --> 10:25.390
place. So as far as who's making those requests, I've got 23 1.2.51, which is

256
10:25.390 --> 10:26.720
firewall one, I've got

257
10:26.720 --> 10:32.790
10.123.0.53 that's firewall three and that's firewall two. So most of these DNS
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

257
10:26.720 --> 10:32.790
10.123.0.53 that's firewall three and that's firewall two. So most of these DNS

258
10:32.790 --> 10:33.360
over TLS

259
10:33.360 --> 10:37.410
requests are coming, it looks like from the firewalls themselves, as they're

260
10:37.410 --> 10:38.800
doing DNS requests. But

261
10:38.800 --> 10:42.350
this is a quick and easy way to drill down, see a big picture of what's

262
10:42.350 --> 10:43.200
happening. So something

263
10:43.200 --> 10:47.320
looks wrong, or you're like, what is that exactly? We have the opportunity to

264
10:47.320 --> 10:48.320
dig down in and take a

265
10:48.320 --> 10:51.640
look. So if you want to go one step back, we can just remove the log view

266
10:51.640 --> 10:52.640
portion there. And that

267
10:52.640 --> 10:55.670
takes us back to the previous that we could go ahead and remove application.

268
10:55.670 --> 10:56.480
And that takes us

269
10:56.480 --> 10:59.660
back to top destinations without the filters. If you want to click on top

270
10:59.660 --> 11:00.800
destination addresses,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

270
10:59.660 --> 11:00.800
destination addresses,

271
11:00.800 --> 11:04.070
then we could also choose like, for example, top country slash region. And that

272
11:04.070 --> 11:04.560
's for the last

273
11:04.560 --> 11:08.150
hour. So if you want to narrow it down to a specific timeframe, you can, for

274
11:08.150 --> 11:08.720
this demo,

275
11:08.720 --> 11:11.830
let me go ahead and just say the last, let's say the last three weeks. And that

276
11:11.830 --> 11:12.880
's going to show us

277
11:12.880 --> 11:17.520
our top country slash region, including blocks and passes. We have some blocks

278
11:17.520 --> 11:18.320
in yellow and the

279
11:18.320 --> 11:21.580
passes in blue. So if we double clicked on the United Kingdom, once again, it

280
11:21.580 --> 11:22.560
filters it down just

281
11:22.560 --> 11:25.540
for destination country equals United Kingdom, and then we could take a closer

282
11:25.540 --> 11:26.320
look there as well.

283
11:26.320 --> 11:29.760
Again, with the yellow indicating a block where it didn't allow the traffic and

284
11:29.760 --> 11:30.240
the blue
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

284
11:29.760 --> 11:30.240
the blue

285
11:30.240 --> 11:32.690
representing where it allowed the traffic to go through. So an interesting

286
11:32.690 --> 11:33.520
question might be,

287
11:33.520 --> 11:37.620
why did some NTP that was going to the United Kingdom? Why did some get allowed

288
11:37.620 --> 11:38.080
and some get

289
11:38.080 --> 11:42.050
not allowed? And we can solve that by double clicking on NTP, where it would

290
11:42.050 --> 11:42.800
take us to the

291
11:42.800 --> 11:45.770
log view again, and then we can take a look at the detailed information here in

292
11:45.770 --> 11:46.320
the logs.

293
11:46.320 --> 11:49.440
So we could add a filter, right? So be going to the action column where it has

294
11:49.440 --> 11:50.160
a check mark,

295
11:50.160 --> 11:53.760
and we can go and say, Oh, I see everything where the action is not all except.

296
11:53.760 --> 11:54.160
And that would put

297
11:54.160 --> 12:00.120
in the filter to give us an idea of what's happening. So, oh, I see, on my fire
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

297
11:54.160 --> 12:00.120
in the filter to give us an idea of what's happening. So, oh, I see, on my fire

298
12:00.120 --> 12:00.640
walls,

299
12:00.640 --> 12:05.050
I have authentication set up on firewall one. And so these devices were

300
12:05.050 --> 12:06.720
attempting to do NTP

301
12:06.720 --> 12:11.660
requests out to NTP servers based on these destination IP addresses. But until

302
12:11.660 --> 12:12.720
they authenticated,

303
12:12.720 --> 12:16.180
the firewall said, you know what, I'll let you do some DNS requests, but I'm

304
12:16.180 --> 12:16.480
not going to let

305
12:16.480 --> 12:21.360
you do other things like NTP or HTTP or HTTPS out to the public internet based

306
12:21.360 --> 12:22.560
on policy until I know

307
12:22.560 --> 12:26.160
who you are. So one of the cool things about a tool like 40 Analyzer and 40 of

308
12:26.160 --> 12:27.280
you is we can drill

309
12:27.280 --> 12:30.710
down and find out, okay, what exactly is this? Do some research and then
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

309
12:27.280 --> 12:30.710
down and find out, okay, what exactly is this? Do some research and then

310
12:30.710 --> 12:31.920
identify, okay, this is

311
12:31.920 --> 12:34.990
okay, this is natural, it should be happening this way. Or is there some other

312
12:34.990 --> 12:35.680
bigger problem,

313
12:35.680 --> 12:38.830
like a misconfiguration, a policy, or something else that's wrong on the

314
12:38.830 --> 12:39.760
network? And again,

315
12:39.760 --> 12:43.370
a tool like 40 Analyzer gives us a chance to dig down in and see what's really

316
12:43.370 --> 12:44.000
happening.

317
12:44.000 --> 12:47.440
As far as policy hits, we can click on the policy hits tab. This is for the

318
12:47.440 --> 12:48.320
past week. Let me go

319
12:48.320 --> 12:53.010
ahead and say the past two weeks, press enter. And this is showing us the firew

320
12:53.010 --> 12:54.160
alls and the actual

321
12:54.160 --> 12:57.350
policy names that are being matched on. And if you want to see which ones have

322
12:57.350 --> 12:58.160
the most sessions,

323
12:58.160 --> 13:00.960
we can click right here on sessions to sort by sessions. And this would
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

323
12:58.160 --> 13:00.960
we can click right here on sessions to sort by sessions. And this would

324
13:00.960 --> 13:02.240
indicate that this firewall

325
13:02.240 --> 13:07.570
policy into out on HQ firewall one is permitting the most traffic that's going

326
13:07.570 --> 13:08.800
out to the public

327
13:08.800 --> 13:12.510
internet. And again, we could drill down to take a look at the actual logs is

328
13:12.510 --> 13:13.760
taking us to log view

329
13:13.760 --> 13:16.980
with that filter in place to take a look at the details here. And then if we

330
13:16.980 --> 13:17.840
click on DNS logs,

331
13:18.160 --> 13:20.930
and once again, we might sure we're looking at the correct timeframe that we're

332
13:20.930 --> 13:21.680
interested in,

333
13:21.680 --> 13:25.080
I'm going to specify the last three weeks. And this is showing us our DNS logs.

334
13:25.080 --> 13:25.760
So here with the

335
13:25.760 --> 13:29.700
yellow, it indicates that is not allowed that traffic. And that's for the

336
13:29.700 --> 13:30.800
domain name CPTH dash
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

336
13:29.700 --> 13:30.800
domain name CPTH dash

337
13:30.800 --> 13:34.210
C and T dot com. And that must be due to a policy. But if we're not sure, once

338
13:34.210 --> 13:35.280
again, we can double

339
13:35.280 --> 13:39.080
click, look at the details of that. So it's user to those trying that. And we

340
13:39.080 --> 13:40.240
double click again,

341
13:40.240 --> 13:43.390
it'll bring us to the log view to take a closer look at what's going on them

342
13:43.390 --> 13:44.400
from here. We can

343
13:44.400 --> 13:48.680
look at the details of one of those events scroll down and then identify why it

344
13:48.680 --> 13:49.600
was blocked. So the

345
13:49.600 --> 13:52.330
action was done based on a UTM block. And that's going to be due to our

346
13:52.330 --> 13:53.600
security profiles associated

347
13:53.600 --> 13:57.940
with our policies that in this case, I believe are looking for command and

348
13:57.940 --> 13:59.280
control or malicious

349
13:59.280 --> 14:03.760
networks where DNS and hey, that's in that category. And it prevented the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

349
13:59.280 --> 14:03.760
networks where DNS and hey, that's in that category. And it prevented the

350
14:03.760 --> 14:05.600
resolution of that IP address.

351
14:05.600 --> 14:10.240
So this case user to this IP address did those DNS requests. However, the

352
14:10.240 --> 14:12.000
responses never were

353
14:12.000 --> 14:16.340
sent back to the client so the client can never get to the actual IP address

354
14:16.340 --> 14:17.920
behind that domain.

355
14:17.920 --> 14:21.920
If you scroll down and for the decision here, they were trying to resolve this

356
14:21.920 --> 14:23.040
name right here.

357
14:23.040 --> 14:26.850
So as a test, we could bring up another client, let's bring up 80 user three.

358
14:26.850 --> 14:28.080
So here is 80 user

359
14:28.080 --> 14:32.550
three on PC three, let me just confirm a few details, including its IP address.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

359
14:28.080 --> 14:32.550
three on PC three, let me just confirm a few details, including its IP address.

360
14:32.550 --> 14:32.960
Let's do an

361
14:32.960 --> 14:40.040
IF config here. Its IP address is 1030.0.103. And currently it was just 80 user

362
14:40.040 --> 14:41.200
two at 1020

363
14:41.200 --> 14:45.120
0102. So this is a different computer, different user. And let's do an NS

364
14:45.120 --> 14:46.640
lookup for that name of

365
14:46.640 --> 14:53.600
CPTH dash CANT.com. So here's the answers the client got back but 1040 0100 is

366
14:53.600 --> 14:54.800
an RC 1918 address.

367
14:54.800 --> 14:58.980
And that's because the firewall has been configured to return that address

368
14:58.980 --> 15:00.240
instead of the real address.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

368
14:58.980 --> 15:00.240
instead of the real address.

369
15:00.240 --> 15:03.440
And as a result, let me go ahead and close that window and minimize that.

370
15:03.440 --> 15:06.480
Try to get this filter in place. Let me remove that filter and let me go back

371
15:06.480 --> 15:07.600
to source and let

372
15:07.600 --> 15:11.460
me go ahead and log v as well. And I still have in my source 80 user two. So go

373
15:11.460 --> 15:12.480
ahead and clear

374
15:12.480 --> 15:16.410
the filter altogether and go back to DNS logs and let me click on refresh. I

375
15:16.410 --> 15:16.800
also could have just

376
15:16.800 --> 15:20.480
gone to DNS logs and started that way as well. So here is still showing five.

377
15:20.480 --> 15:21.680
If we double click on

378
15:21.680 --> 15:25.880
that is still showing all 80 user two. So even though I think the firewalls are

379
15:25.880 --> 15:26.720
all configured

380
15:26.720 --> 15:30.450
to immediately send the logs, it may take a moment or two for those logs to be
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

380
15:26.720 --> 15:30.450
to immediately send the logs, it may take a moment or two for those logs to be

381
15:30.450 --> 15:31.600
injected into the

382
15:31.600 --> 15:35.610
SQL database. And then after it's in the SQL database, that information can

383
15:35.610 --> 15:36.320
show up here

384
15:36.320 --> 15:40.820
in the four to view dashboards. So we go back to traffic DNS logs and again, I

385
15:40.820 --> 15:41.200
'm going to get

386
15:41.200 --> 15:45.400
that a moment and it should be showing up right here. And there it is. It shows

387
15:45.400 --> 15:46.560
seven. It was five.

388
15:46.560 --> 15:49.440
And now at seven. So let's go ahead and double click on that here showing

389
15:49.440 --> 15:50.960
number of clients to

390
15:50.960 --> 15:56.560
including the client at 1031.03 with two. And here, oh, look at that. It's

391
15:56.560 --> 15:57.600
showing as

392
15:57.600 --> 16:00.760
responded. So we double click on that. And then let's go ahead and open up one
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

392
15:57.600 --> 16:00.760
responded. So we double click on that. And then let's go ahead and open up one

393
16:00.760 --> 16:01.600
of those. This is

394
16:01.600 --> 16:06.150
firewall three that's reporting that effectively it allowed it. And if you look

395
16:06.150 --> 16:07.200
at the other one,

396
16:07.200 --> 16:10.960
this is also firewall three reporting it allowed it. However, oh, this is

397
16:10.960 --> 16:12.400
fascinating because

398
16:12.400 --> 16:16.730
what we're seeing here is information from firewall three. But the actual

399
16:16.730 --> 16:18.240
response that came back

400
16:18.240 --> 16:23.360
was from firewall one, which supplied that 1040 0100 address. So from firewall

401
16:23.360 --> 16:24.320
three's perspective,

402
16:24.320 --> 16:28.490
it didn't have any policies that blocked it. It was firewall one. So firewall

403
16:28.490 --> 16:29.280
three itself

404
16:29.280 --> 16:34.000
didn't block that DNS requests, but firewall one did because firewall one has
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

404
16:29.280 --> 16:34.000
didn't block that DNS requests, but firewall one did because firewall one has

405
16:34.000 --> 16:34.640
those policies in

406
16:34.640 --> 16:39.900
place and firewall three doesn't. So we go back to 40 analyzer and let's go to

407
16:39.900 --> 16:41.760
security and DNS.

408
16:41.760 --> 16:46.400
And I want to filter down just to firewall one and take a look at the logs. And

409
16:46.400 --> 16:46.560
that way,

410
16:46.560 --> 16:49.280
I don't have to wait for information to go through four to view or into the SQL

411
16:49.280 --> 16:50.160
database. See the

412
16:50.160 --> 16:54.240
details. So I'm going to remove all the devices and just go to firewall one,

413
16:54.240 --> 16:55.520
click on OK. And sure

414
16:55.520 --> 17:00.150
enough, there's the two DNS requests from 80 user three. And based on the times
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

414
16:55.520 --> 17:00.150
enough, there's the two DNS requests from 80 user three. And based on the times

415
17:00.150 --> 17:00.800
that let's go ahead

416
17:00.800 --> 17:05.260
and just say last 30 minutes is great. There they are. And oh, one was for the

417
17:05.260 --> 17:06.080
A record and one was

418
17:06.080 --> 17:09.140
for a quad A record. Let's double click on the A record and we scroll down this

419
17:09.140 --> 17:09.760
warning. And

420
17:09.760 --> 17:13.460
here showing us domain was blocked by DNS botnet command and control at

421
17:13.460 --> 17:14.560
firewall one. And that's

422
17:14.560 --> 17:18.160
why I gave back the bogus address. Let's also verify that for the quad A record

423
17:18.160 --> 17:19.760
. So if we scroll down

424
17:19.760 --> 17:23.830
and it was also blocked based on policy on firewall ones. So I believe in a

425
17:23.830 --> 17:24.640
moment or two,

426
17:24.640 --> 17:29.120
it will also show that that traffic was denied, but at firewall one. And those

427
17:29.120 --> 17:29.520
are all part of

428
17:29.520 --> 17:33.450
the same security fabric. So in time, they'll be reflected here as well. So as
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

428
17:29.520 --> 17:33.450
the same security fabric. So in time, they'll be reflected here as well. So as

429
17:33.450 --> 17:34.400
we continue down

430
17:34.400 --> 17:38.390
with 40 view, let's go to shadow it just show you what's there. So here we have

431
17:38.390 --> 17:40.240
top cloud applications.

432
17:40.240 --> 17:43.890
Again, we can change the timeframe we're looking for. So I'll go ahead and say

433
17:43.890 --> 17:45.440
past three weeks.

434
17:45.440 --> 17:49.040
I also want to make sure we're looking at all devices, which we are doing a

435
17:49.040 --> 17:50.000
sort, for example,

436
17:50.000 --> 17:54.240
based on videos played. And it looks like right here, YouTube 18 videos played

437
17:54.240 --> 17:54.800
if we double click

438
17:54.800 --> 17:58.450
on that once again, it'll bring a filter in place for YouTube. And as far as

439
17:58.450 --> 17:59.120
video played,

440
17:59.120 --> 18:03.860
we'll sort that they're showing us the source address is 1070 107, which is PC
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

440
17:59.120 --> 18:03.860
we'll sort that they're showing us the source address is 1070 107, which is PC

441
18:03.860 --> 18:04.960
seven is playing

442
18:04.960 --> 18:08.450
the most videos as shown right here. Then still with a 40 few dashboards, if we

443
18:08.450 --> 18:09.200
go to applications

444
18:09.200 --> 18:13.040
and websites, once again, a great pre collection of tools we can use to see

445
18:13.040 --> 18:14.400
what's happening. So

446
18:14.400 --> 18:17.970
here we have which devices we're going to be looking at the timeframe, which

447
18:17.970 --> 18:18.640
currently is set

448
18:18.640 --> 18:21.360
to one week. I'll go ahead and change that to the last three weeks. Here's the

449
18:21.360 --> 18:22.160
block and pass

450
18:22.160 --> 18:25.660
information for that timeframe. And regarding the top applications, like many

451
18:25.660 --> 18:26.400
features inside a

452
18:26.400 --> 18:29.640
40 analyzer, we can customize it. So we'll go to the hamburger menu, go to

453
18:29.640 --> 18:30.640
settings, and then we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

453
18:29.640 --> 18:30.640
settings, and then we

454
18:30.640 --> 18:34.900
can specify the chart type stack bar or bar or table or bubble. And then we'll

455
18:34.900 --> 18:36.240
go ahead and click on

456
18:36.240 --> 18:40.270
OK. So those are the bubble version for the top 10. We're getting top

457
18:40.270 --> 18:41.440
applications. Anyone

458
18:41.440 --> 18:44.180
want to change that to the top 20, for example, go back to settings and say,

459
18:44.180 --> 18:44.960
you know what, I want

460
18:44.960 --> 18:49.650
to see the top 20 just by selecting 20 and clicking on OK. And there we have it

461
18:49.650 --> 18:50.160
. So a couple of

462
18:50.160 --> 18:54.620
other options here is in our settings, let's go back to a table and top 100

463
18:54.620 --> 18:55.600
will click on OK.

464
18:55.600 --> 18:58.480
And then it shows us the top 100. So then from here, if we want to sort based

465
18:58.480 --> 18:59.840
on risk level, we can

466
18:59.840 --> 19:03.310
sort based on that column, and then we can drill down, for example, in the RDP
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

466
18:59.840 --> 19:03.310
sort based on that column, and then we can drill down, for example, in the RDP

467
19:03.310 --> 19:04.480
and VNC, which

468
19:04.480 --> 19:08.140
appears the highest risk level of applications that have been reported into the

469
19:08.140 --> 19:09.120
40 analyzer.

470
19:09.120 --> 19:12.920
So going across the top, there's top website domains. Again, we can control the

471
19:12.920 --> 19:13.760
timeframe.

472
19:13.760 --> 19:17.280
So I'll go ahead and say last number of weeks is three. We could also specify a

473
19:17.280 --> 19:17.920
narrow down to

474
19:17.920 --> 19:21.560
which devices we want to look at. Here's top website categories. Again, I'm

475
19:21.560 --> 19:21.920
going to change

476
19:21.920 --> 19:25.130
it to the last three weeks, pulling on the log information that's down on the

477
19:25.130 --> 19:25.760
SQL database

478
19:25.760 --> 19:29.800
from all devices. And here for proxy avoidance, for example, there's a lot of

479
19:29.800 --> 19:30.400
traffic that's
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

479
19:29.800 --> 19:30.400
traffic that's

480
19:30.400 --> 19:33.000
been allowed. So that'd be a great one to investigate. So go ahead and double

481
19:33.000 --> 19:34.080
click on proxy avoidance.

482
19:34.480 --> 19:37.670
Which puts it in as a filter. And once again, we could double click to drill

483
19:37.670 --> 19:38.720
further and see the

484
19:38.720 --> 19:43.030
detailed log information that's supporting these views here inside of 40 view.

485
19:43.030 --> 19:44.000
So here for the top

486
19:44.000 --> 19:48.120
browsing users, let's go ahead and change the timeframe to the last three weeks

487
19:48.120 --> 19:48.960
. And here we

488
19:48.960 --> 19:52.970
have based on browsing time and bytes sent to received in a number of sites

489
19:52.970 --> 19:54.320
visited. Looks like

490
19:54.320 --> 19:59.780
our winner for the most browsing time, this source IP address right here, 1020.

491
19:59.780 --> 20:00.960
102. If we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

491
19:59.780 --> 20:00.960
102. If we

492
20:00.960 --> 20:05.390
double click on that, that's been a very, very busy computer. And here are the

493
20:05.390 --> 20:06.240
details regarding

494
20:06.240 --> 20:09.320
what they were doing. And once again, we could drill down by double clicking

495
20:09.320 --> 20:10.240
here and would take

496
20:10.240 --> 20:14.360
us for the filter with the individual logs for that activity. And then still

497
20:14.360 --> 20:15.680
with 40 view dashboards,

498
20:15.680 --> 20:20.920
we have VPN. As an example, we've got a site to site over the last two weeks

499
20:20.920 --> 20:21.920
here showing us traffic

500
20:21.920 --> 20:26.050
for an IP [garbled] site site tunnel. And we've got a system again, under a 40 view

501
20:26.050 --> 20:26.960
system, we have to

502
20:26.960 --> 20:30.070
have for admin logins. And it's currently showing the past week. I'm going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

502
20:26.960 --> 20:30.070
have for admin logins. And it's currently showing the past week. I'm going to

503
20:30.070 --> 20:30.880
go ahead and say the

504
20:30.880 --> 20:34.070
past two weeks by putting that in and pressing enter. Looks like this user

505
20:34.070 --> 20:34.960
admin has been very

506
20:34.960 --> 20:40.050
busy and has had 40 logins over the past two weeks with one failed login, which

507
20:40.050 --> 20:40.960
was probably

508
20:40.960 --> 20:44.810
just a typo. Also shows here the number of configuration changes. So we could

509
20:44.810 --> 20:45.920
double click. This is now

510
20:45.920 --> 20:49.300
taking us to the log view with the filter in place for admin. And then we get

511
20:49.300 --> 20:50.480
down here to alert

512
20:50.480 --> 20:53.760
and double click. This is a log message regarding a configuration change. If we

513
20:53.760 --> 20:54.720
go to system events,

514
20:54.720 --> 20:58.020
and again, I'll put in two weeks, and then we get sort by severity. And we can

515
20:58.020 --> 20:58.480
then further

516
20:58.480 --> 21:01.990
investigate some of these issues or challenges. So sometimes if I lab, I'll
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

516
20:58.480 --> 21:01.990
investigate some of these issues or challenges. So sometimes if I lab, I'll

517
21:01.990 --> 21:03.120
bring up my devices in

518
21:03.120 --> 21:06.800
not the optimal order, for example, I'll bring up the 40 gates first, and I'll

519
21:06.800 --> 21:07.440
bring up the switch

520
21:07.440 --> 21:10.210
that connects them all, and then I'll bring up for the analyzer. And so

521
21:10.210 --> 21:11.760
sometimes we may have some

522
21:11.760 --> 21:15.580
issues there until it all gets dialed in. But once again, we could double click

523
21:15.580 --> 21:16.240
on any of these to

524
21:16.240 --> 21:19.390
go to the actual logs and take a closer look. Then we have a tab for resource

525
21:19.390 --> 21:20.000
usage. Again,

526
21:20.000 --> 21:24.000
I'll take a look at the last two weeks. So wherever the last two weeks, we have

527
21:24.000 --> 21:25.680
our four firewalls.

528
21:25.680 --> 21:30.540
And it's actually showing us five because branch firewall one is in an HA pair.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

528
21:25.680 --> 21:30.540
And it's actually showing us five because branch firewall one is in an HA pair.

529
21:30.540 --> 21:31.440
So we have firewall

530
21:31.440 --> 21:35.310
one, two, and three, the headquarters location, then branch firewall one, and

531
21:35.310 --> 21:36.320
it's HA pair at the

532
21:36.320 --> 21:40.850
branch location. And here it's showing CPU usage, memory usage, disk usage, etc

533
21:40.850 --> 21:41.920
. Which is a great way

534
21:41.920 --> 21:45.640
of having a big picture view of what's going on on our network. And as far as

535
21:45.640 --> 21:46.480
resource usage

536
21:46.480 --> 21:50.430
peak, we scroll down and let's go to logs per second. So for the resource peak

537
21:50.430 --> 21:50.800
usage,

538
21:50.800 --> 21:58.160
firewall one wins that award with 37,704 logs per second with 1,857 concurrent

539
21:58.160 --> 21:58.960
sessions. And then

540
21:58.960 --> 22:02.220
for failed authentication attempts, which was also super useful to look for
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

540
21:58.960 --> 22:02.220
for failed authentication attempts, which was also super useful to look for

541
22:02.220 --> 22:03.040
attacks and

542
22:03.040 --> 22:06.650
people trying to log into our systems who are not authorized to do so. And

543
22:06.650 --> 22:07.200
doing, for example,

544
22:07.200 --> 22:11.070
like a brute force attack, let's take a look at the last three weeks. And I

545
22:11.070 --> 22:12.320
have the admin user

546
22:12.320 --> 22:16.010
here who failed to log in coming from the source IP address. And it looks like

547
22:16.010 --> 22:16.880
he was trying to log

548
22:16.880 --> 22:20.200
into the management IP address on firewall two based on the IP address. And

549
22:20.200 --> 22:20.960
then I also have some

550
22:20.960 --> 22:25.210
authentication failures for the authentication of the AP sec tunnels. That's

551
22:25.210 --> 22:26.160
because I reboot

552
22:26.160 --> 22:30.100
these firewalls almost daily. And so initially, if one comes up earlier or late
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

552
22:26.160 --> 22:30.100
these firewalls almost daily. And so initially, if one comes up earlier or late

553
22:30.100 --> 22:30.720
, I'm going to take

554
22:30.720 --> 22:34.560
a few attempts for the authentication of the IP sec tunnel. So for the admin

555
22:34.560 --> 22:35.440
authentication

556
22:35.440 --> 22:38.540
failure, if you double click on that, here's the details, go and double click

557
22:38.540 --> 22:39.280
and take a look at

558
22:39.280 --> 22:43.440
firewall two and admin login failed. Probably due to a typo, as I was putting

559
22:43.440 --> 22:44.080
my password,

560
22:44.080 --> 22:47.050
which I tried again, then it worked. However, if we have a lot of these, they'd

561
22:47.050 --> 22:47.760
be super important

562
22:47.760 --> 22:48.400
to be aware of.

563
22:48.400 --> 22:57.940
[BLANK_AUDIO]