In most cases, this means that the rule allowing internal systems to use HTTP to any system on the Internet and the rule allowing external users to access the organization’s Web site sho
Trang 1Chapter 9: Internet Architecture 159
Firewall Rule Set Design
Good rule set design can be as important to a firewall as good hardware Most firewalls
work on “first match” when deciding whether to accept or reject a packet When
design-ing a rule set, the “first match” algorithm dictates that the most specific rules be placed at
the top of the rule set and the least specific or most general rules be placed at the bottom
This placement guarantees that more general rules do not mask the more specific rules
NOTE: Some firewalls provide a rule set processor that examines the rule set for rules that are
masked by other rules The processor then flags this condition for the firewall administrator before
in-stalling the rules on the firewall
While this is a good general guideline, it does not address the performance issue of
the firewall The more rules that must be examined for each packet, the more processing
must be done by the firewall Good rule set design must take this into account to make the
firewall more efficient
To do this, look at the expected traffic load of the firewall and rank the traffic types in
order Generally, HTTP traffic will be the largest To make the firewall more efficient,
place the rules pertaining to HTTP at the top of the rule set In most cases, this means that
the rule allowing internal systems to use HTTP to any system on the Internet and the rule
allowing external users to access the organization’s Web site should be very near the top
of the rule set The only rules that should be above them will be specific deny rules
per-taining to HTTP
NETWORK ADDRESS TRANSLATION
At first glance, IP addressing does not seem like a topic for a security book The
address-ing of systems is clearly a network administration issue, of course Well, not quite Any
organization that plans to install a firewall will have to deal with addressing issues In
fact, addressing that is not well thought out and configured properly can cause many
headaches At the root of the problem is the shortage of IP address space The familiar
32-bit addresses in the dot notation (xxx.yyy.zzz.aaa) are simply being used up Because
of this, ISPs are reluctant to give out large blocks of addresses to their customers Most
ISPs will provide blocks of 16 or 32 addresses (which actually become 14 or 30 addresses
when the broadcast addresses are taken into account) Thirty addresses are not enough
for a small organization, never mind a medium or large organization Most organizations
have more than 30 systems So what do you do? The solution is called network address
translation (NAT)
Trang 2What Is Network Address Translation?
NAT is just what it sounds like—it translates one or more addresses into other dresses So how does this help? When we build our networks we use the 30 or so ad-dresses provided by the ISP for systems that must be visible to the Internet On the inside of the network, we use addresses that are not visible but are translated or NATed for communication to the Internet
In most networks, the firewall performs the NAT function Routers can also be used for this function if necessary Application layer firewalls perform NAT as part of their de-sign Since all connections terminate on the firewall, only the firewall’s address is visible
to the outside Packet filtering firewalls also have this capability but it must be configured during firewall setup
NAT can also provide a security function as the hidden addresses of the internal systems are not visible to the Internet If the system is not visible, it cannot be addressed and targeted
NOTE: NAT does not provide complete protection from attack and should not be relied upon at the
expense of other security measures If the attacker is within the organization or has direct access to the internal network via a VPN or dial-up connection, for example, NAT is no protection at all
Private Class Addresses
So we have this concept of NAT but we still need addresses for the internal network The choice of internal addresses can cause all types of routing problems if it is not done prop-erly RFC (that is, Request for Comment, which is how Internet standards are published)
1918 specifies what are called private class addresses These addresses are intended for use
on internal networks behind a firewall that performs NAT
The RFC specifies the following addresses as private class addresses:
▼ 10.0.0.0 – 10.255.255.255 (10.0.0.0 with an 8-bit mask)
■ 172.16.0.0 – 172.31.255.255 (172.16.0.0 with a 12-bit mask)
▲ 192.168.0.0 – 192.168.255.255 (192.168.0.0 with a 16-bit mask) The use of these addresses provides an organization with a lot of flexibility in design-ing its internal addressdesign-ing scheme Any of these addresses can be used in any combina-tion within the organizacombina-tion’s internal network There are no limitacombina-tions on this
None of these addresses are routable on the Internet If you attempt to ping to a pri-vate class address, the packets will be returned with a “network unreachable” message
NOTE: Some ISPs use private class addresses on their internal network There may be some places
where a ping response is received to a private class address in this case If the ISP is using the private class addresses internally, routes to these networks should not be broadcast and thus will not affect an organization’s use of these addresses
160 Network Security: A Beginner’s Guide
TE AM
FL Y
Team-Fly®
Trang 3Static NAT
We architect a network to use private class addresses and we want to use NAT to allow
systems to be accessible from the Internet For this situation, we use what is called static
NAT Static NAT maps a single real address from the organization’s external network to a
system on the DMZ Figure 9-14 shows how this translation works
NOTE: You could map the address to a system on the internal network but the system is then
acces-sible from the outside and such systems should be in the DMZ
An obvious question that arises is why bother with NAT? You could just assign real
addresses to the DMZ and be done with it While this is true, there are two issues that
come up First, you would need a second set of addresses to do this or you will need to
further subnet the 30 addresses that the ISP is providing If you wish to place some
sys-tems on a second DMZ, yet another set of addresses will be required Second, not all
systems on the DMZ may need real addresses If you look back to Figure 9-8, you will
see an application server on the DMZ This application server does not require access
from the Internet It is there to process information received by the Web server and to
interact with the internal database server
Static NAT is a one-to-one configuration For each system that must be accessible
from the Internet, one real address is used Static NAT is appropriate for servers in a DMZ
but it is not appropriate for desktop client systems
Chapter 9: Internet Architecture 161
Figure 9-14. Static network address translation
Trang 4Dynamic NAT
Dynamic NAT differs from static NAT in that many internal addresses are mapped to a
single real address (see Figure 9-15) instead of using a one-to-one mapping Typically, the real address that is used is the external address of the firewall The firewall then tracks the connections and uses one port for each connection This creates a practical limit of about 64,000 simultaneous dynamic NAT connections Keep in mind that a single internal desk-top system may open as many as 32 simultaneous connections when accessing a Web site Dynamic NAT is especially useful for desktop clients who use Dynamic Host Config-uration Protocol (DHCP) Since systems using DHCP are not guaranteed the same IP ad-dress when the system boots, static NAT will not work Systems that use dynamic NAT are not addressable from the outside since only the firewall maintains the mappings of ports to systems and the mappings will change regularly
Figure 9-15. Dynamic network address translation
Trang 5PARTNER NETWORKS
The design concepts that have been discussed for Internet architectures can also be used
when designing networks with partners Connectivity between organizations has
in-creased dramatically as organizations have discovered that it can reduce costs
Use of Partner Networks
Partner networks are generally established to exchange certain files or pieces of data
be-tween organizations This translates into a requirement for particular systems within one
or-ganization to communicate with particular systems in the other oror-ganization It does not
mean that one organization requires unrestricted access to the other organization’s network
If you apply a risk-management approach to a partner network, you’ll see that a risk
exists if the two organizations are connected By connecting the networks of the two
orga-nizations, access is now available to the other organization’s employees Also, remember
that two of the agents of threat discussed in Chapter 6 were business customers and
sup-pliers Clearly, some control must be put in place to manage this risk
Setup
The security requirements for the partner network differ little from the requirements of
an Internet connection Thus, we can use the same architectures and methodologies
The services necessary for the connection are identified and the systems that provide
these services are placed in a DMZ This is not the same DMZ that is used for the Internet
connection, although it may reside off the Internet firewall if sufficient resources are
available (see Figure 9-16) When you look at the figure, notice that the firewall added
two interfaces: one to the partner DMZ and one to the partner network
Additional rules must be added to the firewall to allow systems at the partner
organi-zation as well as internal systems to access the partner DMZ systems However, there
should be no rules that allow systems in the partner organization to connect to the
inter-nal network, to the Internet DMZ, or to the Internet In many firewalls this may require
explicit denies Table 9-5 shows how the rules will change
As you can see from Table 9-5, there are rules at the top of the list that specifically
deny access to and from the partner organization’s networks Since most firewalls work
on the first rule that matches, specific deny rules must be placed prior to the global accept
rules such as rules 5, 6, 7, 8, and 9
Addressing Issues
There is one other issue when dealing with partner networks and that is addressing Most
organizations use private class addresses for internal networks Because of this you’re very
likely to run into a partner using the same addresses as your organization Organizations
that do not pay attention to this problem may end up defining the entire 10.x.x.x network as
Chapter 9: Internet Architecture 163
Trang 6belonging to a particular partner only to find out that another partner organization also uses 10.x.x.x
To alleviate this issue, it is good practice to use NAT when connecting to partner works By defining a translation policy for the partner network, you can allow their net-work to become part of your addressing scheme
Figure 9-16. Partner DMZ using the Internet firewall
Trang 7NOTE: The discussion in this section is only intended to bring this issue to your attention Addressing
and the correct routing of interconnected networks is a book-length topic all to itself Care must be
taken when building interconnected networks so that traffic flows in the correct manner and so that
ad-ditional security issues are not introduced
Chapter 9: Internet Architecture 165
Rule
Number Source IP Destination IP Service Action
1 Partner
network
Partner DMZ Appropriate for
partnership
Accept
2 Partner
network
3 Partner DMZ Partner network Appropriate for
partnership
Accept
8 Internal
network
Any HTTP, HTTPS,
FTP, Telnet, SSH
Accept
Table 9-5. Rules for Internet Firewall with Partner Network Access