Tl MELY. PRACTICAL. RELIABLE.
`UNIVERSITYOFB.C.‘LIBRARV
`
`
`
`
`
`
`
`
`
`
`3’9424‘04802‘1'189
`Firewall
`Architecture
`for the
`Enterrise
`
`Tim Crothers
`
`Norbert Pohlmann
`
`_
`
`Unified Patents Ex. 1006, pg. 1
`
`Unified Patents Ex. 1006, pg. 1
`
`

`

`Firewall
`
`Architecture for
`
`the Enterprise
`
`Norbert Pohlmann and Tim Crothers
`
`Wiley Publishing, Inc.
`
`Best-Selling Books a Digital Downloads - e—Books 0 Answer Networks
`e—Newsletters - Branded Web Sites 0 e-Learning
`
`Unified Patents Ex. 1006, pg. 2
`
`Unified Patents Ex. 1006, pg. 2
`
`

`

`Firewall Architecture for the Enterprise
`Published by
`Wiley Publishing, Inc.
`909 Third Avenue
`New York, NY 10022
`www.wiley.com
`Copyright © 2002 by Wiley Publishing. Inn, Indianapolis, Indiana
`Library of Congress Control Number: 2002102445
`ISBN: 0—7645-4926-X
`Manufactured in the United States of America
`10 9 8 7 6 5 4 3 2 I
`IOIQTlQX/QSIIN
`Published by Wiley Publishing, Inc., Indianapolis, Indiana
`Published simultaneously in Canada
`No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form
`or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise. except as
`permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior
`written permission of the Publisher. or authorization through payment of the appropriate per—copy fee
`to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, [978) 750-8400, fax {978)
`750-4744. Requests to the Publisher for permission should be addressed to the Legal Department,
`Wiley Publishing, Inc., 10475 Crosspoint Blvd, Indianapolis, IN 46256, (317) 572-3447, fax [317)
`572-4447. E-Mail: permcoordi nator'@wi ley . com.
`
`LIMIT OF LIABEITYIDISCLAIMER OF WARRANTY: WHILE THE PUBLISHER AND AUTHOR HAVE
`
`
`USED THEIR BEST EFFORTS IN PREPARJNG THIS BOOK, THEY MAKE NO REPRESENTATIONS OR
`
`WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS
`
`BOOK AND SPECIFICALLY DISCLAIM ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
`FITNESS FOR A PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED OR EXTENDED BY
`
`
`SALES REPRESENTATIVES 0R WRITTEN SALES MATERIALS. THE ADVICE AND STRATEGIES
`
`
`CONTAINED HEREIN MAY NOT BE SUITABLE FOR YOUR SITUATION. YOU SHOULD CONSULT WTI'H
`
`
`A PROFESSIONAL WHERE APPROPRIATE. NEITHER THE PUBLISHER NOR AUTHOR SHALL BE
`
`
`LIABLE FOR ANY LOSS OF PROFIT OR ANY OTHER COMMERCIAL DAMAGES, INCLUDING BUT
`
`NOT LIMITED TO SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR OTHER DAMAGES.
`
`
`For general information on our other products and services or to obtain technical support, please
`contact our Customer Care Department within the US. at 800—762—2974, outside the US. at
`311-572-3993 or fax 317-572-4002.
`
`
`
`Wiley also publishes its books in a variety of electronic formats. Some content that appears in print
`may not be available in electronic books.
`Trademarks: Wiley and the Wiley Publishing logo are trademarks or registered trademarks of Wiley
`Publishing, Inc., in the United States and other countries, and may not be used without written
`permission. All other trademarks are the property of their respective owners. Wiley is not associated
`with any product or vendor mentioned in this book,
`
`@Wiley Publishing, Inc.
`
`is a trademark ofWiIEy Publishing, Ine-
`
`Unified Patents Ex. 1006, pg. 3
`
`Unified Patents Ex. 1006, pg. 3
`
`

`

`
`
`I I4 Firewall Architecture for the Enterprise
`
`inspection. smart filtering, or
`extended state—oriented packet filters as stateful
`adaptive screening. With this extended functionality, they are often offered as user—
`oriented packet filters. Figure 4—15 illustrates state-oriented packet filters.
`
`
`
`State
`machine
`
`D t
`a a
`
` -
`
`| SIS
`n
`A a Y
`
`Header
`network
`
`Header
`transport
`
`Analysis Module
`
`
`
`Header
`access
`
`
`
`
`
`Integration Module
`
`
`
`Network access layer
`
`
`
`Network access layer
`
`
`Insecure
`
`
`network
`
`
`
`Network
`
`to be
`protected
`
`
`Figure 4-15: State—oriented packet filters
`
`State—oriented packet filters have the same advantages as packet filters, but they
`can also check the applications. Some risks remain because the services are not
`directly isolated from each other.
`Because it is a complex matter to simultaneously hold and interpret the commu—
`nications data in the different communications layers, state—oriented packet filters
`generally have a shallower depth of analysis. or they are particularly prone to
`
`Unified Patents Ex. 1006, pg. 4
`
`Unified Patents Ex. 1006, pg. 4
`
`

`

`
`
`Chapter 4: Elements of a Firewall System I 15
`
`errors connected with their very powerful software. Basically, you can't test the
`complex software of state—oriented packet filters sufficiently 0r comprehensively to
`prove that errors cannot occur in any operating state. For this reason, one must
`continue to assume that the complex programs contain potential security risks that
`could be used to perpetrate an attack.
`A better and more secure way to analyze the application data is to use applica-
`tion gateways with proxies. This approach is described in the next section.
`
`Network Address Translation
`
`As its name implies, NAT {Network Address Translation) works by using one set of
`addresses for communications on the Internet and a separate set of addresses for
`communications on the internal network. To fully support this translation,
`the
`IANA set aside three ranges of IP addresses in RFC 1918:
`
`O 10.0.0.0 through 10.255.255.255 (10.0.0.0/8)
`
`O 172.16.0.0 through 172.31.255.255 (172.lB.0.0/l2)
`
`O 192.168.0.0 through 192.168.255.255 [192.168.0.0/16]
`
`These addresses are reserved for intemal use only and, as a consequence, are
`nonroutable on the Internet. Attempts to communicate with any of these ranges
`through the Internet result in ICMP "network unreachable“ errors.
`An organization implementing NAT uses one of the preceding ranges for their
`internal network addressing. The external interface of the firewall
`is assigned a
`normal routable IP address. When the firewall transmits a packet from the internal
`network to the Internet,
`it actually creates a new packet destined for the same
`address but originating from the external address(es) ofthe firewall. This packet is
`then transmitted to the destination. The firewall keeps a table of current communi—
`cations so that when the return communications reach the firewall, they are taken
`and placed into a new packet destined for the internal computer and transmitted
`internally.
`The NAT process affords a substantial degree of security. Since all direct com-
`munications are prevented [as long as the systems are properly configured], an
`external attacker is forced to compromise the firewall or find a means of passing
`his communications through it successfully rather than attacking the internal host
`directly. Given the firewall protection module and hardening, this is a relatively
`significant challenge.
`Not inconsequentially, NAT prolongs the life expectancy of IPv4 on the Internet.
`Were it not for address translation, the supply of Internet addresses would have
`been exhausted long ago. Using NAT, 3 company with hundreds of internal com—
`puters can communicate fully with the Internet using only a handful of routable
`addresses.
`
`Unified Patents Ex. 1006, pg. 5
`
`Unified Patents Ex. 1006, pg. 5
`
`

`

`I 16
`
`
`Firewall Architecture for the Enterprise
`
`In addition to being used dynamically, NAT is also used in a static translation
`mode. Static translation NAT uses a one—to—one correspondence of an external
`routable address to an internal nonroutable address. It is used for application sewers
`such as Web, e-mail, DNS, and FTP where externally originated communications are
`necessary. By using NAT in these circumstances, the firewall is still required to be a
`bridge between the internal server and the Internet. thus requiring the attacker to
`deal with the firewall in addition to the host security of the protected server.
`
`Some of the challenges posed by NAT are covered in Chapter 11.
`
`
`
`Application Gateways and Proxies
`This section describes how the application gateway firewall element works. The dis—
`tinguishing feature ofthe application gateway is that it separates the two networks
`logically and physically, as shown in Figure 4-16.
`In some firewall configurations, the application gateway is the only computer
`system that can be accessed from the insecure network [for example, the Internet];
`thus, the application gateway requires particular protection. For this reason, the
`computer system on which the application gateway is implemented is also referred
`to as a bastion host.
`
`The application gateway —implemented as a dual-homed gateway — has two
`network interfaces, one in the network to be protected and the other in the insecure
`network. The term “dual—homed“ refers to the fact that the application gateway has
`complete control over the packets that are to be passed between the insecure net—
`work and the network to be protected.
`The application gateway can also be operated as singlenhomed w in other words,
`operated with only one network interface. in this case, however, an attacker could
`bypass the application gateway.
`
`ANALOGY TO THE SECURlTY GUARD
`The “application gateway security guard" does not just inspect the addresses of
`inbound deliveries. He also opens every packet, examines its contents, and checks
`the shipping documents prepared by the originator against a clearly defined set of
`evaluation criteria. After he has completed his detailed security check, the security
`guard signs the delivery note and sends the truck on its way again. This time, how—
`ever, he arranges for a trustworthy driver from his own company to take the pack—
`ets to the actual recipient. The security check at this point is significantly more
`reliable than just packet filtering, and the driver of the outside company does not
`see the company premises. It is true that the check takes longer, but as a result. any
`activities that threaten security can be ruled out.
`
`Unified Patents Ex. 1006, pg. 6
`
`Unified Patents Ex. 1006, pg. 6
`
`

`

`
`Chapter 4: Elements of a Firewall System
`1 17
`
`
` Application
`
`gateway
`
`
`
`User authentication
`A
`
`
`
`.
`t
`
`L
`Secrurity management
`]
`
`
`A,
`A
`,
`
`
`Application
`gateway
`
`n service proxy
`
`FI'P proxy
`
`Telnet proxy i
`
`
`1
`TCPIIidriver
`TCPIIPIdriver
`[
`
`
`|
`Network driver
`|
`Network driver
`I
`
`
`
`Network
`
`insecure
`
`
`to be
`
`network
`
`
`
`protected
`
`
`Figure 4—16: Application gateway
`
`How Application Gateways Work
`A user who wants to communicate through the application gateway must first
`identify himself and undergo authentication. Application gateways generally offer
`different authentication procedures.
`To authenticate, the user first establishes a connection with the application gate—
`way. The direct communication partner is not the destination computer system but
`the application gateway. However, once identification and authentication are com—
`plete, the application gateway is transparent so that the user has the impression of
`working directly on the destination computer system.
`
`BASIC APPROACH
`The application gateway receives the packets via the network access and TCP/IP dri—
`vers on the appropriate ports. If only one service is to be allowed on a given port,
`software must be available on the application gateway that will transfer the packet
`
`Unified Patents Ex. 1006, pg. 7
`
`Unified Patents Ex. 1006, pg. 7
`
`

`

`
`
`1 18 Firewall Architecture for the Enterprise
`
`that corresponds to that service from the network on one side of the application
`gateway to the network on the other side, and vice versa. Such software, which only
`allows packet transmissions for one particular service (FTP, HTTP, Telnet, and so on)
`through the application gateway,
`is known as a proxy. The term proxy is used
`because, as far as the user accessing the facilities is concerned, he is communicating
`with the actual server process of the service on the destination computer system.
`Each proxy on the application gateway can offer additional security services tai—
`lored to the service for which it is responsible. Because each proxy specializes in
`one service, the scope ofthe security and logging functions that are possible on the
`application gateway is greater. A particularly thorough analysis is possible in this
`communication layer, as the context of the application data is clearly defined for
`the relevant service. The proxies concentrate on what is essential. The advantage is
`that small, straightforward modules are used, so that the susceptibility to imple—
`mentation errors is reduced [see Figure 4—17].
`
`Re-encryption or re-coding can be performed in the proxy.
`
`
`
`SECURITY CONCEPT OF AN APPLlCATI ON GATEWAY
`For every service that is to be used over the application gateway, a special proxy
`must be provided. if certain services are to be barred completely. you should have
`no proxies for those services on the application gateway, nor should any other soft—
`ware be present that would enable them to run.
`Thus, as little software as possible should be installed on the application gate-
`way to avoid the possibility that, either by mistake or deliberate introduction by an
`attacker, some other software can adopt the role of proxy (packet transmission in
`the application gateway] for a service that ought not to be allowed.
`Security Management is intended to make work as easy as possible for the user
`and is therefore supplied with powerful software [X—Terminal, database, and so on].
`However, for purposes of security, it should not be run on the same computer sys—
`tem (or at least not at the same time) as the application gateway.
`To prevent the possibility that the proxies will be bypassed, application gateways
`should, for security reasons, have no routing functionality.
`Since the application gateway is linked during communication to both the com—
`puter system of the insecure network and to the computer system of the protected
`network, the application gateway provides Network Address Translation. The appli«
`cation gateway has an IP address in the insecure network [for example, an official
`Internet IP address such as 194.1733.” and an IP address in the network to be pro-
`tected (for example, a private IP address such as 192.168.].60 that is reserved for
`this purpose). During communication with computer systems in the insecure net-
`work, the application gateway uses the IP addresses ofthe insecure network; during
`
`Unified Patents Ex. 1006, pg. 8
`
`Unified Patents Ex. 1006, pg. 8
`
`

`

`
`Chapter 4: Elements of a Firewall System
`I 19
`
`communication with computer systems on the network to be protected, it uses the
`IP addresses of that particular network.
`
`Analysis Module For Proxy n
`
`Analysis Module for Proxy Y
`
`Anal sis
`\/
`
`State
`
`machine
`
`
`
`
`
`
`
`integration Module
`
`Transport
`
`Network (IPHX)
`
`
`
`
`Network access
`
`Network access
`
`
`
`Insecure
`
`k
`
`
`Nflwork
`
`
`to be
`protected
`
`Figure 4—17: Analysis Modules for proxies on the application gateway
`
`networ
`
`Unified Patents Ex. 1006, pg. 9
`
`
`
`
`
`
`Transport
`
`
`Network (IP—Y]
`
`
`
`
`Unified Patents Ex. 1006, pg. 9
`
`

`

`
`120
`Firewall Architecture for the Enterprise
`
`The Proxies
`
`A distinction can be made between application level proxies and circuit level prox-
`ies in their implementation.
`
`APPLICATI UN LEVEL PROXIES
`
`Application level proxies are implemented for particular services and/or applica—
`tions. In other words, they know the commands ofthe particular application proto—
`col involved and can analyze and monitor them. Application level proxies work
`with the standard client software for FTP or Telnet [no modifications are necessary)
`or with browsers. However, the procedure followed for user-oriented services may
`differ from the one that
`is usually followed. For example,
`identification and
`authentication with the application level proxy is initially required before transpar-
`ent communication is available to the user.
`In the next section, some application level proxies are described in detail and
`illustrated with particular implementation types, and the basic ideas behind proxy
`technology are presented. Some proxies function according to the store—and"
`forward principle (SMTP), while others are interactive and user-oriented (Telnet,
`FTP, and HTTP].
`
`SMTP PROXY
`An SMTP proxy works according to the store—and-fonuard principle. Under this
`principle, the SMTP proxy accepts the mail in its entirety, stores it temporarily, and
`then forwards it. No end-to—end link is required between the actual transmitter and
`the receiver.
`
`ANALOGY WITH A COMPANY’S MAILBOX (MAlL PROXY]
`A mail proxy can be compared to a company's mailbox. If an employee wants to
`send a letter to another person in the company, he can put it directly or indirectly
`into the company’s mailbox. The letters go to the internal mail room and are dis-
`tributed by a messenger who works for the organization. In this way, the external
`mailman does not need to enter the building, and hence presents no risk. The open-
`ing to the outside is a potential area exposed to attack.
`With SMTP proxies, solutions work either with or without a Message Transfer
`Agent [MTA) on the same system. Figure 4—18 shows an SMTP proxy with an MTA
`available.
`
`DESCRlPTlON
`The SMTP proxy does not work in a user-oriented fashion. so no user authentica—
`tion is required.
`An SMTP proxy on port 25 receives inbound mail and, after the originator [IP
`address and computer name of the mail server) has been checked, it is stored on the
`application gateway in a special directory. The SMTP daemon checks periodically to
`see whether any new mail has arrived. The Mail Transfer Agent (MTA) delivers the
`mail to the addressee either directly or through one or more other MTAs. The SMTP
`proxy thus prevents direct access to the internal MTA from the insecure network.
`
`Unified Patents Ex. 1006, pg. 10
`
`Unified Patents Ex. 1006, pg. 10
`
`

`

`
`Chapter 4: Elements ofa Firewall System
`121
`
`Inbound
`mail
`,
`Porr25
`
`
`MTA
`
`
`[sendmaill
`
`
`
`...................
`
`
`
`
`
`Outbound
`mail
`
`Figure 4—18: SMTP proxy
`
`One example of a commonly used MTA is Sendmail, which is known to exhibit
`a number of security weaknesses and implementation errors.
`An SMTP proxy only processes the following commands, which are security-
`neutral:
`
`9 It processes HELD, MAIL, RCPT, DATA, QUIT, RSET, NOOP.
`
`0 Some additional commands are supported with standard replies in order
`to make communication possible: HELP, VRFY, and EXPN.
`
`Security-relevant commands, such as DEBUG, can send a spontaneous message
`to Security Management. If the DEBUG command is detected in an SMTP proxy, no
`resulting error can occur because the SMTP proxy does not react to it. However, if
`an outsider attempts to execute a DEBUG command, the fact can be interpreted to
`mean that it is concealing an attempted attack. This information on an attempted
`attack can be important.
`it is possible to neutralize the complex
`With the store-and-forward principle,
`and erroreprone Sendmail program (MTA). In this way, attacks known to exploit the
`shortcomings of Sendmail are prevented, as it is possible to prevent Sendmail from
`being addressed directly and ensure that only the substitute software of the SMTP
`proxies can be accessed. The SMTP proxy is straightforward and thus the software
`is easy to test.
`
`LOGBOOK
`With an SMTP proxy or MTA, the following log data can be recorded in the appli-
`cation gateway's logbook:
`
`O IP address and name of the source computer system
`
`0 Time and date of connection setup
`
`Unified Patents Ex. 1006, pg. 11
`
`Unified Patents Ex. 1006, pg. 11
`
`

`

`
`122
`Firewall Architecture for the Enterprise
`
`O Originator ofthe mail (as specified in the mail header)
`
`0 Addressee of the mail {as specified in the mail header]
`
`0 Number of bytes transmitted
`0 Time and date of disconnection
`
`If a problem arises, the extensive log data covering events in the SMTP proxy
`can be used to resolve it.
`
`USER—ORIENTED APPLlCATl ON —LEVEL PROXlES
`The proxies for Telnet, FTP, and HTTP are user~oriented proxies that enforce
`authentication of the user concerned, analogous to a security guard. Assuming the
`user is successfully identified and authenticated, this authentication is only good
`for that particular proxy. if the user wants to use another service [that is, a differ-
`ent proxy), he must undergo identification and authentication again. The advan-
`tage of user—oriented proxies is that the user and IP address are, without exception,
`correctly assigned to the desired service.
`
`PROCESS OF COMMUNlCATIONS THROUGH
`AN APPLICATlON PROXY
`The following example presents a connection setup over the application gateway
`with the aid of a simple password procedure for user—oriented services (refer to
`Figure 4-19].
`
`9 Phase 1: Establishing a Connection to the Application Gateway. The
`user attempts to establish a connection from his source computer system
`to a desired destination computer system over the application gateway.
`The application gateway accepts the connection setup and asks the person
`seeking access to undergo identification and authentication.
`0 Phase 2: User Authentication. The user enters his user identification and
`
`the destination computer system [name or address]. A check is performed
`on the application gateway as to whether the user is allowed to access the
`desired destination computer system from his source computer system and
`what restrictions apply to such access. In this case, the user is then asked
`to enter his password. A check is performed on the application gateway as
`to whether the user has entered the correct password [as with the security
`guard).
`
`Authentication in firewall systems can be implemented in a number of
`ways. For example, one can use a standard password procedure, a one—
`time password, or Challenge/Response. Authentication procedures that
`make use of cryptographic algorithms require the user to have a security
`token or smart card. The particular authentication procedure that is used
`generally depends on the protection requirement and the direction of
`communication through the firewall system. Communication through the
`
`Unified Patents Ex. 1006, pg. 12
`
`Unified Patents Ex. 1006, pg. 12
`
`

`

`
`Chapter 4: Elements of a Firewall System
`
`123
`
`firewall system can be implemented from a network to be protected to an
`insecure network with a simple authentication procedure, or even without
`one. Where communication is directed from an insecure network to a net—
`
`work to be protected, encryption (involving a security token or smart
`card} should always be used.
`
`Source
`
`Destination
`
`
`Application
`gateway
`
`
`
`
`connection
`
`
`
`Username.
`destination computer
`
`Establishing
`
`Please
`
`enter
`authentication
`password
`
`User
`9assword
`
`
`
`
`
`
`
`Establishing
`
`connection
`
`
`
`Disconnect
`
`Figure 4-19: Communication over an application-level proxy
`
`Unified Patents Ex. 1006, pg. 13
`
`Unified Patents Ex. 1006, pg. 13
`
`

`

`
`
`124 Firewall Architecture for the Enterprise
`
`6 Phase 3: Establishing a Connection to the Destination Computer. After
`the user seeking access has been successfully identified and authenticated,
`a second connection is established from the application gateway through
`the proxy to the desired and permitted destination computer system.
`
`9 Phase 4: Data Transfer. Data transfer occurs. Depending on the proxy
`concerned, the transfer of data through the proxy is monitored, controlled,
`and logged on the application gateway. This phase is transparent to the
`user.
`
`0 Phase 5: Disconnection. In the final phase, the connection through the
`application gateway is terminated.
`
`Telnet Proxy
`The Telnet proxy is responsible for controlled communications using Telnet. It pro-
`vides appropriate special security—enforcing functions for this service. A connec—
`tion is established from the source computer system (client) to port 23 of the
`application gateway [the port for the Telnet service).
`The Telnet proxy takes over the connection on port 23. The user on the source
`computer system identifies and authenticates himself, informing the Telnet proxy
`of the connection destination. Once identification and authentication have been
`successfully completed, a user profile containing entries that correspond to the fol-
`lowing information is activated:
`
`. IP address of the source computer system that wants to establish the
`connection
`
`0 User name that was used during identification and authentication
`
`0 JP address of the destination computer system
`
`The Telnet proxy establishes a second connection from the application gateway
`to port 23 of the destination computer system. The user can now use the Telnet ser-
`vice of the destination computer system from the source computer system via the
`Telnet proxy [see Figure 4-20].
`
`CONTROL MONITOR
`During the Telnet session, a control monitor can check whether or not the user is
`accessing the permitted destination computer system from the source computer
`system, or a different computer system without permission. The monitor must
`check the data stream for byte sequences that could possibly be used to hop to a
`different computer. It can also look for other information, such as control charac—
`ters, that are not supposed to be used (for example, Ctrl+C).
`
`Unified Patents Ex. 1006, pg. 14
`
`Unified Patents Ex. 1006, pg. 14
`
`

`

`125
`Chapter 4: Elements of a Firewall System
`
`
`Application gateway
`
`
`
`Authentication 1-----------------------------;
`
`
`
`User profile
`
`
`
`Workstation
`
`lll
`llll
`llllllll
`
`
`
`
`
`
`
`
`
`Logbook
`
`Al
`
`ifi
`
`Port 23
`
`
`
`TELN ET proxy
`
`Figure 4-20: Telnet proxy
`
`LOGBOOK
`The Telnet proxy can write the following protocol entries to the logbook of the
`application gateway:
`
`IP address and name of the source computer system
`
`IP address and name ofthe destination computer system
`
`60000. Time and date of disconnection
`
`Time and date of connection setup
`Name ofthe user
`
`Number of bytes transmitted
`
`With a Telnet connection, it is often appropriate to make a recording ofthe com-
`plete communication for audit purposes. This security-enforcing function not only
`permits subsequent analysis of the recording, but also exercises a warning effect
`that should not be underestimated.
`
`EXAMPLE lLLUSTRATlNG THE USE OF THE AUDIT TRAlL
`The audit security mechanism can be agreed upon in the service contract with a
`company, perhaps in a case where remote maintenance is being provided. With this
`mechanism in place,
`the employee who performs the maintenance knows that
`everything he does will be recorded and will thus be motivated to perform only
`those actions that are required to complete the job. Should anything untoward
`occur, the log can be used to identify any impermissible or unnecessary actions that
`were carried out via remote access. in other words, the employee’s actions can be
`reliably determined after the event.
`
`Unified Patents Ex. 1006, pg. 15
`
`Unified Patents Ex. 1006, pg. 15
`
`

`

`126
`
`Firewall Architecture for the Enterprise
`
`EXAMPLE OF THE USE OF AN APPLICATlON
`GATEWAY WITH TELNET PROXY
`Security can be implemented between two networks that have different protection
`requirements. using an application gateway with a Telnet proxy. Figure 4—21 shows
`two networks: Network X with the [P address 192.168.3.X, and Network Y with the IP
`address 192.168.5.Y. These two networks are independent of each other; there is no
`direct connection between them. The administrator of Server 1 in Network X is work—
`ing at Workstation A in Network Y and wants to have remote access to Server 1
`in
`Network X. The two networks will be connected using an application gateway with
`Telnet proxy in such a manner that only a Telnet session from Workstation A in
`Network Y to Server 1 in Network X is permitted.
`
`Server 1
`
`
`
`
`
`
`191168.14
`192.168.33
`Network X
`
`192.168.3100
`
`Application
`
`
`gateway
`
`
`192.168.5200
`
`Network Y
`191168.520
`191168.521
`C
`
`1:1
`DOC)COD
`—- 888 —> ~-
`1
`
`User P
`
`Security
`Token
`
`
`Workstation A
`
`Workstation B
`
`Figure 4-21: Use of an application gateway with Telnet proxy
`
`CHARACTERlSTlCS OF THE TELNET CDMMUNlCATlON SERVlCE
`Telnet communications has the following attributes:
`
`O Telnet is based on TCP.
`
`O The standard port number used by Telnet servers is 23 [TCP destination
`port number).
`
`Unified Patents Ex. 1006, pg. 16
`
`Unified Patents Ex. 1006, pg. 16
`
`

`

`
`Chapter 4: Elements of a Firewall System
`
`127
`
`O The TCP source port number used by Telnet clients is any port number
`greater than 1023.
`
`FILTER RULES SPEClFlED FOR USER P
`Here are some typical rules that might apply to a user.
`
`6 P can only use the Telnet service on server 1 on working days between
`7 a.rn. and 6 pm.
`
`0 P can establish this connection under the following conditions:
`I Workstation A must use IP address 192.168.5.20.
`
`l Server 1 must use IP address 192.168.3.3.
`
`l The transport protocol used is TCP.
`
`l The Telnet port on server i must be 23.
`
`l The source port on workstation A must be greater than 1023.
`
`0 P must authenticate himself using a security token.
`
`O The complete connection should be logged.
`
`9 The actions that take place during connection should be monitored (con—
`trol monitor].
`
`0 User P can only use the Telnet service at the specified times, and cannot
`use any other services.
`
`0 User P can't access any other computer systems in network X [for exam-
`ple. server 2].
`
`OTHER USERS
`Different users in an organization have different rights to access systems and data.
`Continuing the example rules, users other than P might be subject to the following
`limitations:
`
`6 Cannot access servers 1 or 2.
`
`O Other users cannot obtain any information as to what computer systems
`exist in the other network.
`
`Table 4—4 shows the filter rules for the Telnet proxy that are necessary to achieve
`the sample rules just outlined.
`
`Unified Patents Ex. 1006, pg.
`
`17
`
`Unified Patents Ex. 1006, pg. 17
`
`

`

`128
`Firewall Architecture for the Enterprise
`
`
`TABLE 4-4 FILTER RULES
`
`
`User Source
`Address
`
`Destination Authenti- Audit Monitor Week- Time
`Address
`cation
`days
`Window
`Procedure
`
`P
`
`192168.520 192.168.33
`
`Security
`token
`
`
`Yes
`
`Yes
`
`Mon—Fri 7 Elm. to 5 pm.
`
`These filter rules specify precisely with which source address workstation A may
`access which destination address of server 1. In addition, precise rules specify the
`time frame within which access is permitted. Finally, the authentication procedure
`and complete logging (audit) and monitoring of actions (control monitor] are also
`specified.
`
`RESULT
`
`Using an application gateway, you can precisely specify that workstation A can
`have a Telnet session with server 1 at particular times; no other communications
`links through the application gateway are possible.
`The Telnet proxy detects whether any other service has been activated on server 1
`on port 23, so that this other service cannot be passed through the application gate-
`way with the Telnet proxy. The 1P addresses of networks X and Y remain concealed.
`Furthermore, user P can only communicate through the application gateway
`with Telnet after he has been authenticated. Since all actions are logged on the
`application gateway. the actions of user P can be traced from the logbooks. The
`procedure is different for user P than when he is communicating without an appli-
`cation gateway, as he must authenticate himself to the proxy before he is granted
`access to server I. Once the authentication phase is complete, however, operation of
`the Telnet proxy is transparent.
`
`FTP PROXY
`
`The FTP proxy is responsible for controlled communications using FTP and pro—
`vides appropriate special security—enforcing functions for this service.
`The connection for the command channel is established from the source com—
`puter system (client) to port 21 [the FTP command port] of the application gateway.
`The user on the source computer system identifies and authenticates himself,
`informing the FTP service of the connection destination. Once identification and
`authentication have been successfully completed, a user profile containing entries
`that correspond to the following information is activated:
`
`9 [P address ofthe source computer system that wants to establish the
`connection
`
`Unified Patents Ex. 1006, pg. 18
`
`Unified Patents Ex. 1006, pg. 18
`
`

`

`
`Chapter 4: Elements of a Firewall System
`
`129
`
`0 User name used during authentication
`
`O IP address of the destination computer system
`
`The FTP proxy now establishes a second command channel from the application
`gateway to port 21 of the destination computer system (see Figure 4—22].
`
`
`
`Application gateway
`
`Authentication
`
`
`
`User profile
`
`
`
`"""""""" :
`File filter
`
`
`
`
`
`:
`Command filter
`--;
`E
`I
`.
`.
`.
`.
`
`Workstation
`
`
`
`
`
`
`Logbook
`l
`i
`
`I
`i
`I
`
`
`
`(Passive support)
`
`Figure 4-22: FrP proxy
`
`COMMAND FlLTER
`The command filter analyzes and checks all the FTP commands entered by the user
`