previous  next  Title  Contents  Index          Previous     Next      Top   Detailed TOC  


Firewalls: a technical Overview

 

Table of contents:


Summary: A quick guide to firewalls

Introduction

Firewalls are a vast and complex subject, of which a limited overview is presented here. The reader is referred to [fire2] and [fire1] (see references section below) for fine detail. All networks should be divided up into security domains, whereby these domains are isolated from one another by Firewalls, hubs/routers or software (VPNs). Classical Firewalls may be eventually eclipsed by Virtual LANs, in which case Firewalls become those machines that connect two VPNs. Either an entity is required that control access between two domains of different security policies.

This section concentrates heavily on Internet Firewalls, although a Firewall can (and should) be used between any two networks of different security levels / domains. 

What is a Firewall?
Definitions:

A packet filter stops or allows packets to flow between two networks according to predefined rules. A simple packet filter is a router. It works on the network layer of the OSI model.
A proxy is a small, simple program which allows/disallows access to a particular application between networks. It works on the Application layer of the OSI model.
A Firewall is a system (or network of systems) specially configured to control traffic between two networks. A firewall can range from a packet filter, to multiple filters, dedicated proxy servers, logging computers, switches, hubs, routers and dedicated servers.
A gateway or bastion host is a secured computer system that provide access to certain applications. It cleans outgoing traffic, restricts incoming traffic and may also hide the internal configuration from the outside. 

Why use a Firewall?

How does a Firewall protect?
A Firewall normally includes mechanisms for protection at the:

PROBLEM: Many Internet applications are not "proxy aware" (e.g. Microsoft NetMeeting) and use a combination of ports that can be different for each connection. It is very difficult to allow these protocols to (securely) traverse a firewall. There seems to be a few practical solutions:

Reference Documentation

Ref. Document number / Author  Title Date
[fire1] ISBN 0-201-63357-4 
Cheswick / Bellovin 
"Firewalls and Internet Security"  1994
[fire2] ISBN 1-56592-124-0 
Chapman / Zwicky 
"Building Internet Firewalls", O'Reilly & Associates
Highly recommended. 
1995
[dcom] Data Communications Magazine (www.data.com) "Can Firewalls Take the Heat" 
A test of some Firewalls' performance.
This report has been criticised quite a bit on the Net. It should not be used alone as decision making basis. 
Nov.
1995 
[sc1] SC magazine, page 45 "firewalls" This article is a comparison of the top ten firewalls and good reference for commercial firewalls. May 1998
[unix1] 1-56592-148-8
Garfinkel & Spafford
"Practical UNIX and Internet Security", Edition 2, ISBN 1996
[corba1] OMG Document orbos/98-07-03 "Joint Revised Submission CORBA/Firewall Security +Errata" July 1998
[nworld] Network World Magazine  "A Flurry of Firewalls"
An interesting summary of current Firewall offerings. Recommended. 
Jan.
1996 
[list] http://www.access.digex.net/
~bdboyle/firewall.vendor.html
by Catherine Fulmer 
Firewall Product Overview
Contains an up-to-date listing of current firewalls & related product offerings since 1996.
Jul.
1998 

Where to start?

  1. Define goals: What services do you want? How much can it cost? Provide a business justification for services.
  2. Who/what are you trying to protect, from whom / against what (threats)?
  3. What known weaknesses need to be addressed?
  4. What risks (likelihood and consequences or impact) do the above threats entail?
  5. Develop a strategy to counter the unacceptable threats: policy, organisation, processes and specific technical mechanisms.
  6. Select the appropriate technical solution: What tools can provide access to the required services with the specified budget at an acceptable risk? Choose a stable well known technical architecture, test the solution, install it securely.
  7. Define a support organisation with roles, processes. You need a well organised team to manage firewalls. Make sure that processes exist for handling a security breach swiftly. Plan for an attack!
  8. Submit the firewall to regular monitoring and independent audits. 
  9. Running a Internet firewall is an endless operation, so it makes sense to follow the technical and social evolution of the Internet.

Policy

You need a written document specify what services are allowed through the firewall and in what direction. Define also whether the default is open or closed i.e. if a service is not specified in the policy, does it mean that it allowed or not?. This must be signed by management, otherwise the Firewall administrator may find himself in deep trouble if security is breached through a hole that "everybody though was covered". An example policy for an Internet Firewall could be as follows:

Internet Firewall Policy (example)

Security Requirements:

1. Access Control

2. Assurance

3. Logging

4. Availability

5. Required Functionality:
Outgoing services:

The following services are required from specific internal hosts (e.g. via proxies) to the Internet:
1. Email, WWW (HTTP), ftp, telnet, SSH
2. DNS (resolve Internet names)
3. News (NNTP)
4. Real Audio

Incoming services:

The following Internet services need to be allowed in by proxy hosts on a specially protected subnet:
1. Email: all users should be able to receive Internet Email, via secured gateways.
2. News (NNTP)
3. Secure Logins (for a small list of people): via SecurID + SSH

Any machines requiring other Internet services will have to be placed on a special outside (insecure) subnet. They shall be directly on the Internet. Access from the hosts to the internal network follows the same rules as access to Internet hosts.
Services provided to the Internet:

The following Services need to be provided to the Internet (by secured servers in a protected zone):

1. DNS resolution of Firewall/gateway machines.
2. WWW server.
3. Anonymous ftp server.
4. User FTP Server for special projects / collaboration with other companies.  

Choosing a type of firewall

1. Buy in or build yourself? : Building yourself is only an option where sufficient skills and resources are available.
Do-it-yourself:

Vendors:

2. Cost : Consider the risk, how valuable are the assets being protected? Is an external connection even worth the risk? Establish a budget. Calculate the real cost of the external connection (hardware, software, consultant, support staff, telco charges, etc.). Consider who will pay the costs: the company, departments or individual users. Don't buy a $100'000 firewall to enable 5 users to send email to the Internet! Don't set a budget of $5000 for 500 users! 

3. Assurance : Use an OS that has been well tested, ideally a Trusted OS (ITSEC evaluated if possible). Remove all unnecessary services and install any security patches.
=> If you buy a ready-made firewall, make sure it uses a secured, stripped down version of an operating system. Ensure that the vendor makes patches available quickly, if needed.

4. Risks:  What issues should a firewall address?

Technical:

Non-technical:

5: Ease of administration

6. Logging

7. Organisation: Firewall security is a moving target. Processes should exist to ensure that the firewall administrators are up to date on the latest security issues. 

8. Availability: Reliability of service requirements should be specified for the Firewall. Is the connection protected by the firewall mission critical? What down time, when is acceptable? Some form of system backup and/or redundancy will probably be necessary. 

Building blocks

Packet Filtering: Routers can be configured as primitive packet filters. However, they have limited (or no) logging capabilities, frequently don't offer state based filtering, often leave high ports (e.g. databases) completely open and have very complex rule sets.
For these reasons, it is preferably to use an intelligent, state based filter or a dedicated host with packet filter software. Note, however, that not all Firewall kits offer state based filtering. If a router is used for filtering, choose one with easy to configure rule-sets. A typical example of filtering required is as follows (finer detail is to be found in the services section below).

Content Filtering Many newer firewalls analyse the content of information passing through in order to restrict the information flow according to an information policy. Email, news messages, ftp and http file uploads and downloads can be analysed. Examples of content that can be recognised and (depending on policy) rejected are:

Proxies: Application proxies (or application gateways) normally offer logging and access control at the application layer, but at the cost of performance (all traffic must pass via the proxy) and complexity (the proxy needs to run on a special host). It may also be necessary to modify the client program. Ideally proxies and filtering should be used together to maximise security. See also the services section below.

Sample Architectures

The are many possible ways to set up a Firewall. Here the principle methods are shown. The choice of Firewall depends on cost, performance, availability needs and the sensitivity of the information being protected by the firewall. Highly secure, high performance, high availability systems are not cheap. If high availability is important, it could double costs.

Security can be maximised through Dept of Defence (a series of different barriers for protection) and Diversity of defence (different methods/products redundantly protecting). 

Basic Filter Architecture (screening router)

The cheapest (and least secure) setup involves using a router (which can filter inbound and outbound packets on each interface) to screen access to one (or more) internal servers. A router is normally needed anyway to connect to the Internet, so the filter is for free. This server is the starting point for all outside connections. Internal clients who wish to access the outside do so via this screened server.

Analysis: This architecture is not recommended, except where finance is a severe problem (even then, is it really worth the risk?). As an improvement, an "intelligent filter" (see below) could be used to replace the router filter. 

Dual Homed Firewall Architecture

In this classical firewall architecture, a host is setup with two network interfaces, one connected to the outside, one to the inside. Packet forwarding is disabled on the gateway, information is passed at the application level. The gateway can be reached from both sides, but traffic cannot directly flow across it. Normally, a router is also needed for Internet connection.

Analysis:

Screened Host Architecture

This variation of the Basic Filter involves the use of two filters, the additional filter being used between the screened host and it's clients. The "protected" host is known as a Bastion Host.

=> This architecture may be a solution for small sites with tight finances, or simple outgoing services.
=> A simple improvement to this architecture would be to an "intelligent filter": use a computer as the outside filter, with special firewall software being used to filter packets and services. This solution is not so expensive (costing perhaps $5000 more on a simple system), but offers better protection and logging possibilities. The OS on this computer must be very carefully configured. 

Screened Subnet (or DMZ) Architecture

This architecture is an extension of the screened host architecture. The classical firewall setup is a packet filter between the outside and a "semi-secure" or De-Militarised Zone (DMZ) subnet where the proxies lie (this allows the outside only restricted access services in the DMZ Zone). The DMZ is further separated from the internal network by another packet filter which only allows connections to/from the proxies.

=> Recommended for large sites, or those protecting valuable assets.. 

Invisible Filter Architecture

Some products act as bridges and are as such invisible to TCP/IP traffic. An example is the SunScreen from Sun Microsystems. This offers a huge advantage, especially if the filter is intelligent - it is very difficult to attack the packet filter.

==> The filter above is a Single point of failure. What if it dies, or the wrong rule is added by mistake?
==> Diversity of defence is not as good as the previous solution, however. For maximum protection, the above filter could be used as the Packet filter/logger shown in the "DMZ Architecture" .

Encrypting firewalls / Tunnels

Where secure data communication over a public network (such as the Internet) is required, the most transparent solution is encryption of TCP/IP traffic at the IP level.

Configuration Issues

OS (Operating System)

Services

See [fire2] for much more detail on configuring services. [unix1] is also an excellent reference.

CORBA & Firewalls (July 1998)

CORBA/IIOP was not designed to expect a "man in the middle" (i.e. firewall) who controls access and manages connections between client & server. A "IIOP enabled firewall" needs to be able to control outgoing access from a IIOP client to a server and also incoming connections from IIOP client to a server behind the firewall. On the server side, the main difficulty is configuring firewalls to listen for IIOP-bearing connections on all the ports, and destined for all the internal hosts (One of the features of IIOP is that ports are dynamically assigned, making it impossible to assign a simple IIOP filter on a particular port number).

CORBA 2.2 is being extended to allow for the introduction of CORBA proxies, but products based on this spec (discussed below) probably won't be available until early 1999 at the earliest. Today, there are two methods of allowing IIOP to traverse firewalls (incoming connections to IIOP servers or ORBs). Outgoing methods are discussed in the CORBA 2.2 section.

  1. IONA's Wonderwall (www.iona.ie/products/internet/wonderwall/ and the Sysadmin doc) is the only known proxy available. The Wonderwall "proxifies" the Interoperable Object Reference (IOR) of an object and allows remote invocations on the proxy IOR. It can also work in HTTP tunnelling mode.
    Advantages: Provides logging and access control on the object level. Requires no changes to applications. Messages to Orbix & Orbixweb can be encrypted. Iona are the market leaders.
    Disadvantages: The issue of callbacks has not been resolved. Proprietary (not an open standard). An unconfirmed worry is that the Wonderwall only works when the client ORB and the server ORB are from IONA (we need some real world testing)..
  2. Visigenic has something called Gatekeeper, but it is merely a gateway that can unpack the tunnelled HTTP and route the request to the right server. They also have a proprietary method of using URLs ( www.sys-con.com/java/reviews/visibroker/index.html) instead of IORs.
  3. HTTP tunnelling: IIOP message are added to HTTP by the client and intercepted by a quasi-HTTP server on the other side that knows how to unpack and handle IIOP.
    Wonderwall can also act in HTTP tunnel mode.
    Advantages: No changes to firewall filter needed, The UBS homebanking (  /www.ubs.com/e/telebanking.html ) works with this architecture  through AdNovum's software ISIWEB ( www.adnovum.ch/ISI/isi.html  ). ISIWEB uses a modified Apache HTTP proxy.
    Disadvantages: Messages are a IIOP/HTTP mix and are no longer CORBA wire-level compatible. The HTTP proxy is "modified" to do something it was not designed to do, a "backdoor" is created. The additional HTTP handling/translation affects performance.

    Definition of IIOP policy/rules and logging of transaction does not happen in the firewall, the firewall has "no control" over what goes through the tunnel - therefore the modified HTTP proxy show also do CORBA object access logging and access control (it does have access to the ne necessaru information. ISIWEB doesn't do this yet. Wonderwall?

CORBA 2.2 Firewall specification:
A new document [corba1] proposes changes to CORBA that would allow firewalls to be integrated into the CORBA model. A GIOP proxy is suggested which is a new element that allows CORBA communication across firewalls and supports call-backs and SSL. Three methods for traversing firewalls are suggested, with the first two being optional, the third mandatory.

  1. Using well known TCP ports with a packet filter. Firewalls can normally TCP/IP packets based on port number and IP address. For outgoing access the firewall can simple allow the IIOP ports from selected inside hosts to (selected) outside hosts. Such a "well known" port does not yet exists, but one should be defined in addition to an SSL enabled port. The firewall understands nothing about the IIOP and cannot provide access control to CORBA objects. This solution then is only suitable for outgoing IIOP connections in certain situations (e.g. the firewall does actually allow non proxied connections).
  2. Using a SOCKS proxy for outgoing connections. By relinking the libraries of CORBA products with SOCKSified TCP libraries, the connection is routed through the SOCKS proxy (in the firewall) on the network layer. SOCKS is an IETF approved standard.
  3. Using a (new) GIOP proxy. The following is an extract (in italics) from the proposal [corba1]. Basically it defines a classical firewall proxy that understands the IIOP application layer and can grant or deny access to inside or outside CORBA objects. it requires changes to the CORBA spec and existing products.
    A GIOP Proxy is an application level firewall that understands GIOP messages and the specific transport level inter-ORB Protocol supported i.e. a TCP GIOP Proxy understands IIOP messages. To establish a connection to a server, a client first sets up a connection to the GIOP Proxy. If the GIOP Proxy is an outbound one, the ORB should be configured with the IOR of the proxy object. If the GIOP Proxy is an inbound one, the server’s IOR should contain the IOR of the proxy object on the firewall. There are two styles of connection through a GIOP Proxy: normal and passthrough.
    • A normal connection is where, from a client perspective, the firewall behaves like a server, and from a server perspective the firewall behaves like a client. The proxy can monitor the GIOP traffic. This gives rise to two security issues. Firstly the client may not trust a GIOP proxy, and hence would not want the proxy to examine the traffic. Secondly, the client and server may be using a particular authentication and/or encryption mechanism that is unknown to the proxy.
    • Passthrough: the proxy simply forwards on all GIOP messages it receives to the appropriate party. This recognizes that either the proxy is not capable or is not allowed to examine the traffic. In a pass-through connection, the firewall is not responsible for maintaining the GIOP dialogue on the connection, and it may not issue any GIOP messages of its own (such as replies or close connection). Pass-through connections exhibit similar behaviour to a transport level firewall, but on an object level i.e. once the proxy permits access to a particular object any traffic (following the rules of GIOP interactions) may flow uninterrupted though the proxy.

The proposal also contains solution for the use of IIOP over SSL, with two scenarios: trusted and untrusted proxies.

  1. Untrusted proxies can forward information from a client in the form of a pass-through connection, i.e. the proxy has no visibility into the encrypted byte stream. This ensures the integrity of the client and server communication but leaves little opportunity for access control. This type of connection restricts the proxy's ability to apply its access control list fully, but it is necessary when either the server or client do not fully trust the proxy.
  2. Trusted proxies can forward connections using a pass-through connection but also can establish separate connections to the server and provide full access control. This allows the implementation of access control either at the server as in the untrusted case or at the proxy on a per operation basis. All trusted proxies belong to a trust group decided by the target servers.

    Since all proxies will have access to the IOR of the target object, and the certificate of the client, they can judge whether this client may use a pass-through connection or not. Whether or not a proxy allows or denies permission for a client to use pass-through in any given circumstance is up to the proxy’s implementor.

The final element of the proposal suggests a mechanisms for supporting call-backs by using bi-directional GIOP or extending the proxy:

To provide a more generic solution in addition to the above, GIOP Proxy objects provide an operation that a client may call. The proxy will generate an IOR with appropriate firewall information in it, that can then be exported to the server. The server can establish a connection to the GIOP Proxy, and send traffic on it. The proxy will re-use the connection it already has with the client in a bi-directional mode to send the GIOP messages to the client.

Sample Products

Intelligent filters (screens)

Intelligent filters are relatively new to the firewall marketplace, but are incorporated into the leading firewalls, such as F1 (see below). In this section, specific, well known  filters are presented.

IP Filter 3.2.9 (free, Updated 7.8.98)

IP Filter is a TCP/IP packet filter, suitable for use in a firewall environment. To use, it can either be used as a loadable kernel module or incorporated into your UNIX kernel; use as a loadable kernel module where possible is highly recommended. Scripts are provided to install and patch system files, as required.

It's author is Darren Reed ([email protected]) and it looks promising for adding a low level packet access control layer to firewalls.  
Features: IP filter offers filtering of protocol (udp or tcp), IP fragments,   ports (and ranges), IP options, TCP flags, ICMP type/code and provides NAT, logging, transparent routing, VLSM (Variable Length Subnet Masks). In addition, redirection of services "transparent proxy" and packet state can be analysed to check that TCP packet ack/sequence numbers are correct.
Advantages: free, flexible, source code, works on many UNIX variants
Disadvantages: no GUI, requires careful configuration
See also http://cheops.anu.edu.au/~avalon/ip-filter.html ftp://coombs.anu.edu.au/pub/net/ip-filter/ and a mailing list can be subscribed to at [email protected]   with a subject "subscribe ipfilter".

The author has briefly looked at this impressive package, but had not time for a thorough test (nor the need, since Sunscreens were already available). Note that when compiled for Solaris, a neat SVR4 package is created for clean installation/de-installation. Here is more information from the README file for 3.1.5:

IP Filter - What's this about ?
============================
The idea behind this package is allow those who use Unix workstations as routers (a common occurrence in Universities it appears) to apply packet filtering to packets going in and out of them. This package has been tested on all versions of SunOS 4.1 and Solaris 2.4/2.5, running on Sparcs. It is also quite possible for this small kernel extension to be installed and used effectively on Sun workstations which don't route IP, just for added security. It can also be integrated with the multicast patches. It has also been tested successfully on all of the modern free BSDs as well as BSDI.

The filter keeps a rule list for both inbound and outbound sides of the IP packet queue and a check is made as early as possible, aiming to stop the packet before it even gets as far as being checked for source route options. .........I've also successfully setup and maintained my own firewalls using it with TIS's Firewall Toolkit, including using it on an mbone router. 

SunScreen 100(G), EFS and 200(G)  (May. 1998)

SunScreen is a recent product from Sun (see www.sun.com/security/overview.html ) which allows packet filtering (state based), transparent switching between up to 4 Ethernets and IP level encryption is offered with hosts that understand the SKIP protocol.
It does not route packets (because it does not understand RIP, have a routing table and is not visible to IP hosts). It functions like an ethernet switch and needs to know what IP addresses to expect on what interface.
The (original) Sunscreen 100 was sold  as a "black box" with Windows-based GUI for configuration. This progressed to the Sunscreen EFS and now the 200 is being sold as software that can be installed on most Sun/SPARCs and has a Motif & Web based admin GUI.
The administration PC or Web GUI is connected to the "black box" (here after called the Sunscreen) via an encrypted TCP (SKIP) connection. Price is about $20k.

VPN: The Sunscreen can be used to setup VPNs (virtual private networks) using the SKIP protocol. End-point to end-point (tunnelling) or end-point to Sunscreen (gateway = normal) encryption can take place. In normal mode the sunscreen needs (Sun signed 512 bit for export) certificates for each end point and rules can be added to only allow certain services (encrypted) to certain target IP addresses. In tunnelling mode, the Sunscreen simply lets SKIP (IP socket 79 for SKIP V1 and socket 57 for SKIP V2) pass or not, individual services cannot be passed or stopped since the packet is not decrypted by the Sunscreen. The Sunscreen 100 & EFS only support SKIP V1.

Overview:
In the 100: the OS (a stripped Solaris 2.4, with an encrypted TCP/IP stack running in single user mode) is embedded on a CD-ROM. The hardware is simply a SPARCstation 5 with 1GB disk, 32MB RAM, a floppy drive, a CD-ROM and a quad Ethernet interface. The Sunscreen boots from CD-ROM and uses the internal hard-disk only for swapping, logging and configuration information.

In the 200: The Sunscreen software has two parts, the admin station and the Screen. Both can be installed on most SPARCs with Solaris 2.5 or later. The admin station generates a boot floppy which is used together with the 200 CD-ROM to install the screen with Solaris 2.5.1, configure it and install the screen software. An installation log is written to the diskette (which is very useful for debugging). Several Screens can be managed by one admin station and several admin stations can access the same Screens.

Advantages:

Disadvantages:

  1. Expensive (IMHO).
  2. 100: It is impossible to automate configuration and monitoring, since on a GUI is available (i.e. no command line interface). The 200 is a vast improvement, with a good command line interface suitable for remote administration and script automation.
  3. There is no "net meeting" filter.
  4. Custom filter engines cannot be created.
  5. 100: It is not possible to configure a range of ports (big problem, depending on your needs) . [fixed on the 200].
  6. Source code is not provided.
  7. Rules don't have an "expiry date", nor can they be applied at certain times of day, certain days of the week, nor do they have a comment field.
  8. 100: No NAT (Network Address Translation) feature. [fixed in the 200].
  9. The "normal" export version has small (40bits = not very useful) encryption key length.
  10. No proxies are included, it is a pure filter. So you still need to buy proxies for your firewall.
  11. Rule conflicts are not allowed, making certain configurations irritating.
  12. 100: The GUI is not very intuitive and clumsy at times. Error messages are vague, finding the real source of problems can be very difficult.. It is full of bugs (see below), none of which have been fixed by Sun since April'96. The 200 is better (more stable), but still has a primitive GUI.
  13. 100: The administration PC cannot be reinstalled, as no software is delivered (the new html front end might solve this). However, a newly installed PC can "get" the current configuration on a production Sunscreen and use it, so the configuration files are not lost if the PC dies.
  14. No high level log analysis is available, with logging occurring on the packet level. The log browser is primitive.
  15. Cabling can be problem, since only RJ45 is supported (i.e. not AUI).
  16. Bugs (100):
    • 100: "Passed" and "Failed" packets can be logged, but not packets dropped at the interface.
    • Crossed RJ45 can be used between the Sunscreen and the PC, but it's not recommended as it can cause transmission problems.
    • Problems have been experienced with the SNMP udp state based filter.
    • When defining "subnet addresses", if the form XX.XX.XX. is entered, the Admin PC adds a number on the end giving XX.XX.XX.4 (for example), instead of it being interpreted as XX.XX.XX.0. Workaround: make sure you add the .0 to the end of subnet addresses.
    • No documentation on the modified PC-NFS is delivered. Problems can be difficult to troubleshoot.
    • The GUI has a serious bug which prevents downloading of Sunscreen configuration. It happens in several situations, e.g. when the administration icon and log browser are used together. Sun have known about this for months, but not fixed it. Workarounds: a) restart the PC b) stop the admin utility, delete the *.pfm files in the config directory, or c) upload a configuration before you download one. For initial installations where no configuration can be uploaded, try to download a config with no rules and download the real config afterwards.
    • The traffic statistics cannot be reset to zero, except by rebooting the Sunscreen.
    • Log files greater than 32MB cannot be transferred to the PC every time, often the files are chopped.
    • Logs cannot be automatically downloaded from the Sunscreen, or transferred to another system.
    • The log browser doesn't count the number of packets in a log file correctly.
    • The "summary" log entries don't show the tcp/udp port number concerned.
    • Downloading large configuration to the Sunscreen often breaks down under mysterious conditions (with a direct crossed RJ45 and hub connections).
    • The rules are recompiled before each download, even if they haven't changed. This can make life very slow.
    • The rules compiler gives cryptic error message, meaning that lots of time can be lost with simple rule errors!
    • When creating a Sunscreen install diskette, a "gateway" i.e. default router must be defined, even though this may not be desirable, for instance if you only want to manage the Sunscreen on a local network. This bug increases security exposure.
  17. Bugs (200):
    • There is a jumbo patch for the 200, make sure you install it. Crossed RJ45 can be used between the Admin station and the Screen, but if hme (100MB interfaces), it refuse to work or be extremely slow. This problem should be fixed by the Jumbo patch for the 200.
    • Problems have been noted with "name mangling" of files on the installation floppy. If the installation fails, log on to the Sunscreen console, mount the floppy & check filenames. If there are any with ~ (tilde), they need to be renamed. This problem happen with Solaris 2.6 admin stations (since 2.6 has different DOS name mangling from 2.5)..
  18. Recommendations:
    • Change the console password from the default value.
    • Consider installing a "warm standby" for high availability. The "warm standby" is installed using the same installation diskette as the master, after the configuration is downloaded. If the master goes down, just switch the cables to the backup. FTP and other connection oriented sessions will be blocked, but HTTP sessions won't really notice. This type of standby machine is also useful when effecting major configuration changes (you can always switch back to the standby if the configuration is wrong). 

Proxies & filters

There are many products on the market today. The following is a sample of the most well known (to the author) or innovative. A detailed, up-to-date list many be found on the net see [list]. See also the intelligent filters section. above 
TBD: screend ftp://ftp.vix.com/pub/vixie/ .

TAMU drawbridge (free)

Drawbridge is a public domain (ftp://ftp.tamu.edu), PC (DOS) based packet filter (not stateful) from Texas University. Hasn't been updated in a few years. 

DEC Firewall

This firewall contains both packet filters (sort of stateful!?) and proxy servers. Easy to configure for non experts (GUI). Performance was reported as poor [dcom], but DEC say the test involved an old version. The [nworld] report praises this Firewall. 

TIS Gauntlet & FWTK (commercial/free)

FWTK (Firewall Toolkit) is the set of free utilities for building your own proxies, Gauntlet is a fully fledged commercial version of the same. FWTK is often used to complement Vendors firewalls who lack certain features/services.

General

Free version: FWTK (Firewall Toolkit)

Commercial version

SOCKS 5 (21 Oct.1996)

SOCKS is a generic proxy system that can be compiled into a client side application to make it work through a firewall. It is easy to use, but does not additional support authentication hooks or extra logging. See ftp.nec.com/pub/security/socks.csts/socks5/ . Netscape's HTTP proxy and the Java Appletviewer support SOCKS. It is now an Internet standard approved by the IETF.

The main problem with SOCKS is that the clients must be "SOCKSified", but there are quite a few SOCKSified clients and appropriate libraries are available for some platforms.

The following is an extract from the Socks version 5 home page, www.socks.nec.com :

The SOCKS5 protocol, also known as authenticated firewall traversal (AFT) is an open Internet standard (rfc1928) for performing network proxies at the transport layer. It is intended to resolve several issues that SOCKS4 didn't address fully or omitted completely:

Strong authentication
Authentication method negotiation
Message integrity and privacy
Support for UDP applications

There are two additional SOCKS5 related standards for supporting two authentication methods. One is the "Username/Password authentication for SOCKS V5" (rfc1929). The other is the "GSS-API Authentication for SOCKS V5" (rfc1961). Besides providing the authentication, the GSS-API (Generic Security Service Application Programming Interface) also supports message integrity and confidentiality.

The public version available from NEC compiles easily on most platforms and offers proxies for ping, ftp, traceroute and telnet out of the box. It can also be used to setup secure tunnels (VPNs), but this feature has not yet been tested by the author. This principal problem with SOCKS is that the client must be SOCKSified i.e. know how to talk to the SOCKS proxy server. This modifications are minor in most cases but do require compilation. However in many cases (Winsock, Solaris), the system shared libraries can be replaced with SOCKS aware libraries allowing the client to use SOCKS without being recompiled or changed!

Author's experience:

Firewall-1 V3.0 (Jan.1998)

Developed by Checkpoint Technologies and also resold by Sun, this product offers both state based packet filtering and proxy servers. It is one of the most popular Firewalls. Performance is very good [dcom] and is a favourite for some [nworld]. Good GUI for filter configuration. Source code not provided. The version sold by Sun is often 6 months behind that sold directly by Checkpoint, but it is better integrated into the Sun environment. Recommended. See www.checkpoint.com

Cyberguard Firewall

This Firewall contains both packet filters (stateful?) and proxy servers. Excellent performance [dcom]. Based on Harris's Trusted UNIX. Cyberguard is well known in the Military and Space industries. Runs on NT and UNIX (SCO). This Firewall sounds very good and is the only one approved by ITSEC (July 1998) but the author has had no experience with it. 

Norman Firewall (June 1996)

Norman Data Systems is another military supplier, offering a Firewall based an a B1 (TCSEC approved) operating system, HP-UX 10.09.01 CMW or Secureware SMP+ 2.4 (an SCO derivative). This Firewall has some unusual features:

"black box" firewalls

HTTP proxies

For HTTP, a proxy with caching will boost performance significantly.

Content filters

Analysis of information flowing through firewalls and restrictions based on content can help to implement information security policies. An article discussing content filter products is on page 50 of the August 1998 issue of SC magazine (www.westcoast.com).

Most commercial firewalls offer content filtering, or hooks to attach content filtering to their proxies. In addition some traffic monitoring tools for intrusion detection also do a type of content filtering.

Log analysis

Finding ways to analyse your firewall logs for attacks, unusual behaviour or for statistics is rarely easy. Most commercial firewalls provide some kind of Log browser, that it often quite primitive.

Tools: See mechanisms.htm#Log analysis tools: for a presentation of several tools.

Firewall Penetration testing

Firewall penetration testing allows the actual security level to be compared with that desired. Here a brief overview of penetration methods/issues are presented. Since this material could be misused to actually attack other firewalls, only relatively well known weaknesses are explained, without providing an incentive to hackers (it is hoped!). It is strongly recommended that the preparation stage mentioned below be carefully executed and that the firewall administrator know of the impending penetration testing, even if this distorts the results somewhat.

Preparation
Obtain management approval, prepare a test plan which indicates:

Test Stage 1: Indirect information collection
At this stage, the firewall is not approached, so no attack attempt can be detected.

Test Stage 2: Direct information collection
Now the firewall administrator may detect us, but no disruption of the firewall should occur.

Test Stage 3a: General attack from outside
The attacks from here on in will make you very popular with the firewall administrator...

Test Stage 3b: Advanced techniques from outside

Test Stage 4: Attack from the inside
Basically all of the methods in Stage 3 are possible, but they are much easier, since the trust of the internal network is generally much higher.

Test Stage 5: Firewall configuration review
Now the auditor comes onsite and completes an on-site audit of the firewall and the network connections.

Report findings
Corrective action: List findings, order by risk, propose corrective action (if required).

Problems:


previous  next  Title  Contents  Index          Previous     Next      Top   Detailed TOC