When you work in technology, and especially in security
with technology, there's a lot of rules involved.
These rules are procedural rules,
they're rules about the way that our devices operate,
they're rules about allowing people access
to different things.
A lot of the things that we do, really, are procedural.
They're both technical and non-technical in nature.
You need policies and procedures,
and what happens when somebody walks into your building
and they don't have their badge?
You need policies and procedures when a new person is hired.
What is the process for getting them
the proper credentials to the network?
And of course, there's technical procedures as well.
When somebody is asking for those credentials,
how do you provide those credentials?
There's got to be a way that you provide that into your system.
They're for environments that are dealing with finances
or medical or other sensitive types of data.
There are also a lot of very specific rules as well.
Some of these rules are things that you've created internally,
some of these rules have been created by third parties
and are required of you to maintain because
of the types of environments that you have.
If you're someone who has medical information-- that's
very private information-- there are certain rules
and requirements that you must follow
to be able to protect your patients' data.
When we look at our technical devices like firewalls,
there's packet filters, even email systems
have filtering rules within them.
These are, in some cases, very very technical rules.
We're dealing with bits and bytes,
and so we also have to apply those rules
to what we're doing as well.
Sometimes, in fact almost all the time, our technical rules
are going to follow the procedural rules
that we set up.
When somebody is asking for credentials
to be able to log into the network they might fill out
a form, they might visit a web page and add their information,
and then you've now got to provide the technical back end
to provide them that data.
So you're almost always spending a lot of time--
before you even touch a keyboard-- determining
what the process is going to be.
Determining what somebody has to provide you in order for you
to get them the access that they need.
These are things that, hopefully, you're
figuring out based on your requirements for your business
or your organization.
But very often you're taking into account
a lot of different requirements from a lot of different people
and putting that all together to create the technical answer
that you might need.
Let's start a technical discussion of rules
dealing with firewall rules, because as a security
professional you are going to be using firewalls quite a bit,
and you're going to be going through the rule bases
to allow or deny people access to certain resources.
And as we look at the rules of the firewall,
we're usually making the decisions
on what people can do based on a number of different tuples.
These are different categorizations
of data that we'll then add information to.
So we may decide if somebody is coming from a certain source IP
address, they may be going to a certain destination IP address,
maybe using a certain kind of port number.
It may be a certain time of the day,
they may be using a certain application,
and on and on and on.
Different firewalls have different tuples
that you could use to make this determination.
And we'll group that together and say
if you match all of these put together,
then you are either allowed or denied
access to certain resources.
Usually, there is also a logical path
that you follow with firewall rules.
Almost always, you start at the top of a rule base
and you work your way down.
It's not that way with every firewall, however.
You'll need to look at your particular firewall
and how it operates to find out exactly the path that it
follows, to be able to determine whether somebody has access
to the internet or not.
These rules can also be very generalized.
Maybe you might want to set a rule that
says if you're anybody inside the network,
you can surf the internet.
That's a very general rule.
Or it might be very specific, that says
if you are in the marketing department
and you are coming from a particular source IP address,
then you have access to this particular resource
on the internet that is that another IP address.
That's a very specific role.
So you tend to put those specific rules
at the top of your firewall list so that they're fired on first
if it applies, and then other more general rules are
at the bottom.
In almost all firewalls-- this is not always
the case-- but a good firewall, anyway, I
like to think that there is something called
an implicit deny at the very bottom of that list.
And that means that if it goes through your list of rules
and at the very bottom of the list
it hasn't hit any of those rules,
we're just going to drop the traffic.
It is implicitly denied traffic at the bottom.
Some people will put an explicit deny at the bottom.
They'll create a rule at the bottom of their firewall
that says if it's any-to-any type traffic at the bottom,
deny everything.
Sometimes that's useful just so you
can see it, and know that that rule is being fired on.
Sometimes they're doing it so that it gets logged,
because usually implicit denies don't log traffic.
Can you imagine logging everything
that comes in from an internet connection that's
not intended to come inside of your network?
It would be an enormous amount of traffic.
Some people, however, would like to see that information.
So they may put an explicit deny down
at the bottom of the rule base, just so they can capture
and log some of that information coming by.
If you don't put a rule, then it's probably the case
that your firewall has an implicit deny,
and it's going to drop all that traffic anyway.
Let's step through a very simple firewall rule base,
and let's see what's really involved here.
I grabbed this rule set directly from an internet service
provider.
This is their default configuration
for their web servers on their Linux host.
And you can see they're numbered one
through seven, all in order.
In fact, they start from the top and work their way down.
And you can see there is a default policy here.
This particular rule set has an implicit deny,
which means unless you're allowing it in this list,
it gets denied.
So let's start with rule number one, which
says if you're coming from any remote IP
address on any remote port number,
and you're connecting to this particular web
server on port 22 with the TCP protocol,
we're going to allow that.
If you're a really good person about documenting
your particular firewall rules-- there
may be one of these fields that's a description field--
and you may put in here that this rule allows anybody
to be able to SSH to our particular firewall.
This is how you take those well-known port numbers
and apply them back to certain applications that are used.
Now that that matches, we'll then allow an SSH.
So let's go down to the next one,
let's say the traffic coming through
doesn't match that, then we'll examine this rule.
It says from any remote IP to any remote port number
over port 80 that's running TCP, allow that traffic.
And of course, port 80 TCP is HTTP based traffic, usually.
That's our web service traffic.
So if we're running a web server on this machine,
somebody's trying to connect to it with a browser,
it is the firewall rule number two
that will allow that traffic to connect to this server.
Let's do one more.
Rule number three is remote IP is
any talking to any remote port number over port 443.
That is the TCP protocol.
Allow it, and of course, port 443 is HTTPS.
And you would step through this list
and make sure that everything here
is what you would like it to be.
In fact, the next rule that says allow all
IPs from any port number to local port 8443 over the TCP
protocol, allow it.
That's not one you often see.
8443 is not usually a well known protocol.
That is a protocol that is used-- a port number that's
used-- to open up access to the management part of the web
server.
So if you don't want people managing your web server
with that front-end web based management that you've created,
you may want to deny traffic if it's
coming from any remote IP address.
So that's a good example of how you can allow or disallow
the traffic based on any of these port numbers coming
through.
And we're simply following the rules of our firewall, one
after the other, until it either fires or gets
to the bottom where traffic is implicitly denied.