Now, once the 40 analyzer has received the logs and taken a moment or two to
insert them into the SQL database,
we can at that moment take advantage of another feature inside of 40 Analyzer
called "Forty View".
So over the past week or so, I've been sending log information from these four
firewalls,
and they're all going to the root administrative domain on the 40 Analyzer.
So because the logs are sitting there and have been injected into the SQL
database,
let's head over to the 40 Analyzer and take a look at how we can leverage
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
for the view. So here is the 40 Analyzer. Now, since the last video, I actually
had to sleep.
So this is the next day. So we have some more logs that have also been sent to
the 40 Analyzer,
and the 40 Analyzer has been up for an hour and 16 minutes. Also, let me just
log off for a moment.
I'll log back in, supply the password, click "Log In", and because we set up
administrative domains,
it's also going to prompt me right here regarding which administrative domain I
want to jump into.
So we want to go to the root "ADOM", because that's where our four 48 firewalls
are. So we'll click here
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
on the root administrative domain, and away we go. Now, in the previous video,
we focused on the logs,
and did that. We went to the "Log View" section, went to "Logs", and then we
worked with the logs from here.
So if we go to "Fortnite Logs", then we have "Logs for Traffic", "Logs for
Security", and also "Logs for
Events". And because 40 Analyzer has now added all that log information into
the SQL database,
we can now take advantage of this other option right here called "Forty View".
Now, here in the
"Forty View", before the line here, these one, two, three, four, five, six at
the moment with this
version of 40 Analyzer, these are all considered to be "Forty View" dashboards. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
version of 40 Analyzer, these are all considered to be "Forty View" dashboards.
And then below the
line, these are referred to as "Forty View" monitors. So under "Forty View", if
we click on "Threats", at the
top left, we'll go ahead and start off with "Top Threats". And then we can
specify our time frame. So for
the last two weeks, and currently we have all devices selected, we can also
limit the time frame
here, we can also limit the devices we're looking at, but I'm going to leave it
set for two weeks
at all devices. So here, we're showing that time frame, the last two weeks, and
we have color-coded for
"Top Threats", we're getting low, medium, high, and critical. And then below, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
"Top Threats", we're getting low, medium, high, and critical. And then below,
we can sort based on
the columns. So we want to sort based on the threat level, we can click here,
and that's sorting on
the threat level. We'll click again, it'll do the inverse sorting, showing the
critical levels at
the top, then high, then medium, and then low. We also can sort on the threat
or the threat type.
So if we click here on "Threat Type" and for threats where there's a CVE ID
associated with it,
we could also sort based on CVE ID. And then here in the gear, if we want to
remove columns that we
don't need to see, we can click on the gear. And then from here, we can choose
the columns that
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
show up in this table. And then just like most things in "40 Analyzer", if we
want to investigate
something further, we can go ahead and double click on it. So here's the dark
side threats,
we'll double click on that. And the blue here represents "Pass", which means we
forwarded the
traffic. So if we wanted to look at that further, if we double click on that
entry, what it's actually
doing in the background is taking us to Log View right here without physically
taking this to Log View,
but showing us the Log View based on this filter, where a threat equals dark
side,
with no username specified, and the source IP address is 10300103. So because
the threat level is
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
critical, we might want to dig deeper and find out what's going on with this
Linux client going
to that IP address. So if we can just double click on one of these, that'll
show us the details,
so scroll down, take a look. So if we look at the details and scroll down, the
source is this IP
address 10.30.0.103, coming in on V30 interface, and it's coming in on HQ
firewall three, it has the name
of Linux client for that device. The source port is 40,208, and the destination
is going to
this IP address 185 105 119, which is associated with the Russian Federation, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this IP address 185 105 119, which is associated with the Russian Federation,
and the destination
port is 443. And that traffic was allowed to go through. So there's the threat
name, dark side,
and if we scroll down here, some additional details, we're getting when it
happened and where it was
going. And here showing the actual policy firewall three into out to allow that
traffic to flow. So
one other thing we could do here is we could actually go and check on that
firewall to verify
that indeed that traffic is being allowed, because this information here is
applying all the data we
need to actually test it. So let's head over to firewall three for a moment. So
here's firewall WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here's firewall
three. And if we go down to policy and objects and firewall policy and click
here on policy match,
we could simulate generate that traffic. So the incoming interface was V 30. In
fact,
let me go take a peek again at 40 analyzers just to confirm. So the incoming
interface was coming in
on V 30. This is the source IP address. And for the destination, it was going
to this IP address,
and the egress or outbound interface was V 123. And the destination port was
443. Let's go back
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
to make sure the source port 40 208. And it's also showing here a policy ID of
one. So with that
information, let's go back to firewall three. So here's firewall three under
firewall policy,
little policy match. So for the protocol, it's supposed to say HTTPS for the
source IP address,
that was 10 30 dot 0, 103. But the source port is 40,208, which for a TCP
session, the source port is
usually used to random high number port available on the computer. And based on
the logs and using
the same exact port, and the destination address is that IP address in Russia,
which if I look at my
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
notes, because I wrote it down is 185 105, 109 dot 19. And the destination port
is 443. And it picked
that because that's the default destination port for HTTPS. So we selected HTTP
, it would use the
default part for HTTP, which is 80. So we'll go back to HTTPS, that looks good.
And just want to do a
fine matching policy. And sure enough, there is the policy firewall three and
out, including the
policy ID number of one. And indeed, this firewall is allowing that traffic to
go out. So that would
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
be something to look into as far as, okay, why don't we have a security policy
in place,
somewhere between this PC PC three and the internet, which is denying that
traffic. So we could be
implementing policy here on far well three or here on far well one to make sure
that traffic
never goes out to close that. And let's go back to the 40 analyzer. So if we
noticed that some of
that traffic had gone out and reached that device, we'd also want to do further
investigation,
either regarding this destination IP address, or the source client, or if we
had user authentication
set up for the source user. And again, by drilling down, we're starting here
under 40 view with threats WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
under 40 view with threats
with top threats, it's actually showing us the log view information here,
including using this
filter, so that we don't have to go back to log view separately and start
digging there. We can
just go ahead and see it right here. So I go ahead and close that filter, just
taking this back to
the top threats and 40 view looking for the threat dark side. And we can remove
that filter as well,
just by clicking here to remove that filter. So then we're going to go back to
top threats,
we can click here on top threats or just click on the top tile for top threats
either way. Also,
in this version of 40 analyzer, if we click on this icon right here, it'll put
those top threats, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
those top threats,
threat map indicators of compromise on the left hand side, who want to move
them back to the top,
we click here on toggle horizontal menu, puts them back on the top, either way
is great. So
here in our 40 view threats, next to top notes, we have a threat map. In fact,
there's a lot of
different map options available in 40 view. There's also indicators of
compromise. So let me go
ahead and specify the last 30 days. And here showing us indicator of compromise
regarding AD-user
three and this source IP address. So let me go ahead and minimize this left
hand side here by
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
clicking on the little hamburger menu that'll push it over here on the left.
Then once again,
if we want to remove or add columns, we can go ahead and do so right here to
control which columns
are showing up. All right, so for this AD user three, let's go ahead and double
click on source
user IP. So now the source user IP is AD-user three, and showing us the
operating system,
the log types, traffic, web filter, and attack, including security actions and
the verdict,
which indicates that this device may be infected. So also showing this here who
's reporting that,
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
it's HQ firewall one, which has effectively this serial number. Then if we
double click,
it'll go ahead and give us more details regarding that log. Here it's
indicating that that outbound
traffic is part of a botnet command and control communications very likely
because of an IP address
associated with command and control networks, showing us the source information
, including the
user AD-user three, the source address of AD-user three, the incoming port that
traffic came in on
on firewall one. If we scroll down, here's the destination of France and the e
gress are outbound
interface and the destination port, which implies it was trying to use HTTP as
shown right here in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
shown right here in
the service field. So if we scroll down, the action was detected. So the
firewall knows about it,
but unfortunately that traffic was allowed because of the profile called all
default pass,
which must be in monitor only mode for that type of threat because it saw it,
but it didn't stop it.
Then here's the attack name and where the traffic was going. So effectively you
're going out to that
command and control network address. Here's a hyperlink for more information.
There's the event
type. It's also showing us how that user was authenticated and other details
about that outbound
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
session. So again, once we drill down here, starting from four to view, it's
actually taking us as we
drill down to the details based on the logs. So let me expand the left hand
side again and let's do a
quick peek at a few other options here in four to view. So we go to traffic, we
're effectively looking
at the traffic logs imported or looking through the lens of four to view with
these pre-built
outputs. Also be aware that if you just power up your 40 analyzer, some of
these options may not be
available yet. They may be grayed out until that traffic has been received from
the 40 gates and
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
actually put into the SQL database. So here we're seeing based on color coding,
block versus pass.
So that's the traffic that was allowed through. And that's the traffic that was
blocked. And again,
we can drill down anywhere we need to. So here for 80 user seven, if we double
click, we're drilling
down with that filter in place effectively. And now everything here is filter
showing just that
user and the source address of 10700107. Then we have sort based on the number
of bytes
sent and received, we can click on that column. And it looks like this is a
pretty heavy duty
Netflix user based on the quantity of traffic. As far as the sessions are
concerned, the biggest
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
number of sessions were DNS requests. So across the top here for the 40 view
traffic, we have top
sources, top source addresses, top destinations, we'll just take a peek at a
few of these. And that
way can help us build a baseline of what normal looks like. So if we look at
sessions, let me
sort based on sessions, most of the sessions that are being reported into this
40 analyzer,
and again, this is from all devices over the past week, in fact, let me go
ahead and say last
two weeks, most of the sessions are DNS requests going out to 8888. And now I
have others going
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
out to these two addresses. And I think these are the two fordnet based DNS
servers to verify
that we could double click on it, take a closer look at what's really going on.
So TCP 853,
and that is for DNS over TLS. So some of our clients are using DNS over TLS for
secure DNS
requests, we double click on that, it'll go ahead and take us to the log view
with that filter in
place. So as far as who's making those requests, I've got 23 1.2.51, which is
firewall one, I've got
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
10.123.0.53 that's firewall three and that's firewall two. So most of these DNS
over TLS
requests are coming, it looks like from the firewalls themselves, as they're
doing DNS requests. But
this is a quick and easy way to drill down, see a big picture of what's
happening. So something
looks wrong, or you're like, what is that exactly? We have the opportunity to
dig down in and take a
look. So if you want to go one step back, we can just remove the log view
portion there. And that
takes us back to the previous that we could go ahead and remove application.
And that takes us
back to top destinations without the filters. If you want to click on top
destination addresses, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
destination addresses,
then we could also choose like, for example, top country slash region. And that
's for the last
hour. So if you want to narrow it down to a specific timeframe, you can, for
this demo,
let me go ahead and just say the last, let's say the last three weeks. And that
's going to show us
our top country slash region, including blocks and passes. We have some blocks
in yellow and the
passes in blue. So if we double clicked on the United Kingdom, once again, it
filters it down just
for destination country equals United Kingdom, and then we could take a closer
look there as well.
Again, with the yellow indicating a block where it didn't allow the traffic and
the blue WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the blue
representing where it allowed the traffic to go through. So an interesting
question might be,
why did some NTP that was going to the United Kingdom? Why did some get allowed
and some get
not allowed? And we can solve that by double clicking on NTP, where it would
take us to the
log view again, and then we can take a look at the detailed information here in
the logs.
So we could add a filter, right? So be going to the action column where it has
a check mark,
and we can go and say, Oh, I see everything where the action is not all except.
And that would put
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
in the filter to give us an idea of what's happening. So, oh, I see, on my fire
walls,
I have authentication set up on firewall one. And so these devices were
attempting to do NTP
requests out to NTP servers based on these destination IP addresses. But until
they authenticated,
the firewall said, you know what, I'll let you do some DNS requests, but I'm
not going to let
you do other things like NTP or HTTP or HTTPS out to the public internet based
on policy until I know
who you are. So one of the cool things about a tool like 40 Analyzer and 40 of
you is we can drill
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
down and find out, okay, what exactly is this? Do some research and then
identify, okay, this is
okay, this is natural, it should be happening this way. Or is there some other
bigger problem,
like a misconfiguration, a policy, or something else that's wrong on the
network? And again,
a tool like 40 Analyzer gives us a chance to dig down in and see what's really
happening.
As far as policy hits, we can click on the policy hits tab. This is for the
past week. Let me go
ahead and say the past two weeks, press enter. And this is showing us the firew
alls and the actual
policy names that are being matched on. And if you want to see which ones have
the most sessions,
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
we can click right here on sessions to sort by sessions. And this would
indicate that this firewall
policy into out on HQ firewall one is permitting the most traffic that's going
out to the public
internet. And again, we could drill down to take a look at the actual logs is
taking us to log view
with that filter in place to take a look at the details here. And then if we
click on DNS logs,
and once again, we might sure we're looking at the correct timeframe that we're
interested in,
I'm going to specify the last three weeks. And this is showing us our DNS logs.
So here with the
yellow, it indicates that is not allowed that traffic. And that's for the
domain name CPTH dash WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
domain name CPTH dash
C and T dot com. And that must be due to a policy. But if we're not sure, once
again, we can double
click, look at the details of that. So it's user to those trying that. And we
double click again,
it'll bring us to the log view to take a closer look at what's going on them
from here. We can
look at the details of one of those events scroll down and then identify why it
was blocked. So the
action was done based on a UTM block. And that's going to be due to our
security profiles associated
with our policies that in this case, I believe are looking for command and
control or malicious
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
networks where DNS and hey, that's in that category. And it prevented the
resolution of that IP address.
So this case user to this IP address did those DNS requests. However, the
responses never were
sent back to the client so the client can never get to the actual IP address
behind that domain.
If you scroll down and for the decision here, they were trying to resolve this
name right here.
So as a test, we could bring up another client, let's bring up 80 user three.
So here is 80 user
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
three on PC three, let me just confirm a few details, including its IP address.
Let's do an
IF config here. Its IP address is 1030.0.103. And currently it was just 80 user
two at 1020
0102. So this is a different computer, different user. And let's do an NS
lookup for that name of
CPTH dash CANT.com. So here's the answers the client got back but 1040 0100 is
an RC 1918 address.
And that's because the firewall has been configured to return that address
instead of the real address. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
instead of the real address.
And as a result, let me go ahead and close that window and minimize that.
Try to get this filter in place. Let me remove that filter and let me go back
to source and let
me go ahead and log v as well. And I still have in my source 80 user two. So go
ahead and clear
the filter altogether and go back to DNS logs and let me click on refresh. I
also could have just
gone to DNS logs and started that way as well. So here is still showing five.
If we double click on
that is still showing all 80 user two. So even though I think the firewalls are
all configured
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
to immediately send the logs, it may take a moment or two for those logs to be
injected into the
SQL database. And then after it's in the SQL database, that information can
show up here
in the four to view dashboards. So we go back to traffic DNS logs and again, I
'm going to get
that a moment and it should be showing up right here. And there it is. It shows
seven. It was five.
And now at seven. So let's go ahead and double click on that here showing
number of clients to
including the client at 1031.03 with two. And here, oh, look at that. It's
showing as
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
responded. So we double click on that. And then let's go ahead and open up one
of those. This is
firewall three that's reporting that effectively it allowed it. And if you look
at the other one,
this is also firewall three reporting it allowed it. However, oh, this is
fascinating because
what we're seeing here is information from firewall three. But the actual
response that came back
was from firewall one, which supplied that 1040 0100 address. So from firewall
three's perspective,
it didn't have any policies that blocked it. It was firewall one. So firewall
three itself
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
didn't block that DNS requests, but firewall one did because firewall one has
those policies in
place and firewall three doesn't. So we go back to 40 analyzer and let's go to
security and DNS.
And I want to filter down just to firewall one and take a look at the logs. And
that way,
I don't have to wait for information to go through four to view or into the SQL
database. See the
details. So I'm going to remove all the devices and just go to firewall one,
click on OK. And sure
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
enough, there's the two DNS requests from 80 user three. And based on the times
that let's go ahead
and just say last 30 minutes is great. There they are. And oh, one was for the
A record and one was
for a quad A record. Let's double click on the A record and we scroll down this
warning. And
here showing us domain was blocked by DNS botnet command and control at
firewall one. And that's
why I gave back the bogus address. Let's also verify that for the quad A record
. So if we scroll down
and it was also blocked based on policy on firewall ones. So I believe in a
moment or two,
it will also show that that traffic was denied, but at firewall one. And those
are all part of
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
the same security fabric. So in time, they'll be reflected here as well. So as
we continue down
with 40 view, let's go to shadow it just show you what's there. So here we have
top cloud applications.
Again, we can change the timeframe we're looking for. So I'll go ahead and say
past three weeks.
I also want to make sure we're looking at all devices, which we are doing a
sort, for example,
based on videos played. And it looks like right here, YouTube 18 videos played
if we double click
on that once again, it'll bring a filter in place for YouTube. And as far as
video played,
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
we'll sort that they're showing us the source address is 1070 107, which is PC
seven is playing
the most videos as shown right here. Then still with a 40 few dashboards, if we
go to applications
and websites, once again, a great pre collection of tools we can use to see
what's happening. So
here we have which devices we're going to be looking at the timeframe, which
currently is set
to one week. I'll go ahead and change that to the last three weeks. Here's the
block and pass
information for that timeframe. And regarding the top applications, like many
features inside a
40 analyzer, we can customize it. So we'll go to the hamburger menu, go to
settings, and then we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
settings, and then we
can specify the chart type stack bar or bar or table or bubble. And then we'll
go ahead and click on
OK. So those are the bubble version for the top 10. We're getting top
applications. Anyone
want to change that to the top 20, for example, go back to settings and say,
you know what, I want
to see the top 20 just by selecting 20 and clicking on OK. And there we have it
. So a couple of
other options here is in our settings, let's go back to a table and top 100
will click on OK.
And then it shows us the top 100. So then from here, if we want to sort based
on risk level, we can
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
sort based on that column, and then we can drill down, for example, in the RDP
and VNC, which
appears the highest risk level of applications that have been reported into the
40 analyzer.
So going across the top, there's top website domains. Again, we can control the
timeframe.
So I'll go ahead and say last number of weeks is three. We could also specify a
narrow down to
which devices we want to look at. Here's top website categories. Again, I'm
going to change
it to the last three weeks, pulling on the log information that's down on the
SQL database
from all devices. And here for proxy avoidance, for example, there's a lot of
traffic that's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
traffic that's
been allowed. So that'd be a great one to investigate. So go ahead and double
click on proxy avoidance.
Which puts it in as a filter. And once again, we could double click to drill
further and see the
detailed log information that's supporting these views here inside of 40 view.
So here for the top
browsing users, let's go ahead and change the timeframe to the last three weeks
. And here we
have based on browsing time and bytes sent to received in a number of sites
visited. Looks like
our winner for the most browsing time, this source IP address right here, 1020.
102. If we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
102. If we
double click on that, that's been a very, very busy computer. And here are the
details regarding
what they were doing. And once again, we could drill down by double clicking
here and would take
us for the filter with the individual logs for that activity. And then still
with 40 view dashboards,
we have VPN. As an example, we've got a site to site over the last two weeks
here showing us traffic
for an IP [garbled] site site tunnel. And we've got a system again, under a 40 view
system, we have to
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
have for admin logins. And it's currently showing the past week. I'm going to
go ahead and say the
past two weeks by putting that in and pressing enter. Looks like this user
admin has been very
busy and has had 40 logins over the past two weeks with one failed login, which
was probably
just a typo. Also shows here the number of configuration changes. So we could
double click. This is now
taking us to the log view with the filter in place for admin. And then we get
down here to alert
and double click. This is a log message regarding a configuration change. If we
go to system events,
and again, I'll put in two weeks, and then we get sort by severity. And we can
then further
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
investigate some of these issues or challenges. So sometimes if I lab, I'll
bring up my devices in
not the optimal order, for example, I'll bring up the 40 gates first, and I'll
bring up the switch
that connects them all, and then I'll bring up for the analyzer. And so
sometimes we may have some
issues there until it all gets dialed in. But once again, we could double click
on any of these to
go to the actual logs and take a closer look. Then we have a tab for resource
usage. Again,
I'll take a look at the last two weeks. So wherever the last two weeks, we have
our four firewalls.
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
And it's actually showing us five because branch firewall one is in an HA pair.
So we have firewall
one, two, and three, the headquarters location, then branch firewall one, and
it's HA pair at the
branch location. And here it's showing CPU usage, memory usage, disk usage, etc
. Which is a great way
of having a big picture view of what's going on on our network. And as far as
resource usage
peak, we scroll down and let's go to logs per second. So for the resource peak
usage,
firewall one wins that award with 37,704 logs per second with 1,857 concurrent
sessions. And then
for failed authentication attempts, which was also super useful to look for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for failed authentication attempts, which was also super useful to look for
attacks and
people trying to log into our systems who are not authorized to do so. And
doing, for example,
like a brute force attack, let's take a look at the last three weeks. And I
have the admin user
here who failed to log in coming from the source IP address. And it looks like
he was trying to log
into the management IP address on firewall two based on the IP address. And
then I also have some
authentication failures for the authentication of the AP sec tunnels. That's
because I reboot
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
these firewalls almost daily. And so initially, if one comes up earlier or late
, I'm going to take
a few attempts for the authentication of the IP sec tunnel. So for the admin
authentication
failure, if you double click on that, here's the details, go and double click
and take a look at
firewall two and admin login failed. Probably due to a typo, as I was putting
my password,
which I tried again, then it worked. However, if we have a lot of these, they'd
be super important
to be aware of.
[BLANK_AUDIO]