Firewall Policies/Rulesets phần 1

Chia sẻ: Tuan Bui Nghia | Ngày: | Loại File: PDF | Số trang:7

Thêm vào BST

Báo xấu

104
lượt xem 13
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

The previously mentioned policies focus primarily on defining the requirements and expectations of the firewall and interrelated systems.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Firewall Policies/Rulesets phần 1

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.