Firewall Fundamentals
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
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
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:
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:
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
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:
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. Figure 10-4. One-Armed DMZ and ACLs
Because the DMZ has a single interface for all traffic going to either the Internet or the internal network, building and applying an ACL to that interface will functionally act as an ingress filter to the internal network but as an egress filter to the Internet. This will make the ACL even more complex to design and implement. The good news is that the same seven steps in building an effective ACL for traffic from the Internet to the DMZ should be applied in this situation, so the methodology remains consistent. Access from the Internet to an Internal Segment
Building an ACL to control traffic from the Internet to an internal segment is functionally no different from the previously discussed ACL scenarios. What differs, however, is that the traffic is going to come from a completely untrusted network and potentially have direct access to internal resources. Now, the knee-jerk response to this type of implementation is to simply not allow it. I have found that there are few constants in network security, however, and whereas 99 percent of the situations that call for direct access to internal resources can probably be worked around in another fashion, there is always that 1 percent that, for whatever reason, you just cannot do anything about. In those cases, you need to be absolutely certain of what you are allowing through the use of your ingress filter. Additionally, although technically not an ingress-filtering issue, you should strongly consider using a firewall that does a true application proxy of the service you are advertising to ensure that only the kind of communications at the application layer that you want to permit are indeed being permitted. An example of this is something like the Microsoft ISA Firewall using its application publishing features to grant access to the resource. Egress Filters
Practically speaking, egress filters are almost identical to ingress filters. The difference lies in what an egress filter applies to. Unlike ingress filters, egress filters apply to traffic that is coming from a trusted network to an untrusted network. As a result, egress filters typically are applied either on firewall interfaces that connect to the internal network or to a DMZ segment. A simple way of thinking of ingress and egress filters is that an ingress filter filters traffic coming in, and an egress filter filters traffic going out. Unlike ingress filters, however, many firewalls default to allowing all traffic from a trusted source to an untrusted source. This is particularly true when it comes to the Cisco Secure PIX Firewall, which uses the concept of interface security levels to determine which networks will automatically be configured to permit traffic. The upside of this kind of configuration is that the firewall can be plugged into the network, and then with virtually no configuration, internal hosts can access external (typically Internet-based) resources. From a usability and simplicity perspective, this is a good thing. Unfortunately, from a security perspective it is a very, bad thing because that same simplicity means that even malicious traffic is going to be permitted by default. Implementing an Egress Filter for Internal Traffic
Perhaps the biggest problem, and reason, that people do not implement egress filters for their internal traffic is that egress filters can be incredibly complex to get right. Ingress filters are relatively straightforward. You know the handful of services and systems that users will need access to, and you configure the ACL accordingly. Because most firewalls today perform stateful packet inspection, the return traffic for connections permitted by the ingress filter is automatically permitted. With an egress filter, there is potentially a much, much larger list of ports that must be opened. Although it is easy to assume that your users really just need HTTP and maybe HTTPS Internet access, the truth is that you probably have users who use all kinds ports to talk to all sorts of legitimate external resources. Similarly, if there are resources in the DMZ that your users need access to, your egress filter is going to need to accommodate those conversations, too. Tip Traditionally, egress filtering has always come as an afterthought to ingress filtering. The focus was always on keeping malicious traffic out, not necessarily restricting traffic that is going out. With the types of Internet worms and distributed denial-of-service (DDoS) attacks that have been propagating recently, more companies are looking to egress filtering to prevent their systems from being used to spread worms or participate in DDoS attacks. In addition, more companies are looking to better control the kinds of data that is exposed to the Internet through Trojans and similar programs which can easily be brought into the internal network on a laptop, and then in a completely unrestricted fashion connect back to the malicious user externally. To prevent this, it is a good idea to really approach your egress filter from the minimalist perspective. For example, your employees almost certainly do not need to make Simple Mail Transfer Protocol (SMTP) connections to external resources. Only your Internet gateway mail server does. So in your egress filter, ensure that you block SMTP traffic from all internal hosts except the Internet mail gateway. Although this is a laborious and time-consuming process to build the initial list, and it is painful to implement (because you will almost certainly overlook something), after the egress filter has been implemented it is relatively easy to maintain and provides a dramatic increase in the security posture of your organization. Once again, the same methodology that is used to build an ingress filter applies to building an egress filter as previously described in this chapter. Implementing an Egress Filter for a DMZ
As mentioned when discussing ingress filters, if your DMZ is a one-armed DMZ segment, the ingress and egress filter may effectively be the same thing because all communications must go through the same network interface on the firewall. This is particularly true for Cisco Secure PIX Firewalls. When implementing the egress filter portion of your ACL, remember to focus on the traffic that will be permitted from the systems on the DMZ to systems on the Internet. Beyond that, however, the same methodology that applies to your other ingress and egress filters applies here. Tip I was performing a security audit in a particular environment and encountered a DMZ situation whereby the ingress filter allowed traffic from a host that was not running the corresponding service, and the egress filter allowed unrestricted HTTP and FTP access to the Internet from DMZ hosts. What I was then able to do, as a result of a security exploit in the web server software it was running, was gain a command shell on the box by which I could run command-line utilities. Next, I was able to use FTP, which the egress filter permitted, to grab the utilities I needed from an FTP server and put them on the server in the DMZ. With everything in place at that point, I was able to launch a different exploit that would grant me a Virtual Network Computing (VNC) session on the servereven though VNC was not installed on the serverand tunnel the display through the firewall over the open port in the ingress filter. This process took approximately 5 minutes to complete from start to finish. Had the egress filter been updated properly to ensure that I could not FTP my utilities to the server, or the ingress filter been updated to account for the fact that the service in question was not running on that server, I would have been nowhere near as successful. As it was, I was able to gain full control of the server in the DMZ, only to discover that it was allowed to make Microsoft RPC connections to the internal network, but that's a story for another day. Management-Access Ruleset
With ingress and egress filtering sorted out, the next security policy task is to review the management access ruleset. Although some firewalls will include management access in the ingress or egress filter as appropriate, given the nature of access it warrants being called out and given special attention. The most important thing to remember about management access is that regardless of method, a few rules apply:
Tip Another discovery during the previously mentioned audit was that the firewall in question permitted management connections from the DMZ. Although this was likely done for troubleshooting purposes, when we gained control of a server on the DMZ and put our utilities on it, it was a relatively trivial thing to begin trying to (and eventually succeeding to) crack the passwords on the firewall, thus allowing us to make whatever changes we wanted. Never, ever allow management access from untrusted networks.
There are numerous methods of performing remote management and logging of a firewall. Some of the most common methods are as follows:
Telnet and SSH
Telnet is ubiquitous for remote management of firewall appliances; largely due to the fact that it is virtually a de facto standard method of making remote command-line connections to UNIX-based systems and network devices. Unfortunately, Telnet is an unencrypted protocol and should be restricted if at all possible. Instead, use SSH for the same functionality. SSH allows you to do pretty much the same thing that Telnet does, gain a remote command shell, but SSH traffic is encrypted and thus a secure remote-management method. Even with this, however, you should never configure SSH to be permitted from an untrusted network. Although it is certainly more convenient to be able to SSH into the firewall from home instead of having to drive into the office, exposing SSH on Internet-connected interfaces in particular is asking for a security incident to occur. Instead, consider implementing a VPN configuration that would allow the remote support personnel to VPN into a DMZ from which they could gain management access to the firewall using SSH. SNMP
SNMP presents a bit of a unique problem with firewalls. On one hand, it is hard to argue the value of SNMP-provided data such as performance statistics. On the other hand, however, SNMP is traditionally an insecure protocol that can be used to completely reconfigure the firewall (assuming that SNMP is not in a read-only mode). In fact, this insecurity is the single biggest reason that organizations decide to completely disable SNMP on their firewalls. Although this is certainly effective, if you want to leverage SNMP you can do some things to make it more secure:
Note For more information regarding SNMP and how SNMP functions, review RFC 3411, RFC 3413, RFC 3414, RFC 3415, RFC 3416, RFC 3417, RFC 3418, and RFC 1157. These can all be located at http://www.rfc-editor.org, where you can search for the term "SNMP" and review all 100+ SNMP-related RFCs
Syslog
Syslog differs from most other management methods in that rather than serving as an active method for the administrator to interact with the firewall, syslog simply transmits logging information and data to a syslog server for review, action, and archiving. Because syslog messages can contain information related to potential security exploits, care should be taken to ensure that the firewall can only transmit syslog data to a designated syslog server. Syslog is typically transmitted in an unencrypted fashion over UDP port 514. Consequently, if security is required, you need to implement IPsec for communications between the syslog server and the firewall. Tip The Cisco Secure PIX Firewall can transmit syslog over TCP, allowing for connection-oriented communications. This allows the PIX to then be configured to stop permitting all traffic if it is for some reason unable to successfully communicate with the syslog server. In a highly secure environment, this is a good thing because it ensures that only traffic that can be successfully logged will be permitted. However, this can dramatically increase down time and the potential for a denial of service if for any reason the firewall cannot communicate with the syslog server. You need to weigh carefully in your environment the requirements for uptime and availability against the increased security using TCP-based syslog may provide. Although more secure sounds great, the first few times that the firewall stops working because the syslog server was rebooted or crashed may cause you to rethink your syslog policy. In PIX OS 7.0, this fail-shut behavior can be disabled by running the command logging permit-hostdown. TFTP and FTP
TFTP and FTP are both used primarily for copying files to/from a firewall and updating the system software or configuration. Although FTP provides for authentication mechanisms that TFTP lacks, both protocols transmit the data in an unencrypted fashion and are therefore susceptible to eavesdropping. Given the fact that the traffic frequently will contain configuration data, this is a significant security issue. To help secure TFTP and FTP traffic, restrict the firewall to only communicate with designated TFTP or FTP servers. Furthermore, if it is possible to encapsulate the TFTP or FTP data in IPsec, do that, too, to ensure that the data in transit is protected accordingly. HTTP and HTTPS
HTTP and HTTPS are both typically used for web-based remote management. Similar to Telnet and SSH, HTTP uses an unencrypted transmission method (whereas HTTPS uses encryption). Consequently, HTTP should never be used if HTTPS is available. Because of the nature of HTTPS, providing security for the firewall is largely a process of ensuring that only specified management workstations are allowed to connect to the firewall over HTTPS. Like SSH, HTTPS should also never be configured over an untrusted network such as the Internet. Proprietary Management Methods
For proprietary management methods such as CheckPoint OPSEC/LEA, connections leave you largely at the mercy of the vendor in terms of ensuring that the protocol itself is secure. The only real options are to ensure that you restrict access only to designated management stations, and if encryption is not provided by the vendor, attempt to encapsulate the traffic in IPsec, similar to SNMP and syslog. |
Категории