Click on our Sponsors to help Support SunWorld
Security: Pete's Wicked World by Peter Galvin

Distinguish firewall hype

Are new firewall technologies improvements or complications? Evaluate the pros and cons. Part 1

SunWorld
December  1996
[Next story]
[Table of Contents]
[Search]
Subscribe to SunWorld, it's free!
Abstract
The firewall industry continues to gain momentum, with new players, versions, and attention from large and small institutions alike. Are the added features useful or are firewalls turning into the next Microsoft Word -- bloated with features that add complication but are little used? This month starts an evaluation of new firewall technology: a better virtual private network.

Also in Pete's Wicked World this month: the "ping of death" arrives in the bug-of-the-month-club, a wu-ftp bug, and some solutions to the SYN attack that was reported last month. And in the bookstore, a paper on the implementation of cryptography and the hazards of letting non-professionals implement the algorithms, and pointers to some of the resources that crackers are using to share information. In the mailbox, useful comments on NIS+ problems of which I should have warned you. And, if you have Solaris security questions, visit Pete's Security FAQ. (2,200 words)


Mail this
article to
a friend

As the firewall competition grows, so does the hype. Product marketing managers look for new and different ways to distance their offerings from the competition. But is the distance caused by useful or useless features? How can you make sense of packet filters that have added "stateful inspection" or gateways that have added packet filters? This month, Pete's Wicked World revolves around exploring these new technologies with an eye toward separating the ground from the clouds. What technologies are useful? Efficient? Easy to manage? Easy to secure? We'll see, but first we need to reexamine the old world before discovering the new.

There are well-known dividing lines in the firewall arena. The major split is based on the type of technology employed:

These technologies also have widely known pros and cons:

Proxy Gateway Packet Filter Details
TCP traffic examination Applies rules to TCP session, monitors data flow to determine if each command within the session is allowed or not Applies rules to each packet, based on source and destination address and port Proxy gateways are more thorough and more efficient for TCP traffic
UDP traffic examination Generic proxies allow UDP traffic to be controlled between fixed ports. Cannot handle varying port addresses (RPC-based traffic, like NFS) Maintains state for UDP communications, keeping a channel open between sender and receiver, handling even RPC traffic The UDP protocol is even less secure than TCP, so no firewall provides thorough UDP security
Flexibility A strength and weakness is the lack of flexibility. Proxy exists for a protocol, or us the generic proxy for other protocols, or protocol can't pass Very flexible. Unfortunately can leave room for misconfiguration A proxy gateway is best if it supports all the protocols you are passing
Ease of configuration Fewer choices, so generally easier to configure Many choices A more expert hand is needed to guide packet filter configuration. For instance, both types can do address hiding, but proxy gateways do it by default and packet filters must be configured to hide addresses
Ease of management Again, simpler means easier Keeping the protocols passed and rules implemented to a minimum can simplify management Both require skill, knowledge, and specific firewall training to be securely managed
Miscellaneous Address hiding for free, good logging and alerting potential Address hiding via configuration options, reasonable logging potential and good alerting potential

Both types of firewalls frequently include virtual private networking (VPN), to varying degrees of encryption and ease of configuration. The encryption can range from 40-bit RC4 encoding to triple-DES (56-bit encryption applied three times). The difficulty of administering VPN tunnels is caused by the age-old issue: key management. Both ends of the tunnel need to know a secret -- the key to decode the data sent their way. This key must be exchanged securely (knowledge of the key could allow other parties to decrypt the data). The challenge is exchanging this key without having an existing secret.

Most firewalls that implement VPN tunnels require that the secret key be entered manually into all endpoints of the communication. The keys then are secure and communication can commence. But it is good practice to change keys occasionally to prevent (or recover from) someone breaking the cypher. Again, the new keys must be entered manually on physically distant systems.

Unfortunately, this isn't the end of the VPN-implementation tale. Rather, it's the beginning. The current state of the industry has each company implementing its own, proprietary, VPN protocol. Firewalls from different vendors cannot talk VPN to each other. Instead they have to be matched sets. That's where IPSEC comes in.

Some firewalls now include the a standardized version of VPN, known as IPSEC (and the S/WAN initiative). Vendors implementing IPSEC should be able to talk VPN to other vendors' products. This effort should widen the use of VPN. It solves a difficult problem because it encrypts all data between the VPN endpoints. That is, all data above the IP layer (including TCP protocols such as Telnet, FTP, and SMTP) is encrypted in this tunnel. Once IPSEC use is wide-spread, disparate companies will be able to establish encrypted data channels, allowing the Internet to be used where, previously, leased lines ruled.

For more information on IPSEC and related technologies, you may want to view some slides from a talk on VPN futures or the RSA cryptography FAQ, specifically question 137.

Bug of the Month Club
Because of the publication of the Solaris Security FAQ last month, there are a lot of bugs to report in this month's column.

A report of a flaw in Firewall-1 was posted to the best-of-security mailing list issue V96 #28. The alleged flaw is exercised when a too-large "ping" packet (the so-called "ping of death") is sent continuously to the firewall. The firewall then becomes too busy dealing with the ping and logging its occurance, allowing other, forbidden connections to pass by the firewall. Follow-on discussions appear to indicate that the flaw is not with Firewall-1, but rather with the way that the machine on which it was running was configured. The lesson to be learned is that a general-purpose Unix machine running a firewall is just that: a general-purpose Unix machine. Care is needed when configuring the machine. Be careful -- the "ping of death" has been found to cause problems on multiple operating system platforms (but not Solaris). If you have machines or routers that are spontaneously rebooting, watch the traffic coming in to them to determine if pings with packet sizes of greater than 64K are being sent.

Most important, keep firewalls simple: the fewer tasks a firewall needs to perform, the more reliable and secure its operation can be made. When designing firewall architectures for customers, I'm frequently asked about combining functionality. For instance, why not run a Web server on the firewall rather than dedicating another machine to that task. Examples like the one above are proof that such an approach is penny-wise but pound-foolish. Just say "no."

While you're reading best-of-security, notice that Stefan Arentz found a bug in Sun's alpha release of the Jeeves server that lets arbitrary Web connections retrieve the contents of /etc/passwd, among other files.

In the Bugtraq mailing list (more information is in the bookstore) is a report of a serious bug in wu-ftp running on Solaris 2.5 (at least).

Sun released a detailed analysis of the SYN attack, current changes that can be made to lesson the impact of the SYN attack on SunOS and Solaris systems, and information on future changes to Solaris that would be more effective against SYN. This information is in Sun's security bulletin #136. If you are not already on Sun's security mailing list you can join with a mail message contents of "subscribe email-address" or just receive a specific bulletin with a contents of "send #DDD" (in this instance, replace DDD with 136).

The bookstore
Also in "best-of-security" V96 #28 is a very interesting article by Bruce Schneier concerning the state of cryptography and its implementations. Bruce argues succinctly that cryptographic algorithms are best implemented not by computer engineers, but by cryptographers. Perhaps self-serving, but also correct, in my opinion.

A long time ago (in computer terms), a paper was published entitled "Improving The Security Of Your Site By Breaking Into It" by Dan Farmer and Wietse Venema. This paper became very influential for a number of reasons, including its approach of thinking like a cracker while evaluating your own systems. Over time, it's gotten easier to think like a hacker, as more and more cracker publications have become available. For instance, the Phrack Newsletter is written by and for crackers. In the latest edition is a detailed article about buffers and stacks, and how programs that use these storage structures can be flawed and therefore cracked. It makes for interesting reading.

Yet another reason to check out that issue is a thought-provoking message about ethics by Gene Spafford. A full thread on this topic has been unwinding in the sneakers mailing list.

If you administer Unix systems, you should really receive the Bugtraq mailing list. Bugtraq is a full-disclosure Unix security mailing list, started by Scott Chasin chasin@crimelab.com. To subscribe to bugtraq, send mail to listserv@netspace.org containing the message body "subscribe bugtraq". An archive of the bugtraq mailing list is available at http://www.geek-girl.com/bugtraq/index.html.

If you're attempting to keep up with cracker activities, you should check out http://www.geocities.com/Area51/5537/. It's an archive of information useful to crackers.

The mailbox
In the October issue of Pete's Wicked World, I encouraged the use of NIS+ as a secure distributed naming facility. Before you do so, however, there are several issues, pointed out by readers, of which you should be aware.

Thanks to Dave Miner (dave.miner@east.Sun.COM) for his report from the front-lines of NIS+ implementation: 


In the column, you say:
"NIS+ credentials are stored in the cred table of the NIS+ domain. This is a
new table that, unlike most other NIS+ tables, does not correspond to an /etc
file."

This is not exactly true.  In fact, it corresponds to *two* /etc files,
/etc/publickey and /etc/netid, which have been around for a long time.
This isn't a big deal, except that I see postings on the net all the time
where people are asking how to back up the cred table like they can all
the other ones with "nisaddent -d", and knowing that cred corresponds to
these two tables answers the question of how you do that backup, since
nisaddent knows about publickey and netid and thus can do the backup/reload
thing for you.

A related point which you ought to emphasize strongly: BACK UP THE CRED TABLE.
If you don't, and you end up with a disaster where it gets wiped out, it can
take a serious amount of work to get your NIS+ domain functioning again (I
know, because I've been there).

Here's the routine that Dave uses (twice a week) to back up his cred table. Its use is highly recommended: 

#!/bin/ksh

# Script to back up the cred table

pk=/etc/publickey.`date +%w`
ni=/etc/netid.`date +%w`

/usr/lib/nis/nisaddent -d publickey >$pk
/usr/lib/nis/nisaddent -d netid >$ni

exit 0

It is especially important to back up your tables in light of bug 1248191, as pointed out by Dan Berger (dberger@online.disney.com). This bug can cause the corruption of the cred table. There are patches for Solaris 5.5 (patch 104000) and 5.5.1 (patch 103995).

Also, Ivan Angus (Ivan.Angus@anu.edu.au) took me to task for not mentioning the serious security hole in the default permissions of the NIS+ tables in Solaris 2.5.X (as reported in CERT advisory 96.10. In fact I did mention 96.10 in two columns, but those were several months ago. Still the point is made: if you are using, or planning to use, NIS+ in a production environment, be sure you understand its authorization and authentication components and verify that the permission settings are correct.

Next month we'll delve in depth into the remaining new firewall features, including stateful inspection and gateways that filter.


Click on our Sponsors to help Support SunWorld

Resources

About the author
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.

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
 -Too long
-Just right
-Too short
 -Too technical
-Just right
-Not technical enough
 
 
 
    

SunWorld
[Table of Contents]
Subscribe to SunWorld, it's free! 		[Search]
Feedback 		[Next story]
Sun's Site

[(c) Copyright Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-12-1996/swol-12-security.html
Last modified: