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.

Contents

Summary
1. Introduction
2. What is a Firewall?

2.1 What is a Departmental Firewall?
2.2 What is a Virtual Private Network?

Summary

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:

• A proxy server allows no direct traffic through a firewall; packet filters do.
• A proxy server prevents direct communication with an outside network or internal sub-network.
• Packet filters permit or deny each network packet based on source and destination addresses, making this type of firewall at risk for spoofing.
• A proxy server uses a "connection filtering" authorization mechanism to determine whether a connection should be made. Before a connection is made, the proxy examines the data within packets rather than just the packet headers, virtually eliminating spoofing attempts.
• A proxy server hides internal networks from those outside the firewall. A hacker cannot obtain formation by scanning internal addresses.

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.

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:

• Uses proper software layering, leaving it much less vulnerable to bad packet formats.
• Can be configured to listen only to client connections on the inside network, and properly identifies IP spoofing attacks originating from the outside but using an inside IP address.
• Provides UDP support in addition to the TCP support found in the original SOCKS 4.2 implementation.
• Provides encrypted data communication between the servers.
• Supports parallel configuration, providing both high availability and load-balancing between servers.
• Does not require a configuration file at each client. The server information is obtained from DNS.
• Does not accumulate log information at each client.

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:

• A Telnet proxy with good user authentication based on the challenge/response system. SNK is available in Release 1.0, and other mechanisms will be added in future releases.
• An SMTP proxy, which acts as a security wrapper for sendmail.
• An NNTP proxy for support of network news.
• An HTTP proxy, primarily intended for support of HTTP servers on a screened subnet.
• An FTP proxy (in a future PrivateNet system release), intended for support of FTP servers on a screened subnet.

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.

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.

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 first section is an access control list for SocksPlus proxy clients connecting to the server. These rules are fairly traditional, using source and destination addresses and port numbers to determine if a given client should be allowed to connect through the server. In addition, there is a configuration clause specifying which interface on the PrivateNet system should accept requests for SOCKS 4.2 and SocksPlus proxy connections.
• The second section configures the rules for behavior when performing server-to-server connections. This section also has a set of access control lists for the connections, which applies to SOCKS 4.2 and SocksPlus proxy connections from other servers. When an organization has both departmental and corporate firewalls, the PrivateNet system allows corporate access rules to be enforced at the corporate firewall independent of access rules implemented at the departmental level. This section also contains configuration clauses that determine which other PrivateNet systems to accept connections from, and how SOCKS 4.2 and SocksPlus proxy connections should be routed when using server-to-server connectivity.
• The final section contains configuration clauses for timeouts and the limitation of connection types. For example, this allows the system administrator to limit the number of WWW connections allowed through the server at a given time.

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.

• System administrators familiar with Sendmail configuration can make configuration changes as usual. Because the basic mechanism is unchanged, users are assured that no new bugs have been introduced into this complex system.
• By default the Sendmail configuration on the PrivateNet system uses a simple forwarding strategy. That is, all incoming email is forwarded to a central mail hub or mail exchanger. This moves all user address resolution (such as the alias file) from the firewall to an internal host with presumed easier access. The internal host is, therefore, simpler to maintain. System administrators with a large user population can implement more complex mail delivery schemes by configuring Sendmail and the name service accordingly.
• Outgoing mail is delivered in a similar way using the PrivateNet system as a mail relay. In its simplest configuration, this is achieved by having all hosts forward email to the mail hub which, in turn, uses the PrivateNet system as a smart host. (While this scheme is attractive in its simplicity, it is not appropriate for larger sites. However, such sites can keep their current strategy as long as all outgoing mail is delivered to the PrivateNet system.)

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:

• No firewall, however well it is implemented, is 100% secure, and, with enough determination and time investment by crackers, any firewall can and will be broken.
• Firewall technology improves all the time, but the tools that are used to penetrate them also improve. Providing a highly secure firewall is an arms race, but a firewall based on a restrictive technology at least has the chance of surviving the longest.

Up to Contents

Appendix A: PrivateNet System Feature Summary

• Authentication Methods

  Token-based authentication is provided through SNK for external-to-internal access. Access to internal resources from outside the firewall uses strong authentication without disclosing passwords to eavesdroppers.

• Blocks IP Address Spoofing

  Internal hosts cannot be spoofed because all IP traffic is filtered at the firewall. The PrivateNet system protects itself against spoofing by briefing and segregating internal and external traffic.

• Client Applications

  For inside-to-outside access the following clients are provided:
  -Telnet
  -FTP
  -Archie
  -World Wide Web (Using Netscape with SOCKS 4.2 support)
  In addition, Windows 3.X applications based on winsock.dll and any SOCKS 4.2 client applications are also supported.

• Client Hardware/Software Platforms

  -SPARC/SunOs 4.1.3
  -SPARC/Solaris 2.3
  -Intel x86/BSDI 2.0
  -Windows 3.X

• Connect Limits

  The system can be configured to limit the number of connections by client service type.

• Connect Time/Traffic

  All connect times and amount of traffic are logged.

• Connection Auditing

  All connection attempts are logged whether successful or not.

• DNS (Domain Name Service)

  The PrivateNet system runs a split DNS configuration, which allows internal systems to resolve both internal and external host addresses and names. External systems cannot resolve names or addresses for internal systems.

• Encryption

  Site-to-site traffic can be encrypted between two PrivateNet systems. This allows for VPNs (Virtual Private Networks) between these sites using inexpensive public networks with a security level comparable to private networks. The VPN supports both UDP/IP and TCP/IP traffic. DES and Triple-DES security methods are used for encryption.

• Exportable Logs

  All PrivateNet system logging is written to a remote system, which provides a secure audit trail even in the event of a PrivateNet system security breach.

• Floppy-Based Key Distribution

  Security keys needed to provide VPN functionality between PrivateNet systems are securely exchanged through a floppy diskette. It is recommended that your security administrator tightly control the diskettes.

• High Availability

  Installation of parallel PrivateNet systems allows access to the external network to continue in the event of the failure of one of the PrivateNet systems.

• IP Address Hiding

  The only IP addresses exposed to the external network are those assigned to the PrivateNet system's external interface(s). Internal IP addresses are effectively translated to an IP address on the PrivateNet server itself. Internal IP addresses are not exposed to the external network.

• Load Balancing

  The SocksPlus proxy clients (Telnet, FTP, etc.) used in conjunction with the PrivateNet system distribute the load between parallel PrivateNet systems. This allows the system to easily scale up for users at large sites. (This is based on random distribution, not on actual load).

• Log-In Attempts Logging

  All access attempts, from inside to outside, or from outside to inside, are logged

• Proxies Supported

  -The following proxies are supported:
  -Telnet (Provided using SNK authentication)
  -SMTP (Provided using true proxy)
  -NNTP (TCP/IP tunnel)
  -HTTP (TCP/IP tunnel)

• Service Use Logging

  Services used are logged.

• SocksPlus Server

  SOCKS 4.2 clients are fully compatible with the SocksPlus proxy. The SocksPlus proxy clients provide additional benefits, such as load distribution. The SocksPlus server can also co-exist with existing SOCKS 4.2 servers.

• Transparent to Users

  Authorized internal users can transparently access external resources with no additional steps required. The PrivateNet server provides access controls to restrict the internal systems that have access to external resources.

• Versatile SocksPlus proxy clients

  The SocksPlus proxy clients are suitable for internal as well as external access. When making internal connections, PrivateNet system clients connect directly to these systems. This avoids unnecessarily loading the PrivateNet server and eliminates the need to have clients for both internal and external access.

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

References

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