I bet some things are pretty frustrating for network
devices.
Consider the FirePOWER appliance.
If we have traffic that's going through,
and we have a policy that says look at the application layer
information and permit this or deny that based on the layer 7
information-- well, if that data is encrypted,
where they're using SSL or TLS for encrypted sessions between
clients and servers--
because it's encrypted, that's really tough for the FirePOWER
appliance to do its job.
So a solution to that is to do SSL/TLS decryption WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So a solution to that is to do SSL/TLS decryption
and how the FirePOWER appliance act
as a sort of man in the middle so that, for a few moments,
it has the naked data, so it can do its proper inspections,
analysis, and traffic control based on what's
really going on.
In this Nugget, I'd like to talk with you
about the concept of SSL decryption,
where we would go to create the policies,
and how to include those policies as part
of our overarching access control policy.
So let's use this topology, and let's use Bob once again.
And let's put Bob here at computer 1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's put Bob here at computer 1.
Now, Bob, if he wants to go out to a website--
let's imagine he wants to go to a gaming website,
and we have a policy on the FirePOWER appliance that says,
hey, any websites in the gaming category are not allowed.
So Bob's frustrated.
And what does Bob do?
Bob does a Google search and says, wow,
I can set up a tunnel?
So Bob sets up a tunnel, and he goes out
to a website via tunnel.
And then from that tunneled site,
he then goes out to his gaming website,
and the reply traffic goes back this direction WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and the reply traffic goes back this direction
and this direction.
And the FirePOWER appliance is none the wiser
because, while the traffic was in that tunnel,
it was encrypted.
And if we're using SSL or TLS, the FirePOWER appliance cannot
see the application layer data to see where that traffic was
really going to.
Now, what the firewall could do is also
have a policy saying, hey, no tunneling sites allowed.
So the initial connection possibly could be stopped.
However, that's just the beginning of our challenges
because, even without Bob being malicious,
there's lots and lots of traffic that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
there's lots and lots of traffic that
is being sent using SSL, Secure Sockets Layer,
or the new and improved flavor of security for HTTPS sessions.
That's TLS, Transport Layer Security, using HTTPS.
So even if Bob is doing innocent things and going using HTTPS,
if the traffic is encrypted, the firewall
is going to have a hard time looking at layer 7 application
information because it's encrypted.
So to solve that, what we can do is we can have the firewall
play the role of a man-in-the-middle attack. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
play the role of a man-in-the-middle attack.
And it would go something like this.
Bob makes his request going out to the internet,
and it's going to be an HTTPS session.
And the FirePOWER appliance intercepts that
and has this whole little conversation between Bob
and the FirePOWER appliance while,
virtually simultaneously, the FirePOWER appliance
is actually going out and building
a session out to the server that Bob was trying to get to.
And the session is actually being built here.
So we have two sessions.
We have session 1 between Bob and the appliance
and another one between the appliance and the actual server WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and another one between the appliance and the actual server
that Bob was trying to go to.
So it's encrypted on this journey and this journey.
But here, for a moment, it's not encrypted.
And that's when the FirePOWER appliance can
look at the application layer information and say, oh, yeah,
gee, he's trying to use Gmail.
Great.
No problem.
I'm going to let that.
Oh, he's trying to use a file transfer
app or peer-to-peer software or something else.
I'm going to deny that based on policy.
And when we do it in this fashion, where Bob is going out
to the internet, what we're doing
is the actual firewall is resigning. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is the actual firewall is resigning.
Not resigning, but re-signing, where internal users are
going to external resources.
And if we have users on the internet-- let's go ahead
and put Lois out here.
So Lois is on the internet, and she
wants to go to server B right here, one
of our public-facing servers.
As her traffic comes in, we could also play that man
in the middle at the firewall.
I guess I should draw this arrow down here at the firewall.
And when Lois is going to one of our servers,
we have these private keys.
And so the inbound traffic to internal servers
from external users is using a known key. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
from external users is using a known key.
But whether we're resigning as traffic goes out,
or we're using a known key that's
on the server for the inbound traffic,
the idea is that we want the firewall to have
a few moments of time to be able to analyze that naked traffic,
so it can implement the inspections and traffic
control that we want to have happen in our network.
Now, there are a couple of times--
actually, several times-- when we do not
want to do any kind of SSL or TLS
decryption-- for example, financial. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
decryption-- for example, financial.
If Bob is going out to a financial website,
we do not want the liability of decrypting that
during that session.
So in our rules and our policies for SSL decryption,
we could have categories of URLs,
like banking websites, financial services,
and so forth, that we are not going
to decrypt the traffic on.
Another example of a good time to not do this
would be medical information.
There's huge fines involved for leaking or not WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
There's huge fines involved for leaking or not
protecting data, especially personally
identifiable information and medical information.
So in our rules for SSL decryption,
we could set up these rules at the beginning saying
don't do any decryption for these categories
or other specific sites while, at the same time,
having some rules in place that are
going to do the SSL decryption.
Now, also be aware that if this firewall Threat Defense
appliance is doing SSL/TLS decryption and re-encryption--
that takes a whole bunch of CPU. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that takes a whole bunch of CPU.
So you'd want to make sure that we have enough horsepower,
and we're not just breaking it by trying
to have it do too much processor-intensive activity
above and beyond what it was designed to do.
So if we have a certain flavor or model of FirePOWER Threat
Defense appliance, perhaps we need
to get a bigger one in order to handle
the actual load that we're going to place on it.
Also, this is where a virtual FirePOWER Threat Defense
appliance is a really poor choice because there just
isn't that much CPU available in a virtualized space WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
isn't that much CPU available in a virtualized space
on that appliance for thousands and thousands of SSL
encryptions and decryptions that all might
need to happen simultaneously.
So I'd like to take a moment and show you
where we could go in the interface on the FMC
to both configure an SSL decryption policy and then how
to link that or tie that into a firewall Threat Defense
appliance.
So here in the FMC, we're going to click on Policies.
From the dropdown list, we have an option for SSL.
And this is where we would configure our SSL policy. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And this is where we would configure our SSL policy.
This also is going to assume that we
have a certificate or two lying around with keys in them
or a certificate authority that is trusted
by our organization that can hand out certificates,
and we have those certificates available.
So I just created this little sample SSL policy
a few moments ago.
And in the policy, we'd simply create rules.
So once we have our SSL policy in place,
including rules that also include
the certificates involved and the traffic that we do not
want to decrypt and the traffic that we do want to decrypt, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
want to decrypt and the traffic that we do want to decrypt,
and that's all in place, the next step
is to include that as part of our access control policy.
And to do that, we're going to go back to Policies
and then go back to Access Control.
That's our overarching umbrella of how
we implement and enforce most of our policies here in FirePOWER.
So then from here, we can take our starter policy, our access
control policy, click on Edit.
And then right here on this starter policy,
we have a link for SSL Policy.
And, currently, we have none assigned.
If we wanted to assign an SSL policy to this access control WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we wanted to assign an SSL policy to this access control
policy, we simply click here where it says None,
use the dropdown, select the SSL policy, and then click on OK.
And now we have this SSL policy associated with this access
control policy.
So the following steps would be to save it and then deploy it,
so our FirePOWER appliances could then implement that SSL
decryption feature.
In this Nugget, we've identified that, even if users
are using HTTPS, the FirePOWER appliance, based on an SSL WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
are using HTTPS, the FirePOWER appliance, based on an SSL
policy, can decrypt those sessions and, based on that,
have a peek at the application layer information,
so it can go ahead and enforce the control that we want.
I hope this has been informative for you,
and I'd like to thank you for viewing.