Novell is now a part of Micro Focus

Ukiah's NetRoad FireWALL: Multilevel Protection for Multiprotocol Networks

Articles and Tips:

Linda Boyer

01 Jul 1997


University Health Services (UHS) at University of California--Berkeleyruns both a NetWare 4.11 network that supports as many as 200 concurrentusers and a RS-232[shy ]based clinical appointment system that supports nearly40 additional users. Last year Kevin Miller, network administrator at UHS,planned to upgrade the clinical appointment system to TCP/IP and route itover the NetWare 4.11 network. In this way, all users would log in to NovellDirectory Services (NDS), and Miller would be able to manage these userswith the NetWare Administrator (NWADMIN) utility, Novell's graphical NDSmanagement tool. However, this plan presented one problem: The NetWare 4.11network is connected to the Internet, and the clinical appointment systemcontains confidential information that Miller"didn't want availablefrom the Internet. That was the impetus,"Miller explains,"forlooking into firewalls."

Miller had a couple of criteria for a firewall, one of which was critical:"We're really short staffed,"Miller explains."We have basicallytwo support personnel for about 200 to 250 users, so we were looking forsomething that would be as easily administered as possible."

Ideally, an easily administered firewall would integrate with NDS, allowingMiller to manage the firewall through the NWADMIN utility. In October 1996,not long after Miller began looking for the ideal firewall, he attendeda NetWare Conference sponsored by NetWare Users International (NUI) andsaw NetRoad FireWALL from Ukiah Software Inc. Miller explains,"[NetRoadFireWALL] fit all of our needs perfectly."

NetRoad FireWALL is a multilevel firewall that runs on IntranetWare andNetWare 4, integrates with NDS, and includes a snap-in module for the NWADMINutility. NetRoad FireWALL combines the capabilities of an IP firewall withan IPX-IP gateway, protecting both TCP/IP- and IPX/SPX-based workstations.NetRoad FireWALL enforces multilevel security, screening traffic at thenetwork, session, and application layers of the Open Systems Interconnection(OSI) model. This multilevel approach to security protects your networkor intranet from the broadest array of security threats.

WISELY BUILT UPON A ROCK

NetRoad FireWALL supports IntranetWare and NetWare 4, as well as WindowsNT Server 4.0 and Windows NT Workstation 4.0. To run NetRoad FireWALL onan IntranetWare or NetWare 4 network, you must have a server with at leasta 486 66 MHz processor, 16 MB of RAM, and 500 MB of hard drive space. Naturally,NetRoad FireWALL's performance improves as the hardware improves: You willget a faster response from a NetRoad FireWALL server with a Pentium or PentiumPro processor and 32 or more MB of RAM.

In addition, you must equip the NetRoad FireWALL server with Novell'sTCP/IP stack and at least two network interface boards--one to attach tothe Internet (the public interface) and one to attach to your network orintranet (the private interface). Having one board per network preventsany direct contact between the two networks for which NetRoad FireWALL screenstraffic. If you need to connect additional private networks to the Internet,you can add more network interface boards.

Why Run Your Firewall on IntranetWare?

NetRoad FireWALL's support for IntranetWare and NetWare 4 offers a significantadvantage if you are familiar with the IntranetWare platform but are lessfamiliar with UNIX, the traditional firewall platform. Familiarity aside,however, why should you run NetRoad FireWALL, a TCP/IP-based firewall, onan IPX/SPX network? Because after you have installed the standalone router(such as one manufactured by Bay Networks) or the software-only router (suchas Novell's NetWare MultiProtocol Router) required to connect NetRoad FireWALLto the Internet, you will have an easily-managed firewall solution runningon a network operating system that not only outperforms UNIX and WindowsNT Server but is also inherently more secure.

UNIX is notoriously insecure--a surprising reputation considering thatUNIX is widely used as a firewall platform."UNIX has been availableto every hacker in the world,"explains Sanjay Sawhney, vice presidentof engineering at Ukiah Software. As a result, the security holes in UNIXare as well known as the UNIX operating system itself. (You can find informationabout UNIX's vulnerabilities at http://www.iss.net/vd/unixappa.html.)

To compensate for the weaknesses inherent to UNIX, firewall vendors customizeit. Gordon Smith, vice president of sales and marketing at Ukiah Software,explains,"[Firewall vendors] take a chain saw to the UNIX operatingsystem,"and in the process,"cut out major chunks of its functionalityto make it secure."

In contrast, both IntranetWare and NetWare 4 are already secure, requiringno modifications to run NetRoad FireWALL. The NetWare platform, Sawhneyexplains,"is historically what you would call a closed platform--notmany people have seen its code."

Management Is a Snap

The IntranetWare platform offers another significant advantage over UNIXand Windows NT Server: NDS. As mentioned earlier, NetRoad FireWALL fullyintegrates with NDS and includes a snap-in module for the NWADMIN utility.Whereas you must manage most firewalls separately from your other networkresources (requiring you to launch a custom utility from the firewall serverconsole, for example), you can manage NetRoad FireWALL from the same locationand in the same way that you manage your other network resources. For example,NetRoad FireWALL allows you to configure rules to filter both inbound andoutbound packets for all TCP/IP applications--including Telnet, FTP, HyperTextTransport Protocol (HTTP), and Simple Mail Transfer Protocol (SMTP)--fromany workstation on your network running the NWADMIN utility and the NetRoadFireWALL snap-in module. (See Figure 1.)

Figure 1: With the NWADMIN utility, you can configure rules that enable NetRoad FireWALL to filter packets based on information specific to a particular TCP/IP application.

With NetRoad FireWALL, you can also buy and manage a firewall and anIPX-IP gateway as a single product--a rare convenience. Few vendors bundlean IPX-IP gateway with their firewall solution, leaving you little choicebut to buy and manage a firewall and an IPX-IP gateway separately if youwant to enable IPX/SPX-based workstations to use TCP/IP and to secure theseworkstations once they have been TCP/IP enabled. NetRoad FireWALL not onlyincludes both a firewall and an IPX-IP gateway, but it also allows you tomanage each of these components through the NWADMIN utility.

Sound Familiar?

If these capabilities sound familiar--firewall services that run on IntranetWareand NetWare 4, integrate with NDS, and include an IPX-IP gateway--they should:Novell's BorderManager (formerly code-named Border Services) includes firewallservices and offers many of the benefits that NetRoad FireWALL offers. However,BorderManager and NetRoad FireWALL are not competing products. On the contrary,NetRoad FireWALL complements the core services that Novell's BorderManagerprovides. (See The Perfect Union: Novell'sBorderManager and Ukiah's NetRoad FireWALL.")

MULTILEVEL PROTECTION AGAINST A VARIETY OF ATTACKS

NetRoad FireWALL offers multilevel protection for TCP/IP- and IPX/SPX-basedworkstations, combining the capabilities of a packet filter, a circuit-levelgateway, and an application-level gateway:

  • Packet Filter. A packet filter operates at the network layer of the OSI model, screening packets' TCP/IP headers and accepting or denying these packets based on the rules you have configured. These rules can instruct the packet filter to accept or deny an incoming or outgoing packet based on the packet's full association, which includes its source and destination IP address, its application or protocol, and its source and destination port number.

  • Circuit-level Gateway. A circuit-level gateway operates at the session layer of the OSI model, validating requests for TCP and User Datagram Protocol (UDP) sessions before opening a connection through the firewall. After the circuit-level gateway has verified the legitimacy of the requested TCP or UDP session, this gateway establishes a connection and then lets all data pass until the session is terminated.

  • Application-level Gateway. An application-level gateway operates at the application layer of the OSI model, screening application-level data. The gateway validates this data before establishing a requested connection and before accepting or denying packets based on the rules you have configured.

Because NetRoad FireWALL combines the capabilities of each type of firewall,it can guard TCP/IP- and IPX/SPX-based workstations against a broad rangeof security attacks. (For information about configuring workstations, see "Transparent Proxy Protection.") These attacks can occur at any layer of the OSI model, so you need a firewallthat operates at the same layer at which a particular attack occurs. Forexample, to guard against an illegal file-write operation to an FTP server(an attack that occurs at the application layer of the OSI model), you wouldneed an application-level gateway. However, an application-level gatewaywould not protect your network from network-layer attacks, such as IP spoofingattacks.

IP-spoofing Attacks

IP-spoofing attacks are among the most common type of security attack.To launch an IP-spoofing attack, a hacker replaces the actual source IPaddress on a malicious packet with a legitimate IP address--typically theIP address of a workstation on your network or intranet. NetRoad FireWALLrepels such attacks through low-level filtering, identifying whether thesource IP address and the origin of the packet correspond: That is, if thesource IP address belongs to a workstation on your network or intranet,the packet should originate from your network or intranet rather than fromthe Internet.

Most packet filters can check a packet's full association but cannotnecessarily differentiate between a forged source IP address and an actualIP source address. NetRoad FireWALL, however, does both.

NetRoad FireWALL checks a packet's full association and uses the NetRoadFireWALL Prescan module to ensure that the packet's source IP address islegitimate. The Prescan module, which runs as a NetWare Loadable Module(NLM) on an IntranetWare or NetWare 4 server, sits between your public andprivate network interface boards and your TCP/IP stack. The Prescan modulechecks every packet transmitted by these boards before forwarding the packetsto the TCP/IP stack.

The Prescan module checks each packet's full association, comparing itto the rules you have configured, and verifies that a packet's source IPaddress is legitimate. If an IP address is associated with your networkor intranet but the packet was transmitted by the public network interfaceboard, NetRoad FireWALL rejects the packet, dropping it before it reachesthe TCP/IP stack.

DNS-spoofing Attacks

NetRoad FireWALL guards against more sophisticated security attacks aswell, such as Domain Name System (DNS)-spoofing attacks. In a DNS-spoofingattack, a hacker accesses the DNS server for your network or intranet andchanges the information stored on this server to suit his or her purposes.

DNS is a distributed database that maps host names to IP addresses andvice versa. The DNS database uses two distinct name space trees: The firsttree maps a host name such as xyz.com to an IP address such as 284.50.365.4.The second tree, which is called aninverse mapping tree, maps anIP address such as 284.50.365.4 to a host name such as xyz.com.

Typically, a DNS server checks only one of these trees, depending onthe UDP query. The UDP query either submits a host name and requests thecorresponding IP address or submits an IP address and requests the correspondinghost name. The DNS server then responds with the requested information afterchecking the appropriate tree.

The disconnection between DNS trees can lead to trouble: A hacker whocontrols a portion of the inverse mapping tree can make the DNS server lie.That is, this tree could falsely map a hacker's IP address to the name ofa trusted host. The hacker could then attempt to use a remote login command(rlogin) to access your network or intranet, which would believe the spoofedsource IP address and accept the command.

NetRoad FireWALL uses a technique calleddouble-reverse lookupto protect your network or intranet from such attacks. When a remote workstationmakes a UDP query, NetRoad FireWALL checks both DNS trees to determine theorigin of the packet. That is, if the UDP query submits an IP address, NetRoadFireWALL first checks the tree that maps IP addresses to host names. Afterlearning the host name, NetRoad FireWALL checks the tree that maps hostnames to IP addresses. If this process yields two IP addresses or two hostnames, NetRoad FireWALL determines that the packet originated from a spoofedIP address and drops both the packet and the connection to the malicioushost.

SYN-flooding Attacks

NetRoad FireWALL also guards against SYN-flooding attacks, a common typeof attack that occurs at the session layer of the OSI model. SYN-floodingattacks fall into a category of attacks calleddenial-of-service attacks,which are a hacker's version of slashing the tires on your car or otherwiserendering useless something you depend on.

SYN-flooding attacks exploit a security weakness in the TCP/IP handshakingthat occurs between a client and host when one or the other requests toinitiate a session. This handshaking involves an exchange of TCP packetsthat are flagged SYN (synchronize) or ACK (acknowledge). (For more informationabout TCP handshaking, see "Great Walls of Fire," NetWare Connection, Jan. 1997, pp. 6[shy ]28. Bygenerating a massive number of session requests, a hacker can overload yournetwork or intranet with SYN-flagged packets and effectively lock out legitimatesession requests.

To guard against SYN-flooding attacks, NetRoad FireWALL's Prescan modulefor your public network interface board checks the rate at which SYN-flaggedpackets are passing through the firewall and determines whether that rateis acceptable. If the Prescan module detects that an unusual number of SYN-flaggedpackets are passing through the firewall, NetRoad FireWALL notifies youimmediately via a console alert, pager, or e-mail, depending on the notificationoptions you have configured. (NetRoad FireWALL's notification options areexplained later in this article.)

The default setting for the maximum number of SYN-flagged packets thePrescan module will accept before notifying you is 2,500 per minute, butyou can configure this setting in the NWADMIN utility. You can also configureNetRoad FireWALL to drop some SYN-flagged packets. Dropping packets is theonly way NetRoad FireWALL can protect your network or intranet from a SYN-floodingattack.

Password-breaking Attacks

To guard against the myriad of attacks that occur at the applicationlayer of the OSI model, NetRoad FireWALL uses application-level proxies.These proxies are software processes that transmit traffic between yourpublic and private network interface boards, filtering packets based oninformation specific to particular TCP/IP applications.

Virtually all TCP/IP applications have inherent security weaknesses.Consider FTP, for example: Because FTP supports the transmission and character-settranslation of text and binary files, FTP is widely used to share filesover the Internet. Some FTP sites restrict access to authorized users withpasswords, which are sent across the wire in clear text. As a result, ahacker could use a packet-sniffer program or a network analyzer such asNovell's LANalyzer for Windows on the public side of your firewall to viewthese passwords. The hacker could then use the passwords to access yourFTP server.

NetRoad FireWALL, like any good firewall, guards against FTP password-breakingattacks (and password-breaking attacks on any other TCP/IP application,such as Telnet, that sends clear-text passwords across the wire) by authenticatingusers who try to connect to the firewall. NetRoad FireWALL authenticatesusers through NDS and one-time password (OTP) authentication using eitherthe MD4 or MD5 message-digest algorithm.

By default, all users are subject to NDS authentication: That is, eachuser must be authenticated to the NDS tree before being granted access toyour network or intranet. You also have the option of enabling OTP authenticationusing MD4 or MD5. (For more information about OTP authentication , see "Once and for All.") OTPs, as the namesuggests, are valid for a single login. Thus, if a hacker intercepted anOTP, he or she could not use that OTP to initiate a session because theOTP is valid only once.

Other Types of Attacks

Because TCP/IP applications have inherent security weaknesses, your networkor intranet is vulnerable to other security attacks. NetRoad FireWALL evaluatesapplication-specific information in each packet generated by all TCP/IPapplications, such as Telnet, FTP, HTTP, and SMTP. For each application,you can specify which source and destination host names you will allow topass through the firewall during what times of day. For some applications,such as FTP, HTTP, and SMTP, you can also specify which file types and commandsyou will allow to pass through the firewall.

For example, suppose that a disgruntled employee tried to move a sensitivedatabase file to a server outside the trusted network using the FTP Putcommand. Because NetRoad FireWALL denies all packets by default, you mustdefine the types of packets you want to allow. For example, if you wantedto allow outgoing packets that contained the FTP Put command, you wouldaccess the NetRoad FireWALL object's Details page in the NWADMIN utilityand click the FTP button on this page. You would then click the OutboundFTP tab to access the Outbound FTP screen. On this screen, you would specifythe file types and commands you want to allow. If you did not explicitlyspecify that you wanted NetRoad FireWALL to accept packets containing theFTP Put command, NetRoad FireWALL would reject these packets.

NOTIFICATION OPTIONS

NetRoad FireWALL can notify you of security attacks in the followingways:

  • An alert that appears on an audit screen at the NetRoad FireWALL server console

  • An alert that appears at a Simple Network Management Protocol (SNMP) management console

  • An alert that appears on a log screen in NDS

  • An alert sent to your pager

  • An alert sent to your e-mail address

To configure NetRoad FireWALL's notification options, you must accessthe Notification Options screen in the NWADMIN utility and select the optionsyou prefer. (See Figure 2.) For each optionyou select, you must specify what level of severity--Extreme, Critical,Severe, Informational, or Warning--a security incident must be associatedwith to warrant this type of notification. To determine how severe a particularsecurity incident is, NetRoad FireWALL uses the security incident classificationscheme devised by Internet Security Systems (ISS) Inc., the company thatprovides the test suite used by the National Computer Security Association(NCSA) to certify firewalls.

Figure 2: You can use the NWADMIN utility to configure the way in which you want NetRoad FireWALL to notify you of security incidents.

For security incidents that are fairly low on the severity scale, suchas a user being denied access to your network or intranet, you might enablethe Audit Screen option so that you are notified of these incidents onlyby way of the NetRoad FireWALL server console. However, for more serioussecurity incidents such as SYN-flooding attacks, you might enable the PagerNotification or E-mail Notification option and set the Severity field toSevere Attacks. You would then be notified of SYN-flooding attacks and otherserious security incidents via pager or e-mail.

The Pager Notification and E-mail Notification options allow you to specifythe length of time you want NetRoad FireWALL to wait after sending the firstnotification and before sending a second notification (assuming that youdon't respond to the first notification). For example, if you configuredNetRoad FireWALL to notify you via pager of all extreme security incidents,you might set a notification interval of 30 minutes. After paging you oncewhen such an incident occurs, NetRoad FireWALL would wait 30 minutes beforepaging you again.

TESTING, 1-2-3

In March 1997,Data Communicationsevaluated 20 firewalls, includingNetRoad FireWALL. TheData Communicationslab used a security scanningtool from ISS to subject these firewalls to nearly 100 types of securityattacks.

NetRoad FireWALL fared exceptionally well, passing all but one test involvinga trace-routing attack, which ISS considers a minor security risk. By performinga trace route on a workstation, a hacker can retrieve information aboutyour network or intranet's topology. For example, a hacker could find outwhether he or she can access a host on your network or intranet, whetherthe host can reply, and which route packets would take to reach this host.

NetRoad FireWALL, like virtually all firewalls, drops trace-routing requestpackets that originate from an untrusted network. However, ISS expects afirewall to do more than simply drop these packets; ISS expects the firewallto respond negatively to a trace-routing request packet by returning anInternet Control Message Protocol (ICMP)"Destination unreachable"message to the host from which the packet originated.

Not everyone in the security industry agrees with the ISS interpretationof the trace-routing test. Some security experts believe that if a firewalldrops trace-routing request packets, as NetRoad FireWALL does, it shouldpass the test. (You can viewData Communicationslab's test methodologyand the test results for NetRoad FireWALL at http://www.data.com/lab_tests/firewalls97.html. These results are also available at http://www.ukiahsoft.com/whatsnew.html.)

In April 1997,NetWare Connectiondid some testing of its own.At our request, network administrator Jason Green installed an evaluationcopy of NetRoad FireWALL to test its ease of installation, its ease of use,and Ukiah's technical support. Green works for Parsons Brinckerhoff, a civilengineering firm in Salt Lake City, Utah that provides World-Wide Web (WWW)services for the Interstate-15 (I-15) reconstruction project run by theUtah Department of Transportation (UDOT).

Green installed NetRoad FireWALL on a NetWare 4.11 server with a Pentium166 MHz processor. NetRoad FireWALL includes seven installation diskettes--onediskette for the server and six diskettes for the workstations. The serverinstallation diskette, which contains the SETUP NLM, is the only disketteyou need to get your firewall up and running. According to Green, the installationprocess"was a snap. You just run the SETUP NLM from the first installationdiskette."Green adds that the SETUP NLM"copies everything onto the server and automatically starts up the firewall."

When you begin the installation process, you have the option of enablingthe IPX-IP gateway. Because Green uses Novell's IPX-IP gateway, he did notenable Ukiah's gateway, which supports TCP and UDP applications. (This gatewayis also available as a separate product called NetRoad FireWARE, which runson a NetWare 3, NetWare 4, or IntranetWare server.)

If Green had enabled Ukiah's IPX-IP gateway, he would have had to installthe Windows 3.x or Windows 95 client software for that gateway on each ofhis nearly 75 IPX/SPX-based workstations. You must install client softwareto use any IPX-IP gateway, Green points out.

Although the installation process was easy, it did not go without theproverbial hitch: Green had some difficulties getting NetRoad FireWALL torun, so he called Ukiah's technical support line. When Green called, heexplained only that he was installing an evaluation copy of NetRoad FireWALLand did not mention that he was doing so on behalf ofNetWare Connection.Green found Ukiah's technical support representatives prompt and"veryhelpful. They answered the question and solved the problem,"Greensays.

Green was impressed with both the installation process and the technicalsupport, but he was even more impressed with NetRoad FireWALL's ease ofuse. Specifically, Green enjoyed NetRoad FireWALL's snap-in module for theNWADMIN utility. With this snap-in module, you can configure everythingfrom the NWADMIN utility that you can configure from the NetRoad FireWALLserver console. Green also enjoyed the fact that NetRoad FireWALL enablesyou to"keep everything in a Novell world--without having to figureout a UNIX firewall."

To actually purchase and install a firewall, Green will have to convincehis managers that Parsons Brinckerhoff needs the level of security thata firewall provides. Green, however, is already convinced. Parsons Brinckerhoffruns Novell Web Server 3.1 for UDOT, which hosts a WWW site containing updatedinformation about the status of its I-15 reconstruction project. For example,this site reveals which exits are closed and which streets to use as alternativeroutes. In April 1997, the site logged"about 500 hits a day,"Green explains. However, he estimates that the number of hits will tripleor quadruple when large-scale construction begins in August.

Because of the increased interest in UDOT's WWW site, Green worries thatthe potential for Internet-related attacks will also increase. As a result,he believes"it would be worth it to install a firewall."Havingexperienced first-hand how easy NetRoad FireWALL is to install and manage--andhaving talked to Ukiah's technical support personnel--Green is sure thatNetRoad FireWALL is the right product for the job.

CONCLUSION

NetRoad FireWALL is available in a 10-, 25-, 50-, 100-, 150- and 250-userversion. You can purchase NetRoad FireWALL beginning at the suggested retailprice of U.S. $995 for a 10-user version and running up to $9,995 for a250-user version.

The number of users each NetRoad FireWALL server supports depends onseveral factors, such as the capacity of your hardware, the speed of yournetwork or Internet connection, and the software running on your server.For example, to screen Internet traffic for up to 50 workstations on yournetwork or intranet over an E-1 connection (2.048 Mbit/s), Ukiah recommendsthat you run NetRoad FireWALL on a computer with a Pentium 133 MHz processorand 16 MB of RAM. For more than 50 workstations, you should increase theamount of RAM to at least 32 MB.

For more information about Net-Road FireWALL, you can call 1-800-98UKIAHor 1-408-369-2890. You can also send an e-mail message to sales@ukiahsoft.com, or you can visit Ukiah's WWW site (http://www.ukiahsoft.com).

Linda Boyer works for Niche Associates, an agency that specializesin technical writing and editing. Niche Associates is based in Salt LakeCity, Utah.

NetWare Connection, July 1997, pp.38-45

The Perfect Union: Novell's BorderManager and Ukiah's NetRoad FireWALL

Ukiah's NetRoad FireWALL has a few things in common with Novell's BorderManager (formerly code-named Border Services): Both products run on IntranetWare and NetWare 4, integrate with NDS, include an IPX-IP gateway, and protect TCP/IP- and IPX/SPX-based workstations. However, BorderManager and NetRoad FireWALL are very different, and the key to understanding the difference between them lies in the scope of each product.

Novell's BorderManager is an integrated set of NetWare Loadable Modules (NLMs) that addresses the security, management, performance, and connectivity problems associated with the border--the point at which your network or intranet meets the Internet. BorderManager protects your network or intranet by providing a packet filter, a circuit-level gateway, and a HyperText Transport Protocol (HTTP) proxy. BorderManager also simplifies management by including a snap-in module for the NetWare Administrator (NWADMIN) utility.

In addition, BorderManager improves performance by caching frequently accessed World-Wide Web (WWW) files, and BorderManager offers several connectivity options by including NetWare MultiProtocol Router, NetWare Connect, and a virtual private network (VPN) configuration tool that enables you to securely connect geographically distant sites over Internet lines. In short, BorderManager is a single product that offers the capabilities of several products. (See "Novell's Border Services," NetWare Connection, May 1997, pp 2536.

In contrast, Ukiah's NetRoad FireWALL addresses only one problem associated with the border: security. NetRoad FireWALL includes a packet filter, a circuit-level gateway, and an application-level gateway that filters packets generated by all TCP/IP applications, such as Telnet, FTP, HTTP, and Simple Mail Transfer Protocol (SMTP). By default, NetRoad FireWALL denies all incoming and outgoing packets, but you can configure rules to allow particular types of packets based on the source and destination IP address, the application or protocol, the source and destination port number, the time of day, and the file type.

Like BorderManager, NetRoad FireWALL also includes a snap-in module for the NWADMIN utility, which you can use to configure these rules. In addition, NetRoad FireWALL supports a one-time password (OTP) authentication scheme, which ensures that hackers who eavesdrop on your network connection cannot use the passwords they intercept to log in to your network or intranet.

If you need accelerated WWW access, a VPN, remote connectivity, a multilevel firewall that supports all TCP/IP applications, and the convenience of managing these capabilities with the NWADMIN utility, running Novell's BorderManager side-by-side with Ukiah's NetRoad FireWALL would be an ideal solution.

Transparent Proxy Protection

Ukiah's NetRoad FireWALL includes transparent application-level proxies for TCP/IP-based workstations. A proxy is a software process that filters packets based on application-specific information. Typically, you must configure each user's World-Wide Web (WWW) browser to access particular TCP/IP applications by way of a corresponding proxy. For example, if you wanted users to access FTP sites through your firewall, you would have to configure these users' WWW browsers to access FTP sites by way of your firewall's FTP proxy.

This process is not required if you use NetRoad FireWALL. Instead, NetRoad FireWALL's transparent application-level proxies intercept all Internet traffic without requiring you to configure users' WWW browsers or load additional software on these users' workstations. These proxies, which support any operating system on workstations running a TCP/IP stack, intercept packets generated by TCP applications such as Telnet, FTP, HyperText Transport Protocol (HTTP), and Simple Mail Transfer Protocol (SMTP), as well as packets generated by User Datagram Protocol (UDP) applications such as Real Audio (which also uses TCP/IP).

IPX/SPX-based workstations, on the other hand, must access the Internet through NetRoad FireWALL's IPX-IP gateway. You must load NetRoad FireWALL's client software for Windows 3.x, Windows for Workgroups, and Windows 95 on these workstations so they can communicate with the IPX-IP gateway. The client software also enables IPX/SPX-based workstations to run all TCP and UDP applications.

Once and for All

Hackers often eavesdrop on a network connection (using a packet-sniffer program or a network analyzer) to intercept a legitimate remote user's login name and password--an attack called a replay attack. Hackers can then use this login name and password to access your network or intranet--and who knows what a hacker will do once he or she has logged in as a trusted user.

With Ukiah's NetRoad FireWALL, you can counter replay attacks by requiring remote users to authenticate to your network or intranet using one-time password (OTP) authentication. OTP authentication guards against replay attacks by ensuring that remote users enter a different password each time they log in to your network or intranet. Thus, a hacker who is eavesdropping on a session protected by OTP authentication will not intercept any useful information, even if the hacker obtains a transcript of the session.

You create users' OTP accounts on the NetRoad FireWALL Access screen in the NetWare Administrator (NWADMIN) utility. To access this screen, click the NetRoad FireWALL Access button on the User object's Details page. This button is automatically created when you install the NetRoad FireWALL snap-in module for the NWADMIN utility.

On the NetRoad FireWALL Access screen, you enable an OTP account, assign a password, and choose the message-digest algorithm (MD4 or MD5) you want NetRoad FireWALL to use to create and read this user's OTP. MD4 and MD5 were developed by Ron Rivest in 1990 and 1991, respectively. MD5 is more secure than MD4, but MD5 is slightly slower.

Basically, OTP authentication involves two processes:

  • A user's workstation generates an OTP.

  • NetRoad FireWALL verifies that the OTP is valid.

When a user for whom you have created an OTP account tries to access your network or intranet, NetRoad FireWALL sends a number and a string of characters, called the seed, to the user's workstation. The user then enters the number, the seed, and the password you assigned this user in the NWADMIN utility into the OTP calculator running on his or her workstation. NetRoad FireWALL includes an OTP calculator for Windows 3.x and Windows 95, but you can also use third-party OTP calculators that support MD4 or MD5 and S/KEY (an OTP authentication scheme developed by Bellcore).

The user's OTP calculator then sends the user's password and the seed through MD4 or MD5, repeating the operation for the number of times that corresponds to the number NetRoad FireWALL sent to the user. This process yields an OTP, a unique password that the user can use--and NetRoad FireWALL can accept--once and only once.

The user's OTP calculator sends the OTP to NetRoad FireWALL, which verifies this OTP. To determine whether the OTP is valid, NetRoad FireWALL uses the same algorithm (MD4 or MD5) that the user's OTP calculator used. NetRoad FireWALL then compares the result with the OTP sent by the user's OTP calculator. If they match, NetRoad FireWALL allows the user to access your network or intranet. If they don't match, NetRoad FireWALL denies the user access.

* Originally published in Novell Connection Magazine


Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates