>> When we think about firewalls,
the first thing we should think about is security.
I think that's probably true for most folks.
What we want to think about
firewalls is their purpose is to isolate
the network or to divide
the network into different security zones.
We talk about security zones.
The idea should be based on trust.
For instance, our local area network,
our internal network, our LAN,
that's our most trusted network.
I can troll the systems that are in the LAN.
I create the security policy,
I provide the authentication rules,
that's my network,
so I trust my network.
Now, the ultimate and entrusted would be the Internet.
Of course, in the middle,
many organizations have what's referred to as
a DMZ, a demilitarized zone.
That DMZ is usually considered to be
semi-trusted because even though
it's under my ownership and management,
I'm going to allow the general public
to access the network.
That's my servers that I want to be
publicly available are going to go.
For instance, my webserver.
I want the public to come to
my webserver because I want their money.
Come visit my site, come spend your money.
When we talk about isolating
these networks from each other,
we're going to use firewall to do so.
That firewall is going to filter
traffic based on a ruleset.
We talk about that as rule-based access control
to determine what traffic should
be allowed between networks.
This is just a little illustration
>> of a DMZ conceptually,
>> we have the untrusted Internet goes
through an external firewall into the DMZ,
then we go through an internal firewall
to access the trusted LAN.
This is why it's sometimes
referred to as a screened subnet.
Is often because the DMZ is
between two screening devices.
Even if you don't have devices in the DMZ,
sometimes it's still set up to provide
a buffer between the Internet and the trusted LAN.
The servers that you have in your DMZ like I said,
you're likely to have the webserver there.
Because your web server is in the DMZ,
you're going to have a web application firewall there.
You always put your firewalls that are specific for
applications beside the device that they're protecting.
Web application firewall protects a web server.
Those both would go and near DMZ.
You could also have a honeyport,
which is a decoded distract attackers.
You might have an intrusion detection system
and they're to analyze for malicious activities.
You're going to have several different
devices in your DMZ.
All these devices should be hardened.
When we talk about those servers that are
Internet-facing and the fact that they're hardened,
we refer to those as bastion hosts.
We want to make sure that they're locked down.
They don't have any extra services or
devices or any extra ports open.
We want those to be hardened as much as possible.
Again, firewalls are designed to
provide filtering between zones of trust.
Firewalls can either be software or hardware-based.
That's always a strange idea
because software is no good without hardware,
and hardware is no good
>> without software but the idea is,
>> I can buy a software product
>> like pfSense and the name of
>> LAN and install it on a Linux machine
and turn that Linux machine into a firewall.
It makes it a firewall as a software,
or I can go out and I can buy
>> an ASA firewall from Cisco.
>> That box is nothing about a firewall.
Sometimes it's called a client space.
It might be called a black-box firewall,
but the idea is that the device
is nothing but a firewall.
That'll be hardware-based.
As a general rule,
you're going to get better protection,
better performance from your hardware-based solutions.
As a general rule,
your software-based solutions will be much cheaper.
Really, it depends on what
your priorities are in this instance.
Different firewalls operate the different layers
of the OSI model.
You really have three layers of firewalls.
You have a layer three firewall,
a layer five firewall,
and a layer seven.
Down at layer three, the network layer,
if you think about what happens down at layer three,
you have IP addressing.
One of the things that
>> layer three firewall can inspect for,
>> is source and destination IP address.
It can also pick just a little bit into layer
four headers and make decisions
based on source and destination port.
That sounds like that's pretty good inspection,
but it's actually very, very broad.
It's almost too broad to be really useful.
Let's say, for instance,
I'm concerned about SYN flood,
which is an exploit of the TCP protocol.
A layer 3 firewall is really just an all-or-nothing.
I don't get to block misbehaving TCP.
I can block all the TCP traffic or none.
You can really see that's really over cool.
Especially because all the network services
and applications need TCP to run.
If you were to block TCP at your firewall,
you'd have almost no traffic and all coming through.
This doesn't get really particular.
I can just block floods or just block
SYN packets that don't have an ACK or a SYN-ACK.
I can't get into details here.
Often these layer three firewalls are really just
routers with access control lists configured on them.
I can create very basic access control lists
on my router or turn them
into what we referred to as
a packet filtering
>> or a static packet filtering firewall.
>> This is usually your screening router that
is the first of entry into your network.
These devices act like a bouncer.
Their job is to keep what's
obviously riffraff off your network.
Traffic coming through port 161,
nope, we're not allowing SNMP traffic coming through.
Traffic on port 53,
nope, we don't have a DNS.
Malformed packet, get out of here.
At layer three, what you give is very basic,
very much all or nothing packet
filtering. It has its place.
You don't want every single type of traffic directed at
your network to go through deep packet inspection.
What you get down at layer three is you get
fast but very broad packet filtering.
As we go up the OSI model,
we get a little bit more understanding.
We get a little bit more knowledgeable
with the layer 5 firewall.
These are sometimes referred to as stateful filtering.
With stateful filters,
those firewalls understand the state of the connection.
By that, I mean things like who initiated the session.
For instance, maybe I don't
want traffic coming in that wasn't solicited.
If I send out a DNS query,
then I want the DNS to reply
to come through the firewall.
But if there was no DNS query,
I don't want a response.
I don't want a reply coming through.
You don't get that degree of
intelligence down at layer three,
you're just looking at source and
destination, IP and port.
But at layer five,
you can get information on who
initiated the session and allow
traffic back based on the criteria.
>> That's very helpful.
>> Also, you generally get an understanding
of the lower-layer protocols at layer five.
You can look a little bit of syntax and for
protocols that aren't behaving according to their RFC.
Sometimes you can get that understanding at layer five.
Where you really get the smarts is up at layer seven.
These are application firewalls.
They're sometimes called proxy servers.
You can hear them called application firewalls,
application proxies, but they are at layer seven.
These are the devices that give
us deep packet inspection.
They have understanding of
the actual content of the packet.
If I want to block traffic that has violent content,
since salespeople after 5:00
PM or between 8:00 and 5:00,
I have a degree of understanding and
complexity at the application layer.
I get great deal of control when I'm
using application layer proxies.
The thing about the application proxy is
each proxy is focused on particular application.
You have web proxies which are
very comparable to web application firewalls.
They do pretty much the same thing.
They focus on HTTP and HTTPS traffic.
Anytime I'm concerned about malformed HTTP headers or
code injection or cross-site scripting attacks
that specifically exploit a web server,
then a web application firewall
is going to be helpful for me.
Again, because they're up at layer seven
>> of the OSI model I
>> get a much greater understanding of
the data and all the headers,
as well as integration with Active Directory,
time content, and a deep knowledge
of specific application protocol.
When we are talking about proxies and we
said they do this deep packet inspection,
I also want to mention they have the both
forward and reverse proxies.
When we think about a forward proxy,
its job is to inspect traffic from
your internal network going out into the Internet.
From the inside out, and
that's going to make it so that way you can
track and control what users
do and view out on the Internet.
There's also the reverse proxy,
which is going to be control what users
from the Internet can do in your environment.
Again, you're going to have
a DMZ where you have your web server
configured and the whole purpose of
that web server is going to be share information.
You're going to make folks from
the Internet first send their requests through
your web proxy or your web application firewall.
That's going to be referred to as a reverse proxy.