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

Generally speaking, three common rulesets need to be defined for the firewall: • Ingress filters • Egress filters • Management-access ruleset Ingress Filters Ingress filters are u

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

http://www.ietf.org/rfc/rfc3704.txt

• RFC 2827, Network Ingress Filtering: Defeating Denial of Service Attacks which use IP Source Address Spoofing http://www.ietf.org/rfc/rfc2827.txt

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

http://www.cymru.com/Documents/bogon-list.html, with a number of different formats that you can reference Alternatively, you can go directly to

http://www.iana.org/ipaddress/ip-addresses.htm, 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