PrivateNetSystem White Paper

Connecting Safely to the Internet

A Study in Proxy-Based Firewall Technology

NEC Technologies
110 Rio Robles Drive
San Jose, CA 95134
Phone:(800) 668-4869 Dept. Code YWEB

1996 NEC Technologies. All rights reserved.

NEC is a registered trademark of NEC Corporation. PrivateNet and SocksPlus are trademarks of NEC Technologies, Inc. Other brands, logos, and product names are trademarks or registered trademarks of their respective holders.


1. Introduction
2. What is a Firewall?

2.1 What is a Departmental Firewall?
2.2 What is a Virtual Private Network?
3. What is the PrivateNet System?
3.1 The PrivateNet Firewall Technology
3.1.1 Circuit-Level Proxy
3.1.2 Application-Level Proxy
3.2 Connection Filtering
3.3 Address Hiding
3.4 User Authentication
3.5 Firewall-to-Firewall Connectivity
3.6 Parallel Configuration for High Performance and High Availability
3.7 Use of Encryption in the PrivateNet System
3.8 Implementation of the UDP Circuit-Level Gateway
3.9 The Configuration Files
3.10 Initial Configuration
4. Name Service
5. Mail Service
6. Performance
7. What a Firewall Cannot Do
Appendix A: PrivateNet System Feature Summary
Appendix B: Firewall Selection Criteria and the PrivateNet Server
Appendix C: Firewall Bombs


The PrivateNet system is an off-the-shelf, commercial firewall product combining hardware and software that provides security for TCP/IP networks. The PrivateNet system can also provide secure communications over public networks, such as the Internet, to reduce network costs through its Virtual Private Network (VPN) technology.

The PrivateNet Firewall Security Server blends two technologies to create a secure Internet communications environment:

  1. Applications that originate their connections from within an internal network are managed by the SocksPlus(tm) proxy, NEC's advanced circuit-level proxy technology.

  2. Applications that originate their connections from outside the network are managed by security-hardened application-level proxy servers. Application services include Telnet, Email (SMTP), Web Server (HTTP), and NetNews (NNTP).

The PrivateNet system is suitable for securing a network from the Internet, as well as isolating subnetworks within a corporate network.

The PrivateNet system provides easy installation and configuration through CD-ROM-based software, friendly administration, user transparency, SOCKS 4.2 protocol compatibility, and parallel and serial firewall configurations.

Up to Contents

1. Introduction

Over the past two years, use and awareness of the Internet has surged. However, being connected to the Internet is much like living in a rough neighborhood. While many corporations and organizations need to be connected to the Internet, they also need to protect their trade secrets, innovative technologies, and private information. Stolen, altered, or deleted information can jeopardize the company's competitive edge in the marketplace, and vandalized or compromised data can be extremely expensive to replace. More and more people called "hackers" or "crackers" are breaking into private networks of corporate America, resulting in losses of billions of dollars.

An increasing number of organizations are choosing to protect themselves from such intruders by erecting a security barrier, known as a firewall, between their private networks and the Internet. A firewall, when correctly implemented, enforces an organization's rules or policies for access to and from the Internet.

In addition, many organizations are now beginning to install firewalls inside their private networks, realizing that while intruders from the Internet are getting most of the press, greater threats can come from inside the organization, from disgruntled employees, for example. Departmental firewalls make it possible to contain some of these threats without rendering the network useless.

NEC now offers the PrivateNet system as both an Internet and a departmental firewall server. It consists of the SocksPlus proxy, NEC's enhanced version of the popular SOCKS 4.2 package[1]; various application proxies for popular Internet protocols; and encrypted communication between firewall servers. More than one PrivateNet system can be installed in a parallel configuration for high availability and/or high performance, and in a serial configuration supporting departmental firewalls and/or encrypted virtual private networks crossing the Internet.

The PrivateNet system provides the necessary framework to implement a corporate Internet security policy, allowing system administrators at an individual site to tailor the operation of the firewall(s) through configuration files that govern the nature and volume of the traffic passing through the firewall.

Up to Contents

2. What is a Firewall?

The primary purpose of an Internet firewall is to provide a single point of entry where a defense can be implemented, allowing access to resources on the Internet from within the organization, and providing controlled access from the Internet to hosts inside the organization's internal networks. The firewall must provide a method for a security or system administrator to configure access control lists to establish the rules for access according to local security policies. All access should be logged to ensure adequate information for detailed security audit.

A traditional firewall is implemented through a combination of hosts and routers. A router can control traffic at the packet level, allowing or denying packets based on the source/destination address of the port number. This technique is called packet filtering. A host, on the other hand, can control traffic at the application level, allowing access control based on a more detailed and protocol-dependent examination of the traffic. The process that examines and forwards packet traffic is known as a proxy.

A firewall based on packet filtering must permit at least some level of direct packet traffic between the Internet and the hosts on the protected networks. A firewall based on proxy technology does not have this characteristic and can therefore provide a higher level of security, albeit at the cost of somewhat lower performance and the need for a dedicated proxy for each type of connectivity.

Each organization needs to choose one of these basic types of technologies. The right choice depends on the organization's access and protection requirements. NEC believes that companies with substantial information assets at risk will choose a higher-security solution, such as that offered by the PrivateNet system.

The primary reasons that NEC decided on a proxy-server architecture are:

Up to Contents

2.1 What is a Departmental Firewall?

A departmental firewall is identical to an Internet firewall except that it controls access to and from a single department in a larger organization. It is used to protect sensitive corporate data, such as financial information and personnel records, from access by unauthorized people. A departmental firewall tends to be more generous in the access it allows, but if insecure services, such as NFS, are allowed through a departmental firewall, the purpose of installing the firewall in the first place might be defeated.

Up to Contents

2.2 What is a Virtual Private Network?

Recently, there has been a great deal of discussion about virtual private networks. A virtual private Network is just another name for an encrypted IP tunnel, typically crossing the Internet. The encryption ensures a high level of privacy in the data that is exchanged, allowing a secure and cost-effective alternative to privately leased lines.

Virtual Private Data Networks

Most connections across the Internet are not encrypted, and most data is exchanged in clear text, making the exchange vulnerable to packet sniffing. Third parties can listen in on these connections, obtaining valuable information such as passwords or the content of private email. Password sniffers are easily available from various places on the Internet. The use of encrypted tunnels prevents any third party from listening in on those connections.

Up to Contents

3. What is the PrivateNet System?

The PrivateNet system has been designed to provide the best technologies for both a firewall and a virtual private network. It offers a very high level of security while providing adequate access. Like most commercial firewall products, the PrivateNet system uses a number of different technologies to establish the required connectivity.

A firewall's primary purpose is to provide security. To do so, all components must be secure, and they must be tested both individually and in combination with the other components. The PrivateNet system is a complete system, including hardware, a security-hardened operating system, and firewall system software. The advantage of a turnkey firewall product with completely integrated components is that it achieves the highest possible level of security and performance.

In addition, NEC is creating a referral program for Internet security consultants who want to team up with its national base of network product resellers to serve PrivateNet system customers. This referral program ensures customers access to experts in Internet security who can recommend an optimal security solution.

Like most other commercial firewall products, the basic assumption in the design of the PrivateNet system is that anything not explicitly allowed is denied. However, the design of the PrivateNet system goes much further than that, making every attempt to provide an effective and secure firewall.

One example of this approach is that all software, including the operating system and other programs, is stored on a CD-ROM and is always loaded directly from the CD rather than from a hard disk. This allows a high degree of trust in the integrity of the software as it is not possible for anybody to modify the content of the CD-ROM. This solution also provides a very easy upgrade path. Installing a new release is only a matter of shutting down the PrivateNet system, replacing the CD-ROM, and rebooting the system. There are no installation scripts to run or patches to apply.

The design of the firewall software is based on the philosophy that being small is good. The software that implements the firewall is split into small individual programs so that each can be easily verified and tested. In addition, different proxy technologies are applied to different levels of security requirements.

The operating system used for the PrivateNet system is a scaled-down and security-hardened version of BSD UNIX 4.4 from Berkeley Software Design, Inc. NEC chose this platform believing that it is the best possible operating system today for Internet connectivity, as opposed to other common UNIX implementations with bloated kernels, which are much more difficult to effectively secure.

The hardware is a based on a Pentium PC, ensuring both adequate performance and reasonable cost. The machine is intended to run without an attached console, but a terminal or terminal server can be connected for configuration and monitoring. The machine is shipped with two Ethernet cards, allowing it to be installed in either a single or dual-homed configuration.

Up to Contents

3.1 The PrivateNet System Firewall Technology

The PrivateNet system uses two different types of technologies for two different levels of security. For connections originating from inside the organization, the PrivateNet system uses a circuit-level proxy. A circuit-level proxy provides a medium level of security, while being both flexible and adaptable to the various access requirements of the organization. However, NEC believes that circuit-level proxies give an inadequate level of protection for access from the Internet to the inside of an organization's private network. Therefore, it provides application-level proxies for such access.

Up to Contents
3.1.1 Circuit-Level Proxy

A circuit-level proxy implements a generalized proxy mechanism that relays IP connections from the originating application through the firewall to its destination. Before completing the connection, the circuit-level proxy verifies that the connection is permitted in its configuration file. When the connection is verified and established, the circuit-level proxy program relays packets back and forth between the user application program and the Internet service to which it is connected. The circuit-level proxy used in the PrivateNet system is based on the popular SOCKS 4.2 protocol, originally implemented by Dave Koblas and maintained by NEC since the public release of the software. The SocksPlus proxy, NEC's commercial version of SOCKS 4.2 , has been completely rewritten to avoid any intellectual property issues, and to eliminate the shortcomings in the freeware version. The SocksPlus proxy has many improvements over the original SOCKS 4.2 implementation. The SocksPlus proxy:

The SocksPlus proxy uses its own improved protocol when communicating with the SocksPlus proxy clients and other the SocksPlus proxy servers, but it is also fully backward-compatible with existing SOCKS 4.2 servers and clients. That means if a site is already using SOCKS 4.2, converting to the PrivateNet system is straightforward. However, such sites are encouraged to convert to the SocksPlus proxy to take full advantage of the improvements in the SocksPlus protocol.

The SocksPlus circuit-level proxy lets the user access standard Internet services such as Telnet, FTP, World Wide Web, and Archie. For Windows, NEC provides SocksPlus Windows client support. Using this utility, any Windows 3.X application client based on the standard Winsock.dll can be used without any modifications.

As for UNIX, other network applications can be easily converted to operate with the SocksPlus proxy through a simple recompilation and relinking procedure. Existing SOCKS 4.2 clients are fully supported by the SocksPlus proxy.

Up to Contents 3.1.2 Application-Level Proxy

An application-level proxy implements a specific proxy mechanism for each application. It is a program that understands the application protocol, and that can screen the traffic passing through the gateway with a comprehension of context not present in either circuit-level proxies or packet filtering.

The main advantage of an application-level proxy over a circuit-level proxy is its ability to understand the flow of information and make intelligent decisions about requests. For example, the PrivateNet system provides a proxy for electronic mail over Simple Mail Transfer Protocol (SMTP). An application-level proxy eliminates the possibility of someone extracting information about the local user population using SMTP commands such as EXPN (expanding a mail alias) or VRFY (verify the presence of a user). While NEC cannot remove these commands without violating the definition of the protocol, it can disarm the commands by not returning any useful information (they echo any argument given to them). Another example is the FTP proxy (available in a future PrivateNet system release), which will intercept and disallow commands considered dangerous, such as the DELETE command.

The disadvantages of this mechanism are that it is not transparent to the user, and it is necessary to design and implement an individual application-level proxy for each supported protocol. The PrivateNet system currently supports the following application-level proxies:

NEC can add third-party proxies after careful inspection. NEC also plans to add other application proxies.

Up to Contents

3.2 Connection Filtering

The access control style used for both a circuit-level proxy and application-level proxy is called "connection filtering" because filtering is performed at the time of connection. In other words, a proxy-based connection needs to be verified only when the connection is initially established, while packet filtering needs to verify each and every packet.

Because verification is performed only once per connection, it is possible to verify the connection thoroughly. When a connection request is received by an application-level proxy, the connection is verified based on a source/destination address and port number. In addition, more checks are performed. For example, it is verified that all connections arrived on the expected interface. If a connection request claims to originate from the internal network but arrives on the interface connected to the outside network, it is recognized by the system as a spoofing attempt. The system reports the attempt in the system log, and the connection is refused. Similarly, as a matter of routine, all name server lookups are validated by a reverse lookup. While this does not guarantee that name server spoofing does not take place, it does decrease the likelihood of a successful name server spoofing attack.

Up to Contents

3.3 Address Hiding

One of the desirable side effects of proxies is that, because all network traffic either originates or terminates at a proxy program on the firewall, internal networks are completely hidden from those outside. This means that a cracker cannot obtain information by scanning internal networks, and the internal networks do not need to be the official registered network addresses. While NEC does not advocate the internal use of network addresses that have been registered by somebody else, the Internet Engineering Task Force (IEFT) has set aside several networks guaranteed not to be registered by anyone else (see RFC 1587 for details) and that should not be routed by anyone else on the Internet. Using such addresses gives an organization all the address space it needs and helps protect the firewall from IP spoofing because the addresses are not supposed to be routed across the Internet.

Up to Contents

3.4 User Authentication

Users from outside the PrivateNet system can Telnet to hosts in the internal network with the Telnet proxy. However, for security reasons challenge and response is the only supported authentication method using non-reusable passwords. It is common practice for crackers on the Internet to run a packet sniffer, which intercepts and records traditional UNIX login name and password pairs.

Non-reusable passwords employ a mechanism to ensure that a given password can be used only once. The current version of the PrivateNet system uses Digital Pathways' SNK calculator for this purpose.

Up to Contents

3.5 Firewall-to-Firewall Connectivity

The PrivateNet system also supports connectivity to other PrivateNet systems within the same organization. This ensures that large organizations can install departmental firewalls that work in unison with the corporate Internet firewall.

When a client requests a connection to a destination host through several PrivateNet servers, each PrivateNet system verifies the request before forwarding it to the next PrivateNet system . After all servers verify that the connection is allowed, an acknowledgment is sent to the client. This strategy ensures that the client receives its acknowledgment only after all verifications have been conducted and the connection to the destination has been established.

Because the PrivateNet system is designed to encrypt communication between servers, it can be used to build encrypted tunnels or virtual private networks across the Internet, allowing transparent access for SocksPlus proxy applications. It maintains the same level of security provided by a privately leased line, in effect giving an organization a cost-effective and secure long distance service.

For geographically distributed organizations, it is possible to allow connections either through the application proxy mechanism or to perform server-to-server connection if the organization has standardized on the PrivateNet system.

Firewall-to-Firewall Connection

Up to Contents

3.6 Parallel Configuration for High Performance and High Availability

For network sites that require high performance and availability, multiple PrivateNet units can be connected in parallel and configured as a single firewall. This configuration ensures the firewall is not overloaded. To distribute the networking load evenly between PrivateNet servers, the internal name server is set up in a round-robin configuration, enabling clients to switch back and forth between servers.

If a server becomes unavailable, any client attempting to connect through that server waits only a few seconds, and then moves on to the next server. Therefore, when a firewall consists of multiple servers, high availability is ensured because the remaining servers continue to transparently service all client connection requests.

High Availability

Up to Contents

3.7 Use of Encryption in the PrivateNet System

As mentioned above, encryption is used in communication between two PrivateNet servers to ensure secrecy. The encryption method is negotiated between the origination and destination servers, while any intermediate server is not allowed to see, and is unable to decrypt, the data that passes through them. Currently, the PrivateNet system supports and uses DES and triple DES encryption.

Up to Contents

3.8 Implementation of the UDP Circuit-Level Gateway

While filtering TCP circuits is difficult at best, securely filtering UDP connections is almost impossible. The difficulty is in the difference between the two types of connections. The TCP protocol implements a virtual circuit and keeps a context for the connection, while a UDP connection is a datagram protocol where each packetis an independent message.

Therefore, the UDP connectivity between PrivateNet system clients and servers is implemented as UDP over TCP. Providing UDP connectivity in this manner simplifies the implementation of the UDP relays significantly, and to a large degree removes the problems normally experienced in providing UDP support through a firewall. While this strategy may be less efficient than a native UDP implementation, its simplicity and ease of security management by far justify the additional overhead. And, in fact, to provide reliable and safe implementation of a native UDP solution, NEC believes the difference in performance would be negligible.

This implementation lets the PrivateNet system provide relatively safe support for internal UDP clients, such as Archie or Xarchie, to connect through the firewall. However, in general the recommendation from CERT (Computer Emergency Response Team) that UDP not be allowed through the firewall should be respected as much as practically possible.

Up to Contents

3.9 The Configuration Files

The PrivateNet system uses two text-based configuration files, allowing a security officer or system administrator to read these files at any time to understand the current configuration. It also lets those who do not like using a graphical user interface (GUI) configure and maintain these files without the GUI. They can log in on the console and perform all configurations with a text editor such as vi.

The two configuration files are Socksplus.conf and authorize.conf.

The Socksplus.conf configuration file contains all rules for access control and server-to-server interaction. There are three major sections:

The authorize.conf configuration file contains the rules for how a user can connect through the firewall. These rules define which users can Telnet to hosts inside the firewall, and what kind of authentication should be used.

Up to Contents

3.10 Initial Configuration

When the PrivateNet system is initially deployed, there is no need to install any software because all executables are loaded at runtime directly from the CD-ROM (which is mounted as the root file system by the operating system). However, network parameters must be specified. This configuration process has been made as simple as possible. The user answers a number of questions on the console, entering information such as host names and IP addresses. When all questions are answered, the system configures and reboots itself.

Large sites and sites with complex configuration requirements may need to add additional configuration information. However, for most sites the default configuration should be sufficient, at least for the initial requirement.

The default configuration of the PrivateNet system allows users inside the firewall to access services on the Internet through Telnet, FTP, and the World Wide Web, and to receive email. With the exception of email and name service, no connections are accepted from the outside.

Besides building the configuration tables for the firewall software, the PrivateNet system configuration program also builds configuration files for the Domain Name Server, Sendmail, and other UNIX-related configuration files. This simplifies the configuration because there is no requirement for the installer to know and understand these configurations. Again this works only in simple cases with straightforward configurations.

Up to Contents

4. Name Service

The domain name server on the PrivateNet system is configured, by default, as what is often referred to as a split name server. In this configuration, two tightly coupled primary name servers are each used with an appropriate number of secondaries. The software for both name servers is the unmodified standard UNIX name server. The PrivateNet system uses bind version 4.9.3, which has many security improvements over the older versions of the software. The name server on the PrivateNet system is configured as a traditional name server with the exception that it has information only about the systems connected to the public networks (typically this is the PrivateNet system alone). This allows sites on the Internet to obtain the information necessary to connect to the services offered by that site.

Resolution of host name and addresses for the internal hosts are handled by an internal name server, which has all information about the internal hosts. Because the PrivateNet system does not perform any kind of packet forwarding, there is no way for the internal name server to connect to any name server on the outside. Instead, resolution of such inquiries is handled through the name server's "forwarder" mechanism, where the inquiry is forwarded to the external name server on the PrivateNet system for resolution. Because this name server can connect to other name servers across the Internet, it can resolve the inquiry in its usual manner and return the result to the internal name server.

Special consideration should be given the PrivateNet system itself since it needs to resolve the inside host names and addresses while still keeping the name server cache uncontaminated with this information. The mechanism for this already exists through the resolver library. Because the PrivateNet system has a local resolver configuration file pointing to the internal name servers, all inquiries originating on the PrivateNet system are resolved by those name servers instead of the name server running on the PrivateNet system.

If a site does not want to employ a split name server, the name server on the PrivateNet system can be configured as the traditional primary or secondary name server with complete information about all internal hosts. However, if configured in that manner, information on all internal hosts would be readily available on the Internet even though these hosts could not be reached directly. This would provide crackers with a great source of information on the internal networks, which they could use to attack the hosts on those networks.

Up to Contents

5. Mail Service

The PrivateNet system provides a simple SMTP mail exchanger for email connectivity between internal and external hosts. All mail passes through the PrivateNet system in three steps:

  1. The SMTP proxy receives the email and stores it in a spool directory on the hard disk, This program has been kept as simple as possible to prevent attacks through email.
  2. The postmaster program picks up the mail, stores it in the file, changes all occurrences of shell meta character, if any, in the address portion of the mail, and then hands the result to Sendmail for delivery
  3. Sendmail delivers the mail in the usual manner.
This strategy has an advantage in that it isolates Sendmail, a common source of security problems, from the network while still using it as a mail delivery agent. It keeps the SMTP proxy mechanism simple and does not require reimplementation of the address rewrite and the delivery mechanism. This implementation has the following noteworthy advantages:

Up to Contents

6. Performance

Performance is a critical issue for any firewall. NEC has conducted some informal performance tests with the PrivateNet system and the results show that performance should not be a problem for most sites. The tests were performed using a configuration with three client machines going through the SocksPlus proxy to access an FTP server on the opposite side of the PrivateNet system. FTP was chosen for this test because it is easy to obtain data for sustained throughput. The networks on both sides of the PrivateNet system were 10-baseT Ethernet.

The performance test was conducted with one increasing to fifty simultaneous connections from the client machines to the FTP server. The transfer rate was an average of approximately 6 M bits-per-second, much higher than required for a T1 Internet connection. In fact, the 6 M bit-per second transfer rate is 60% of Ethernet speed and close to maximum Ethernet throughput. This indicates better transfer rates may be archived if faster network connections are used. Thus, the installation of the PrivateNet system does not have a major impact on network performance since connection performance is bottlenecked by the bandwidth of the connection line to the Internet.

Up to Contents

7. What a Firewall Cannot Do

When installing a firewall, it is very important to understand what a firewall can and cannot do. First, it can protect internal networks only at the point where the connection passes through the firewall. If an organization has more than one Internet connection (as many large organizations do), or if the organization has a widespread use of modems, the installation of a firewall may not guarantee security since there may be other ways to break into internal networks. NEC encourages organizations to conduct a security analysis as part of the planning process.

It must also be understood that a firewall is a technical solution to a technical problem. It does not protect against other problems, such as disgruntled employees causing security breaches from an access point on the inside of a firewall, or from attacks based primarily on social engineering.

The book Firewall and Internet Security[2] has a humorous example of social engineering (borrowed from Tea with the Black Dragon by R. A. MacAvoy).

"We have to boot up the system."


The guard cleared his throat and glanced wistfully at his book. "Booting is not my business. Come back tomorrow."

"But if we don't boot the system right now, it's going to get hot for us. Overheat. Muy caliente and a lot of money."

The guard's pudgy face creased with worry, but he shrugged. "I cannot boot. What can I do?"

"You have the keys, I know. Let us in so we can do it."

The guard blinked resentfully. "I cannot do that," he stated. "It is not permitted."


"Have you ever seen a computer crash?" he demanded. "It's horrible, All over the floor!"

Generally, social engineering is very successful, because most people want to be helpful to other people. Some examples of how social engineering can enable a hacker to extract an amazing amount of confidential information can be found in the paper Information Security Technology?... Don't Rely on It. A Case study in Social Engineering[3].

The two main lessons to be learned are that:

Up to Contents

Appendix A: PrivateNet System Feature Summary

Up to Contents

Appendix B: Firewall Selection Criteria and the PrivateNet Server

  1. A firewall should hide internal network information (IP address, etc.) as much as possible.
    The PrivateNet system uses the proxy method, which totally hides internal IP address from the outside, and acts as a bastion host. Also, the PrivateNet system supports DNS, and the bastion host includes the external domain name server.

  2. Inbound connections (email, Telnet, etc.) should be configured for maximum security.
    The PrivateNet system provides an application-level Telnet proxy with SNK authentication.

  3. Outbound connections should be relatively easy so that the client user does not need to know of the firewall's existence.
    The PrivateNet system provides the SocksPlus circuit-level proxy gateway, NEC's improved version of SOCKS 4.2 . The SocksPlus proxy is 100% compatible with SOCKS. The SocksPlus proxy is transparent to the user, easy to use, yet highly secure.

  4. Mail and news services should be included in the product.
    The PrivateNet system provides SMTP (mail), NNTP (news), and HTTP (Web server) proxies.

  5. The bastion host on which the firewall software runs should have maximum security.
    All software, including the operating system, is on the PrivateNet system CD-ROM. All insecure functions in the operating system are removed or modified. The PrivateNet system is offered as a software and hardware product, to maximize security.

  6. The firewall system should be expandable for corporate network extension.
    Using a multiple PrivateNet system serial or parallel configuration, the user can configure both hierarchical security subnetworking and virtual private networking (using PrivateNet-to-PrivateNet encryption). Parallel configuration also provides the fault tolerance and load balancing.

  7. The firewall should be supported domestically and internationally.
    NEC is an international company with offices in more than 150 countries. The product has shipped first in the United States and Japan.

Up to Contents

Appendix C: Firewall Bombs

The book Firewall and Internet Security, by Cheswik and Bellovin (Addison-Wesley Professional Computing Series) has an appendix that lists 42 "bombs," each describing a problem that can allow a firewall to be penetrated. Many of the risks present in those bombs are from services that are inappropriate to offer on a firewall, while others can be minimized or eliminated through a security-aware implementation of the software running on the firewall. The PrivateNet system has been designed and implemented so that it is able to protect against all of these risks:

  1. Password system failures are the single biggest problem.
    The PrivateNet system allows users to authenticate themselves only through challenge-response system authentication methods. Users are not allowed direct access to the firewall machine. The only exception is when the system administrator is logging in on the console. Because this connection does not cross any network, it does not present this problem.
  2. Sequence number attacks can be used to subvert address-based authentication
    This problem in the implementation of TCP/IP has been corrected by BSDI.

  3. It is easy to spoof UDP packets.
    The PrivateNet system does not allow UDP connections through the firewall. The SocksPlus proxy allows clients using UDP to connect through the PrivateNet system, but the connections on the inside are implemented as UDP over TCP, eliminating this problem.

  4. ICMP packets can tear down all connections between a pair of hosts.
    The PrivateNet system does not allow ICMP packets to pass through the firewall.
  5. ICMP Redirect messages can subvert routing tables.
    The PrivateNet system uses static routing for its routing tables and is therefore not subject to this type of spoofing.
  6. IP Source routing can subvert address-based authentication.
    It is not appropriate for a firewall to honor source routing. The PrivateNet system does not allow source routing information and is therefore not subject to this type of spoofing.

  7. It is easy to generate false RIP messages.
    The PrivateNet system uses static routing for its routing tables, and does not forward any RIP messages. It is therefore not subject to this type of spoofing.

  8. The inverse DNS tree can be used be used for name-spoofing.
    The PrivateNet system uses reverse-name-serve-lookup to minimize this risk. Users are strongly encouraged to use only IP numbers in the configuration tables, which eliminates name server spoofing.
  9. The DNS cache can be contaminated to foil crosschecks.
    The PrivateNet system uses a new version of the nameserver, but for this bomb users are strongly advised to use only IP numbers in the configuration tables. This eliminates name server spoofing.
  10. Return addresses in mail are not reliable.
    This problem cannot be solved by firewall technology. However, the SMTP proxy is implemented so that it does not give out information though the "EXPN" and "VRFY" commands, and it examines and prevents "mail header" attacks.

  11. Sendmail is a security risk.
    The PrivateNet system uses an SMTP proxy to receive email. This prevents Sendmail attacks based on network access or header corruption.
  12. Don't blindly examine MIME messages.
    The PrivateNet system does not interpret MIME messages, and is therefore not sensitive to this kind of spoofing.

  13. It is easy to wiretap Telnet sessions.
    Telnet (and all other connections) between multiple PrivateNet systems are encrypted, and a challenge/response system is used for authentication. However, these are only partial solutions. The correct solution to this problem requires an end-to-end solution. A redesign of the Telnet protocol, as well as a reimplementation of the Telnet client and server are required. This is outside the scope of what a firewall can provide.

  14. You can subvert NTP to attack authentication protocols.
    NTP is not an appropriate service to offer on a firewall. The PrivateNet system does not offer this service, and is therefore not subject to this risk. Sites that use NTP internally are advised to get their own time source, rather than relay on this service from the Internet.

  15. Finger discloses too much information.
    The PrivateNet system does not support fingering of internal hosts. Therefore, no information can be disclosed in this manner.

  16. Don't trust RPC's machine name field.
    RPC is not an appropriate service to offer on a firewall. The PrivateNet system does not offer this service, and is therefore not subject to this risk.

  17. The portmapper can call RPC services for its caller.
    Portmapper is not an appropriate service to offer on a firewall. The PrivateNet system does not offer this service, and is therefore not subject to this risk.

  18. NIS can often be persuaded to give out password files.
    NIS and NIS+ are not appropriate services to offer on a firewall. The PrivateNet system does not offer these services, and is therefore not subject to these risks.

  19. It is sometimes possible to direct machines to phony NIS servers.
    This is a risk only when NIS is offered as a service. The PrivateNet system does not offer this service, and is therefore not subject to this risk.

  20. It is hard to revoke NFS access.
    NFS is not an appropriate service to offer on a firewall. The PrivateNet system does not offer this service, and is therefore not subject to this risk.

  21. If misconfigured, TFTP will hand out /etc/passwd.
    TFTP is not an appropriate service to offer on a firewall. The PrivateNet system does not offer this service, and is therefore not subject to this risk.

  22. Don't make FTP's home directory writable.
    The PrivateNet system does not offer FTP services at this time.
  23. Don't put real passwords on the anonymous FTP area.
    The PrivateNet system does not offer FTP services at this time.
  24. FTP is often abused to give out files to those who should not have them.
    The PrivateNet system does not offer FTP services at this time.
  25. Be careful about interpreting WWW format information.
    This is a risk for WWW clients. There are currently no solutions a firewall can provide, other than to deny WWW access.

  26. WWW servers should be careful about file pointers.
    This is a risk for WWW servers. There are currently no solutions a firewall can provide, other than not to offer WWW services.
  27. Attackers can use FTP to create Gopher control information.
    The PrivateNet system does not offer Gopher services at this time.
  28. Poorly written query scripts pose a danger to WWW servers.
    This is a risk for WWW servers. There are currently no solutions a firewall can provide, other than not to offer WWW services.
  29. The MBONE can be used to route through some firewalls.
    The PrivateNet system does not offer MBONE service at this time.
  30. An attacker anywhere on the Internet can probe for X11 servers.
    X11 is not an appropriate service to offer on a firewall without an application proxy. The PrivateNet system does not include a X11 proxy and does not otherwise offer this service. It is therefore not subject to this risk.

  31. Don't trust port numbers supplied by outside machines.
    This risk is for packet filters only and does not apply to proxy servers. Because the PrivateNet system allows access only through a proxy mechanism, it is not subject to this risk.

  32. It is all but impossible to permit most UDP traffic through a packet filter safely.
    The PrivateNet system uses proxy servers, not packet filters. It is therefore not subject to this risk.

  33. A tunnel can be build on top of almost any transport mechanism.
    This is a management problem, not a technical one. This problem is almost impossible to prevent, but relatively easy to detect.
  34. Firewalls cannot block attacks at higher levels of the protocol stack.
    The PrivateNet system uses proxy technology everywhere because proxies are less sensitive to this problem than packet filters. However, they are not immune to it.

  35. X11 is very dangerous, even when passed through a gateway.
    X11 is not an appropriate service to offer on a firewall without an application proxy. The PrivateNet system does not include an X11 proxy and does not otherwise offer this service. It is therefore not subject to this risk.

  36. Network monitoring tools can be very dangerous on an exposed machine.
    The proxy mechanism implemented in the PrivateNet system does not allow any packets to pass through the firewall. This minimizes the information that can be gained through packet sniffing. Because the PrivateNet system uses a challenge/response mechanism to authenticate users, password sniffing does not reveal any useful information for the cracker.

  37. Be careful at directing finger to a subverted machine.
    This is a problem that must be addressed in a finger client program.
  38. Watch out for booby-trapped file names.
    The log analyzing program planned for a future release of the PrivateNet system is designed to treat all messages as data only. It is therefore not be possible to spoof it by using logged data as executable programs.

  39. Hackers plan silent password grabbers.
    Because all programs on The PrivateNet system are stored and loaded directly from the CD-ROM, a cracker cannot install a Trojan horse if access is gained to The PrivateNet system itself.

  40. There are many ways of grabbing /etc/passwd.
    Even if a cracker manages to get a copy of the password file, this is not an advantage because access is restricted by The PrivateNet system. Access to the internal network is possible only by successful authentication through the challenge/response mechanism.

  41. Logging failed logins will often capture passwords.
    The PrivateNet system does not capture passwords in its logs. Even if it did, this information would be useless, because one-time passwords are used.

  42. You may be liable for a hacker's activities.
    This is outside the technical realm of a firewall.

Up to Contents


  1. Dave Koblas and Michelle R Koblas, SOCKS, Third USENIX UNIX Security Symposium Proceedings, 1992.
  2. William R. Cheswik and Steven M. Bellovin, Firewall and Internet Security, Repelling the Wily Hacker, Addison-Wesley Professional Computing Series
  3. Ira S. Winkler and Brian Dealy Information Security Technology?... Don't Rely on It. A Case study in Social Engineering, Fifth USENIX UNIX Security Symposium Proceedings, 1995.

Up to Contents

Send your comments and questions to