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

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

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