© 1997 The McGraw-Hill Companies, Inc. All rights reserved. Any use of this Beta Book is subject to the rules stated in the Terms of Use.

Chapter 14

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.

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.

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.

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.

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

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.

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

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.

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 syst