Click on our Sponsors to help Support SunWorld
|
Avoid firewall pitfalls
Poor planning can result in nonfunctional firewalls and broken networks. We give you a firewall implementation checklist and tell you how to stay clear of common mistakes
|
|
Abstract
One of the common mistakes made in implementing a firewall is
concentrating too much on the firewall functionality. Obviously,
you need to consider the network entities and rules, but the
integration of the firewall into the existing environment is equally
important and equally fraught with pitfalls. If the integration is
not carefully planned, it can result in nonfunctional firewalls and
broken networks. This month, we provide a list of steps to take when
planning a firewall implementation and some examples of what can go
wrong in integrating a firewall with your facility.
Also in Pete's Wicked World this month: In the
buglist, some more buffer overrun exploits on Solaris. In the toolbox, a new secure telnet
tool. The bookstore has some hot links to
security Web pages.
And don't forget to check out Pete's recently updated Security
FAQ.
(2,700 words)
Reminder: There is a lot happening at the Sun User
Group conference in Boston on June 2-4.
Beware the unplanned firewall
implementation. In previous columns, we've discussed the hazards of
attempting to secure a facility without having a security policy in
place. Unfortunately, a good policy, like a bad movie, only takes you
halfway there. The implementation of the security policy needs
careful attention to detail and careful network integration planning.
For example, consider some of the complex problems that can occur
when a firewall is rolled into a facility. At one site, the ISP had
provided some network addresses. These addresses were actually part
of a Class-A network address that had been subnetted into Class-Cs.
Unfortunately, those Class-Cs were active both inside and outside of
this site. Using the "KISS" principle (Keep it simple, Stupid), the
firewall was going to use only static routes. (The use of static
routes also improves security, especially resilience to
denial-of-service attacks.) The bottom line was that the firewall
needed static routes to Class-C networks inside the company, but the
Class-Cs were subnets of a Class-A. Solaris (and most other
operating systems, I believe), doesn't allow a netmask to be
specified via the route command, so there was no (easy)
way to tell the Solaris-based firewall how to route packets to a
remote, internal, Class-A subnetted network while still allowing
packets to reach the external parts of that Class-A network. Because
the firewall in this case allowed address translation, the final
solution was to renumber the internal network to an RFC-1597
private subnet range.
A lack of a thorough understanding of the firewall's functionality,
combined with a lack of planning, can lead to other unfortunate
circumstances. For instance, some proxy gateway-based firewalls cannot pass a protocol that is not proxied. No assumptions can be made about
what the firewall will do. Consider the utility of the
ping and traceroute commands. Now imagine
the consternation of system administrators when they realize that the
newly-installed firewall does not allow those protocols to pass.
Advertisements
The checklist
Before embarking on a firewall implementation, you would be wise to
work your way through this checklist of issues to consider.
-
Determine the protocols that need to be passed through the firewall
and the source and destination of those protocols. For instance, a
"typical" protocol scheme consists of:
- From "inside" to Internet protocols: telnet, HTTP, FTP, SMTP
- From Internet to mail server: SMTP
- From "inside" to mail server: POP
- From Internet to Web server: HTTP
Where "inside" is the network that is being protected by the
firewall. To determine the correct list for your site, consider the
opinions of your user community and the traffic that you detect on
your current network. Frequently, users do not know what protocols
they use. Only after the installation of the firewall has disabled
some esoteric protocol will it be brought to your attention as being
essential.
Figure 1: Click image for expanded view
|
- Architect your firewall solution. Typically, the design will include
four components: the Internet, the inside networks, a DMZ, and the
firewall (Figure 1). Included in this design should be all pertinent
networking, including: IP addresses for each interface of interest,
netmasks, routes, and default routes. You will need all of these things for a
smooth firewall installation. It is important to note (because it is
sometimes forgotten or misunderstood) that each interface of the
firewall must connect to a unique subnet. This requirement can be met by
subnetting, if necessary, but the use of subnetting does tend to
complicate the installation and ongoing maintenance of the firewall.
- What is the current connectivity between the Internet and your facility?
- Currently connected, no firewall
Condolences. You have the difficult task of interjecting a
firewall into an existing, functional Internet connection. Your users
should be warned of the downtime needed to implement the firewall and of
what will and will not be allowed to pass through the
firewall. During implementation, be especially careful of DNS
changes. Due to the TTL (time to live) field of DNS records, DNS data
is usually cached for 24-hour periods. Changing IP addresses can leave
your facility unreachable while DNS information catches up. One
solution is to change the TTL of your DNS records to one hour a few
days before the firewall implementation. Then, make the DNS change and
reset the TTL to 24 hours.
- No official connections
Congratulations. Your users do not know what they are
missing, so you can impose restrictions without taking much flack. There
probably are connections to the Internet already in place, in the form
of modems connected to PCs. These connections are back doors into your
facility. If they are not disabled, network traffic could bypass your
firewall and leave your facility unsecured (and you insecure).
- Connected, upgrading firewall
Upgrading an existing firewall should be, and usually is,
straightforward. Monitoring of the current firewall operation should
allow you to plan for a successful move.
- Consider hiding your IP addresses. Most firewalls implement
"address translation" or "address hiding." This feature rewrites the
source address on packets being sent from your inside network. The
address seen by the Internet is that of the firewall's outside
interface, even though the actual packet may have originated anywhere
within your facility. Aside from increasing security, this feature can
ease your addressing woes; private addresses (again, from RFC-1597)
can be used on all networks that are behind the firewall. Only
IP addresses which are seen on the Internet must be official, registered
addresses.
- Determine how many IP addresses the firewall will be
protecting. This number is the usual measure of the "size" of your network,
for calculation of the size of the firewall license you will need to
purchase. For instance, if there are 51 PCs on your inside network,
each with an IP address (either static or DHCP-allocated), and each
possibly using the Internet, then your license must be for at least 51
hosts. On the other hand, if only 10 of your PCs
will ever use the Internet, your license can be for 10 hosts. The
license pertains to the number of hosts for which the firewall will
actually pass packets, not simply the number of hosts you own.
- Determine the rule form. Depending on your firewall, rules can
be based on network information (IP address, host name, domain name)
or on user name. Although user name-based rules can be tempting,
they can also cause problems. Consider a facility with DHCP-provided
IP addresses. If users have various Internet access rights, the user
name is the only static information that can be a basis for access
rules. Unfortunately, each HTTP URL accessed creates a new TCP
connection. An unfortunate user could be stopped and asked for a
name and password for each URL being accessed. Going on vacation
will never have sounded so tempting.
- Are you planning on using VPN (virtual private network) technology? A
VPN is an authenticated, encrypted channel. Unfortunately,
using a VPN internationally can be problematic. For instance, only weak
authentication can be exported from the U.S., and some countries
(notably, France) place serious restrictions on any encryption occurring
within their borders. Consult with your company's legal counsel if
these issues may effect you.
- To block or not to block. Many firewalls now include a facility
to allow or to deny access to specific URLs. For instance,
Microsystems Software, the maker of Cyber Patrol, has a product that
allows denial of access to URLs in many categories. The URL list
used by this program is updated via a subscription. Even if you do
not use a subscription service, some firewalls allow the use of a
static list of "known bad" sites to which you can deny access.
- Various authentication methods are provided by firewalls. These methods
includes standard passwords, as well as S/Key and hardware token
methods such as CryptoCard and SecurID. If you are implementing user
authentication, think of the firewall as a request forwarder. The
firewall typically does not take the place of the vendor's
authentication server. Rather, it forwards requests from the user
to the authentication server, and, depending on the authentication
result, either allows or disallows the connection.
- If the firewall is a software product, be sure that the hardware that you
plan on using is supported and sufficient. These criteria vary
depending on the firewall product. They also vary depending on the
firewall's use. For instance, using VPN tunnels or other
forms on encryption places a substantial load on the firewall,
making a faster system necessary.
- Understand DNS, or prepare to fight an ongoing battle of service and
performance issues. DNS is one of the keys to the successful
implementation of a firewall. There are many DNS service options,
most of which are built around split-DNS. In split-DNS, there are two
separate DNS name spaces. Inside your facility, there is a need for a
name service for internal machines, as well as a DNS server that these
machines can query to resolve Internet addresses. Outside of the
facility, Internet sites need to be able to resolve addresses for
your company's public services. The easiest solution to this problem
is to have your ISP serve as your primary and secondary public DNS
servers. Either the firewall or an internal machine can serve as the
internal DNS server. The only remaining problem is getting the
internal server to forward requests to either the firewall or the ISP
to resolve Internet names. Frequently, poor connection performance is
related to incorrect DNS configuration.
- It is important to plan on educating users. A firewall is the first
step in securing your facility, and users need to be aware that they
are part of the security problem and solution. You may also want to
inform them that the firewall logs can show you exactly what they are
doing on the Internet.
This list should help you avoid the common problems seen in firewall implementation.
The Bookstore
Bill Wall has put together some very complete links to Web security
and computer resources. Check them out at http://www.txdirect.net/~wall/solution.htm and http://www.txdirect.net/~wall/compsec.htm
Bug of the Month Club
AUSCERT is reporting two new buffer-overflow-allowing-root-access bugs
in Solaris 2.x. The vulnerabilities are in ps and
chkey. Information is available from CIAC. The only current fix is to
remove the setuid-bit from these two programs. AUSCERT has gone one better
and written a generic wrapper than can be used when running
setuid-programs to prevent them from having buffer overflow exploits.
While you're visiting CIAC, check out report H-56.
It describes another Solaris bug, this one in lp, that
allows users to gain lp rights.
If you have Creator-3D graphics on your computers, then try this
command: /usr/bin/pkginfo -l SUNWffbcf. If you do not
receive an error, then you have the
SUNWffbcf package installed, and it has a security hole.
Sun has a patch
to fix the problem.
The Toolbox
If you are interested in secure telnet sessions, take a
look at stelnet. It's
similar to ssh and SSLTelnet, but claims to
be based on a more recent telnet code base. It uses SSL to create an
authenticated, encrypted telnet channel.
Click on our Sponsors to help Support SunWorld
|
Resources
About the author
![[Peter Galvin's photo]](/sunworldonline/icons/galvin.gif)
Peter Galvin is
chief technologist for Corporate
Technologies, Inc., a systems integrator and VAR. He is also
adjunct system planner for the Computer Science Department at Brown
University, a member of the board of directors of the Sun User Group,
and has been program chair for the past four SUG/SunWorld
conferences. As a consultant and trainer, he has given talks and
tutorials world-wide on the topics of system administration and
security. He has written articles for Byte and Advanced
Systems (SunWorld) magazines, and the Superuser
newsletter. Peter is coauthor of the best-selling Operating
Systems Concepts textbook.
Reach Peter at Peter.Galvin@sunworld.com.
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright97.gif)
If you have technical problems with this magazine, contact
webmaster@sunworld.com
URL: http://www.sunworld.com/swol-06-1997/swol-06-security.html
Last modified:
![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
Figure 1: Click image for expanded view
