Extinguishing firewall hyperbole Are new firewall technologies improvements or complications? Evaluate the pros and cons. Part 2

January  1997

The firewall industry continues to gain momentum, with new players, generations, 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 concludes an evaluation of new firewall technologies: stateful inspection, filtering proxy gateways, and new add-on packages.

Also in Pete's Wicked World this month: The bookstore, has some interesting reading from the Princeton group on WWW security vulnerabilities. Also, a pointer to some interesting reading from the U.S. Army. And, if you have Solaris security questions, visit Pete's Security FAQ. (2,200 words)

Mail this article to a friend

Last month's column reviewed firewall technologies and described the advances being made in virtual private networks (VPNs). With a thorough understanding of where firewalls are coming from, it's time to consider where they are going. What are the features of the new generation, and do you need them? What technologies are useful? Efficient? Easy to manage? Easy to secure? Let's consider the major new technologies:

• Stateful inspection. Because packet filtering firewalls examine network traffic at a low level, they have trouble seeing the forest for the trees. They examine each packet as it arrives at an interface, determine the source and destination IP address and ports, and apply rules to determine whether to pass that packet. Because this technology simply passes packets, it is considered to be less thorough, and thus less secure, than proxy gateways.

To try to address this weakness, some packet-filter firewalls have added new technology, variously known as stateful inspection, stateful filtering, stateful multi-layer inspection, cut-through proxy, and adaptive security algorithms. The market-leading Firewall-1 implements stateful inspection. What does this technology do? Even the vendor documentation is vague on the subject. Generally speaking, it consists of two components:
1. Pattern matching -- the firewall examines not just the headers of the packet, but also the contents, to determine more about the packet than just its source and destination information. This is still weaker than the full protocol analysis that proxy gateways do, but it is stronger than merely examining header information.

2. State maintenance -- the firewall maintains some state information about current data exchanges. State maintenance is necessary for the UDP protocol, which is by definition stateless and connectionless. The problem posed to firewalls is that some protocols are built on UDP (ping for instance), and therefore sites may want to pass UDP through the firewall. Consider the (simplified) case of a ping initiating inside a firewall. The initiator wants to see the reply information, of course, but the firewall is configured to disallow any ping packets from the outsite. How does the firewall know that the ping packets from the outside are replies to the inside ping? The firewall maintains state, essentially making UDP stateful so it can track the original and reply packets, while still preventing unwanted UDP packets.
While the stateful inspection technology expands the breadth of proxy filters, and gives them further control over network packets, it does not increase the power of packet-filter-based firewalls greatly. However, note that proxy gateways also have problems with UDP-based protocols. Because UDP is stateless, it is impossible to build a proxy to handle UDP traffic (there's nothing to proxy). The solution -- filtering proxy gateways -- is discussed below.
• Proxying packet filters. There is no arguing that proxy gateways and packet filters each have benefits and detriments. It is only natural that the two be combined to strengthen weaknesses and decrease vulnerabilities. Most packet filters are now adding proxies for specific uses. Functionally, the packet filters still filter those packets, but for specific types of packets, the packet is sent to a proxy on the firewall rather than being forwarded through to the destination machine. A common use of this technology is for authentication. For example, a typical site might want to allow telnet from or to specific hosts, but only if the outsider is first identified via a one-time password mechanism (such as S/Key, CryptoCard, or SecureID). In this case, a proxy is needed because it must:
  1. Prompt for authentication information
  2. Understand the telnet protocol, so it can ask for authentication via that protocol
  3. Compute the correctness of the authentication answer
  4. Allow the telnet if the authentication is correct
  Filter technology can still be used to examine source and destination and determine if the connection should be allowed, but the proxy must further limit connections by allowing only authenticated connections.

• Filtering proxy gateways. While packet-filter firewall vendors have been busy adding proxy technology, proxy firewall vendors haven't been resting on their laurels (and we know how painful that can be). They've been adding packet-filtering features, of course. At first blush, it doesn't make sense to add filtering to a proxy-system. Don't underestimate the power of virtual private network (VPN) connections. When a VPN tunnel is established between two firewalls (or client software and a firewall), all IP-level communications between the two is encrypted (see Figure 1). Figure 1.
  Any protocol that layers on IP, including all TCP and UDP protocols, can be passed through that encrypted tunnel. Generally, firewalls provide no means of limiting the protocols that can be sent. Once that tunnel is established, anything goes. The external machine at the end of the VPN tunnel has the same abilities as if it were inside the firewall, for almost all purposes. Either the machine is trusted explicitly, or it can't be an end of a VPN tunnel. Until now. Some proxy gateways, including Raptor's Eagle, now allow filtering of VPN tunnels. Specific protocols now can be allowed or denied, and the direction of initiation can be specified. Source and destination addresses can be specified, as well as the authentication method to be used. This combination adds control to the VPN facility, and now makes it possible to allow VPN tunnels and maintain a secure outer perimeter. As an added bonus, a "null VPN tunnel" adds flexibility to firewall UDP processing. Proxy gateways and UDP generally do not play well together. For instance, it used to be impossible to pass ping through a true proxy gateway. Because VPN tunnels work at a lower network layer, they can pass UDP. By creating a tunnel within the firewall -- both ends living on the firewall -- UDP can be passed (and filtered) through the firewall. Protocols like ping can be passed from and to specific hosts, as designated by the firewall administrator.

• Statistical and graphical analysis of firewall data traffic patterns
• Sophisticated blocking of "undesirable" Web sites
• Filtering based on MIME type, as well as the ability to block transfer of Java applets
• E-mail virus-scanning software to evaluate and block (or warn of) binaries and e-mail that contains viruses

Bug of the Month Club
For those keeping score (or trying to keep their sendmail server secure), BSD sendmail is now up to release 8.8.4. Get it before the next version is released.

The Bookstore
The group at Princeton is again raising alarms about the (in)security of the WWW. This time they've demonstrated a man-in-the-middle attack and produced a paper that describes the problem, its effects, and the implementation. Simply put, a man-in-the-middle attack consists of an entity interposing itself between the two parties that are trying to negotiate. The middle-man can then intercept communications, attempt to pretend it is one or the other end (or both), and so on. By pretending to be one side to the other, the middle-man is spoofing the other side. Putting this attack into work, the Princeton group set up a Web server that pretended to be another site. When pages were requested of it, it simply retrieved them from the legitimate site and displayed them to the requestor. The potential damage is huge. The server could have given out misinformation, captured credit card or other financial information as if it were requested from the legitimate site, and so on. For more information on this attack and how it could make your life miserable, check out the paper. Thanks to Joel McNamara for the following posting on best-of-security. The Army site is worth a look:

From: Joel McNamara <joelm@eskimo.com>
To: best-of-security@suburbia.net
Subject: BoS:  Army Cryptanalysis manual online
The US Army's Field Manual on Basic Cryptanalysis (FM 34-40-2), dated
September 1990 is available for downloading as an Acrobat PDF file from:

http://www.atsc-army.org/cgi-win/$atdl.exe/fm/34-40-2/default.htm
Fairly classic in nature (substitution, transposition, and code systems).
Huge files (so far, at 28.8, after about an hour and a half, I've only been
able to grab the table of contents and a couple of appendices - some
kind-hearted person with a T1 or greater may want to get everything, then
zip and mirror to save us bandwidth challenged folks the pain).
Also, for the complete listings of almost 300 downloadable FMs through the
Army's Digital Training Library (ATDL), check out:
http://www.atsc-army.org/cgi-win/$atdl.exe?type=fm&header=%2F
atdl%2Fbrowse%2Ffm.htm
Have fun!
Joel
Note: This site isn't wholly reliable.  It seems to regularly go up and
down, and sometimes the bandwidth is terrible.  Probably worth your
patience though.

There's also a mirror site O'Reilly and Associates has done a statistical study of Web sites to determine the state of WWW commerce. It makes for interesting reading. To summarize, they found that although there are quite a few Web sites running SSL servers, most of these sites don't have digital certificates available to allow their authentication by clients. For more information visit http://www.ora.com/research/. Next month we'll look at the world of penetration testing.

Resources

• SAIC
  http://www.saic.com
• ISS
  http://www.iss.net
• NetCat
  http://www.l0pht.com/~weld/netcat/
• Comparison of firewalls
  http://www.fortified.com/fwcklist.html
• Whitepaper on man-in-the-middle attacks
  http://www.cs.princeton.edu/sip/pub/spoofing.html
• US Army's Field Manual on Basic Cryptanalysis
  http://www.atsc-army.org/cgi-win/$atdl.exe/fm/34-40-2/default.htm
• Mirror site
  ftp://ftp.europa.com/outgoing/theoe
• O'Reilly study of Web commerce
  http://www.ora.com/research/
• Past Security
  /sunworldonline/common/swol-backissues-columns.html#security
• Also check out the SunWorld's Site Index for stories on Web server security
  /sunworldonline/common/swol-siteindex.html#websec

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.

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

URL: http://www.sunworld.com/swol-01-1997/swol-01-security.html
Last modified: