Tài liệu Firewall Policies/Rulesets phần 2 pdf

Figure 10-4. One-Armed DMZ and ACLs [View full size image] 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: • Restrict management access to specific management workstations only. • Never allow management access from an untrusted network. 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. • Always use an encrypted management method. • In the event that you cannot use an encrypted management method (for example syslog), consider implementing IPsec to secure the traffic in question. 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 • SNMP • Syslog • TFTP and FTP • HTTP and HTTPS • Proprietary management methods 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: • If SNMPv3 is available on your firewall, use it rather than SNMPv1 or SNMPv2c. SNMPv3 provides for encryption as well as user-based authentication. • If SNMPv1 or SNMPv2c must be used, consider using IPsec to encapsulate and secure the traffic. • Do not use the same SNMP community strings on your firewalls that you use anywhere else in your network. This ensures that if the firewall is compromised in some way, the community string is worthless elsewhere in your network. • If you do not actively intend to use SNMP to make changes to your firewall, implement SNMP in a read-only fashion. • Restrict SNMP management access to designated management workstations only. 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. . on your firewall, use it rather than SNMPv1 or SNMPv2c. SNMPv3 provides for encryption as well as user-based authentication. • If SNMPv1 or SNMPv2c must. 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