If you're connected to the internet at home
or in your office, then you are using a firewall
to help protect your network from whatever
happens to be on the internet.
This is a component that allows us
to control the flow of traffic.
This might be inbound traffic into your network,
or it may be traffic that we're sending out to the internet.
This can be especially important in corporate environments
where we want to be sure that anyone on the internet
does not have access to the sensitive information that's
on the inside of our network.
Your firewall might also include content filtering.
So there may be a way for your system administrator
to define exactly what type of content
you're able to access on the internet.
And with some firewalls, we have-- antivirus, anti-malware,
and other modes of detecting malicious software
if it happens to flow through that firewall.
A traditional firewall is able to control traffic
based on the IP address and port numbers that are in use.
Some of the newer next-generation firewalls
are able to go a step further and identify
the applications that may be flowing across the network.
Many firewalls can also act as a VPN endpoint for IP site
tunnels or communication from end users.
This allows you to configure the firewall
as the central point of security for all of your remote access
devices.
And it's also very common for your firewall to act,
as a layer 3 device can effectively
replace the router that you're using
to connect to the internet.
This also means that we have the ability
to change addressing with network address translation
so that you can have a group of internal private addresses.
And all of those private addresses
are able to communicate to the internet.
And since this firewall is acting as a router,
you're able to have dynamic routing, route redistribution
and other advanced routing functions.
We can think of the communication on our network
as a flow of traffic.
We might begin to query a web server from one device
and the web server will return a response to our query
to the original requester.
That is a single flow of communication.
And when we make that request to the web server,
we naturally expect there's going
to be a response from that web server.
There is an older style of firewall
called a stateless firewall that doesn't
have any idea about these flows of communication.
A stateless firewall doesn't know that when
you make a request to a web server,
that there is going to be a response from that web server,
and all traffic going one direction through the firewall
needs its own set of rules.
Traffic coming the other direction through the firewall
needs a completely different set of rules.
A stateless firewall is not able to determine
that the response from a web server
is being sent inbound because we originally
made a request earlier to that web server.
This means that the firewall is not
going to keep track of any of these flows going
back and forth.
So it needs to have a rule base that
covers all communication in both directions.
This rule base has a first rule which says,
the source IP of 10.1.1.1 which is Jack's workstation is able
to communicate to 10.10.10.10 which is the SGC web server.
It's able to communicate to that device using TCP of the port 80
and that information is allowed.
Since this firewall has no idea that a state of communication
exists, it also needs a rule that allows
traffic the other direction.
So we have a second rule in this firewall that allows
10.10.10.10, which is the SGC web server to communicate
to 10.1.1.1, which is Jack's workstation,
using any TCP port and allowing that traffic to pass through
the network.
Let's test the rules in this stateless firewall.
We'll begin with Jack communicating
to the web server.
The firewall evaluates that traffic as 10.1.1.1
communicating to 10.10.10.10.
It sees that that information is allowed if that's TCP port 80.
And in this case, it is.
So that traffic is allowed through the firewall.
The SGC web server is going to respond to that communication
and send the information back to the firewall.
But since this is stateless, the firewall
has no idea that this is the response to that earlier
request.
So it has to look into its rule base again and see that there
is a rule that allows this traffic from to 10.10.10.10
to 10.1.1.1.
Since that is allowed, that information
continues to Jack's workstation.
Let's say an attacker now gains access to the SGC web server
and wants to send some unprompted data into Jack's
workstation.
So the SGC web server will send a packet of information.
Since the firewall has no idea what the state of this flow
might be, the only thing it can rely on
is the firewall rule base.
And this rule base does allow 10.10.10.10 to communicate
to 10.1.1.1, which is Jack's workstation.
And that information even though it
is something that could be malicious,
is allowed through the firewall.
These days it would be very unusual to find
a stateless firewall.
Practically, all firewalls that you'll find
are stateful devices.
Stateful devices are much more secure
and are much more intelligent about how they allow traffic
through the network.
Let's take the same scenario where
Jack is going to communicate to the SGC web server.
With a stateful firewall, the set of rules is very different.
We only need a single rule which would be 10.1.1.1,
Jack's workstation, communicating to 10.10.10.10
which is the SGC web server and that traffic is allowed using
TCP port 80 through the firewall.
Notice that there is not another rule that allows
traffic the other direction.
Since this is a stateful firewall,
it knows that if a conversation is beginning from Jack
that it's going to allow the return
communication through the firewall automatically.
So now let's send this information
from Jack's computer.
It hits the firewall, it's evaluated,
that particular traffic flow is And the firewall creates
a state table.
The session table is going to have information
about this particular flow.
This flow is from 10.1.1.1, has a source port of 15442,
it is heading to 10.10.10.10 over port 80.
And that information continues to the web server.
When the SGC web server responds to that request,
the firewall will look through the rule base
and see that a rule is not allowed for that traffic.
However, it does show an active session table which
does show that this is part of an active communication
and therefore it allows that traffic back
through to Jack's computer.
If we have the same scenario where the attacker gains access
to the web server and is sending information to Jack's computer
without a flow existing originally,
when that hits the firewall, it won't
match any of the rule bases.
It won't match anything in the session table
because this is using a different destination TCP port
and therefore that information will be denied access
through the firewall.
You can see that the stateful firewall is much more
secure for these active flows.
The rule bases are much simpler on a stateful firewall.
Which is why the stateful firewall
is most likely the default firewall type that you'll use.
Historically, we've continued to improve
the capabilities of these firewalls
and they've become more than simply a device that allows
or disallows network flows.
We created a newer version of the firewalls called a UTM.
This is a Unified Threat Management
device or what some people call, a web security gateway.
These devices include a number of additional features
over simply being a firewall.
For example, a UTM might include URL filtering or content
inspection, it can look for malware communicating
through the firewall, it can provide spam filtering
in some cases.
Some of these UTMs have CSU/DSU connectivity for your wide area
network serial connections.
It could have routing and switching
functionality built into interfaces
that are on the UTM device.
And of course they provide firewalling,
IPs/IDS functionality, bandwidth shaping, VPN endpoints
and even more.
One of the challenges we have with UTMs
is that, there generally was never
one single vendor that could provide
all of this in a single device.
And installing other manufacturer's code
into a third party device often created more problems
than it actually solved.
We needed a smarter way to include this functionality
in a device that was really built
to handle the loads of our modern networks.
That's why most of our enterprise firewalls
today are next-generation firewalls or NGFW devices.
They are application layer devices
that can see the application flows
across all of the communication on our network.
You might also hear of these called application layer
gateways, stateful multilayer inspection
devices, or deep packet inspection devices.
A next generation firewall is going
to evaluate all of the traffic flowing through the network
and it's able to understand exactly what applications
are in use regardless of what IP addresses or port
numbers may be used.
These are much more intelligent devices
than a UTM or a traditional firewall.
But every packet has to be analyzed and categorized
so that it can then apply security rules to all
of the traffic.
Next-generation firewalls are commonly
network connected devices.
They are able to look at all of the traffic going through
and show how much web browsing, how much BitTorrent, how much
Blackboard communication, and all of these other applications
as well.
These might also include intrusion prevention
capabilities.
There's usually application-specific rules
inside of the firewall that are able to recognize and react
to any vulnerabilities that may exist for that application.
And since we're looking at everything
going by with the next-generation firewall,
we can also apply rules relating to URL filters
or categorizations of URLs.
This newer style of security provides much more efficiency
and provides more security on the network.
Which is why you often see people now
throwing out their UTMs and replacing them
with next-generation firewalls.
If you're responsible for securing web services
and you want to provide additional security
for the information that's being input into those web service
applications, then you need a web application firewall
or a WAF.
This is not like a traditional firewall
that is able to allow or disallow traffic based
on IP address or port number.
And this is not like a next-generation firewall which
is examining application flows.
This is a firewall specifically built
for web web-based applications.
And it's going to apply rules to the conversations that
are taking place for your HTTP and HTTPS based applications.
Instead of allowing or disallowing
traffic based on an IP address or port number,
a WAF is going to allow or deny traffic
based on the input to that particular application.
For example, if an attacker sends information
to a web server that exploits a SQL injection vulnerability,
the WAF can recognize that a SQL injection has been attempted
and block that traffic flow.
This is the type of security you would commonly
see with very high end web-based applications.
If you're accepting credit card numbers to your website,
then you must comply with the Payment Card Industry Data
Security Standard or PCI DSS.
And part of that compliance requires that you have in place
a web application firewall.
Here's a log file from a web application firewall.
This particular firewall has caught some instances
where there has been a cross site scripting attack.
This particular attempt was denied by the firewall.
We have another problem that was an error code four or five,
where there was an error from the web server
although the response to that error
was suppressed so that the end user would not see the error
and that information was logged.
We also have a SQL injection that was attempted
and in this case that particular SQL injection
was denied by the web application firewall.
In this video, we've described the rule base
within a firewall that allows or disallows traffic.
You might see this referred to as a security
policy or an access control list or ACL.
This provides us with a list of rules
that the firewall will follow to decide whether information
should be allowed through the firewall
or denied through the firewall.
The series of variables that you would choose are called tuples,
and they are groupings of information.
So your firewall can make these forwarding decisions
based on the traffic itself.
It can find whether there is a source
IP a destination IP in use, a particular port
number, the time of day, the application that's being used,
and other criteria as well.
The firewall evaluates all of these different characteristics
to see if it can match any of the rules
within the access control list.
And once it finds a rule that matches
it looks at the disposition for that role
to determine whether that information should be allowed
or denied through the firewall.
Some firewalls have hundreds or even
thousands of rules in the rule-base.
So it's important to understand which particular rule is
evaluated first.
On most firewalls, it's done through a top
to bottom approach.
As the data is coming through the firewall,
the firewall tries to match that data
based on the information in the first rule
at the very top of the rule base.
If nothing matches in that rule, the firewall
looks at the second rule in the rule base.
If nothing matches in that rule we go to the third rule
then the fourth and the fifth and so on.
Eventually, we will find a rule that
does match the characteristics of that flow
and we'll know what the disposition is.
This means we generally put the more specific rules
at the top of this firewall list.
So these very specific rules can be
evaluated before any other rules in the rule base.
If we go through this entire list of rules on the firewall
and we have no matches to the data flow,
you'll find that most firewalls are configured
with an implicit deny.
Which means once you get to the bottom of the rule base
and nothing matches, none of that data
is allowed through the firewall by default.
Let's step through a firewall rule base
and see if we can determine what these particular rules are
allowing our denying.
We have a rule base that has a rule number, a remote IP
address, remote port number, local port number, a protocol
and an action.
The first rule in the rule base looks for any remote IP address
that we're sending information to over any port number,
and it allows us to send this traffic if the local port
number is 22 using the TCP protocol.
If our network traffic matches that rule,
then that information will be allowed through the firewall.
The second rule also has all remote IP addresses.
We are communicating to any remote port number.
The local port number that's being used is port 80 over TCP
which would be web traffic and that traffic is
allowed through the firewall.
Rule 3 is also, any remote IP from any port number
is allowed through the firewall if it
matches a local port of 443.
Which would commonly be HTTPS communication over TCP ports.
And again, we are allowing that traffic.
Rule number 4 allows any remote IP over any remote port number
to communicate to port 3389 on our local network using
the TCP protocol which would commonly
be used for remote desktop.
This is also allowed traffic.
Rule 5 is a little bit different.
We are allowing any remote IP but the remote port no
that's allowed is port 53.
This would go to any local port number
with the UDP protocol, which means we're allowing
DNS traffic into our network.
Rule 6 is a similar rule that allows any remote traffic using
port number 123.
So this would be the network time protocol
for time synchronization.
And that is UDP protocol that is allowed to our network.
Now normally, at the bottom of the rule-base,
anything else that came through would be denied
due to our implicit deny.
But implicit denies are not commonly logged.
We may decide that certain traffic should always
be logged in our firewall.
So we have a single rule at the bottom,
that for all remote traffic that is communicating via the ICMP
protocol into our network, we will deny any of that traffic.
And because we have a specific rule written for that deny,
that information will be logged in the firewall logs.
There are many different kinds of firewalls
with many types of implementations,
and those implementations have many different advantages
and disadvantages.
For example, you have the choice on whether you
would like to use an open-source firewall
versus a proprietary firewall.
Open source firewalls tend to allow or disallow traffic
based on the traditional firewall rules for an IP
address or a port number.
It's unusual to find an open-source firewall that
has a large understanding of the different applications that
can flow through the network.
For that functionality, you may want
to use a proprietary firewall which does have application
control and visibility into all of the application
flows on your network, and it's usually
built on hardware that's designed for these high speed
networks.
This is one of the big advantages
for having a piece of hardware that has been purpose built.
To be a firewall, is that it's designed for speed.
That firewall can provide very efficient traffic flows
and provide different types of interfaces
so that you're connecting to not only ethernet networks
but perhaps even wider area network or wireless networks
as well.
You can also get software based firewalls
that you might install on your own hardware.
This would give you the flexibility
to put these firewalls anywhere you'd
like in your organization.
And with so many services moving into a virtual environment,
it's important to understand the differences
between using an appliance-based physical firewall
versus a virtual software-based firewall.
An appliance often has the fastest throughput
because there's purpose-built hardware that's
designed for the speeds and connections
that you would commonly find on an enterprise network.
On servers and workstations, you can run a host-based firewall.
Those devices, since they're running
as part of the operating system, can understand
exactly what applications you're running on that device
and can make security decisions based on what applications
are in use.
Since you're also running this on your local machine,
it can view information that has been decrypted
once it comes off the network.
And if you're in an environment where there's
many different virtual systems, you
might want to use a virtual firewall to provide security
for all of the traffic within a single data center.
We refer to that as East-West traffic.
And having a virtual firewall in that environment
can help you control exactly what application traffic moves
between servers.