Firewalls Complete - Types of Firewalls and Products on the Market

This section provides you with a technical overview of the main firewall products available on the market as of Summer of 1997. I made sure to include a vast and extensive selection of all the major players and architecture so you can have a chance to evaluate each one of them before deciding which firewall best suite your needs.

This selection includes many different firewall architectures, from application proxy and circuit relay ones, such as Raptor’s EagleNT, Ukiah’s NetRoad and Secure Computing’s Borderware firewall, to stateful inspection and packet filter ones, such as WatchGuard Technologies’s WatchGuard, Sun’s SunScreen, Check Point’s Firewall-1 and Cycon’s Labyrinth ones.

Evidently, I’m not in the position of recommending any of these products as the needs and features of a firewall product will change depending of your environment. Although I may have my preferences, it probably would be a biased one, which would be directly related to the environment I work with. Thus, all the information you find in this section was totally provided by the vendor of each firewall outlined here. Some provided more information then others, as others provided more graphics and figures. By no means you should opt for any of these firewalls based on the amount of pages or details here provided. Most of the vendors listed here also provided demo and/or evaluation copies of their products in the CD that accompanies this book.

In order to make an informative decision when selecting a firewall that best suites your needs, I strongly encourage you to carefully read this chapter, and summarize on a table all the features you are looking for, or need, in a firewall for your organization. Then, I suggest you to check the CD and install the firewall(s) you selected and run a complete "dry-run" on them before you can really make a decision. Also, don’t forget to contact the vendor directly, as these products are always being upgraded and new features incorporated to them, which could make a difference in your decision. Contact information and a brief background about the vendor is provided at the beginning of every section of the product covered.

Check Points’ Firewall-1 Firewall - Stateful Inspection Technology

Check Point FireWall-1, developed by Check Point Software Technologies (http://www.checkpoint.com), is based upon Stateful Inspection architecture, the new generation of firewall technology invented by CheckPoint. Stateful Inspection Technology delivers full firewall capabilities, assuring the highest level of network security. FireWall-1’s powerful Inspection Module analyzes all packet communication layers, and extracts the relevant communication and application state information. The Inspection Module understands and can learn any protocol and application. Figure 14.1 shows a screenshot of Check Points site.

Note: For more information, contact Check Point Software Technologies, Redwood City, CA, (415) 562-0400 or at their Web site at URL http://www.checkpoint.com

FireWall-1 Inspection Module

The FireWall-1 Inspection Module resides in the operating system kernel, below the Network layer, at the lowest software level. By inspecting communications at this level, FireWall-1 can intercept and analyze all packets before they reach the operating systems. No packet is processed by any of the higher protocol layers unless FireWall-1 verifies that it complies with the enterprise security policy.

Full State Awareness

The Inspection Module has access to the "raw message," and can examine data from all packet layers. In addition, FireWall-1 analyzes state information from previous communications and other applications. The Inspection Module examines IP addresses, port numbers, and any other information required in order to determine whether packets comply with the enterprise security policy. It also stores and updates state and context information in dynamic connections tables. These tables are continually updated, providing cumulative data against which FireWall-1 checks subsequent communications. FireWall-1 follows the security principle of "All communications are denied unless expressly permitted." By default, FireWall-1 drops traffic that is not explicitly allowed by the security policy and generates real-time security alerts, providing the system manager with complete network status.

Securing "Stateless" Protocols

The FireWall-1 Inspection Module understands the internal structures of the IP protocol family and applications built on top of them. For stateless protocols such as UDP and RPC, the Inspection Module extracts data from a packet’s application content and stores it in the state connections tables, providing context in cases where the application does not provide it. In addition, it can dynamically allow or disallow connections as necessary. These capabilities provide the highest level of security for complex protocols.

The INSPECT Language

Using Check Point’s INSPECT language, FireWall-1 incorporates security rules, application knowledge, context information, and communication data into a powerful security system. INSPECT is an object-oriented, high-level script language that provides the Inspection Module with the enterprise security rules.

In most cases, the security policy is defined using FireWall-1’s graphical interface. From the security policy, FireWall-1 generates an Inspection Script, written in INSPECT. Inspection Code is compiled from the script and loaded on to the FireWalled enforcement points, where the Inspection Module resides. Inspection Scripts are ASCII files, and can be edited to facilitate debugging or meet specialized security requirements.

INSPECT provides system extensibility, allowing enterprises to incorporate new applications, services, and protocols simply by modifying one of FireWall-1’s built-in script templates using the graphical user interface. Figure 14.2 shows a diagram of the Stateful Inspection technology.

Stateful Inspection: Under the hood

As discussed throughout this book, in order for you to have a robust security at your company you should have a firewall. But this firewall must be able to track and control the flow of communication passing through it. To reach control decisions for TCP/IP based services, such as whether to accept, reject, authenticate, encrypt and/or log communication attempts, a firewall must obtain, store, retrieve and manipulate information derived from all communication layers and from other applications.

It is not sufficient to examine packets in isolation. State information, which is derived from past communications and other applications, is an essential factor in making the control decision for new communication attempts. Depending upon the communication attempt, both the communication state, derived from past communications, and the application state, derived from other applications, may be critical in the control decision.

Thus, to ensure the highest level of security, a firewall must be capable of accessing, analyzing and utilizing the following:

• Communication Information - information from all seven layers in the packet
• Communication-derived State - the state derived from previous communications. For example, the outgoing PORT command of an FTP session could be saved so that an incoming FTP data connection can be verified against it.
• Application-derived State - the state information derived from other applications. For example, a previously authenticated user would be allowed access through the firewall for authorized services only.
• Information Manipulation - the evaluation of flexible expressions based on all the above factors.

Check Point’s Stateful Inspection is able to meet all the security requirements defined above. Traditional firewall technologies, such as packet filters and application-layer gateways, each fall short in some areas, as shown on Table I.

Table I: Comparison of capabilities for three main firewall architectures

Firewall Capability	Packet Filters	Application-layer Gateways	Stateful Inspection
Communication Information	Partial	Partial	Yes
Communication-derived State	No	Partial	Yes
Application-derived State	No	Yes	Yes
Information Manipulation	Partial	Yes	Yes

If you take packet filters, for example, historically they are implemented on routers, are filters on user defined content, such as IP addresses. As discussed on chapter 7, "What is an Internet/Intranet Firewall After All?," packet filters examine a packet at the network layer and are application independent, which allows them to deliver good performance and scaleability. However, they are the least secure type of firewall, especially when filtering services such as FTP, which was vastly discussed on chapter 8, "How Vulnerable Are Internet Services." The reason is that they are not application aware-that is, they cannot understand the context of a given communication, making them easier for hackers to break. Figure 14.3 illustrates it.

If we look into FTP filtering, packet filters have two choices with regard to the outbound FTP connections. They can either leave the entire upper range (greater than 1023) of ports open which allows the file transfer session to take place over the dynamically allocated port, but exposes the internal network, or they can shut down the entire upper range of ports to secure the internal network which blocks other services, as shown on figure 14.4. This trade-off between application support and security is not acceptable to users today.

As with application gateways, as shown on figure 14.5, the security is improved by examining all application layers, bringing context information into the decision process. However, they do this by breaking the client/server model. Every client/server communication requires two connections: one from the client to the firewall and one from the firewall to the server. In addition, each proxy requires a different application process, or daemon, making scaleability and support for new applications a problem.

For instance, in using an FTP proxy, the application gateway duplicates the number of sessions, acting as a proxied broker between the client and the server (see figure 14.6). Although this approach overcomes the limitation of IP filtering by bringing application-layer awareness to the decision process, it does so with an unacceptable performance penalty. In addition, each service needs its own proxy, so the number of available services and their scaleability is limited. Further, this approach exposes the operating system to external threats.

The Stateful Inspection introduced by Check Point overcomes the limitations of the previous two approaches by providing full application-layer awareness without breaking the client/server model. With Stateful Inspection, the packet is intercepted at the network layer, but then the INSPECT Engine takes over, as shown on figure 14.7. It extracts state-related information required for the security decision from all application layers and maintains this information in dynamic state tables for evaluating subsequent connection attempts. This provides a solution which is highly secure and offers maximum performance, scaleability, and extensibility.

The Stateful Inspection tracks the FTP session, as shown on figure 14.8, examining FTP application-layer data. When the client requests that the server generate the back-connection (an FTP PORT command), FireWall-1 extracts the port number from the request. Both client and server IP addresses and both port numbers are recorded in an FTP-data pending request list. When the FTP data connection is attempted, FireWall-1 examines the list and verifies that the attempt is in response to a valid request. The list of connections is maintained dynamically, so that only the required FTP ports are opened. As soon as the session is closed the ports are locked, ensuring maximum security.

Extensible Stateful Inspection

Check Point FireWall-1’s Stateful Inspection architecture utilizes a unique, patented INSPECT Engine which enforces the security policy on the gateway on which it resides. The INSPECT Engine looks at all communication layers and extracts only the relevant data, enabling highly efficient operation, support for a large number of protocols and applications, and easy extensibility to new applications and services.

The INSPECT Engine is programmable using Check Point’s powerful INSPECT Language. This provides important system extensibility, allowing Check Point, as well as its technology partners and end-users, to incorporate new applications, services, and protocols, without requiring new software to be loaded. For most new applications, including most custom applications developed by end users, the communication-related behavior of the new application can be incorporated simply by modifying one of FireWall-1’s built-in script templates via the graphical user interface. Even the most complex applications can be added quickly and easily via the INSPECT Language.

Tip: Check Point provides an open application programming interface (API) for third-party developers and regularly posts INSPECT Scripts to support new applications on the Check Point Web site at http://www.checkpoint.com.

The INSPECT Engine

When installed on a gateway, the FireWall-1 INSPECT Engine controls traffic passing between networks. The INSPECT Engine is dynamically loaded into the operating system kernel, between the Data Link and the Network layers (layers 2 and 3). Since the data link is the actual network interface card (NIC) and the network link is the first layer of the protocol stack (for example, IP), FireWall-1 is positioned at the lowest software layer. By inspecting at this layer, FireWall-1 ensures that the INSPECT Engine intercepts and inspects all inbound and outbound packets on all interfaces. No packet is processed by any of the higher protocol stack layers, no matter what protocol or application the packet uses, unless the INSPECT Engine first verifies that the packet complies with the security policy.

As discussed earlier, because the INSPECT Engine has access to the "raw message", it can inspect all the information in the message, including information relating to all the higher communication layers, as well as the message data itself (the communication- and application-derived state and context). The INSPECT Engine examines IP addresses, port numbers, and any other information required in order to determine whether packets should be accepted, in accordance with the defined security policy.

The INSPECT Engine understands the internal structures of the IP protocol family and applications built on top of them. For stateless protocols such as UDP and RPC, the INSPECT Engine creates and stores context data, maintaining a virtual connection on top of the UDP communication. The INSPECT Engine is able to extract data from the packet’s application content and store it to provide context in those cases where the application does not provide it. Moreover, the INSPECT Engine is able to dynamically allow and disallow connections as necessary. These dynamic capabilities are designed to provide the highest level of security for complex protocols, but the user may disable them if they are not required.

The INSPECT Engine’s ability to look inside a packet enables it to allow certain commands within an application while disallowing others. For example, the INSPECT Engine can allow an ICMP ping while disallowing redirects, or allow SNMP gets while disallowing sets, and so on. The INSPECT Engine can store and retrieve values in tables (providing dynamic context) and perform logical or arithmetic operations on data in any part of the packet. In addition to the operations compiled from the security policy, the user can write his or her own expressions.

Unlike other security solutions, FireWall-1’s Stateful Inspection architecture intercepts, analyzes, and takes action on all communications before they enter the operating system of the gateway machine, ensuring the full security and integrity of the network. Cumulative data from the communication and application states, network configuration and security rules, are used to generate an appropriate action, either accepting, rejecting, authenticating, or encrypting the communication. Any traffic not explicitly allowed by the security rules is dropped by default and real-time security alerts and logs are generated, providing the system manager with complete network status.

The Stateful Inspection implementation supports hundreds of pre-defined applications, services, and protocols, more than any other firewall vendor. Support is provided for all major Internet services, including secure Web browsers, the traditional set of Internet applications (e.g. mail, FTP, Telnet, etc.), the entire TCP family, and connectionless protocols such as RPC and UDP-based applications. In addition, only FireWall-1’s Stateful Inspection offers support for critical business applications such as Oracle SQL*Net database access and emerging multimedia applications such as RealAudio, VDOLive, and Internet Phone.

Securing Connectionless Protocols such as UDP

UDP (User Datagram Protocol)-based applications (DNS, WAIS, Archie, etc.) are difficult to filter with simplistic packet-filtering techniques because in UDP, there is no distinction between a request and a response. In the past, the choice has been to either eliminate UDP sessions entirely or to open a large portion of the UDP range to bi-directional communication, and thus to expose the internal network.

Stateful Inspection implementation secures UDP-based applications by maintaining a virtual connection on top of UDP communications. The FireWall-1’s INSPECT Engine maintains state information for each session through the gateway. Each UDP request packet permitted to cross the firewall is recorded, and UDP packets traveling in the opposite direction are verified against the list of pending sessions to ensure that each UDP packet is in an authorized context. A packet that is a genuine response to a request is delivered and all others are dropped. If a response does not arrive within the specified time period, the connection times out. In this way, all attacks are blocked, while UDP applications can be utilized securely.

Securing Dynamically Allocated Port Connections

Simple tracking of port numbers fails for RPC (Remote Procedure Call) because RPC-based services (NFS, NIS) do not use pre-defined port numbers. Port allocation is dynamic and often changes over time. This is another feature of the INSPECT Engine of Firewall-1, which dynamically and transparently tracks RPC port numbers using the port mappers in the system. The INSPECT Engine tracks initial portmapper requests and maintains a cache that maps RPC program numbers to their associated port numbers and servers.

Whenever the INSPECT Engine examines a rule in which an RPC-based service is involved, it consults the cache, comparing the port numbers in the packet and cache and verifying that the program number bound to the port is the one specified in the rule. If the port number in the packet is not in the cache (this can occur when an application relies on prior knowledge of port numbers and initiates communication without first issuing a portmapper request) the INSPECT Engine issues its own request to portmapper and verifies the program number found to the port, as shown on figure 14.9.

Firewall-1 Performance

The following are the major performance strength of Firewall on through its INSPECT Engine:

• Runs inside the operating-system kernel, which imposes negligible overhead in processing. Also, no context switching is required, and low-latency operation is achieved.
• Uses of advanced memory management techniques, such as caching and hash tables, which are used to unify multiple object instances and to efficiently access data.
• Its generic and simple inspection mechanisms are combined with a packet inspection optimizer, which ensure optimal utilization of modern CPU and OS designs.

According to independent test results (http://www.checkpoint.com/products/fproduct.html) and an article on Data Communication magazine of March 97, the network performance degradation when using Firewall-1 is too small to measure when operating at full LAN speed (10 Mbps) on the lowest-end SPARCstation. FireWall-1 supports high-speed networking such as 100 Mbps Ethernet and OC-3 ATM with the same high level of performance.

As far as certified benchmark, KeyLabs Inc. (http://www.keylabs.com) conducted extensive testing of the Solaris and Windows NT versions of FireWall-1 to document firewall performance under various configurations. The test methodology was carefully designed to simulate actual network conditions and test automation applications were employed to ensure accurate results.

Several FireWall-1 configurations were tested to determine whether performance is impacted by encryption, address translation, logging and rule base size. In addition, FireWall-1 was stressed to determine the maximum number of concurrent connections that can be supported. The Fastpath option was enabled on FireWall-1 for several configurations to maximize performance. Fastpath is a widely used FireWall-1 feature that optimizes performance without compromising security.

FireWall-1 was configured with two network interfaces: internal and external. Each interface utilized two Fast Ethernet connections to maximize throughput and ensure that FireWall-1 was thoroughly stressed. Multiple clients on the internal network made HTTP and FTP requests to multiple servers on the external side of FireWall-1. Clients generated approximately 5 Mbps of traffic each and were added incrementally to increase the traffic level through FireWall-1.

During this test, 75% of the connections were of HTTP (75 kbytes) 75%, and the remain 25% were FTP (1 Mbyte) connections.

To determine the maximum number of concurrent connections that FireWall-1 can support, multiple clients made HTTP requests to servers on the external FireWall-1 interface. Each client was capable of establishing and maintaining 500 total connections, as shown on figure 14.10.

The results? When running on Solaris, as shown on figure 14.11, FireWall-1 supports approximately 85 Mbps with Fastpath enabled (top line) and 53 Mbps with Fastpath disabled (second line from top). This is sufficient to support both T3 (45 Mbps) and effective Fast Ethernet data rates.

For Windows NT, as shown on figure 14.12, 25 Mbps can be maintained with Fastpath enabled, and approximately 20 Mbps is supported without Fastpath. This is seen in the bottom two lines of the graph. The test results show that both T1 (1.544 Mbps) and Ethernet data rates are supported by the Windows NT version of FireWall-1. With this level of performance across multiple platforms, FireWall-1 is well-suited for high-speed Internet and Intranet environments.

For more information, check Keylabs Inc. Site, as listed above or Check Point’s site. There you will find a comprehensive result of Firewall-1 performance in many other environment and situations.

Systems Requirements

The FireWall-1 system requirements is the following:

• Platforms supported: Sun SPARC, HP-PA-RISC 700/800, Intel x86 or Pentium
• Operating systems: Windows NT 3.51 and 4.0, SunOS 4.1.3 and 4.1.4, Solaris 2.3, 2.4, and 2.5, HP-UX 9 and 10 and IBM AIX
• Window systems: Windows 95, Windows NT, X/Motif and Open Look
• Disk space: 20 MB
• Memory: 16-32 MB
• Network interface: All interfaces supported by the operating system
• Routers management (optional): Cisco Systems IOS version 9, 10, 11 Bay Networks version 8, 9
• Media: CD-ROM

CYCON’s Labyrinth Firewall - The "Labyrinth-like" System

The CYCON Labyrinth firewall is the world’s first "labyrinth-like" system incorporating true bi-directional network address translation with a powerful, intelligent connection tracking (ICT) firewall to create an integrated security and network management device. CYCON Labyrinth firewall is currently in use by several major corporations, Internet Service Providers, and research institutions. Figure 14.13 shows a screenshot of CYCON’s site.

Note: For more information, contact CYCON Technologies, Fairfax, VA, (703) 383-0247, or at their Web site at URL http://www.cycon.com

CYCON Labyrinth firewall’s stateful inspection engines support all IP based services and correctly follows TCP, UDP, ICMP, and TCP SYN/ACK traffic. Support for all major IP services include, but not limited to:

• Telnet
• SMTP
• DNS (both TCP and UDP)
• FTP
• HTTP
• SSL
• NFS
• NNTP
• Archie
• Gopher
• X11
• NTP
• X500
• IMAP and POP3
• LDAP
• ICMP (ping, traceroute)
• RealAudio

CYCON Labyrinth firewall offers full bi-directional network address translation. CYCON Labyrinth firewall can rewrite the source, destination, and port addresses of a packet. Network address translation conceals internal addresses from outside untrusted networks. Additionally, bi-directional address translation enables CYCON Labyrinth firewall to properly redirect packets to any host in any system. Using two CYCON Labyrinth firewalls together allow the proper communication between two private IP networks connected to the Internet by translating both incoming and outgoing traffic.

CYCON Labyrinth firewall can be configured to authenticate users on both inbound and outbound access. Inbound access authentication is used to implement stronger security policies. Outbound access authentication can be used to track and log connections for internal billing or charge backs purposes. Authentication is at the user level, not at the IP address level. This allows the user to move across networks and retain the ability to use resources regardless of their physical IP address, making it appropriate for Dynamic Host Configuration Protocol (DHCP) address assignments.

CYCON Labyrinth firewall supports multi-level logging. In regular mode, connections are logged. In debug logging mode, connections, packets, bytes, and actions taken are logged. Log files are written in standard UNIX syslog ASCII format and are easily manipulated by a firewall administrator for analysis. Syslog logging allows multiple CYCON Labyrinth firewalls to log to a single machine for greater security and ease of analysis.

CYCON Labyrinth firewall utilizes a rewritten BSD UNIX kernel incorporating optimized data structures and algorithms designed to produce high-speed packet filtering. CYCON Labyrinth firewall implements stateful inspection and packet modifying technology to overcome gaps found in traditional packet filtering methods

An Integrated Stateful Inspection

The CYCON Labyrinth firewall provides outstanding protection to all aspects of an organization’s network: Internet, Intranet, and enterprise-wide connectivity. Its security model utilizes next generation firewall technology, intelligent tracking of connections, and packet modifying engines to offer transparent use of current and emerging Internet technologies. Client applications and protocol stacks operate without modifications.

Features include user authentication, high-speed static and dynamic filters, Web-based management GUI, support for up to six network interfaces, real-time monitoring and reporting, multiple logging levels, and custom alarm notifications. Also, introduced in January of 1997, this firewall includes IPSec-compliant encryption for Virtual Private Networking, native low port NFS support, and secure support for VDO, Vosaic, VXTreme, Internet Phone, and Microsoft’s NetShow.

Its integrated stateful inspection and bi-directional network address translation engines allows this firewall to perform unusual tasks, as discussed below. Also, command line syntax is included in the descriptions, as appropriate, to explain how the CYCON Labyrinth firewall’s filter rules can be applied in each scenario.

Here are some examples of these tasks:

• Intelligent Connection Tracking
• Redirecting Traffic
• Network Address Translation
• Load Balancing of Connections
• Proxying - source address rewriting
• Spoofing - destination address rewriting
• IPSec - encryption

Intelligent Connection Tracking

The CYCON Labyrinth firewall transcends ordinary packet filtering devices by utilizing an advanced connection tracking feature called Intelligent Connection Tracking (ICT). The ICT module is designed to recognize the internal portions of IP packets, enabling the CYCON Labyrinth firewall to "remember" authorized connections for replies. This algorithm heightens security, as it alleviates opening large holes in the filter rules required by other firewalls. These large holes are common areas of security breaches.

The ICT module examines each packet as it is processed by the CYCON Labyrinth firewall, and stores vital information about the packet. The module compares the packet information to the saved state of previously transmitted packets, and permits only those packets that are successfully tested.

The CYCON Labyrinth firewall uses a combination of static and dynamic filter rules to achieve ICT. As traffic crosses an interface, it encounters one of two rule sets: dynamic or static. If a static rule considered Stateful is encountered, the CYCON Labyrinth firewall creates a dynamic rule in the opposite direction, allowing the manipulations performed on the outbound packet to be reversed when the destination system replies. A stateful static rule would be:

ipcycon de0 in spoof ip 0.0.0.0:0.0.0.0 1.1.1.1 spoofaddr 2.2.2.2

Traffic enters the interface "de0" from any source address destined for the host 1.1.1.1. These packets match static rules and trigger the following dynamic rule on the outbound portion of the interface:

ipcycon de0 out proxy ip 2.2.2.2 3.3.3.3 spoofaddr 1.1.1.1

When traffic returns from host 2.2.2.2 destined for host 3.3.3.3, it will match the above dynamic rule and adjust the source address back to 1.1.1.1 so traffic will route normally.

This example illustrates how the CYCON Labyrinth firewall "remembers" the packet state via the dynamic static rule couplet and can successfully route the traffic through the ICT algorithm.

Redirecting Traffic

The address translation features of the CYCON Labyrinth firewall is used to redirect traffic to any host in any network. This feature has a number of real-world uses; examples include: transparent redirection to fault-tolerant systems; diverting scanning programs back to the attacker; and diverting an attacker to a dummy machine specifically designed to trap and log the attacker.

Address translation is accomplished by altering the destination address of the packet to a new location, and altering the source address of the packet to reflect the address of the CYCON Labyrinth firewall. When the reply packets are returned from the receiving host, the address translation process is reversed, and the packets are rewritten and sent to the original sender as though they came from the originally intended destination.

Transparent Redirection to Fault-Tolerant Systems

If a Web server inside your network fails, the CYCON Labyrinth system is used to redirect all incoming Web traffic to an external backup system. This is accomplished by changing both the source and destination addresses in the packets destined for your internal Web server. Assuming your failed Web server’s IP address is 1.1.1.1 and the backup external Web server’s IP address is 2.2.2.2, the exact rules to accomplish this are:

ipcycon de0 in spoof tcp 0.0.0.0:0.0.0.0 1.1.1.1:255.255.255.255 dst-eq 80 spoofaddr 2.2.2.2:255.255.255.255  
ipcycon de0 out proxy tcp 0.0.0.0:0.0.0.0 2.2.2.2:255.255.255.255 dst-eq 80

The second command alters the source address, ensuring that replies from the external Web server are sent through CYCON Labyrinth system and back to the client.

Diverting Scanning Programs

A special variation of the spoof rule redirects unwanted traffic back to the sender. This particular form of the spoof rule is called Rubber and Glue, and is designed specifically to confuse hackers by reversing the connection back onto the hackers system(s). For example, to redirect all unwanted traffic entering your network back to the sender, use the following spoof rule (assuming your network is 1.1.1.0):

ipcycon de0 in spoof ip 0.0.0.0:0.0.0.0 1.1.1.0:255.255.255.0 spoofaddr 0.0.0.0:255.255.255.255   

The source address of these unwanted packets will need to be altered to complete the ruse, as follows:

ipcycon de0 out proxy ip 0.0.0.0:0.0.0.0 0.0.0.0:0.0.0.0

This spoof rule uses the 0.0.0.0:255.255.255.255 as the spoof address. This special form of the spoof address is used to represent the source address of the original packets. The result is that the packet’s destination address is changed to the source address, and the source address is changed to the firewall’s address. All of these address changes are reversed when a reply packet is received.

A more complex version of this rule may be used to redirect traffic to the hacker’s network instead of redirecting traffic to the source address used in the attack. This is accomplished by using a different mask on the spoof address. For example, to redirect unwanted traffic to the hacker’s network, use the following spoof rule:

ipcycon de0 in spoof ip 0.0.0.0:0.0.0.0 1.1.1.0:255.255.255.255.0 spoofaddr 0.0.0.0:255.255.255.0   

This rule will cause the destination address to be replaced with the first three octets of the hacker’s address, followed by the last octet of the original destination. If the hacker is coming from the address 3.3.3.3 and sending packets to 1.1.1.15, then the new destination address would be 3.3.3.15. If the hacker is sending packets to 1.1.1.32, then new destination address would be 3.3.3.32.

Network Address Translation

The CYCON Labyrinth firewall transcends traditional Network Address Translation (NAT) by utilizing full bi-directional network address translation. Ordinary NAT is used to alter either the source or destination address in packet headers. Bi-directional NAT rewrites source, destination, and port identifiers of packets on both inbound and outbound interface traffic. This is extremely useful to route traffic over public networks using private IP addresses or to load balance one URL among multiple Web or FTP servers.

The CYCON Labyrinth firewall performs bi-directional NAT by using special rules to instruct the translation modules to substitute any address "B" for the originating address "A" of a packet. The syntax of the command would appear as follows:

ipcycon de0 out proxy ip 1.1.1.1 165.80.1.1 spoofaddr 192.80.4.3
  |      |   |    |    |    |       | |         |
command  |   |    |    |    |       | |         |
  interface  |    |    |    |       | |         |
       direction  |    |    |       | |         |
     action  |    |       | |         |
         service  |       | |         |
     source     | |         |
destination       |         |
       tag        |
 NAT address

This command alters IP packets leaving the interface "de0" from source 1.1.1.1 bound for destination 165.80.1.1 so that the source address is rewritten to 192.80.4.3. The CYCON Labyrinth firewall has mechanisms in place for proper translations of any reply packets.

The packet leaving the de0 interface is detected by the CYCON Labyrinth firewall as its internal rules are being processed, and is marked for action because the packet originated from host "1.1.1.1" and is destined for the host "165.80.1.1". As 1.1.1.1 is not routable on the public network, the source address must be changed or the sender will get the error No Route to Host.

If a rule matching the source and destination addresses is encountered, the Proxy action occurs, and the spoofaddr address 192.80.4.3 is substituted for 1.1.1.1 as the source address. The packet is modified and routed through the interface.

This is all that is necessary to route the packet out of the network, but any replies to the packets will have 192.80.4.3 as the destination address. Replies to 192.80.4.3 will not be routed back properly into the internal network, so the CYCON Labyrinth firewall rewrites the incoming destination address. The CYCON Labyrinth firewall remembers the original source address and established port of the packet and rewrites packets of expected reply traffic (known as Intelligent Connection Tracking).

When the original packet was processed and the 1.1.1.1 address rewritten, the CYCON Labyrinth firewall created a dynamic rule and applied it to the inbound portion of the de0 interface, noting the original destination address and destination port of the packet. When the firewall encounters traffic from 165.80.1.1 destined for 192.80.4.3 on port 3456 (in this example, a negotiated TCP port), the CYCON Labyrinth firewall knows to replace the 192.80.4.3 destination address back to 1.1.1.1 and route the packet to the internal network. This dynamic rule remains until the transaction is terminated and removed from memory.

The following is a time-lapse view of how and when the packets are rewritten:

• Packet going out to destination

source	destination
1.1.1.1	165.80.1.1

• Source address being rewritten by the CYCON Labyrinth firewall

source	destination
192.80.4.3	165.80.1.1

• Reply packet coming back from outside host

source	destination
165.80.1.1	192.80.4.3

• Destination address being rewritten by the CYCON Labyrinth firewall

source	destination
165.80.1.1	1.1.1.1

This concept of altering source and destination addresses can be applied to either direction (inbound and outbound) and on any individual interface. This provides extreme flexibility for generating rules. Other examples of the applicability include load-balancing one address among multiple servers, directing any inbound web requests to one web server on the DMZ, and sending all SATAN packets back to the originator (causing attackers to attack themselves).

Load Balancing of Connections

The CYCON Labyrinth firewall uses SPOOF and PROXY rules to load balance incoming connections between multiple hosts and/or networks. Load balancing is a process in which packets are redirected to alternating hosts or networks per concurrent connection. This capability allows organizations to use multiple small hosts to serve requests, rather than investing in high-powered systems.

Using standard IP addresses and netmasks, you can construct a single rule that can disperse traffic to four different hosts and networks.

These special rules use a standard rolodex calculation. Each time a connection is established, the firewall directs the connection to the next available address. When the list of addresses has been exhausted, the CYCON Labyrinth firewall returns to the beginning of the list to establish the connection.

Multi-Host Load Balancing

Advertised Address:1.1.1.5

Web Server 1: 1.1.1.1

Web Server 2: 1.1.1.2

Web Server 3: 1.1.1.3

Web Server 4: 1.1.1.4

ipcycon de0 in spoof ip 0.0.0.0:0.0.0.0 1.1.1.5:255.255.255.0
spoofaddr 1.1.1.1 1.1.1.2 1.1.1.3 1.1.1.4

The CYCON Labyrinth firewall is intelligent. Utilizing intelligent connection tracking modules, the firewall creates dynamic rules for each connection and thus "remembers" the correct host.

This technology enables an organization to spread connections to one web address across multiple web servers. Without the CYCON Labyrinth firewall, an organization is forced to use either multiple web servers or inefficient round-robin Domain Name Server (DNS) techniques.

Proxying - Source Address Rewriting

The CYCON Labyrinth firewall offers bi-directional address translation of host and network addresses; that is, the CYCON Labyrinth firewall has the capability to translate addresses in the header portion of IP packets on traffic either entering or leaving a specific interface. This is particularly useful in areas such as host load balancing, using private IP addresses in a public space, hiding internal networks, etc.

CYCON Technologies uses the term Proxy to describe the capability of rewriting the source address of IP packet headers. Proxying IP addresses allows sites to use private or unregistered addresses to connect to the Internet using any publicly routed address, thereby hiding internal IP addresses and eliminating the high cost of reassigning IP addresses when changing providers. Utilizing special rules, the CYCON Labyrinth firewall, upon receiving traffic that matches a proxy rule, rewrites the source address to an individual address, translates network to network, or chose one of four possible network/hosts addresses.

The CYCON Labyrinth firewall utilizes subnetmasks to achieve the host to host, host to network, and network to network address translation. A wild card mask - 0 - can be used in any octet position to cause the firewall to use the existing assumed octet address. If the spoof address is left blank, the address of the interface is assumed.

In the event a site using a private address space wants to access the Internet, the only option in the past was to acquire an IP segment from the provider and visit each host and alter configurations. This is both time consuming and costly. Utilizing the Proxy feature of the CYCON Labyrinth firewall, organizations can get a single Class C address space and proxy all traffic, creating the appearance that it is coming from the provided network. For example:

ipcycon de0 out proxy ip 172.16.1.0:255.255.255.0 0.0.0.0:0.0.0.0 spoofaddr 204.5.16.0:255.255.255.0   

Spoofing - Destination Address Rewriting

The CYCON Labyrinth firewall offers bi-directional address translation of host and network addresses, that is, the firewall has the capability to translate addresses in the header portion of IP packets on traffic either entering or leaving a specific interface. This is particularly useful in areas such as load balancing, using private IP addresses in a public space, hiding internal networks, etc.

CYCON Technologies uses the term Spoof to describe the capability of rewriting the destination address of IP packet headers. Utilizing special rules, the CYCON Labyrinth firewall, upon receiving traffic that matches a spoof rule, rewrites the destination address to one address, translates network to network, or chooses one of four possible network/hosts addresses.

The CYCON Labyrinth firewall utilizes subnetmasks to achieve the host to host, host to network, and network to network address translation. A wild card mask - 0 - can be used in any octet position to cause the firewall to use the existing destination octet address. The following are examples of the rules:

• Host to Host - When the CYCON Labyrinth firewall encounters a packet coming from any host destined for host 1.1.1.1, it changes the 1.1.1.1 address to 2.2.2.2. For example:

ipcycon de0 in spoof ip 0.0.0.0:0.0.0.0 1.1.1.1 spoofaddr 2.2.2.2:255.255.255.255

• Host to Network - When the CYCON Labyrinth firewall encounters a packet coming from any host destined for host 1.1.1.1, it changes the 1.1.1.1 address to 2.2.2.1. For example:

ipcycon de0 in spoof ip 0.0.0.0:0.0.0.0 1.1.1.1 spoofaddr 2.2.2.0:255.255.255.0

• Network to Network - When the CYCON Labyrinth firewall encounters a packet coming from any source destined for any host on the 1.1.1 network, it changes the 1.1.1 address to 2.2.2 network address. For example:

ipcycon de0 in spoof ip 0.0.0.0:0.0.0.0 1.1.1.0:255.255.255.0 spoofaddr 2.2.2.0:255.255.255.0

• Port-based Spoofing - To add another level of complexity, the CYCON Labyrinth firewall also has the ability to distinguish traffic based on port mappings. For example, an internal web server may be used, and all incoming traffic for any local IP address with a destination port of 80 is remapped to the single web server, as follows:

ipcycon de0 in spoof ip 0.0.0.0:0.0.0.0 0.0.0.0:0.0.0.0 dst-eq 80 spoofaddr 1.1.1.1

The CYCON Labyrinth firewall also has the ability to spoof only destination ports and remap only the port. For example, an advertised web server at port 8080 and can be changed to the standard WWW port 80. The CYCON Labyrinth firewall identifies any inbound traffic destined for the internal web server on the original port and rewrites the header to map to the new destination port, as follows:

ipcycon de0 in spoof ip 0.0.0.0:0.0.0.0 1.1.1.1 dst-eq 8080 spoofaddr 1.1.1.1 spoofport 80

IPSec - Encryption

IPSec is a set of standards for Internet security to ensure open standard host-to-host, host-to-firewall, and firewall-to-firewall connectivity. The standard includes two parts: Authentication and Encapsulation. The CYCON Labyrinth system supports these standards as specified in RFC 1825, RFC 1826, RFC 1827, RFC 1828 and RFC 1829.

The Authentication Header (AH) provides a mechanism whereby the sender signs IP packets and the receiver verifies the signature. This helps to prevent alteration of packets and spoofing during transit.

The Encapsulation Security Protocol (ESP) provides a mechanism whereby the sender encrypts IP packets and the receiver decrypts the packets. This helps to preserve confidentiality and privacy and is key to implementing virtual private networks (VPN).

IPSec Filter

The CYCON Labyrinth firewall supports IPSec as specified in the standards RFC-1825, RFC-1826 and RFC-1827. The CYCON Labyrinth firewall allows AH and ESP to pass through the system using security filter rules. AH is treated as an attribute of the protocol field while ESP is treated as a separate protocol. For example, to permit AH signed packets into interface de0, the following firewall command is used:

ipcycon de0 in permit ip-ah 128.33.0.0:255.255.0.0 115.27.0.0:255.255.0.0

The "-ah" attribute can be used on any protocol. When used, a packet must have an Authentication Header within the packet.

To permit ESP packets into interface de0, the following command is used:

ipcycon de0 in permit esp 128.33.0.0:255.255.0.0 115.27.0.0:255.255.0.0

The ESP protocol matches all encrypted packets.

These two methods only permit packets in and out of interfaces. Concurrently, the CYCON Labyrinth firewall also functions as an IPSec gateway. Using the following features, it is possible to authenticate and/or encapsulate communication to and from the firewall as well as to and from hosts on networks via the CYCON Labyrinth firewall.

IPSec Gateway

The CYCON Labyrinth firewall uses two versions of a special security key system to control the AH and ESP mechanisms within the firewall. As such, the CYCON Labyrinth firewall can be configured to sign packets (AH) on behalf of the client system, and/or check the AH signature of packets entering the network. Furthermore, the CYCON Labyrinth firewall can encrypt and decrypt communications between hosts or networks communications through the CYCON Labyrinth firewall. This is accomplished by configuring the encryption, decryption, and authentication algorithms, keys, and addresses with the spi command.

When the CYCON Labyrinth firewall is functioning as an IPSec gateway, an additional set of attributes is available for the ipcycon rules. These attributes are set for inbound rules when a packet is successfully authenticated or decrypted. Likewise, these attributes force authentication and encryption when used on outbound rules. For example, a packet decrypted by the CYCON Labyrinth firewall will match the attribute "-via_esp". To accept decrypted packets through the de0, the following command is used:

ipcycon de0 in permit ip-via_esp 10.9.0.0:255.255.0.0 129.2.0.0:255.255.0.0

To force encryption on communications through the de0, the following command is used:

ipcycon de0 out permit ip-via_esp 10.9.0.0:255.255.0.0 129.2.0.0:255.255.0.0

Likewise, the "-via_ah" attribute may be used to match properly authenticated packets or force authentication headers to be added to packets.

Common Use

The most common mode of operation is to support Virtual Priave Networks (VPN). In this mode, two or more LANs communicate with eac other over public networks (e.g., the Internet) and maintain their security by encrypting all communications between these networks. In this mode, the CYCON Labyrinth firewall resides between the LAN and the public network. The system encrypts all traffic from the LAN before it is passed over the public network to another LAN. The system also decrypts all traffic entering the LAN from the public network. As a result, the computers on the LAN do not have to support encryption. Instead, they communicate as they would with any other system, and the CYCON Labyrinth firewall does all the work transparently to the users.

The next common mode of operations supports access to private LANs via public networks by remote users. In this mode, the remote user will use an IP stack that support the IPSec standard. If the user’s IP address dynamic, then a third-party authentication is needed to identify the user, the IP address and the encryption keys needed for the session. If the user’s IP address is static, then a weaker authentication method could be used. Once the remote users is authenticated, all traffic in and out of the LAN to and from the user’s address is encrypted and decrypted. This protects sensitive information from sniffer attacks while it traverses the public network.

Protection of Attached Networks and Hosts

CYCON Labyrinth firewall intercepts, examines, decides, and either blocks or permits IP traffic passing between the protected and unprotected networks. CYCON Labyrinth firewall blocks or permits those traffic flows based on the rules that the firewall administrator creates.

Blocking and permitting of network traffic is based on CYCON Labyrinth firewall’s ability to examine packet headers, compare the information against filter rules, and take an appropriate action. If the packet’s header information does not directly apply to a permit rule, the packet is dropped. In addition, the stateful inspection module remembers outgoing connections and only allows the expected replies of permitted connections back through the firewall. CYCON Labyrinth firewall can perform the following actions on packets:

• Permit - permits the packet and routes it to the appropriate interface;
• Deny - denies the packet and sends an appropriate ICMP message back to the sender;
• Drop - drops the packet with no reply message;
• Track - permits the packet and creates a dynamic rule to permit expected replies;
• Proxy - rewrites the source address of the packet with either the address of the firewall or a range of user specified IP addresses; and,
• Spoof - rewrites the destination address of the packet with either the address of the firewall or a range of user specified IP addresses.

The proxy and spoof actions can redirect packets to any host on the network or on the Internet.

CYCON Labyrinth firewall protects against network spoofing with one simple rule. The filter rule will not accept packets originating from the external interface that contain source addresses that match any internal IP addresses. In addition, all source routed packets or IP fragments are dropped.

CYCON Labyrinth firewall supports standard username and password authentication and 128-bit encrypted S/KEY (MD5) authentication. Inbound and outbound authentication is performed via an embedded technology called "VISA."

The firewall administrator maintains access lists of users and groups. A user must authenticate with the authentication server (which runs on the firewall, but optionally can run on a dedicated machine) before access is permitted. Upon successful authentication, the "VISA" system creates a dynamic rule permitting access for the user as defined in the access lists.

Any possible access rights are predefined by the firewall administrator and can be set to expire after a predefined time has passed. It is possible to allow only certain types of access (e.g. Web, Telnet, ftp) to one group of users while allowing a different type of access (e.g. Archie, gopher, NFS) to another group. The "VISA" system is flexible enough to receive authentication requests from third-party servers, such as DHCP and WINNS servers.

CYCON Labyrinth firewall supports temporary and timed rules. These rules allow security policies that prevent certain protocols during specific times. An organization may want to restrict outbound Web access to non-business hours, or only during lunch time.

Protection of Individual Hosts

No client-side modifications of software are necessary to provide host-to-firewall authentication. Inbound and outbound access can be configured to be completely transparent, require authentication for each session, or require authentication which is usable for a predefined period of duration.

As discussed above, the incorporation of IPSEC standards in CYCON’s Labyrinth firewall enables the support of full featured peer-to-peer encrypted traffic by any third-party mechanism, either software or hardware. The IPSEC standards implemented provides fully compliant Virtual Private Networking (VPN) technology for net-to-net, host-to-net, and host-to-host connectivity.

Systems Requirements

Hardware Requirements:

• Intel Pentium or Intel 486 (Pentium recommended), 100 MHz minimum for active 10 MB Ethernet, or 166 MHz minimum for 100 MB Ethernet
• 16 MB RAM minimum, 32-64 MB RAM for active Ethernet (each rule [static or dynamic] requires 128 bytes)
• 1 GB HD (IDE or EIDE) for typical sites (intensive logging requires more space and may degrade performance)
• CD-ROM (IDE recommended)
• 3.5" Floppy drive
• Mouse (recommended for initial load and setup)

NetGuard’s Guardian Firewall System - MAC Layer Stateful Inspection

NetGuard Ltd. is a software company specializing in security solutions for corporate networks attached to the Internet. The Guardian Firewall System, the company’s first product, was released in 1995 and was acknowledged world-wide as a leading firewall product. The Guardian was the first firewall designed to operate on the popular Windows NT platform, and is recommended by Microsoft as a Windows NT solution .

Guardian Firewall software has won the British EMAP Networking Industry Award 1996 as "Internet Product of the Year". The judges described the Guardian as "...a sensibly thought-out package, which is easy to implement and manage...the Guardian takes a refreshing look at problems of implementing Network security..." NetGuard Ltd. is a subsidiary of LanOptics Ltd. a leading supplier of hubs and networking products. NetGuard takes full advantage of LanOptics’ large customer base and field-proven experience in the network environment to provide high quality and efficient. Figure 14.13 is a screenshot of NetGuard’s Web site, showing the awards and certification of this product.

Note: For more information, contact NetGuard Ltd, via e-mail, info@ntguard.com, or visit their Web site at URL http://www.ntguard.com/. You can also contact their headquarters at 2445 Midway Road, Carrollton, Texas 75006, Tel: (972) 738-6900 - Fax: (972) 738-6999.

According to NetGuard’s press release of August, 1997 (http://www.ntguard.com/newlan.htm), GUARDIAN Firewall software was named "The Best of LAN Times" in the magazine’s Aug. 4 review of the industry’s leading Windows NT-based firewalls.

Guardian was designed to enable you to easily and accurately establish comprehensive security strategies and manage on-going corporate Internet access.

Guardian firewall is basically an Internet Control and Firewall software that protects the private network against sabotage, unauthorized information access, intrusions, and a wide range of threats initiated from the Internet. Guardian is certified by NCSA.

Guardian’s firewall architecture is based on the unique MAC Layer Stateful Inspection that makes it immune to Operating System security leaks. It is available for Windows NT server and workstation operating systems.

The developers of Guardian, NetGuard, are a leading provider of advanced Internet and Intranet Security and Productivity products and is the first company worldwide to offer Internet Productivity Monitoring and Bandwidth control capabilities.

A Unprecedented Internet Management Tools.

NetGuard, besides being an effective user-friendly firewall System offers Network Administrators unique Internet Access Control Tools. Much has been said throughout this book, and everywhere in the news, about the hazards involved in connecting to the Internet, and indeed the issue of secured Internet connectivity has been the prime concern of network administrators in recent years.

The Firewall Market evolved in order to give a satisfactory answer to Internet security issues and NetGuard’s Guardian, winner of the EMAP networking Industry Award under the category "Internet Product of the Year", plays a major hole in setting the standards for Internet security. Thus, Guardian 2.1 ordinates and facilitates the task of Internet Connectivity Management, offering Network Administrators a variety of powerful management tools and comprehensive inside information in real-time. The following sections describe some of the most relevant features and tools provided by Guardian

Visual Indicator of Enterprise-Wide Agent Activity:

Figure 14.14 shows Guardian manager screen, one of the powerful tools available with Guardian. Through it, you’re able to effectively manage the firewall, including analysis of bandwidth allocated, as shown on figure 14.15 and more,a s the following sections describes.

Another useful tool is the Agent Icon, as shown on figures 14.16 and 14.17, which in its minimal capacity format enables you to receive comprehensive visual indication of the overall activity by viewing on the same screen the activity of as many Agents as he/she chooses.

Extended Gateway Information

Guardian also provides a comprehensive interface to gather extended gateway information through an enlarged Agent Icon, as shown on figure 14.18. As you can see on figure 14.18, the interface provides gateway Information on:

• Total bandwidth available
• Total bandwidth consumption
• Number of connections
• Number of active users, and
• Total number of users

Activity Monitoring Screen

The Activity Monitoring Screen of Guardian allows auto detection of active users. Every User is represented by an icon which functions as an activity indicator, as shown on figure 14.19. The green computer screen indicates an active user and the blue one a non-active user.

Enhanced Activity Monitoring Screen:

The Activity Monitoring Screen of Guardian, as show on figure 14.20, can be configured to show additional user activity information if necessary, which includes:

• IP address and name (if assigned)
• Number of active connections
• Number of bytes received and sent
• Actual bandwidth allocation for each user
• Type of service in use

Monitoring User’s Connectivity

Users connectivity can be monitored with Guardian by using the connection monitoring screen, as showing on figure 14.21. By selecting a user icon on the Activity Monitoring Screen you are able to monitor a "real-time user connection monitoring" window which shows the following information about the user’s active connection:

• Destination IP address and name
• Type of Service in Use
• Number of bytes received and sent
• Elapsed time for this connection
• Bandwidth allocation for each session

The Connection Monitoring Window introduces two new administrative functions:

• Allows the Network Administrator to close an active connection for a predefined period of time
• Allows the Network Administrator to create rules which determine the conditions under which a user operates.

Firewall Strategy Wizard

The Guardian’s firewall strategy wizard, as shown on figure 14.22, has two main functions:

• To assist you in creating a basic set of security strategy rules which serve as guidelines for a corporate security strategy. These guidelines rules in themselves can provide adequate security for the Network.
• Or, if you want to benefit from the more advanced features of the system, you may opt to develop a unique strategy rules using the firewall strategy editor.

Also, the Guardian Strategy Wizard has a tutorial function as well, which helps clarify the process of creating strategy rules and paves the way for independent creation of complex security strategies.

WAN Adapter Support

Guardian can also be configured to work on WAN adapter connected to the Internet. The additional adapters on which an agent can be installed such as modems, ISDN and Frame Relay adapters can be used and installed on any NDIS compatible LAN or WAN adapter.

In many cases this new feature can eliminate the requirement to install a router, as shown on figure 14.23.

Also, as shown on figure 14.24, NetGuard has added to Guardian the capability to define several class C networks. When defining a NAT strategy, looking at the example below, two rules will be defined:

• Our network-1 - Global Network-1 ( 1st class C network)
• Our network-2 - Global Network-2 ( 2nd class C network)
• Our network-1, Our Network-2, Global Network-1, Global Network-2 are networks defined in the Network Object dialog box.

Logoff Command on Authentication Client

While enabling authentication for users, Guardian enables requires the user to be assigned a time period to logon and work, as shown on figure 14.25.

This process is executed while setting an Authentication client, In the firewall strategy, when entering relevant Action for the user, where the total access time that the user can be logged on (Authenticate with an Access for) must be entered, as shown on figure 14.26. The interface also has a mechanism to control spoofing attacks, as shown on figure 14.27.

Figure 14.27

Guardian enables you to specify a list of networks to be checked for spoofing attempts

CyberGuard’s CyberGuard Firewall - Hardening the OS

CyberGuard Corporation is dedicated to providing the strongest, most comprehensive Internet, intranet and electronic commerce security solutions for organizations with enterprise-wide data networks.

CyberGuard Firewall is a multi-level secure computer that resides between internal networks - or between an internal network and the Internet - to provide a single secure connection point through which all data must travel. The firewall screens and filters all traffic to and from any public network before allowing it to pass. To eliminate the possibility of data theft or damage, unauthorized attempts to communicate with the internal network are logged and blocked.

The CyberGuard Firewall Release 3 is now expanded to run on Intel boxes. CyberGuard Firewall features a lower cost software-only entry-level option for departmental and remote office security solutions. CyberGuard Corporation claims to provide the world’s most secure firewall on the Intel platform, also allowing you to integrate the firewall with industry-standard off-the-shelf hardware.

CyberGuard Firewall’s Release 3 is an off-the-shelf software solution comprised of a trusted UNIX-based operating system, integrated secure networking software and a Remote Graphical User Interface (GUI) Manager.

This latest release (version 3) combines packet filtering and application proxy security in a solution that can be customized to allow two-way, incoming-only or outgoing-only communication while blocking high-risk commands. CyberGuard delivers high performance, high throughput, enterprise-wide security applications.

Note: For more information, contact CyberGuard Corp, at 2101 W Cypress Creek Road, Fort Lauderdale, FL 33309, Phone: 800.666.4273 or Phone: 954.973.5478 - Fax: 954.973.5160. You can also contact them via e-mail at E-mail: info@mail.cybg.com or at the URL http://www.cybg.com

The Trusted Operating System

CyberGuard’s integrated suite of secure firewall components gives you the highest degree of protection against attacks. In a typical firewall solutions, if an attacker penetrates the firewall application, the unsecured operating system can be accessed and penetrated.

With the CyberGuard Firewall solution, the operating system has been hardened with extra security measures, as shown on figure 14.29, so unauthorized users or requests can not penetrate the O/S and the network. The secure operating system and secure networking software are based on multi-level security that restricts access to information based on the sensitivity of the information and the access authorization of system users.

The underlying operating system and networking software are designed for demanding security environments. The high performance operating system has the ability to process high levels of throughput without time-consuming failures. CyberGuard Firewall technology can be utilized with your remote offices to operate secure enterprise-wide mobile security applications, secure database applications and access controls.

CyberGuard claims to be the strongest enterprise security solution available because it is built on a secure operating system that utilizes an extension of multi-level security called Multiple Virtual Secure Environments (MVSE), as shown on figure 14.29 above. MVSE matches data access to user privileges, preventing theft or unauthorized access to highly sensitive data via networks at lower levels of security.

This unique capability, Multiple Virtual Secure Environments (MVSE), allows a single physical network to be divided by security level into multiple virtual networks. Simultaneously, customers can divide their physical data servers into multiple virtual data servers, each with a unique level of security. MVSE ensures that the data at a given level of security only travels over networks at the same level of security. MVSE technology recognizes the need for protection of two separate corporate assets - the data and the network. Contemporary firewalls generally protect the network but not the data traveling across it. The CyberGuard Firewall is the only firewall to protect data at all enterprise levels.

MVSE’s capacity to create over 200 virtual networks/servers from a single network/server provides the flexibility and growth potential the your company may need. CyberGuard’s unique Multiple Virtual Secure Environments also provides a secure, cost-effective, multiple network implementation while extending security coverage to data traveling over the network.

Intuitive Remote Graphical User Interface (GUI)

The CyberGuard Firewall 3 on the Intel platform offers a Remote Graphical User Interface with an optional remote feature that allows you, as an administrator, to centrally control and monitor multiple CyberGuard Firewalls. This capability significantly lowers the cost of firewall administration by simplifying administration tasks and eliminating the need to have multiple firewall security administrators.

This innovative feature provides an integrated graphical environment for setup, configuration, monitoring and reporting. Based on the X Window System and OSF/Motif, the system hides internal mechanics from the user while presenting an easy-to use, intuitive interface. All features are configurable through the GUI. The online help includes window-level context-sensitive information, a table of contents, "how-to" tasks and a glossary, as shown on figure 14.30.

Dynamic Stateful Rule Technology

Security decisions made on a machine without a trusted O/S are inherently insecure. Part of CyberGuard’s strong security approach is its dynamic stateful rule technology that extends common packet-filtering (as shown on figure 14.32) capabilities. Figure 14.31 shows the proxy configuration screen of CyberGuard.

CyberGuard Firewall monitors each connection to ensure that all network traffic from the client or server adheres to the network security policy and network protocol. The dynamic stateful rule technology of CyberGuard works with all IP network traffic, including UDP and ICMP and split DNS system, as shown on figure 14.33. Unlike other firewalls on the market today, CyberGuard’s secure solution is not limited to TCP traffic. With dynamic stateful rule technology, CyberGuard Release 3 on the Intel Platform can identify network attacks such as IP spoofing and hijacking.

Further, CyberGuard establishes unique dynamic stateful rules for each new connection to or from the firewall, even if multiple connections are between the same client and server. The dynamic stateful rules reflect the state of the connection at any moment in time. Each connection has a unique dynamic stateful rule allowing CyberGuard to monitor the status of the individual connection and enforce its connection-specific security policy. Any packets received by the firewall that do not match are discarded as invalid, and alarms are tripped, as shown on figure 14.34. At the conclusion of each session, CyberGuard Firewall dismantles the dynamic rule to prevent hijacking of the connection.

Certifiable Technology

The CyberGuard Firewall Release 3 is designed by the same team that created the hardware/software CyberGuard Firewall solution (Release 2.2) with an operating system and integrated networking software that have been evaluated at the B1 level of trust by the National Computer Security Center (NCSC) and certified by the National Computer Security Association (NCSA). The CyberGuard Firewall Release 2.2 was also tested in by Celar in France and is the first firewall solution to undergo ITSEC E3 evaluation in the United Kingdom.

This firewall, for Intel platform, is offered in three configurations:

• An entry-Level Option, supporting 50 users or less;
• A workgroup Option for 51-250 users; and
• An enterprise Option which has unlimited user support.

With CyberGuard Firewall 3, both Pentium and Pentium Pro processor systems (single or dual processor configurations) come with the same high throughput, scaleability and flexibility of previous versions of CyberGuard. An easy-to-use remote graphical user interface (GUI) manager allows system administrators to configure and manage the firewall from both remote and local sites. Figure 14.35 shows the basic architecture design of CyberGuard.

Systems Requirements

The following is the recommended systems requirements for configuring CyberGuard:

• Pentium and Pentium Pro processor systems (single and dual processor configurations)
• 32MB local memory
• 2 Ethernet connections (with optional additional independent connections)
• UNIX SVR4 compliant
• 2GB hard disk
• 17-inch color monitor
• 4mm DAT backup medium
• High resolution super VGA video interface
• Tower enclosure (or optional rack-mountable chassis)
• Optional encryption (U.S. and international)
• Optional WebTrackTM Internet-access tracker and controller

Raptor’s Firewall - An application-level Architecture

Founded in 1992, Raptor Systems is a leading company in integrated firewall security management software and services. Based on an application-level firewall architecture, the Eagle family comprises a suite of modular software components that provide real-time network security for Internet, workgroup, mobile computing, and remote office domains within the enterprise. The Eagle family, when used individually or as part of an integrated network security management system, addresses the need for network security in large and small companies. Eagle runs on Sun Microsystems, Hewlett-Packard, as well as Windows NT workstations. Figure 14.36 shows a screenshot of Raptor’s Web site.

Note: For more information of Raptor’s Eagle family of firewalls, contact Raptor Systems, Inc., 69 Hickory Drive, Waltham, MA 02154, telephone 800-9-EAGLE-6 or 617-487-7700, Fax: 617-487-6755. You can also reach them via email at info@raptor.com.com or on the Web at URL http://www.raptor.com/

Enforcing Security at All Levels of the Network

Comprehensive security is a key strength of Raptor’s Eagle family firewalls. Industry experience shows that of all attacks, the most damaging are those that rely on application data streams. Attacks at this level, as seen throughout this book, often go undetected by stateful packet filters, which only examine the protocol headers of packets at the network layer. Circuit level gateways are also vulnerable, since they lack the ability to examine application level data.

The Internet represents only one domain that must be secured. Every enterprise - whether newly emerging or an established multinational - has security needs that extend beyond unauthorized access over the public network.

Securing confidential data among and between workgroup LANs is a growing concern, see figure 14.37. An executive would never send an employee’s salary review to human resources in an unsealed envelope. Nor would an engineering team leave product development plans on the table. A prospect list in unauthorized hands could mean disaster for quarterly sales. When that same data sits unprotected on a PC or within a server, however, it is susceptible to privacy breaches that would never be allowed in a "paper" world. It is common knowledge that over 85% of all computer crime is perpetrated by individuals who are authorized to use the systems they are working on. Hence, desktop PCs and workgroup LANs must be secured from "unauthorized" users within an organization as well as from Internet users.

Working at all seven layers of a network-based application gives the Eagle access to all contextual information needed to make authorization and authentication decisions, including:

• The specific type of application used
• Specific application commands and data allowed or disallowed
• The users, groups, or times of use allowed for the service
• Time and date ranges
• Authentication information

Based on this information, the Eagle makes complex security decisions. It automatically enforces service restrictions, issues alerts via email or beeper, SNMP trap or client program, and compiles a comprehensive log on all connections-whether they are allowed or not.

To derive only a portion of the information available to the Eagle, packet filtering firewalls must evaluate each IP packet individually, capturing state information on-the-fly. This makes these systems particularly vulnerable to attacks that exploit packet fragmentation and reassemble operations. The Eagle’s architecture makes it invulnerable to such attacks.

Raptor defines five domains of network security to promote an integrated approach to protecting the enterprise:

• Domain 1: Internet Security - To protect networks exposed to unauthorized Internet access, as shown on figure 14.38, Raptor Systems offers the flagship Eagle firewall. Designed as the foundation on which any enterprise solution can be built, Eagle is a flexible, application-level firewall that secures bi-directional communications through the public network. It includes EagleConnect virtual private networking, a powerful, real-time network security management facility with intuitive GUI, suspicious activity and alert monitoring, encryption and multiple types of authentication and proxy software to foil IP spoofing attacks. Multiple hardware platforms are supported including Sun Microsystems, Hewlett Packard and Windows NT on Intel and DEC Alpha platforms.
• Domain 2: Workgroup Security - Raptor Systems provides two solutions to protect sensitive data that reside at a workgroup level, as shown on figure 14.39. The EagleLAN is a departmental firewall that integrates seamlessly with the Eagle. If one department attempts to access another department’s data without authorization, the network administrator will know immediately. As with our Eagle firewall, real-time alarms let administrators catch hackers in the act. And for desktop security, EagleDesk resides on a user’s PC, behind the firewall, to provide secure communications between the PC and any other authorized destination inside or outside the enterprise.
• Domain 3: Mobile User Security - The combination of portable PCs, telecommuters, and virtual offices opens the door to data access anywhere in the enterprise from anywhere in the world through public and private networks. To protect this newly-emerging mobile portion of the enterprise, Raptor Systems provides EagleMobile (see figure 14.40). An option to the Eagle firewall, EagleMobile can be installed by a non-technical user on any portable or off-site PC for additional password protection and encryption between their PC and an Eagle firewall.
• Domain 4: Remote Site Security - To secure communications among corporate headquarters, corporate divisions, and branch offices (see figure 14.41), Raptor offers the EagleRemote firewall. EagleRemote includes all of the superior security features of the flagship Eagle firewall for remote sites that must use the public network to communicate with other enterprise "satellites." The EagleRemote is configured and monitored by the Eagle firewall. This allows the network administrator to have complete control from one central location back at the enterprise.
• Domain 5: Integrated Enterprise Security - As shown on figure 14.42, Raptor has designed its products as a suite of modular software components that can interact seamlessly with each other using a common management and monitoring capability. This building-block approach to security management lets companies change and grow their network security systems without changing their underlying security strategy. Central to this integration is Raptor’s EagleConnect virtual private networking technology, which transparently manages the connections among network security points within the enterprise.

Eagle’s strong, rules-based defense (see screenshot on figure 14.43) is very impressive. Packet filtering firewalls authorize passage of IP packets on a first fit rule matching basis. As packets enter a router or filtering firewall, the device compares each packet in turn against a set of match conditions (filters).

By default, the device accepts the first fit to these conditions to allow or deny the packet. Herein lies the problem: filtering rules are inherently general and highly order dependent. This means that the first match triggered may allow a connection that would be denied by a subsequent comparisons. Thus, whether a packet gets into your network may depend on the way you order of the rules, rather than on the rules themselves. This complexity makes misconfiguration an ever present possibility.

Therefore, with the Eagle Firewall,

• All connections are denied unless explicitly permitted
• Automatic suspicious activity monitoring
• Comprehensive logging for all connections
• Fine grained access-controls and service restrictions
• "Best-fit" Rule management

The Eagle’s best fit approach is simpler, tougher, and easier to manage. To begin with, the Eagle denies all network traffic except for that which is explicitly allowed. Second, the rules the Eagle applies are not order-dependent, so it always chooses a rule specific to the connection attempt at hand. And to make sure the rule chosen is specific, the Eagle always applies conservative best fit criteria to allow or deny a connection. And if no rule meets its best fit criterion, the Eagle denies the connection. This approach to rule management by the Eagle firewall allows a firewall administrator to concentrate on the creation and management of a security policy rather than on the management of the firewall itself.

Reliance on Dedicated Security Proxies

The Eagle uses secure application proxies to examine each attempt to pass data in or out of your network. As discussed throughout this book, proxying connections provides the strongest safeguard against network intrusion. These proxies provide:

• Protection against application level attacks
• Automatic hiding of all internal IP addresses and their associated systems
• Strong and weak user authentication
• Comprehensive logging of all activity
• Fine grain control of direction of service, e.g. FTP put versus get.

The Eagle’s secure proxy architecture presents a virtual brick wall between your networks and the unsecured world of the Internet. This wall protects you in two ways:

1. Only connections explicitly allowed are permitted. This greatly simplifies configuration. This in turn virtually eliminates security breaches arising from mismanagement.
2. Your networks are not only protected but hidden from the outside world. This bars hackers from probing for insecurities in your internal systems, and safeguards the critical information needed to mount an attack.

Using Raptor’s Firewalls Eagle Family

Eagle is very easy to set up and use. Its richness of function and flexibility are married to a graphical user interface that makes configuration and monitoring easy.

Graphical Policy Configuration

The Hawk graphical user interface segregates all aspect of your security set-up into discrete areas of function. You use one window to write rules, and others to define internal and external systems, specify firewall users, create authentication templates, and perform other functions. This makes the process of rule authoring straightforward, and the rules you write easy to understand. The Eagle’s monitoring window gives you a birds-eye view of all connection attempts into your network. Its log file window displays statistical information on all connections at a glance.

According to Raptor, the Eagle is the only product in the industry with graphically configurable service proxies for all key services, including:

• HTTP (Web browsing)
• SMTP
• TELNET
• GOPHER
• SNMP (due on next release, by mid-November of 1997)
• FTP puts and gets (file transfer)
• DNS (name resolution)
• RealAudio
• Secure Remote Login (remote management)

In addition to supporting commonly used applications with out-of-the-box proxies, Hawk makes it a snap to specify additional applications.

Consistent Management- Locally or Remote

Whether you are managing the Eagle locally, or via an encrypted Internet link, Hawk presents you with the same management interface. So there is never any doubt about whether the policies you put in place are really in force.

One of the key requirements for administrators is to be able to easily and securely gain access to the host operating system that the Eagle runs on top of. Raptor provides a Secure Remote Login (SRL) capability that allows administrators to remotely gain access to the operating system for configuration and maintenance. SRL establishes an encrypted and authenticated TELNET session to the firewall system.

The Eagle allows you to enforce policy decisions for end users, while making it easy for them to get their jobs done. Whether this entails use of Web browsers, file transfer, or remote login to selected systems, the Eagle’s presence is unobtrusive. In most cases, users are not even aware of the Eagle’s operations.

The Flexibility to Allow "Transparent" Access

While it presents an unbreachable wall to unwanted users, the Eagle provides flexible access to users you need to accommodate. In fact, you can configure the Eagle so that users will not be aware of its presence.

Usually referred to as transparency, this level of access allows users to "see" and (apparently) connect directly to certain systems. These connections are still proxied by the Eagle, which continues to carry on extensive logging and alerting operations. So even though your users may be unaware of it, the Eagle is still watching the store.

Address Redirection

At times, you may need to allow users to access data on certain internal systems, and still conceal these systems’ identities and addresses, as showing on figure 14.47. Examples of this could include customer information databases or commerce servers: resources that you must both protect, and provide access to from the outside world. The Eagle can be configured to present one or many public IP addresses which can then be mapped or redirected (on a per service basis) to systems behind the firewall with different (and hidden) IP addresses. A common use is to map multiple public IP addresses to multiple and different Web servers behind the firewall.

As for performance, independent lab tests performed at the National Software Testing Laboratories (NSTL) confirm the Eagle as the fastest transaction processing engine of any tested.

The Eagle’s application proxy architecture is the key to its great performance. Since the Eagle authorizes connections at the application-level, it has access to all contextual information on each connection attempt. As a result, the Eagle only needs to evaluate each connection once. No additional checking is needed to proxy packets securely. This delivers a big performance advantage over other approaches.

Fine-grained control of VPN Tunnels

The ability to apply packet filters within configurable Virtual Private Networking (VPN) tunnels, as shown on figure 14.44, provides Eagle administrators with fine-grained control of the types and direction of traffic that can be passed between hosts or systems. This control boosts overall network performance by enabling you to specify appropriate levels of encryption for each tunneled application.

The Eagle performs all filtering on the VPN tunnels you establish between trusted systems. All traffic passed between these systems is encapsulated and encrypted by cooperating Eagle systems, as shown on figure 14.46. This ensures the privacy and integrity of the communication. The additional use of packet filters provides an even higher level of security on these trusted tunnels, allowing only certain types of traffic in specifiable directions. Figure 14.45 shows the monitoring of real-time suspicious activity of Raptor’s Eagle family firewall.

Integrated Web Blocking Capability

The Eagle’s integrated WebNOT software gives you the ability to restrict web browsing from sites containing objectionable materials. The service restrictions the Eagle supports give you the power to limit browsing activities in specific, carefully defined ways. This ensures that your organization gets the full benefit of the Internet’s resources, while avoiding the unnecessary risks and performance degradation.

Tip: For more information on WebNOT, check Raptor’s URL at http://www.raptor.com/products/webnot/webnot.htm.

HTTP Service limitations

In addition to the WebNOT blocker, the Eagle gives you the tools you need to limit Web access and content retrieval. Controls available for HTTP rules include:

• Filtering of designated MIME types, including Java applets
• Filtering of file types by extension
• Filtering by designated URL
• Automatic filtering of specific HTTP attacks related to buffer overruns, embedded 8-bit characters and illegal URL formats

Systems Requirements

Raptor’s UNIX firewall is available on Sun Solaris and HP-UX. Now in its fourth generation, Eagle NT provides the same robust security and flexibility of our award winning UNIX variant, tightly integrated with the Microsoft Windows NT platform.

The Eagle supports the broadest range of authentication types in the industry. It’s design makes it easy to combine weak forms of authentication (like gateway password and NT domain) and strong, single-use password schemes in a single rule.

According to Raptor, the Eagle firewall family is also the first commercially available firewall to offer full support for IPSec, including DES, triple DES and RC2 encryption. Additional standards supported include SNMP V1 and V2 traps, and NT Domain, TACACS+ and Radius authentication types.

Milkyway’s SecurIT FIREWALL - a Factory Hardened BSDI Kernel

Milkyway Networks, incorporated in 1994, is a leading global supplier of Internet and Intranet security applications designed to safeguard corporate-wide information. The company’s vision is to provide a single security solution for internetworking, no matter where users or servers are located on the network.

SecurIT FIREWALL is the centerpiece of the Milkyway SecurIT SUITE, the industry’s first bundled suite of security products that leverages the power of Milkyway’s flagship Black Hole technology with a secure, remote access product and a network security auditing tool. Milkyway’s firewall product has been evaluated by the Canadian Security Establishment as an information security product achieving international draft functional specifications and "tested and certified" by the National Computer Security Association in the US. It has also been identified by Network World as the most innovative firewall. Milkyway is the first firewall vendor to incorporate a "factory hardened" UNIX kernel, which experts agree is more secure than other approaches that merely filter out unauthorized Internet addresses or use unhardened operating systems. Figure 14.47 shows a screenshot of Milkyway’s Web site.

Note: For more information, contact Milkyway Networks Corp., 2650 Queensview Drive, Suite 150, Ottawa, ON - CANADA, K2B 8H6 or via their distributor in U.S., North Eastern, 109 Danbury Road, Office #4B, Ridgefield, CT, USA, 06877. By telephone, dial 613) 596-5549 or 800) 206-0922, Fax: (613) 596-5615 or via e-mail at info@milkyway.com and Web site at URL http://www.milkyway.com/

A Bullet Proof FIREWALL

SecurIT FIREWALL acts like a security guard to protect your private network from the Internet, as seen on figure 14.49. But the people at Milkyway know that the security guard itself must be protected to remain effective. Protection is crucial, you do not want your security guard to be attacked while on duty.

To protect the firewall, the SecurIT FIREWALL kernel has been "hardened" to eliminate insecure processes. Thus the firewall is very secure and will stand up to any attack. In fact, SecurIT FIREWALL also monitors for many types of attacks and alerts the system administrator if an attack is in progress. Figure 14.50 illustrates how SecurIT FIREWALL controls and monitors network visibility.

Building a Secure Kernel

For any operating system, the Kernel is responsible for resource allocation, low-level hardware interfaces, and security. The configuration of the kernel dictates the functions that the operating system supports and includes everything from basic functions like hard drive access and video support, to more advanced features such as sound card support. To enhance security, Milkyway also suggests a dual SecurIT FIREWALL setup, as illustrated on figure 14.51, but the secure kernel is one of the main features of SecurIT FIREWALL.

Note: Configuring a Dual SecurIT FIREWALL The following policy is used in this configuration: Inside Network users can access the Private Network transparently: Inside Network users can have an Inside DNS/Mail server or they can access the DNS/Mail server on the Private Network. Similarly, Inside Network users can have an Inside News server or they can access the News server on the Private Network. Private Network users will need user level authentication to access the Inside Network. Private Network users and Inside Network users can access the Internet transparently (or they may need user-level authentication for going through the Outside SecurIT FIREWALL, if so configured by the system administrator). Internet users will need user-level authentication to access the Private Network. Internet users CANNOT access the Inside Network. This policy is a combination of a rule on the Inside SecurIT FIREWALL and a user-base security policy. This policy combination requires that an authorized user from the outside, after having connected to a machine on the Private Network, CANNOT start a session on that machine to another on the Inside Network (even if the user is normally allowed to do so from within the Private Network). Since users who have access to the Inside Network are considered trusted, this policy should not be difficult to enforce. Otherwise, do not allow any incoming sessions to the Inside Network. In this configuration, all the internal users on both the Private Network and the Inside Network still enjoy transparent access and the Inside Network is immune to access to the Internet by a man-in-the-middle attack. The Dual SecurIT FIREWALL configuration provides the ultimate defense against man-in-the-middle attacks to the protected sub-network and allows all users (private and sub-net) transparent access to the internet.

To build a secure kernel for SecurIT FIREWALL, Milkyway started with a standard UNIX kernel for the platform on which SecurIT FIREWALL was to run (a Sun Sparc kernel and a BSDI kernel). Then the kernel was modified to remove all non-essential functions, resulting in a kernel that only supported TCP/IP networking, hard drive access, and similar basic functions on a restricted selection of platforms. The result is a specialized and very secure kernel but with limited functionality.

Functionality was carefully added to support the needs of a firewall. Care was taken to ensure that all functionality that was added was secure. The resulting SecurIT FIREWALL kernel is a very secure hardened kernel that has limited and specialized functionality. In addition, the kernel has also been made untouchable so that it cannot be accidentally modified (and its security compromised) by the administrator.

This limited functionality means that the SecurIT FIREWALL kernel does not support a wide range of devices but support is limited to devices essential to a firewall. As new devices are developed, before they can be supported by the SecurIT FIREWALL kernel they must be evaluated by Milkyway and only added if they are essential and a secure way can be found to support them.

For this reason SecurIT FIREWALL does not support all types of network cards. In fact, support for two network cards was not added to the kernel because the vendors of the cards could not supply Milkyway with drivers that would allow secure support of the product.

SecurIT FIREWALL Kernel Modifications

When designing SecurIT FIREWALL, Milkyway examined the standard kernel and identified seven network functions that can cause security vulnerabilities. To protect against these vulnerabilities, the SecurIT FIREWALL kernel:

• Disables automatic source routing so that the firewall does not route any packets automatically. All packets that are received by the firewall must be authenticated.
• Disables Internet Control Message Protocol (ICMP) redirect functions. If enabled, these functions allow remote users to change routing. Disabling ICMP redirect protects SecurIT FIREWALL from this sort of tampering.
• Disables IP forwarding so that the firewall does not act as a router. All TCP and UDP packets are forced to be processed at the application layer rather than the kernel layer, where the packets can be authenticated.
• Disables communications on the syslog ports. The syslog ports are used by the SecurIT FIREWALL system log and disabling communication on these ports protects the firewall system log from being altered.
• Monitors all 64,000 TCP/UDP ports to detect all connection attempts. No connection is possible on any port until it is authenticated. No other firewall is able to monitor all ports.
• Verifies IP packet direction to eliminate the possibility of an intruder on the Internet masquerading as an internal IP source address. This firewall also verifies the direction of the traffic flow to detect and log all IP spoofing, and masquerading attempts. Milkyway’s firewall also verifies packet direction for all interfaces to the firewall, not just the interface to the Internet (called the insecure interface).
• IP packet absorber functionality has been added, so that the network layer accepts any packets received on any of its configured devices. All packets are forwarded to the kernel layers above the network layer. This permits SecurIT firewall to spoof the originating host into believing that Black Hole is the actual destination machine.

Kernel Security Features are Certified By CSE

According to Milkyway, SecurIT FIREWALL successfully completed an EAL-3 Common Criteria (CC) evaluation from the Communications Security Established (CSE).

The CSE, a Canadian federal government organization, evaluates commercially available information security products under the Trusted Product Evaluation Program (TPEP) to ensure that such products meet stated functional specifications. Thus, the Canadian Security Establishment (CSE) has certified that the Black Hole technology, including the basic secure kernel and all of the additions made to the kernel, function as documented.

Key Management

Key management is one of the most difficult and crucial aspects of providing a usable and trusted virtual private network. The basic problem is how to provide all trusted users with access to up-to-date keys while keeping private keys from being intercepted by people outside the realm of trust.

SecurIT FIREWALL uses the Entrust Public Key Infrastructure (PKI) as a mechanism for authentication and encryption using public keys. This PKI is based on the X.509 standard for authentication and encryption.

Automated key distribution using Nortel Entrust PKI means that once identity is established, distribution of public keys is managed automatically. Key distribution using an X.500 database and Version 3 X.509 certificates can be centrally managed by a third-party key management service or by an in-house key management system.

Automated key distribution provides all SecurIT FIREWALLs on the VPN with easy access to up-to-date public keys for any other SecurIT FIREWALL on the VPN.

Key Management and Certification Service

A third-party key management service, such as Stentor’s OnWatch, uses an Entrust/Server to create an identity for each node of your VPN. The identity includes public keys, which are stored in the key management service’s X.500 public key database. Figure 14.52 illustrates this concept.

When two SecurIT FIREWALLs use Entrust/Session to start a VPN session, they authenticate each other using SPKM. The key management service is also the certificate authority for authentication of the public key. The advantages of using a key management service are the ability to provide the best security possible with a minimum of administration.

In-house Key Management

In-house key management involves creating an X.500 database behind one of the SecurIT FIREWALLs on the VPN. Entrust/Server can be used to create identities and manage public keys in the X.500 database, as shown on figure 14.53. In-house key management can provide virtually the same quality of security (key management and certificate authority) as using a key management service. But keep in mind the operating cost of this, as running Entrust/Server in-house and maintaining an X.500 database is usually an option for larger organizations.

Manual Public Key Management

The key management and distribution systems described previously employ Entrust/Session running on SecurIT FIREWALL and Entrust/Server to provide key management. A third option is to use Entrust/Lite to provide key management and create public and private keys for each SecurIT FIREWALL on the VPN, as shown on figure 14.54.

Entrust/Lite incorporates the standard Entrust features, except that Entrust/Lite does not require an X.500 infrastructure and does not support automated key distribution. Instead, Entrust/Lite creates an address book containing public keys for each SecurIT FIREWALL on a VPN. This address book must be distributed to each SecurIT FIREWALL, and each copy of the address book must be kept up-to-date.

Private Keys

SecurIT FIREWALL supports the use of private keys for data encryption and decryption, as shown on figure 14.55. Note that while a private key system requires very little overhead, it may be difficult to keep private keys for many SecurIT FIREWALLs up-to-date in a reliable and secure manner.

Something Else You Should Know: Ubiquitous Monitoring of All Ports

As mentioned in the section above, SecurIT FIREWALL is the only firewall capable of listening ubiquitously to all ports to detect and report any attempt to communicate with the firewall. SecurIT can intercept any attempt by an intruder trying to gain access to the firewall or the private network being protected by the firewall. When an intruder is detected, SecurIT logs all of the details of the intrusion attempt and alerts the system administrator.

Securely implementing Internet access, Intranets and Extranets is as confusing as ever with a myriad of security technologies, claims and concerns to consider. While "crackers" account for the vast majority of external intrusion attempts, internal incidences account for 70% of all security compromises. Industrial espionage is the most serious threat to a company, though it accounts for a very small portion of detected problems. Therefore, a layered "belt and suspenders" approach is essential for protecting your organization's networked assets. Figure 14.56 shows the fundamental components of corporate security as seeing by Milkyway, as the base for their firewall product development.

Watch for Port Numbers: The Milkyway Way

For a packet of information to be received by a computer communicating across the Internet, the packet must include a port number. The port number identifies the network service required to receive the packet. For example, if a computer is running an FTP network application, it can receive packets containing the FTP port number. If no FTP network application is running, the computer cannot receive FTP packets.

All network applications are assigned a port number. FTP uses port 21. Telnet uses port 23 and so on. There are a total of 64,000 ports. The port number is used by a computer receiving a packet to determine what application or service is required for the packet. If there is a network service running that can receive the packet, the computer can receive information on that port. If the network service is not running, then the computer does not receive information on that port.

A common first step to gaining access to a computer is to run a port scanning program against the computer. The port scanner attempts to communicate with the computer using each communications port and reports back the ports that receive information.

Knowing which ports receive information lets an intruder know what network services can be used to access the computer.

For example, if the port scanner found that the computer was accepting packets sent to port 21, this means that the computer is capable of communicating using FTP. This allows the intruder to attempt to use an FTP program to access the computer or to exploit known FTP weaknesses.

One of the strongest feature I find on SecurIT is that it listens on all ports. Listening on all ports means that this firewall accepts communications on all 64,000 ports, which has two important consequences:

• All ports accept communications
• All attempts to connect to the firewall are intercepted.

As far as I can tell, as I write this section (August 1997), listening on all ports is unique to SecurIT firewall. This is a very important feature, as an effective way to protect a system from unauthorized access is to prevent an intruder from learning anything about the system. As discussed earlier, port scanning normally provides an intruder with exploitable information about a system. However, if all the hacker learns is that all ports are accepting communications he/she is no further ahead. There is nothing to distinguish one port from another. No new information is gained.

Further, any attempt to connect to any port on a SecurIT firewall is recorded by the Logging Facility. The information logged includes the source address of the connection attempt. This information can then potentially be used to determine the source of the attack.

In addition, the Alarm Facility of this firewall continuously analyses logging information and will raise an alarm if compromising activity (such as port scanning) is recognized.

Defending Against Common Attack Methods

As discussed earlier, listening on all ports protects SecurIT FIREWALL, and the networks behind SecurIT FIREWALL, from most attacks. In addition to the broad-band protection offered by listening in all ports, SecurIT FIREWALL has other security features built in to protect against other kinds of attempts to gain unauthorized access.

Buffer Overflow

A buffer overflow occurs when a program adds data to a memory buffer (holding area) faster than it can be processed. The overflow may occur due to a mismatch in the processing rates of the producing and consuming processes, or because the buffer is simply too small to hold all the data that must accumulate before some of it can be processed.

Software can be protected from buffer overflows through careful programming, but if a way to cause a buffer overflow is found, the computer running the software can be compromised. If a user accesses a computer across the Internet and intentionally causes a buffer overflow, the program that the user was running may crash but the user may remain connected to the computer. Now, instead of accessing the computer through the controlled environment of the program, the user may have direct unrestricted access to all of the data on the computer.

Milkyway codes the programs (for example, proxies) that run on SecurIT FIREWALL to stop buffer overflow from occurring. Even if a buffer overflow occurs, the proxy crashes because the memory "box" in which the proxy runs is protected from buffer overflow. Also, when the proxy crashes the user is disconnected because the connection depends on the proxy.

In addition, protecting the memory buffer means that the firewall keeps running and security is not compromised. If a firewall that is not protected in this way encounters a buffer overflow the entire firewall may crash, causing a service disruption.

Trojan Horses Running on the FIREWALL

If you remember, a Trojan horse is a program designed to break security or damage a system but that is disguised as something benign. There is no way to load or run unauthorized applications on SecurIT FIREWALL. Thus a program used to create a Trojan horse would not be able to run.

Spoofing

Spoofing can occur when a packet is made to look like it came from an internal network even though it came from an external one. SecurIT FIREWALL eliminates spoofing by recognizing the firewall interface that specific source addresses can connect to. If a port receives a packet that should only be received at another port, the packet is denied.

Sniffing

Sniffing involves observing and gathering compromising information about network traffic in a passive way. This can be done by any node on a non-switched Ethernet. On non-broadcast media (for example, ATM, T1, 56k, ISDN) an intruder would either have to be in the telephone switches, have physical taps, or easiest, break into any router where the data travels.

SecurIT FIREWALL does not prevent people from sniffing the external network. As a matter of fact, no firewall can prevent that! However, since the firewall keeps external people from breaking into the internal network, this effectively prevents external people from running sniffers on the internal network.

Hijacking

Hijacking a connection involves predicting the next packet in a TCP communications session between two other parties and replacing it with your own packet. For example, hijacking could be used by an intruder to insert a command into a Telnet session. To hijack successfully, an intruder must either make an educated guess about the TCP sequence information, or be able to sniff the packet.

Hijacking is a threat because the intruder can wait for users to authenticate themselves, and then the intruder can take over the authenticated connection. Hijacking of a connection can happen no matter how strong the authentication required to start the connection

Since traffic on the networks protected by SecurIT FIREWALL cannot be seen, and cannot be sniffed, this firewall prevents hijacking attacks on traffic that does not pass through the firewall. Figure 14.57 shows Milkyway’s product family at glance to protect against all the issues discussed in this section. Figure 14.58 shows a screenshot of Milkyway’s site at URL http://www.milkyway.com/prod/info.html, which provides a product information matrix. I recommend you to access this page for additional information.

Systems Requirements

The following is the recommended systems requirements for configuring SecurIT:

• Pentium and Pentium Pro processor systems (single and dual processor configurations)
• 32MB local memory
• 2 Ethernet connections (with optional additional independent connections)
• UNIX SVR4 compliant
• 2GB hard disk
• 17-inch color monitor
• 4mm DAT backup medium
• High resolution super VGA video interface
• Tower enclosure (or optional rack-mountable chassis)

WatchGuard Technologies’s Watchguard Firebox System - Combining All Major Firewall Approaches into a Firebox

Founded in 1996 and based in Seattle, Washington, WatchGuard Technologies' founders and engineers have expertise in network management and firewall technology from previous entrepreneurial ventures, including the highly successful Networx and Mazama Software Labs. WatchGuard Technologies is building on this heritage by delivering next-generation Internet/intranet security products that eliminate the cost and complexity associated with current offerings and feature powerful hybrid firewall technology plus intelligent security management at an affordable price. During late summer of 1997, the company unveiled WatchGuard SchoolMate, the first firewall product intended specifically for use in schools. Based on the low-cost, plug-in-appliance designed for mid-sized corporations, it integrates Microsystems's CyberPatrol filtering software with the WatchGuard Firebox system.

According to WatchGuard Technologies, their firewall product, Watchguard Security System, is the industry’s first network security appliance and Windows-based security management system. It is also the industry’s lowest cost complete firewall solution, and the first to bring high function firewall protection to Microsoft network administrators without extensive UNIX networking expertise.

The WatchGuard Security System is also the first product to Figure 14.59 shows a screenshot of WatchGuard Technologies Web site.

Note: For more information, contact WatchGuard Technologies Labs, Inc. at 316 Occidental Avenue South, Suite 300, Seattle, WA 98104. Tel.: 206/521-8340 and Fax: 206/521-8341. Or you can visit their Web site at URL http://www.sealabs.com

WatchGuard at Glance

WatchGuard offers you all major approaches to firewall design, such as packet filtering, proxies and stateful inspection as many of its competitors, however, with a low cost and easy to use interface. It also adds features not easily available in other similar products, such as inspection of executable content such as Java and ActiveX and the ability to e-mail you with traceroute and finger information.

Basically, the WatchGuard System consists of the WatchGuard Firebox, a network security appliance featuring a Pentium processor, and WatchGuard Security Management System (SMS), software that runs on Windows NT, Windows 95 and Linux workstations.

The WatchGuard "point-and-click" approach makes it very easy to install and configure the firewall. Configuration information is presented on a service-by service basis, allowing you to setup security even if you don’t have extensive knowledge of your network. You only add Internet services you wish to enable, keeping access to a minimum and security to a maximum. Also, WatchGuard’s visualization tools allow you to get a complete picture of your network security land see overall trends and network usage patterns.

WatchGuard has the ability to automatically warn you of security-related events occurring at the firewall. It delivers these messages by e-mail, pager, or custom script to almost any device, computer, or program that you use. It can provide detailed logging of every firewall event or simply record events that you designate to be significant. Thus, you can test for "holes" and see at-a-glance what visitors to your site can and cannot do.

The Firebox itself is a dedicated network security "appliance". It contains a real-time firewall operating system giving you the ability to be up-and-running right out of the box. The firewall operating system does not allow user log-ins and only supports encrypted connections to the Firebox from the SMS software.

As a standalone element, the security appliance is a specialized solution. As such, the WatchGuard Firebox is more reliable than a general-purpose system modified to do the specialized work of network security.

Other advantages associated with the standalone, dedicated nature of the appliance include the following:

• It plugs into the network and is operational within minutes. As a dedicated device rather than a general-purpose computer, it is simpler to boot up and run.
• It is managed from an ordinary desktop Windows 95 or NT PC that is used for other functions, yet it serves any network-PC, Macintosh, or a cross-platform environment.
• Its specific configuration makes it easier to verify security performance. In a general-purpose OS, a stew of network drivers, devices, and third-party software produces unbounded and sometimes undetectable security risks.
• Its exclusive focus on security ensures that it does not degrade the router or the network server's performance.

WatchGuard is built around the basic premise that unless an external user has authorization for a specific activity, then that external user is denied an inbound connection. The second premise is WatchGuard’s ability to enforce security even if your network fails. It ensures that your site and the SMS software itself are not under attack by intruders. If WatchGuard suspects that its own software has been tampered with, it shuts off access to your network before an intruder can circumvent its protective screen.

WatchGuard Security Management System

As illustrated on figure 14.60, WatchGuard consists of two major components, the Security Management System (software) and the Firebox (hardware). The Security Management System (SMS), as shown on figure 14.59a, configures and monitors the Firebox and performs logging and notification of firewall events. SMS provides a secure gateway or firewall between any combination of IP hosts and IP networks. It can act in the following ways:

• InternetGuard, to protect corporate networks and bastion hosts from the Internet and to define company-level security
• GroupGuard, to protect departmental systems, restrict information and packet f