COffiQUtef
`conmJnications
`
`ELSEVIER
`
`Computer Communications 21 (1998) 1107-1123
`
`Tutorial
`
`Internet/Intranet firewall security-policy, architecture
`and transaction services
`
`Ray Hunt*
`
`Department of Computer Science, University of Canterbury, Private Bag 4800, Christchurch, New 'Zealand
`
`Received 22 September 1997; received in revised form 1 April 1998; accepted 3 April 1998
`
`Abstract
`
`The development of Internet/Intranet security is of paramount importance to organisations that plan to gain the economic benefits from
`interconnection with the Internet. This paper commences by examining firewall policy, focusing on both network service access policy and
`firewall design policy. Various firewall architectures, ranging from simple packet filters through to screened subnets and proxy gateways, are
`then discussed. Finally, the various mechanisms by which transactions can be secured over the Internet/Intranet are covered. These include
`encrypted tunnelling, 1Pv6, point-to-point tunnelling protocol, secure sockets layer, secure electronic transactions and secure multipart
`Internet mail encoding.© 1998 Elsevier Science B.V.
`
`Keywords: Firewall design policy; Network service access policy; Packet filter/screening router; Dual-homed gateway; Screened host/
`subnet; Proxy gateway; Encrypted tunnelling; 1Pv6; PPTP; SSL; SET; S/MIME
`
`1. Firewall policy
`
`A firewall is a method of achieving security between
`trusted and untrusted networks and the choice, configuration
`and operation of a firewall is defined by the policy. The
`policy defines the services and type of access permitted
`between trusted and untrusted domains. Therefore, a fire(cid:173)
`wall can be viewed as both a policy and the implementation
`of that policy in terms of network configuration, host
`systems, routers, encryption tunnels, authentication proce(cid:173)
`dures and applications systems.
`The definition of a firewall policy requires a clear expli(cid:173)
`cation of the security perimeter, since different firewall
`architectures provide different levels of guarantee against
`attack. Another important term is "zone of risk" that gen(cid:173)
`erally applies to TCP/IP capable networks, although net(cid:173)
`works using other protocols such as Netware/lPX, DECnet
`and SNA can also be vulnerable.
`In principle, the zone of risk covers all networks and
`servers connected to the Internet, including the Internet
`backbone and related network infrastructures. The objective
`of the firewall policy is to minimise the organisation's
`zone of risk by removing the possibility of attack from an
`
`* Tel.: +64 3 3642347; fax: +64 3 3642569; e-mail: ray@cosc.canterbury.
`ac.nz
`
`0140-3664/98/$19.00 © 1998 Elsevier Science B.V. All rights reserved
`Pll S0140-3664(98)00173-X
`
`external network. In other words the firewall becomes the
`zone of risk for the trusted network.
`It is widely accepted that there is a real risk from insider
`threats, and it is often stated that there are more insider
`attacks (for which a firewall is of little value) than external
`attacks [ 1 ]. Insiders usually have more direct access to the
`systems and the opportunity to abuse privileges. For exam(cid:173)
`ple, many workstations can be easily reconfigured to grant
`privileged access and it is then a simple task to run a pro(cid:173)
`tocol analyser or decode software. Also, most standard TCP/
`IP applications, such as Telnet, FTP, rlogin, etc., have weak
`authentication control and passwords are transmitted in
`cleartext.
`There are two levels of policy that influence the design,
`installation and use of a firewall:
`
`• network service access policy (NSAP)
`•
`firewall design policy (FDP).
`
`1.1. NSAP
`
`The NSAP defines which services are to be explicitly
`allowed or denied between
`trusted and untrusted
`networks, together with the way in which these services
`are to be used as well as any conditions for exception to
`this policy.
`
`Juniper Ex. 1032-p. 1
`Juniper v Implicit
`
`

`

`1108
`
`R. Hunt/Computer Communications 21 ( 1998) 1107-1123
`
`The NSAP should be an extension to existing business
`policy that will have already addressed the following issues:
`
`1.2. FDP
`
`•
`
`•
`
`information value-what value does management
`places on information?
`responsibility-who is responsible for ensuring the pro(cid:173)
`tection of the organisation's information from untrusted
`networks?
`• commitment-what is the organisation's commitment
`to protecting its information resources?
`• domains-what domains should or should not be
`protected?
`
`already
`
`have
`
`should
`policy
`business
`Further,
`implemented controls on such systems as
`• virus scanning 1
`• physical security access
`•
`floppy disk controls
`• RAID back-up systems.
`
`At the highest level the organisational policy might state:
`
`•
`•
`
`information is the strategic resource for the organisation;
`the availability, integrity, authenticity and confidential(cid:173)
`ity of the information will be protected by every cost(cid:173)
`effective measure possible;
`• ensuring the availability, integrity, authenticity and con(cid:173)
`fidentiality of the information is a priority for all users at
`all levels of the company.
`
`Below thi~ level, specific policies are implemented which
`cover issues such as
`
`• access to services (dial-in, dial-out)
`• version controls
`• user authentication
`•
`trusted/untrusted network access.
`
`It is at this level that the firewall's NSAP is formulated.
`The NSAP must be drafted before the firewall is imple(cid:173)
`mented. It must provide a balance between protecting the
`trusted network from known risks while providing users
`with convenient access to the untrusted network. Further, if
`a firewall denies access to certain services on an untrusted
`network, it is essential that the NSAP ensures that these con(cid:173)
`trols are not circumvented or disabled. A typical NSAP might
`
`• allow no access to applications or services on the trusted
`network from the Internet;
`• as above, but allow access to a subset of applications or
`services by way of a secure server (e.g. bastion host);
`• allow access from the Internet to selected applications
`on the trusted network (e.g. e-mail) in conjunction with
`strict authentication procedures ( e.g. challenge/response
`and one-time password controls).
`
`1 Contrary to popular belief, firewalls can scan for viruses. This may
`require scanning at the application layer (mail or file headers). Most com(cid:173)
`mon antivirus products such as McAfee, F-Prot, Dr Solomon, Symantecs
`and Norton's AntiVirus can be configured to achieve firewall virus control.
`
`FDP defines how the firewall implements restricted
`access and service filtering specified by the NSAP and
`addresses issues such as
`•
`IP address filtering
`• encryption tunnelling
`•
`secure socket control to facilitate application access
`•
`audit and accounting control.
`This policy is specific to the firewall and defines the rules
`and procedures necessary to implement the NSAP, but it
`must take account of the capabilities and limitations of the
`particular firewall platform as well as the threats and
`vulnerabilities associated with TCP/IP. For example, if the
`NSAP forbids access to all applications on the trusted
`network, then implementing a firewall by way of a packet
`filtering router is extremely risky.
`In principle a firewall can
`• permit any service unless it is specifically disallowed
`• deny any service unless it is specifically permitted.
`
`However, in practice, only the latter option is used. The first
`option might unintentionally allow denied services to run on
`non-standard TCP/UDP ports. Further, some services such
`as FTP, RPC and X-Windows are difficult to filter {2].
`Depending upon the various security and flexibility
`requirements, some firewalls are more appropriate than
`others, which means that the NSAP must be carefully
`designed before the firewall is implemented. For example,
`dual-homed gateways (Section 2.2.1) and screened subnets
`(Section 2.2.3) can both be used to implement a "deny all"
`firewall. However, the dual-homed gateway is cheaper but
`also less flexible than the screened subnet.
`In order to arrive at a successful design policy, together
`with a platform that implements this policy, it is usual to
`start by restricting all access from the untrusted to the
`trusted network, and then to specify the following [3].
`
`• What Internet services will the organisation use (e.g. e(cid:173)
`mail, Telnet, FTP, World Wide Web (WWW))?
`• Where will these services be used from (intra-company,
`between branches, on a mobile or dial-in basis, by sub(cid:173)
`sidiary organisations, etc.)?
`• What additional security features will be needed (e.g.
`one-time password control, authentication procedures,
`encryption
`tunnels,
`secure sockets, point-to-point
`encryption, dial-in/dial-back procedures. etc.)?
`• What risks result from the provision of these services?
`E.g. is a 40-bit RSA [ 4] encryption key adequate for
`certain government or banking applications? Is dial-in
`access without formal authentication procedures an
`acceptable risk?
`• What is the cost (e.g. financial, inconvenience) of pro(cid:173)
`viding these services? For example, how is key distribu(cid:173)
`tion handled? What is the cost of managing a dedicated
`authentication server?
`
`Juniper Ex. 1032-p. 2
`Juniper v Implicit
`
`

`

`R. Hunt/Computer Communications 21(1998)1107-1123
`
`1109
`
`• What is the balance between usability and security
`(e.g. if a particular service is too expensive or risky to
`use should its use be forbidden, thus creating great
`inconvenience)?
`
`Some services that are inherently insecure may, with
`the addition of certain technologies, be secured to pose
`little or no risk. For example, a remote Telnet session can
`be very vulnerable to packet sniffing for passwords, and
`would pose a high risk when connecting a machine to a
`trusted network over an untrusted network such as the Inter(cid:173)
`net. However, with the addition of encryption or strong
`authentication techniques this risk can be dramatically
`reduced.
`Implementation of the firewall based upon these consid(cid:173)
`erations requires careful use of risk analysis so that the
`calculated level of risk can be compared with that deemed
`to be acceptable according to overall company policy [5).
`This may result in a change to the initial policy. For
`example, if the original NSAP denied all dial-in access,
`certain exceptions to this rule may need to be considered
`so as to achieve some overall organisational objective.
`
`1.3. Sample policies
`
`1.3.1. Remote access policy
`As a specific example a ''remote user advanced authen(cid:173)
`tication policy'' might address dial-in user access from the
`Internet as well as authorised users on travel or working
`from home. All such connections should use the advanced
`authentication service of the firewall to access systems at the
`site. Policy should reflect that remote users might not access
`systems through unauthorised modems placed behind the
`firewall, as it takes only one captured password or one
`uncontrolled modem line to enable a backdoor around the
`firewall.
`Authorised users may also wish to have a dial-out
`capability to access those systems that cannot be reached
`through the Internet. These users need to recognise the
`vulnerabilities they may be creating if they are careless
`with modem access. A dial-out capability may easily
`become a dial-in capability if proper precautions are not
`taken.
`Therefore, both dial-in and dial-out capabilities should be
`incorporated into the design of the firewall. Forcing outside
`users to go through the advanced authentication of the fire(cid:173)
`wall should be strongly reflected in policy. Policy might also
`prohibit the use of unauthorised modems attached to host
`systems if the modem capability is offered through the fire(cid:173)
`wall.
`Since users could run point-to-point protocol (PPP) to
`create new network connections into a site protected by a
`firewall, it needs to be considered as part of the overall
`access policy. Such connections are potentially a backdoor
`around the firewall, and may be an even greater danger than
`a simple dial-in connection.
`
`1.3.2. Information server policy
`A site providing public access to an information server
`may wish to incorporate appropriate access controls into the
`firewall design and policy should reflect the idea that the
`security of the site will not be compromised in the
`provisioning of an information service. For example, a
`Web server that is intended to provide access for Internet
`users may not need to be behind the firewall at all, as the
`information provided by this server resides on that machine
`rather than being drawn from systems on the internal
`network. As long as the machine is regularly backed up it
`can operate unencumbered by a firewall and simply be
`restored if attacked.
`It is useful to make a distinction between two fundamen(cid:173)
`tally different types of traffic:
`
`•
`
`information-server traffic (traffic concerned with retrieving
`information from an organisation's information server);
`• business traffic, such as e-mail, file transfer, transaction
`services, etc.
`
`The two types of traffic have their own risks and do not
`necessarily need to be mixed with each other. Screened
`subnet firewalls (Section 2.2.3) allow information servers
`to be located on a subnet and, therefore, to be isolated
`from other site systems. This reduces the chance that an
`information server could be compromised and then used
`to attack site systems.
`
`1.4. Policy evolution
`
`Two considerations drive the formation of an FDP with
`respect to Internet connections:
`
`•
`
`•
`
`the risk to the organisation's internal information and
`systems from external threats, e.g. denial of service
`attacks, IP spoofing, etc.;
`the risk of sensitive organisational information being
`disclosed as it is transmitted across the Internet, e.g.
`password file capture, information leakage attacks (e.g.
`finger), etc.
`
`Once the FDP has been drafted, maintenance and review
`are important ongoing activities.
`
`1.4.1. Maintenance of the FDP
`Unlike many organisational policies, the FDP is not static
`and may need to change on a day-by-day basis depending
`upon new vulnerabilities which arise. For example JAVA
`was considered to be a great invention and the industry was
`assured by SUN that it was not a security risk. Therefore, as
`browsers evolved to become JAVA aware, JAVA code
`(applets) passed through firewalls. It is likely that JAVA
`never appeared in any company's firewall policy as it was
`probably considered to be part of the WWW. One large
`multinational decreed from the highest level that JAVA be
`disabled on all browsers, thus demonstrating the dynamic
`nature of an FDP. Other examples of policy maintenance
`
`Juniper Ex. 1032-p. 3
`Juniper v Implicit
`
`

`

`1110
`
`R. Hunt/Computer Communications 21 (1998) 1107-1123
`
`include changes to a network's filtering rules as well as rule
`changes resulting from the introduction of new services.
`
`1.4.2. Review of the FDP
`It is most important that the FDP remains under constant
`review to ensure that the policy reflects the current state of
`play. As a result of FDP maintenance, the original policy
`can become unrepresentative of reality and this can intro(cid:173)
`duce security holes. Examples include: change of the
`systems expert; wrong versions of software being loaded
`following a system crash. In many of these cases problems
`may not be detected until after a security breach has
`occurred.
`
`1.5. Installing and operating a firewall
`
`Once the decision is made to use firewall technology to
`implement an organisation's security policy, it is then
`necessary to install a cost-effective firewall that provides
`an appropriate level of protection. In general, a firewall
`should provide the following levels of protection:
`
`•
`•
`
`support and not impose a security policy;
`support a "deny all services except those specifically
`permitted" design policy (even if this policy is not initi(cid:173)
`ally implemented);
`• accommodate new facilities and services should an
`organisation's security policy change;
`• contain advanced authentication measures, such as
`encryption, challenge/response systems, and should con(cid:173)
`tain the hooks for installing these facilities;
`• employ filtering techniques to permit or deny services to
`specified hosts as needed;
`• use flexible and user-friendly IP filtering and be able to
`filter on as many attributes as possible, including
`source and destination IP address, source and destination
`TCP/UDP port, protocol type, and inbound/outbound
`interfaces;
`• use proxy services for applications such as FTP and
`Telnet, so that advanced authentication measures can
`be utilised at the firewall.
`
`It will also assist if the firewall supports proxies for ser(cid:173)
`vices such as NTP, NNTP, X-Windows, Finger, HTTP, and
`certain web browser software (Section 2.2.4). The firewall
`should also have the ability to centralise simple mail transfer
`protocol (SMTP) access, thus reducing direct SMTP con(cid:173)
`nections between site and remote systems. This results in
`centralised handling of site e-mail.
`The firewall should have the ability to concentrate and
`filter dial-in access as well as logging suspicious activity. If
`the firewall requires an operating system such as UNIX or
`Windows NT, then a secured version of the operating sys(cid:173)
`tem should be part of the firewall, with other security tools
`as necessary to ensure firewall host integrity. The operating
`system should have all patches installed and be developed in
`a manner that its strength and correctness is verifiable. It
`
`should be simple in design so that it can be understood and
`maintained.
`Some organisations have the capability to put together
`their own firewalls, using available software components
`and equipment or by writing a firewall from scratch. Trusted
`Information Systems (TIS) Internet Firewall Toolkit [6] is a
`good example of a company that offers ''firewall construc(cid:173)
`tion kits". At the same time, there are many vendors 2 [7]
`offering a wide range of services in firewall technology
`which include
`
`• provision of the necessary hardware and software
`• development of security policy and carrying out risk
`assessments
`security reviews and security training.
`
`•
`
`Consideration of the following questions may help an
`organisation decide whether or not it has the resources to
`install and operate a successful firewall.
`
`• How will the firewall be tested?
`• Who will verify that the firewall performs as expected?
`• Who will perform general maintenance of the firewall,
`such as backups and repairs?
`• Who will install updates to the firewall, such as for new
`proxy servers, new patches, and other enhancements?
`• Can security-related patches and problems be corrected
`in a timely manner?
`• Who will perform user support and training?
`
`As a general rule it is desirable that sites:
`
`•
`
`•
`
`standardise operating system versions and software to
`make installation of patches and security fixes more
`manageable;
`institute a program for efficient, site-wide installation of
`patches and new software;
`• use services to assist in centralising system administra(cid:173)
`tion, if this will result in better administration and better
`security;
`• perform periodic scans and checks of host systems to
`detect
`common
`vulnerabilities
`and
`errors m
`configuration.
`
`2. Firewall architecture
`
`There are many different interpretations of the term
`firewall and this can be a source of confusion. One
`basis for defining a firewall is the OSI 7-layer model
`(Fig. 1) which provides a clearer picture than does the
`TCP/IP model.
`
`2 Examples include Digital's Alta Vista Firewall, Secure Computing's
`Firewall for NT, Eagle NMS (Raptor Systems), ANS Interlock Service
`3.06 (ANS CO + RE Systems), Borderware Firewall Server, Firewall-I
`v2.0 (Checkpoint Software), Black Hole 3.0 (Milkyway Networks Corp.),
`Sidewinder, Gauntlet (Data General), GFX Internet Firewall (Global Tech(cid:173)
`nology Associates).
`
`Juniper Ex. 1032-p. 4
`Juniper v Implicit
`
`

`

`R. Hunt/Computer Communications 21 (1998) 1107-1123
`
`1111
`
`Application
`Level Filter
`
`Application Layer
`
`Presentation Layer
`
`Session Layer
`
`Transport Layer
`
`Network Layer
`
`Link Layer
`
`Physical Layer
`
`Packet
`Level
`Filter
`
`Fig. I. Firewall architecture in relation to the OSI model.
`
`It can be seen that firewall architecture consists of two
`levels:
`• Packet-level firewalls that operate at the network (IP)
`and transport (TCP) layers. These are commonly
`referred to as screening routers or packet filters and
`block transmission of certain classes of traffic;
`• application-level firewalls which operate at the session,
`presentation and application layers. They are usually
`implemented using dedicated hosts running specialised
`software and can also be referred to as bastion hosts or
`proxy servers, usually running under UNIX or Windows
`NT. They can also provide relay services to compensate
`for the effects of the filter(s).
`
`Another important term often used in conjunction with a
`firewall is
`''gateway'', and Internet firewalls are often
`
`referred to as secure Internet gateways. However, there is
`a more specific use of this term, as can be seen in Fig. 2. The
`network occupied by the gateway is often referred to as the
`demilitarised zone (DMZ) [8].
`The gateway in the DMZ may consist of both an internal
`and external machine, as shown in Fig. 3. Normally these
`two gateways will have more open communication through
`the inside packet filter than the outside gateway has to other
`internal hosts. The outside packet filter can be used to pro(cid:173)
`tect the gateway from attack, while the inside gateway can
`be used to guard against the consequences of a compro(cid:173)
`mised gateway.
`
`2.1. Packet filters/screening routers
`
`As packets pass through the router their filtering is based
`upon a set of rules established by the NSAP. Filtering based
`upon one of more of the following criteria are commonly
`applied:
`
`source IP address
`•
`• destination IP address
`• TCP/UDP source port
`• TCP/UDP destination port.
`
`Not all packet filters can filter on TCP/IP port numbers.
`Some can examine which of the network interfaces a packet
`arrived at and then use this as further filtering criterion.
`
`Demilitarized Zone (DMZ)
`
`Gateway(s)
`
`Packet FIiters/Screening Routers
`
`Fig. 2. Firewall design (filter/router and gateway).
`
`Packet Filtars/ScrNning Routara
`
`Fig. 3. Firewall design (filter/router with internal and external gateways).
`
`Untrusted Network
`
`Trusted Network
`
`Fig. 4. Firewall using a packet filter/screening router.
`
`Juniper Ex. 1032-p. 5
`Juniper v Implicit
`
`

`

`1112
`
`R. Hunt/Computer Communications 21 ( 1998) 1107-1123
`
`Telnet Gateway
`132.181.19.12
`
`SMTP Gateway
`132.181.19.15
`
`Telnet traffic only
`
`l SMTP traffic only
`
`Packet Filter/
`Screening Router
`
`i
`
`All non-Telnet and
`non-SMTP traffic blocked
`
`Fig. 5. Packet filtering on Telnet and SMTP.
`• X-Windows (ports 6000 + ) and OpenWindows (port
`2000), can leak information from X-Window displays,
`including all keystrokes (intruders can even gain control
`of a server through the X-server);
`• RPC (port 111 ), remote procedure call services includ(cid:173)
`ing NIS and NFS, which can be used to steal system
`information such as passwords and read and write to
`files;
`rlogin, rsh, and rexec (ports 513, 514, and 512) services
`if
`improperly
`configured,
`can
`permit
`which,
`unauthorised access to accounts and commands.
`
`•
`
`Filtering can be used to block connections to or from
`specific hosts or networks (Fig. 4 ), as well as to block
`connections to specific ports. A site might wish to block
`connections from certain addresses, such as from hosts or
`sites that it considers being untrusted. Alternatively, a site
`may wish to block connections from all addresses external
`to the site (with certain exceptions, such as SMTP for
`receiving e-mail).
`Adding TCP or UDP port filtering to IP address filtering
`results in a great deal of flexibility. Servers such as the
`Telnet daemon usually reside at specific ports (e.g. port
`23). If a packet filter can block TCP or UDP connections
`to or from specific ports, then it is possible to implement
`policies that call for certain types of connection to be made
`to specific hosts, but not others. For example, a site may
`wish to block all incoming connections to all hosts except
`for several firewalls-related systems. At those systems, the
`site may wish to allow only specific services, such as SMTP
`for one system and Telnet or FTP connections to another
`system. By filtering on TCP or UDP ports, this policy can be
`implemented in a simple manner using a packet filtering
`router or a host with packet filtering capability.
`Fig. 5 shows an example of packet filtering with a policy
`that permits only certain connections to a network of
`address 132.181. *. *:
`
`• Telnet connections will only be allowed to the Telnet
`application machine (Telnet gateway) with an IP address
`of 132.181.19.12
`• SMTP connections will only be allowed to the SMTP
`application machine (e-mail gateway) with an IP address
`of 132.181.19.15.
`
`All other services and packets are to be blocked. This is a
`very basic example of packet filtering, and actual rules can
`become very complicated in practice.
`
`2.1.1. Policing protocols
`It is the NSAP that determines which protocols and fields
`are filtered, i.e. which systems should have Internet access
`and the type of access to permit. The following services are
`inherently vulnerable to abuse and are usually blocked at the
`firewall [3]:
`
`• TFTP (port 69), trivial FTP, used for booting diskless
`workstations, terminal servers and routers, can also be
`used to read any file on the system if set up incorrectly;
`
`Other services, whether inherently dangerous or not, are
`usually filtered and possibly restricted to only those systems
`that need them. These could include:
`
`• Telnet (port 23), often restricted to certain systems;
`• FTP (ports 20 and 21), like Telnet (port 23), often
`restricted to certain systems;
`• SMTP (port 25), often restricted to a central e-mail ser(cid:173)
`ver;
`• RIP (port 520), routing information protocol, can be
`spoofed to redirect packet routing;
`• DNS (port 53) domain names service, contains names of
`hosts and information about hosts that could be helpful
`to attackers and it can be spoofed;
`• UUCP (port 540) UNIX-to-UNIX CoPy, if improperly
`configured can be used for unauthorised access;
`• NNTP (port 119) network news transfer protocol, used
`for reading network news;
`• NTP (port 123) network time protocol, used for setting
`system clocks;
`• gopher (port 70) and HTTP (port 80) information servers
`and client programs for gopher and WWW clients,
`should be restricted to an application gateway that con(cid:173)
`tains proxy services.
`
`At most sites, not all systems require access to all ser(cid:173)
`vices. Although some of these services, such as Telnet or
`FTP, are inherently risky, blocking access to these services
`completely may be too drastic a policy. For example,
`restricting Telnet or FTP access from the Internet to only
`those systems that require this type of access can improve
`security at no cost to user convenience. Services such as
`NTP and NNTP may seem to pose little threat, but restrict(cid:173)
`ing these services to only those systems that need them helps
`to create a cleaner network environment and reduces
`
`Juniper Ex. 1032-p. 6
`Juniper v Implicit
`
`

`

`R. Hunt/Computer Communications 21 ( 1998) 1107-1123
`
`1113
`
`the likelihood of exploitation from yet-to-be-discovered
`vulnerabilities and threats.
`Forged or spoofed packets can cause a real threat, as
`indicated above in relation to RIP and DNS. IP spoofing
`can be used to make a host look as though it is a trusted
`host by changing the IP number for example. Also, if
`source routing is used, the IP header contains the route
`that the packet will take to reach its destination and
`thus override routing table instructions. However, attackers
`who are attempting to circumvent security can generate
`source-routed packets with Telnet clients to ensure packets
`follow specific paths. Worse still, reply packets are intended
`to use the inverse of the original route and this can now
`permit a two-way connection which was supposed to be
`blocked.
`
`2.1.2. Non-IP protocols
`Most policing protocols outlined in Section 2.1.1 focus on
`IP. However, other protocols at the same level as IP-such
`as IPX, NetBeui and AppleTalk-have different packet
`header formats and filtering characteristics. These non-IPs
`are rarely used between organisations across the Internet.
`Some packet filters offer limited filtering support for non(cid:173)
`IPs, but they are usually considerably less flexible than their
`IP equivalent. Many packet filters are configured to just drop
`non-IP packets. Most non-IPs can be handled by encapsu(cid:173)
`lating them within IP packets. Packets filters then usually
`either permit or deny encapsulated protocols in their entirety
`[9].
`Another reason to disable non-IP packets is because their
`escape from LAN domains can reveal important informa(cid:173)
`tion, such as the LAN's primary architecture. Many of the
`older protocols, such as RIPX, NetBios and Digital's LAVC
`(VAX cluster keep alive packets), broadcast the presence of
`devices that support these protocols across large parts of the
`network and misconfigured routers may not limit this
`dangerous traffic to a single LAN segment.
`
`2.1.3. Stateful inspection
`Stateful inspection, sometimes also known as dynamic
`packet filtering, is a recent development by some firewall
`manufacturers and represents yet another approach towards
`firewalling. Stateful inspection intercepts packets at the
`network layer and examines these packets based on their
`communication state. This mandates the storing of state
`information from one or more packets as well as buffering
`and reassembling the datagram before an access decision
`can be made.
`The advantage of this approach lies in its diversity and
`ability to support a variety of protocols and services. By not
`relying on the native stack of the firewall host for proces(cid:173)
`sing, as well as its ability to look back at past information
`related to the session, stateful inspection can apply any rule
`based on the communication content itself. Stateful inspec(cid:173)
`tion is usually implemented with support of the entire TCP/
`IP suite.
`
`2.2. Application-level .firewalls
`
`Unfortunately, packet filtering routers have limitations
`and are frequently difficult to configure and update. Packet
`filtering rules are complex to specify and usually no testing
`facility exists for verifying the correctness of the rules ( other
`than by exhaustive testing by hand). Some routers do not
`provide any audit capability, so that if a router's rules still
`let through dangerous packets, this may remain undetected
`until a break-in has occurred.
`Exceptions to rules will often need to be made to allow
`certain types of access that normally would be blocked.
`However, exceptions to packet filtering rules can make the
`filtering rules so complex as to be unmanageable. For exam(cid:173)
`ple, it is relatively straightforward to specify a rule to block
`all inbound connections to port 23 (the Telnet service). If
`exceptions are made and certain systems need to accept
`Telnet connections directly, then a rule for each system
`may need to be added (some packet filtering systems
`allow the sequential order of the filter rules to be signifi(cid:173)
`cant). Sometimes the addition of certain rules can compli(cid:173)
`cate the entire filtering scheme and open up further holes.
`Advantages of application-level firewalls or gateways
`include:
`
`•
`
`•
`
`information hiding, in which the names of internal
`systems need not necessarily be made known via the
`DNS to outside systems. The application firewall may
`be the only host whose name must be made known to
`outside systems;
`robust authentication and logging, in which the applica(cid:173)
`tion traffic can be pre-authenticated before it reaches
`internal hosts and can be audited more effectively;
`• cost-effectiveness, since third-party software or hard(cid:173)
`ware for authentication or auditing needs to be located
`only at the application gateway;
`less-complex filtering rules, in which the rules at a
`packet filtering router will be less complex than they
`would if the router neede