Tài liệu Firewall Policies/Rulesets phần 1 pptx

Firewall Policies/Rulesets
The previously mentioned policies focus primarily on defining the requirements and
expectations of the firewall and interrelated systems. After the requirements have been
defined however, you must actually build the configuration and ruleset that the firewall
will use. Although somewhat confusing, this is also commonly referred to as the firewall
security policy, even though practically the firewall security policy is better defined as a
combination of standards, guidelines, and procedures than a policy per se.
For this reason, I like to think of the firewall policy more in terms of the firewall ruleset,
to ensure that there is a distinction between the security policies that define the
requirements and the security policies (or ruleset) that define the actual rule configuration
that adheres to the defined requirements. Generally speaking, three common rulesets need
to be defined for the firewall:
• Ingress filters
• Egress filters
• Management-access ruleset
Ingress Filters
Ingress filters are used to restrict traffic coming into an interface or from a given network
segment. Ingress filters are commonly applied to traffic coming from an untrusted source
(such as the Internet or a DMZ segment) to a trusted source (such as a DMZ or internal
network, respectively). To really get comfortable with the concept of ingress filters, it is
important to understand that a filter is an ingress filter relative to the direction and source
of the traffic being filtered. For example, if you consider a simple single firewall
configuration with a one-armed DMZ segment, potentially two ingress filters would
apply to the firewall, as pointed out in Figure 10-3
.
Figure 10-3. Ingress Filters
[View full size image]



As you can see by the traffic-flow arrows, traffic can flow from the Internet to the DMZ

segment, from the DMZ segment to the internal network, from the internal network to
either the DMZ or the Internet, and from the DMZ to the Internet (these last two
scenarios are technically egress-filtering scenarios, which we discuss in the "Egress
Filters" section). Flow is not permitted from the Internet directly to the internal network.
In this scenario, two potential ingress filters will be built. The first will control the access
from the Internet to the DMZ. In this instance, the Internet is considered the untrusted
network, and the DMZ is considered the trusted network. The second will control the
access from the DMZ to the internal network. In this instance, the DMZ is considered the
untrusted network, and the internal network is considered the trusted network.
For most commercial firewalls today, the default ingress-filtering methodology is to take
a minimalist approach to permitting traffic. This just means that by default all traffic
coming in from an untrusted network is denied, except that which is specifically
permitted.
Although this is a great out-of-the-box configuration, the reality is that virtually all
firewalls that you will implement must be configured to allow some traffic from
untrusted to trusted network, most commonly from the Internet to a DMZ and from a
DMZ to an internal network. To help in building your ingress filters, follow a systematic
approach to ingress filtering.
Note
For more information regarding ingress filtering, review these two RFCs:
• RFC 3704, Ingress Filtering for Multihomed Networks
/>
• RFC 2827, Network Ingress Filtering: Defeating Denial of Service Attacks which
use IP Source Address Spoofing />


A Systematic Approach to Ingress Filtering
Perhaps the most effective method of implementing ingress filtering is to use a systematic
approach to building your filters. Adhering to the concept of the minimalist approach, an
effective method of building your ingress lists is to follow this procedure:

Step 1.
Identify the source (untrusted) and destination (trusted) networks or systems
that the filter will apply to.
Step 2.
Identify the services or applications that will be required.
Step 3.
Identify the TCP and UDP ports required for the identified services or
applications.
Step 4.
Identify the source (untrusted) and destination (trusted) systems that a
particular service, port or rule will apply to.

A combination of these first four steps will help you identify what your ingress
filter needs to look like to provide access to the services and applications you
have decided to make available. In addition to this, however, ingress filtering
can be used to protect your network from additional attacks such as denial of
service attacks and to some degree IP address spoofing.
Step 5 5.
Identify network source addresses that should not be allowed from the
untrusted network. In many cases, this includes the RFC 1918 private address
spaces of 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16; the RFC 3330 special-
use addresses; and the IP address space of the trusted network and the IP
address space of any unassigned addresses, frequently referred to as bogons.
Tip
Although the RFC 1918, RFC 3330, and trusted network IP address space is
relatively static and not subject to change, bogons change whenever Internet
Assigned Numbers Authority (IANA) assigns someone a new IP address
space. Consequently, you will need to update and maintain the bogon list that
you will apply to the ingress filter. The list of bogons is maintained at
/>, with a number of different

formats that you can reference. Alternatively, you can go directly to
/>, but the list maintained by
Team Cymru is generally much easier to dissect and implement.
Step 6.
Build and implement the ACL that will apply to your ingress filter and then
apply it to the appropriate interface in the appropriate direction.
Step 7.
Monitor the ACL to determine whether there is traffic that needs to be
permitted which is not being permitted, or more important, if there is traffic
that is being permitted that is probably not needed. For example, if the firewall
is not reporting any traffic matching a permit statement, consider removing the
permit statement completely.
Adhering to this methodology helps ensure that your ingress filter is complete, adheres to
your firewall security policy, and functionally protects the resources intended. This
methodology can then be applied to virtually any environment; however, there are really
three common situations where ingress filtering is implemented:
• Access from the Internet to a DMZ segment
• Access from a DMZ segment to an internal segment
• Access from the Internet to an internal segment
Access from the Internet to a DMZ Segment
In a perfect world, you would be able to implement a firewall and block all traffic from
the Internet, thus protecting your environment from a wealth of external threats and
sources. We do not live in a perfect world, however, and more and more it seems that
what started as a firewall with relatively few Internet-based access requirements has
become a more and more porous situation. Of course, the problem with this is that every
time traffic is permitted through the firewall, the firewall becomes less and less effective
as a security barrier.
Some folks, particularly at BlackHat 2004, went so far as to declare the network
perimeter dead, and although I do not think we are at that point yet, certainly it cannot be
argued that firewalls today are in many cases less secure than their counterparts in years

past as a direct result of the number of ports that must be opened. With each
configuration change, there is also an increase in the likelihood of a mistake or
misconfiguration occurring, further reducing the effectiveness of the firewall as a security
device.
Although there is no foolproof method of ensuring that mistakes will not happen (indeed,
you should plan for and expect mistakes to occur), one can definitely minimize mistakes
by implementing an ingress filter for traffic from the Internet to a DMZ segment that is
based on a sound baseline or starting template and then takes into account the seven-step
method previously described to build the more complex ingress filter required, as seen
here:
Step 1.
Start by denying everything. Although many systems include an implied deny
statement at the end of any ACL, it is worth ensuring that there is an explicit
deny at the end of any ACL. There are a number of reasons for this. First, this
will ensure that nothing gets overlooked or that in the event that your firewall
does not include an implicit deny you are not caught off guard. Second, it will
give you the opportunity to configure the firewall to log those denied packets,
in the event that you require the information for regulatory reasons, and so on.
Step 2.
Evaluate the required DMZ services and corresponding ports that are required
for operation. Keep in mind that in most cases ACLs are read top to bottom;
so, an entry at the top of the list supersedes one at the bottom of the list.
Step 3.
Evaluate the required source and destination IP addresses that correlate with
the services and ports that need to be opened. Something to consider is that if
everyone on the Internet does not need access to a particular service or port, do
not grant everyone on the Internet that access. For example, if you have certain
systems that you need to be able to FTP to and from, open your FTP server to
those Internet IP addresses only. A service can only be exploited if it is in some
way accessible.

Step 4.
Review all the rules that you have built in to your ACL and verify the
following:
• That services and ports you expect to function do function.
• That services and ports you do not expect to function do not function.
• That you have not opened ports that are not in fact necessary. This can
be done by logging the corresponding line in the ACL and testing the
application or service in question. If the log shows a permitted
connection, it is working. If the log does not show a permitted
connection, you might be able to shut that port down. This is historically
a problem with services such as FTP that some people mistakenly
believe need both TCP port 20 and 21 open inbound to function.
Step 5.
Log every ACL line (unless you are certain you do not need the data logged).
Although this may seem like an insurmountable amount of data that will be
stored, all compliance legislation is pointing to the need for this information to
be stored properly. To help manage it, consider implementing third-party
security management software such as Cisco CiscoWorks or NetIQ Security
Manager.
Step 6.
Apply the ACL accordingly on your firewall.
Step 7.
Monitor the results of permitted and denied traffic as a result of the ACL until
you are comfortable with how the ACL and firewall are functioning.
Note
The terms ACL and ruleset are in most cases completely interchangeable. Some firewalls,
such as the Cisco Secure PIX Firewall, use ACL to refer to the traffic-filtering list. Other
firewalls, such as the CheckPoint series of firewalls, use ruleset to refer to the traffic-
filtering list. In truth, the terms are virtually interchangeable in this context, and therefore
best practices and recommendations for one are largely applicable to the other, with the

technical implementation typically being the only difference.


Access from a DMZ Segment to an Internal Segment
This is perhaps the most important ingress filtering you will implement because it is what
truly protectsor exposesyour internal resources to external threats. Today's Internet
applications are requiring more and more access to internal resources, and an effective
method of mitigating the risks involved in granting that access is to implement a
middleware server in the DMZ that is accessed from the Internet, which in turn accesses
the back-end data that is typically located on the internal network.
Although this sounds like a relatively simple configuration, the devil is in the details, and
in many cases the number of ports that must be opened to facilitate communications can
often times cause one to wonder why have a firewall at all! Take, for example, a
particularly troublesome DMZ service such as Microsoft Outlook Web Access (OWA).
To get an OWA server in the DMZ communicating with the internal Exchange Server
and domain controllers, it requires so many ports to be opened that a compelling case can
be made that the OWA server might as well be on the internal network anyway. One
reason for this is that when you open some ports in the firewall, such as Microsoft
Remote Procedure Call (RPC), firewalls cannot distinguish between the RPC
communications required for OWA and RPC communications for mapping a drive. From
the firewall's perspective, it all is using the same TCP or UDP port, and therefore it is
permitted accordingly. Consequently, it is critical when looking at ingress filters from the
DMZ to the internal network to take a hard look at what it really means to open up
access.
Another issue with ingress filters from DMZ segments is when you have a one-armed
DMZ and are using a firewall such as the Cisco Secure PIX Firewall, as shown in Figure
10-4.