In the previous Nugget, we took a look at some of the actions
that we can set up as part of an axis control policy
and what they do and what they mean.
And just for good measure before we implement the rule let's
go to our client who's on that inside network.
We'll do an ifconfig just to confirm.
So this client's at 0.103, and if we do a ping out
to 8.8.8.8--
that works, great.
Control C to stop that.
Let's ping something else.
Www.cisco.com, that looks great.
Great.
I just wanted to make sure that we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I just wanted to make sure that we
had full connectivity before we start restricting
some of that traffic.
So let's go to the FMC next.
All right.
So here at the FMC we'll go ahead
and we'll modify our access control policy
by adding a new rule to it.
We'll do that by clicking on the Policies tab here at the top,
and then from below that if it isn't already selected
we'll click on Access Control.
And that's where we are.
Fantastic.
And here's our starter policy that's currently
being used on FTD-1, and we'll click on the pencil icon
to edit that policy.
Now, why are these all policies is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, why are these all policies is
that we can only have one access control
policy applied to a given firewall at any given time.
So we get lots of different policies
and we could swap them out, but only one access control policy
per firewall at any given time.
So with the Starter Policy selected and the Rules tab
selected, let's go ahead and click here to Add a New Rule.
And let's call this No Ping to 8.8.8.8.
And instead of saying from any zone to any zone,
let's specify that traffic from an interface associated WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
let's specify that traffic from an interface associated
with the inside zone where the traffic's
coming into the firewall and being ratted
out the outside zone or an interface associated
with the outside zone, and we could
click on the Networks tab.
We could be very granular here about the source
and destination networks.
For the source I don't really care.
We could add 10 if we wanted to, but I'm really concerned
about the destination.
We want to focus on the destination for this access
control rule to be 8.8.8.8.
So there is an object right here, Google at 8.8.8.8,
and if there wasn't an object that represented our target WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and if there wasn't an object that represented our target
we could click on the plus symbol
and go ahead and create it and then use it.
So here I'll just drag and drop Google 8.8.8.8
over to the destination.
Our next thing we want to match on is ports.
So we'll click on Ports.
Now, even though ICMP really isn't a port,
it's really a protocol.
This is where we'd specify that that's
what we want to match on.
So for the destination we'll go ahead
and let's create a new object that represents
an ICMP echo request.
So we'll click on plus to create new object. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll click on plus to create new object.
Click on Add Object and we'll call this ICMP_Request_IPv4,
and it is going to be ICMP and it
is going to be an echo request, which is type 8.
Looks great.
All right.
And we'll click on Save.
We called this ICMP_Request_IPv4.
Click on Save and then we'd go ahead and grab that and select
that for the destination.
So if we have traffic that's coming in on the inside, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we have traffic that's coming in on the inside,
going to the outside and it's destined for 8.8.8.8
and it's ICMP and in that ICMP payload
there's an echo request, then it's going to be a match.
Now the question is, what do we want to do as an action
if this is matched?
And that's what we're supposed to have right here
in the dropdown for actions.
Do we want to allow it, which allows for the processing?
Do we want to trust it, which means
no further processing forward?
Or do we want to monitor it, meaning at a log entry for it,
or do we want to block that sucker? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or do we want to block that sucker?
And that's exactly what we're going to choose.
There's block right there.
And also, while we're here I'm going
to click on the Logging tab and let's go ahead
and also do logging at the beginning of this connection,
and that way we can see that it happened in our events log.
So once that's all set we'll click on Add.
We can also resize the columns to see all the wording
if we want to as well.
But there's our policy.
So we're going to click on Save.
That's step number one, and then step number two,
we're going to go ahead and deploy it
so it actually takes effect on the Firepower Threat Defense WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so it actually takes effect on the Firepower Threat Defense
appliance.
So we'll do that now.
We'll click on Save, click on Deploy,
and then make sure that FTD-1 is selected.
There's the access control policies.
It's going to be modified in this new policy
and we'll click on Deploy and then
we'll give that like, I don't know, a minute and a half.
90 seconds to go ahead and do its magic,
push that policy out to FTD-1, verify that it's good,
and then you and I will verify that the policy is working
by trying a few more pings from our client
on the inside network.
All righty. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All righty.
Under Status it says that the task of deployment is done.
And so let's go ahead and try it.
Let's go over to our client.
So here in our client let me hit the up arrow
key a couple of times, leaving our ping to 8.8.8.8,
and that's great.
It's failing.
Now, the fact that it's failing is good
and what we want to make sure is that the other pings
to anywhere besides that direction or that IP address
also work.
So we'll do a Control C, hit the upper arrow key
a couple of times, we'll ping cisco.com,
and that indeed is working. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and that indeed is working.
That is great news.
And we can go verify some of the details of that
by looking at the log information
back on the Firepower Management Center.
So back on the FMC, if we click on the Analysis tab
here at the top, and then from the sub-tab select Connections,
then from that menu select Events.
So the breadcrumbs is analysis, connections, events.
And that looks great.
So here we have a block of this client trying to go to 8.8.8.8 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So here we have a block of this client trying to go to 8.8.8.8
and that was the echo request.
This little allow right here is using UDP, great,
so that should have been permitted.
And that UDP as I look at the port number
right there, that's a DNS requests because right after we
did our ping to cisco.com so that DNS request to resolve
cisco.com to an IP address, and then
it proceeded with the pings right here to cisco.com
So it was between DNS requests and ICMP
echo requests that were all here allowed,
but the block happened exactly as we expected it to.
In the previous Nugget, we took a look at some of the actions WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In the previous Nugget, we took a look at some of the actions
that we can set up as part of an access control policy
and what they do and what they mean, and in this Nugget
we implemented an example policy rule
and then verified the results based
on the action we assigned in that policy.
I hope this has been informative for you
and I'd like to thank you for viewing.