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
, 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.