BorderManager 3.0: Patrolling the Borders of Your Network

Articles and Tips:

Linda Boyer

01 Oct 1998

WhenNetWare Connectionintroduced you to Novell's BorderManager 18 months ago, the termborderwas relatively new in the networking industry. Now this term is widely used to refer to the points at which a network meets another network. External borders, such as the border between your company's network and the Internet, are typically secured with a firewall to guard against hacker attacks--that is, attacks launched by unauthorized users.

Interestingly, hacker attacks are not as common as insider attacks, which involve trusted, authorized users. In fact, the 1998 Annual Industry Survey conducted byInformation Securityreveals that employee access abuses are one of the most common security breaches (second only to viruses). Specifically, 54 percent of companies that participated in the 1998 Annual Industry Survey experienced a security breach involving an employee, while only 12 percent of these companies experienced a hacker attack. (Information Securityis the official publication of the International Computer Security Association, or ICSA, formerly known as the NCSA. To read the 1998 Annual Industry Survey, go to http://www.icsa.net/magazine, and select the June 1998 option from the Archived Articles menu.)

You can reduce the chances of experiencing an insider attack by strengthening security on the internal borders between your company's departmental networks. And you can use BorderManager 3.0 to help you do the job. (For more information about protecting internal borders, see "Mini-Firewalls for Internal Web Servers.") BorderManager 3.0 is the latest version of BorderManager, the only integrated family of directory-based network services that centrally manages, secures, and accelerates users' access to information at every network border--internal and external alike.

As with previous versions of BorderManager, BorderManager 3.0 enables you to implement mini-firewalls at departmental borders. Naturally, you can also use BorderManager 3.0 to secure your company's Internet border.

Furthermore, because BorderManager 3.0 remains fully integrated with Novell Directory Services (NDS), you can easily control users' access through these borders. For example, by using the BorderManager snap-in module for Novell's NetWare Administrator (NWADMIN) utility, you can control where users go on your company's network or the Internet, when they can go there, and what level of access they have once they get there. You can also control when and which users can access your company's network from the Internet.

Of course, you could use any version of BorderManager to secure internal and external borders. So what's new in BorderManager 3.0? In short, BorderManager 3.0 is the same, only better. BorderManager 3.0 is faster, more secure, and more convenient to manage than previous versions of BorderManager. With BorderManager 3.0, Novell has enhanced BorderManager's three strong suits: performance, security, and management.

HTTP AND FTP--YOU'LL WANT THAT IN CACHE

Although BorderManager has many valuable features, it is perhaps best known for BorderManager FastCache, Novell's proxy cache. In fact, today more than four million users use BorderManager FastCache to speed users' access to the Internet or an intranet, to accelerate a World-Wide Web site, and to reduce network bandwidth requirements.

Previous versions of BorderManager offered only an HTTP proxy cache and an HTTP accelerator, which you can use to store pages requested from HTTP, FTP, or Gopher servers. Using a feature callednormal caching, orpassive caching,the HTTP proxy cache allows you to store pages that internal users request from external web sites (such as web sites on the Internet). Using a feature called acceleration, orreverse caching,the HTTP accelerator allows you to store pages that external users request from internal web sites (that is, web sites on your company's intranet).

In addition to the HTTP proxy cache and the HTTP accelerator, BorderManager 3.0 now includes an FTP proxy cache and an FTP accelerator. As a result, BorderManager 3.0 performs FTP caching when users are accessing FTP through a native FTP application. Because previous versions of BorderManager included only an HTTP proxy cache and an HTTP accelerator, these versions performed FTP caching only when users accessed FTP through a web browser.

You can use the BorderManager snap-in module for the NWADMIN utility to set caching options for the HTTP and FTP proxy caches and for the HTTP and FTP accelerator. (See Figure 1.) The passive and reverse caching options are the same for HTTP and FTP. For example, you can configure the following options:

Figure 1: You can use the snap-in module for the NWADMIN utility to set caching options for BorderManager 3.0 servers.

The location of the cache
The maximum size of pages stored in cache
The number of minutes, hours, or days BorderManager 3.0 should wait before retrieving a page again from the original web site
Pages you do not want to cache

Fetch!

All of these options allow you to customize BorderManager FastCache for your company's network and make BorderManager FastCache fast. But just how fast can BorderManager FastCache be? In a keynote address at BrainShare '98 in Salt Lake City, Drew Major, Novell's chief scientist and vice president of advanced development, claimed that BorderManager FastCache is capable of processing more than 5,000 hits per second when configured to run from RAM (as opposed to running from the hard drive). BorderManager FastCache, according to Major, is 5 to 10 percent faster than other proxy servers also configured to run from RAM. (You can view a video of Major's keynote address at http://www.novell.com/webcast/98/bs98/index.html#major.)

Major's opinion is arguably biased, but opinions from unbiased sources are notably similar. For example, according to Mindcraft Inc., an independent testing company, BorderManager FastCache can process 4,055 hits per second--that's 350 million hits per day.

To place 350 million hits per day in context, consider this: In a recentPC Weekarticle entitled "Microsoft.com's Poor Performance Frustrates Users," author Norvin Leach implies that Microsoft has acknowledged its web site is sluggish. According to Leach, Microsoft "attributes the problems partly to skyrocketing usage, which officials are estimating at 88 million hits per day." (SeePC Week, June 30, 1997. You can download this article from http://www.zdnet.com/pcweek/archive/1428/pcwk0118.html.)

If Leach's claim is true, Microsoft's excuse for its web site's poor performance is both revealing and weak. The excuse is revealing because it implies that Microsoft's own proxy cache technology is not up to the task of supporting www.microsoft.com. And the excuse is weak because BorderManager FastCache can efficiently process nearly four times the number of hits per day that are apparently slowing Microsoft's web site.

In BorderManager 3.0, BorderManager FastCache is even faster. BorderManager 3.0 now offers two additional options for HTTP and FTP caching that speed the caching process:

Read-ahead caching
Scheduled batch downloads

Read-Ahead Caching

Read-ahead caching, also calledactive caching, is intelligent caching. That is, with read-ahead caching, the proxy cache makes intelligent assumptions about what the web browser will request next, such as images on a page. The proxy cache automatically requests what it assumes the web browser will request--and makes that request without waiting for further instructions from the web browser.

How important are read-ahead capabilities? A proxy cache without read-ahead capabilities will not retrieve an object unless the web browser explicitly requests the object--no matter how obvious it is that the web browser will request that object next. For example, when a web browser requests a particular URL, the proxy retrieves the page and stores it in cache. This page most likely includes path names to embedded objects (such as images) that the web browser will almost certainly request next.

However, a proxy cache without read-ahead capabilities does not anticipate the next request that a web browser will make. Instead, this type of proxy cache waits for the web browser to open the page and to send separate requests for embedded objects on that page.

Of course, a proxy cache with read-ahead capabilities makes this retrieval process quite a bit faster. For example, when a web browser requests a particular URL, a proxy cache with read-ahead capabilities retrieves the page and, upon finding path names to embedded objects, retrieves these objects as well.

When the web browser opens the page and sends separate requests for embedded images, the proxy cache with read-ahead capabilities has already retrieved these objects. Thus, the embedded objects are stored in cache, ready to be sent to the web browser in an instant.

In BorderManager 3.0, you enable read-ahead caching on the Cache Control screen, which you can access by clicking the Caching button on either the Acceleration screen or the Proxy Cache screen in the NWADMIN utility. (See Figure 1.) BorderManager 3.0 offers two read-ahead caching options, in addition to the option of disabling read-ahead caching:

Read-ahead images embedded in the page
Maximum number of concurrent read-ahead requests

When you select the first option, BorderManager FastCache retrieves embedded objects on a requested page without waiting for the web browser to request these objects.

You can also specify the maximum number of concurrent read-ahead requests, which limit the number of embedded images that BorderManager can retrieve at one time. In this way, you can prevent the proxy cache from becoming overburdened.

Scheduled Batch Downloads

BorderManager 3.0 also offers scheduled batch downloads for the HTTP proxy cache and the HTTP accelerator. Scheduled batch download capabilities, like read-ahead caching capabilities, make BorderManager FastCache even faster.

Scheduled batch download capabilities allow you to download particular URLs when network utilization is low. You can use scheduled batch downloads to download frequently accessed web sites, so BorderManager FastCache is always current and contains the web sites that users request most often.

In addition, BorderManager 3.0 allows you to specify the frequency of scheduled batch downloads. For example, you can specify that you want a particular download to occur once only, once a day, on particular days of the week, or during the hours you specify. For each URL you want to download at a scheduled time, you can also indicate how many levels deep BorderManager FastCache should go--that is, how many embedded images BorderManager FastCache should retrieve and store.

TIGHTENING UP SECURITY AT THE BORDER

Although BorderManager provides caching, it is much more than a proxy server. BorderManager also offers several firewall security features. All versions of BorderManager are well-fortified with security features, including network address translation (NAT), packet filtering, the Novell IP gateway, and the HTTP application proxy. With BorderManager 3.0, Novell has enhanced nearly all of these security features and has added a new one: alerts delivered via Simple Mail Transfer Protocol (SMTP) or Simple Network Management Protocol (SNMP).

Many customers who used previous versions of BorderManager reported the need for alerts. In fact, Patrick Harr, a product manager at Novell, says that Novell "received a lot of feedback about including an alert mechanism as a core feature." As a result, Harr explains, Novell built alerts into BorderManager 3.0, which can now alert you to particular security violations, including various denial-of-service attacks and the Ping of Death.

The Ping of Death is notorious for bringing down Microsoft's web site in June 1997. The Ping of Death refers to an attack that involves sending an unusually large ping packet--larger than 65,536 bytes--from a remote computer to a server. A ping packet, which is typically about 65 bytes, contains an Echo message. Generally, a server or a client uses Internet Control Message Protocol (ICMP) to "ping" another server or client to check the performance of that server or client. Because many systems cannot handle an unusually large ping packet, they often crash or reboot when faced with one--just as Microsoft's web site did.

To prevent the Ping of Death from wreaking havoc on your company's network, BorderManager 3.0 warns you when a server has been hit by the Ping of Death or by other types of attacks. You can then respond immediately to attacks that threaten to bring down the network.

You enable alerting by using the BorderManager snap-in module for the NWADMIN utility. You can then specify whether you want BorderManager 3.0 to alert only you or to alert other people whom you specify as well. In addition, you can indicate whether you want the alerts delivered by way of an e-mail message (using an SMTP gateway), by way of a pager (using an e-mail-to-pager gateway), or by way of messages sent through an SNMP-compliant management application, such as Novell's ManageWise.

CREATING SECURE RETURN PATHS

In addition to adding alerting capabilities, Novell made several enhancements to the security features available in BorderManager 3.0. For example, Novell enhanced the following security features:

The packet-filtering firewall
The circuit-level gateway
The application-level gateway

All versions of BorderManager provide a packet-filtering firewall, which allows you to filter TCP/IP packets based on source and destination address, port number, and protocol. BorderManager 3.0, however, includes two new filters. Using Novell's familiar FILTCFG utility, which is included with BorderManager 3.0, you can enable the following filters:

Stateful filters
ACK bit filters

State of Security

Stateful filters automatically create return paths for outbound packets, enabling internal users to communicate with the outside world while preventing unwanted outsiders from initiating sessions with these users. When you enable a stateful filter, BorderManager 3.0 automatically creates a return path for traffic flowing from the source port number and address you specify to the destination port number and address you specify. You can then block traffic originating from a particular port number and address while still allowing return traffic from that same port number and address.

Stephen Wu, an engineer at Novell, explains stateful filters by using the following example: Suppose that you wanted to allow users to access external FTP servers but you wanted to block FTP traffic originating from an external source. Enabling a stateful filter for a dynamic port range on your private network interface board and the FTP port (21) on your public network interface board would do the trick.

To enable a stateful filter, you would use the FILTCFG utility to specify the source and destination interfaces, the packet type, and the source and destination port numbers and IP addresses to which this filter should apply. You would then simply choose to enable the Stateful Filter option. The example below shows the information you would specify:

Src Interface

Dest Interface

Packet Type

Src Port

Dest Port

Src Address

Dest Address

ACK Bit Filter

Stateful Filter

Private

Public

TCP

1024-65535

21

Any

Any

Disable

Enable

In previous versions of BorderManager, you could configure static filters to filter inbound traffic originating from external sources. Admittedly, static filters are a bit faster than stateful filters. However, Wu explains, there are two advantages to using stateful filters rather than static filters to screen traffic originating from external sources. One advantage is that a stateful filter is inherently more secure than a static filter because there is less chance for human error in configuring a stateful filter than in configuring a static one.

Why? In order to use a static filter to filter inbound traffic originating from an external source, you would have to configure a total of six filters: two for the control channel, two for the PORT data channel, and two for the PASV command data channel. In contrast, to use a stateful filter, you need to configure only one filter. The convenience of enabling one filter versus six filters is the second advantage to using a stateful filter.

Don't Let 'Em In Without ACK

ACK bit filters (sometimes called SYN bit filters) ensure that only TCP packets containing the ACK bit set can pass through the firewall. To better understand how an ACK bit filter works, you must first understand the handshaking that servers and clients use when they establish TCP sessions. This handshaking involves an exchange of TCP packets containing SYN (synchronize) bits and ACK (acknowledge) bits.

The first packet in a TCP session contains the SYN bit set and indicates a request to open a session. The return packet contains the ACK bit set, acknowledging the receipt of the initial SYN packet. This return packet also contains a SYN bit set, indicating the recipient server's willingness to synchronize (that is, establish) a session with the requesting client.

For example, suppose that a client on your company's network tried to establish a session with an external server. The handshaking between the server and the client would occur as follows:

Client A would initiate a session with server B by sending a SYN(a) packet to server B.
Server B would respond by sending an ACK(a) packet, along with a SYN(b) packet, to Client A.
Client A would finish the handshaking with an ACK(b) response to server B.

Now suppose that you wanted to allow users to access external Telnet servers. To allow Telnet clients to connect to Telnet servers, you could configure a filter. This filter would allow outgoing packets from a dynamic port range on your private network interface board, such as 1025-65535, to access port 23 (the port Telnet services typically use) on your public network interface board.

You would also need to configure a filter that would allow incoming packets from port 23 to access dynamic port range 1025-65535. However, as Jayakumar Ramalingam, an engineer at Novell, explains, configuring such filters creates a "hole because a bad guy could use port 23 as a source port to connect to services available in the dynamic port range on your private network interface board."

You can plug such holes by enabling an ACK bit filter when you create the filter to allow incoming packets from port 23 bound for the dynamic port range 1025-65535. If you enable an ACK bit filter in this situation, incoming packets from port 23 on the public interface board would be able to access the dynamic port range 1025-65535 only if these packets contained the ACK bit set. In other words, port 23 could not be used to initiate TCP sessions using the specified port range because packets that initiate TCP sessions contain only SYN bits--they don't contain ACK bits.

In short, an ACK bit filter prevents incoming packets without ACK bits from entering your company's network. As a result, internal users can initiate TCP sessions with the outside world, but the outside world cannot initiate TCP sessions with internal servers or clients.

Using an ACK bit filter protects your company's network from common attacks, such as SYN flooding attacks. A SYN flooding attack is a denial-of-service attack that a "bad guy" initiates by overloading your network with SYN-flagged packets and effectively locking out legitimate session requests for TCP sessions.

MORE CLIENTS, LESS WORK

Novell didn't stop at enhancing its packet-filtering firewall, however. When creating BorderManager 3.0, Novell also enhanced its circuit-level gateway, the Novell IP gateway. (For more information about circuit-level gateways, see "Great Walls of Fire,"NetWare Connection, Jan. 1997, pp. 6-28. You can download this article from http://www.nwconnection.com/jan.97/fire17.)

The Novell IP gateway in BorderManager 3.0 and in previous versions of BorderManager consists of two components: an IPX-to-IP gateway and an IP-to-IP gateway. In previous versions of BorderManager, the Novell IP gateway enabled Windows 95 clients using IPX or IP to access the Internet without requiring you to assign a specific IP address to each workstation. (For more information on the Novell IP gateway, see "Novell's Border Services," May 1997,NetWare Connection, pp. 25-36. You can download this article from http://www.nwconnection.com/may.97/border57.) BorderManager 3.0 extends this support to Windows 98 clients and Windows NT servers and clients.

If you are already using BorderManager, you might be thinking that supporting additional clients means additional work. But that is not the case. Unlike previous versions of BorderManager, BorderManager 3.0 supports WINSOCK 2.0. As a result, you no longer have to replace the WINSOCK software running on Windows clients with Novell's own WINSOCK software. The Novell IP gateway in BorderManager 3.0 supports the WINSOCK software that is already running on Windows clients.

PROXY PATROL

BorderManager has always included an HTTP proxy, which is an application-level gateway. An application-level gateway provides the highest level of firewall security available, enabling you to control not only which ports and addresses users can access but also which files they can access using these ports and addresses. (For more information about application-level gateways, see "Great Walls of Fire,"NetWare Connection.)

All versions of BorderManager include the HTTP proxy to provide this degree of control. However, only BorderManager 3.0 offers the transparent HTTP proxy.

In previous versions of BorderManager, you had to configure each workstation's web browser to ensure those web browsers used the HTTP proxy. In contrast, the transparent HTTP proxy included in BorderManager 3.0 allows web browsers to use the HTTP proxy without requiring you to configure these browsers on individual workstations. You don't have to configure web browsers on workstations running Novell's 32-bit client software, and you don't have to configure web browsers on workstations that are not running this client software.

All Internet-bound traffic from workstations running Novell's 32-bit client software flows through the BorderManager server. When the TCP/IP stack on the BorderManager server receives this traffic and finds that it is bound for port 80 (the port HTTP services typically use), the TCP/IP stack redirects that traffic to the HTTP proxy on the same server.

For workstations that are not running Novell's 32-bit client software, you do have to do some configuring--but not on hundreds of individual workstations. Instead, you configure your internal router or switch to direct all Internet-bound traffic from workstations that are not running Novell's 32-bit client software to the BorderManager server. By doing so, you ensure that users at these workstations who try to access HTTP services do so "transparently." The internal router or switch routes HTTP traffic from these workstations to the BorderManager server. In addition, when the TCP/IP stack on the BorderManager server receives traffic bound for port 80 from workstations not running the 32-bit client software, the TCP/IP stack redirects that traffic to the HTTP proxy.

More Proxies, More Security, More Control

The bad news is you must configure applications on individual workstations to use the other proxies available in BorderManager 3.0. Which brings us to the good news: BorderManager 3.0 includes seven new application proxies, in addition to the HTTP proxy:

An FTP proxy
An SMTP/Post Office Protocol 3 (POP3) proxy
A Network News Transfer Protocol (NNTP) proxy
A Domain Naming System (DNS) proxy
A Real Audio/Real Video proxy
A generic TCP proxy
A generic User Datagram Protocol (UDP) proxy

The generic TCP proxy and the generic UDP proxy allow you to create your own proxies for any TCP or UDP applications for which BorderManager 3.0 does not yet provide a specific proxy. These generic application proxies enable you to route applications through the BorderManager 3.0 server, so you don't have to configure packet filters for these applications. For example, you might want to create a proxy for the Telnet server on your company's network. (See Figure 2.)

Figure 2: You can use generic application proxies to create your own proxies for a TCP or UDP application.

As with all proxies, a proxy for this Telnet server would ensure that there was never direct communication between Telnet clients and the Telnet server. Telnet clients would communicate only with the BorderManager server, and the Telnet proxy on that server would relay messages between the Telnet clients and the Telnet server. Although Telnet clients would be communicating through the Telnet proxy, it would appear to these clients that they were communicating directly with the Telnet server. That's the beauty of application proxies.

You can configure specific access controls for each of the new application proxies included in BorderManager 3.0. Naturally, all of the access controls previously available for the HTTP proxy are still available in BorderManager 3.0. (See Figure 3.) You can control users' access to the application proxies (including the proxies you create using the generic TCP or UDP proxy) based on one or all of the following options:

Figure 3: You can use the snap-in module for the NWADMIN utility to control users' access to application proxies.

Days of the week
Times of the day
Source information, which can be NDS objects, DNS host names, host addresses, or subnet addresses
Destination addresses, which can be specific URLs

In addition, for many of the new application proxies, including the SMTP/POP3 proxy and the NNTP proxy, you can configure specific access controls. For example, for the SMPT/POP3 proxy, you can screen packets based on the source or destination e-mail username or domain name. And for the NNTP proxy, you can screen packets based on the name of the destination news group.

INTERFACE LIFT

I have already mentioned several of the management conveniences provided by BorderManager 3.0: the support for WINSOCK 2.0, which eliminates the need to replace the WINSOCK software on Windows clients; the transparent HTTP proxy, which eliminates the need to configure web browsers on individual workstations; and the BorderManager snap-in module for the NWADMIN utility, which you can use to manage most BorderManager features (including protocol gateways, application proxies, and access control rules).

In previous versions of BorderManager, you had to run the BorderManager snap-in module for the NWADMIN utility on a Windows 95 workstation. Support for Windows 98 and Windows NT was available, but only as a patch. The snap-in module for BorderManager 3.0, however, supports Windows NT, Windows 98, and Windows 95 out of the box, so you can use whichever platform you prefer.

As you might expect, Novell has changed the screens in the snap-in module for BorderManager 3.0, primarily to accommodate new BorderManager features. For example, in previous versions of BorderManager, you were able to access all of the screens that would enable you to perform management tasks by clicking the Setup button from the Details page for the BorderManager Server object. In BorderManager 3.0, the BorderManager Server object offers two new details, in addition to the BorderManager Setup detail:

BorderManager Alert, which you use to enable alerts
BorderManager Access Rules, which you use to configure all outgoing rules

The BorderManager Alert detail is entirely new to BorderManager 3.0. The BorderManager Setup detail and the BorderManager Access Rules detail are modified versions of screens you have seen before.

Novell also enhanced the logs in BorderManager 3.0. In previous versions of BorderManager, you could view service logs only through the NWADMIN utility, and you could not print these logs. The only exceptions to these restrictions were the logs for the HTTP proxy. BorderManager 3.0, on the other hand, allows you to export all log files to a text file, which you can then import into a spreadsheet or word-processing application to view and print.

You can combine these log files into one text file, or you can create a separate text file for each service. And if you are using the HTTP accelerator for multiple web sites, you can create a separate text file for each web site. For example, an Internet service provider (ISP) hosting multiple web sites could provide each customer with a customized log.

To create reports that are even easier to read, you can import the log text files into WebTrends, a log analysis tool from WebTrends Corp. WebTrends produces graphical reports and charts.

BorderManager 3.0 includes another more noticeable, interface-related change as well: BorderManager 3.0 offers a new Java-based GUI installation utility. This wizard-driven utility is similar to the Java-based GUI installation utility shipping with NetWare 5. (For more information about the Java-based GUI installation utility, see "Installing NetWare 5 With a Graphical Utility,"NetWare Connection, Sept. 1998, pp. 12-19. You can download this article from http://www.nwconnection.com/sep.98/install98.) This fact should come as no surprise to you, once you learn that NetWare 5 is the default operating system for BorderManager 3.0. BorderManager 3.0 even includes a two-user version of NetWare 5.

The user-friendly installation utility included with BorderManager 3.0 was designed to make installation easy--even for users who have never installed a Novell product. "What we're trying to accomplish with this new GUI installation utility," explains Simon Kandah, a product marketing manager at Novell, "is to leave users with an up-and-running BorderManager server with a default configuration by the end of the installation process." In previous versions of BorderManager, even after you installed the software, you had to perform a couple of extra steps before the BorderManager server was up and running.

SINGLE SIGN-ON

In addition to its interface lift, BorderManager 3.0 offers a few other management enhancements that will probably make your life--and users' lives--easier. For example, in previous versions of BorderManager, users who attempted to access a web site through the HTTP proxy had to log in to this proxy using a unique username and password, rather than their NDS username and password. The username and password users entered to authenticate to the HTTP proxy had to be different than their NDS username and password because the authentication information was sent over the wire in clear text. As a result, someone could potentially discover usernames and passwords and compromise security for the entire network.

With BorderManager 3.0, users at workstations running Novell's 32-bit client software do not need to log in to the HTTP proxy at all. These users log in just once to NDS, which provides the background check necessary to enable authentication to the HTTP proxy.

So what about users at workstations that are not running Novell's 32-bit client software, such as users at UNIX and Macintosh workstations? Admittedly, these users have to log in to the HTTP proxy. But the good news is, users at such workstations can use their NDS username and password to authenticate to the HTTP proxy.

Get Your SOCKS On!

Users at workstations that are not running Novell's 32-bit client software can use their NDS username and password to authenticate to the HTTP proxy for two reasons: BorderManager 3.0 supports SOCKS versions 4 and 5, and BorderManager 3.0 supports a number of authentication methods, including real NDS authentication and authentication using the Secure Sockets Layer (SSL) protocol. (With real NDS authentication, passwords never cross the wire.)

SOCKS is a security mechanism that enables a server inside a firewall to access resources outside that firewall while maintaining the internal server's security requirements. SSL, a protocol designed by Netscape Communications, provides for encrypted, authenticated communications across intranets and the Internet and between servers and web browsers.

If you want to enable users at workstations that are not running Novell's 32-bit client software to authenticate to the HTTP proxy using their NDS username and password, you must configure the BorderManager server as a SOCKS server to which SOCKS clients can then connect. Naturally, these workstations must be running SOCKS client software. SOCKS client software is available for UNIX and Macintosh, but this client software is not included with BorderManager 3.0.

To configure a BorderManager server as a SOCKS server, you choose the Gateway tab from the BorderManager Setup detail and, from the Gateway window, double-click the SOCKS V4 and V5 button. The next window that appears allows you to configure the BorderManager server as a SOCKS server. For example, you can specify the authentication method you want users to use when accessing the BorderManager server. You can select the following authentication options:

No authentication required, and data in clear text
No authentication required, but data encrypted using SSL
Authentication required (using NDS username and password), and data in clear text
Authentication required (using NDS username and password), and data encrypted using SSL
Real NDS authentication, and data in clear text
Real NDS authentication, and data encrypted using SSL

You can also configure a BorderManager server as a SOCKS client. You can then use BorderManager 3.0 inside a space protected by a SOCKS-compliant firewall, thereby preserving your company's investment in its existing firewall.

To configure a BorderManager server as a SOCKS client, you would click the SOCKS Client button shown on both the Acceleration tab and the Application Proxies tab in the BorderManager Setup detail. The SOCKS Client window allows you to specify the address of the SOCKS server to which you want the BorderManager server to authenticate.

For example, suppose that you were using BorderManager 3.0 to protect an internal border between your company's network and the web server for the human resources department. Also suppose that you had already installed a third-party, SOCKS-compliant firewall on the border between your company's network and the Internet. If you wanted users in the human resources department to use BorderManager 3.0 services to access the Internet (including an application proxy or the Novell IP gateway), these users could do so only if the BorderManager server could authenticate to the firewall.

To ensure that the BorderManager server could authenticate to the firewall, you would configure the BorderManager server on the internal border as a SOCKS client. You would then specify the firewall's IP address as the SOCKS server to which you wanted the BorderManager server (configured as a SOCKS client) to authenticate. Thereafter, Internet requests from users in the human resources department would pass through the BorderManager server, which would forward these requests to the firewall.

THERE'S MORE WHERE THAT CAME FROM

Although this article discusses several of the new features available in BorderManager 3.0, it does not discuss all of them. There are more where these features came from, but you'll have to check out BorderManager 3.0 for yourself to discover every one. For example, the site-to-site virtual private network (VPN) included with BorderManager 3.0 now supports the IP Security (IPSec) protocol and the Simple Key Management for Internet Protocol (SKIP). (For more information about VPNs and about IPSec and SKIP, see "Virtual Private Networks: Making a Public Network Private,"NetWare Connection, February 1998, pp. 6-21. You can download this article from http://www.nwconnection.com/feb.98/vpn28.)

Novell chose to support these emerging industry standards to increase the potential for interoperability between the BorderManager VPN and other VPNs that also support IPSec and SKIP. Of course, at this stage, no VPN vendor can guarantee interoperability. A. E. Natarajan, engineering manager for Novell's BorderManager group, points out that while support for IPSec and SKIP ensures interoperability on the wire, it cannot guarantee interoperability between VPN configurations. The Internet Engineering Task Force (IETF), Natarajan says, is still working to resolve problems related to interoperability between VPN configurations.

Novell also offers several value-added services for BorderManager 3.0, including BorderManager Authentication Services and the new client VPN services. (For more information about client VPN services, see "Take Your Work Home--or Wherever.")

The number of features in BorderManager--even before BorderManager 3.0--promptedNetwork Magazineto name it the Product of the Year for 1998 in the Proxy Server category. (See "1998 Products of the Year,"Network Magazine, Apr. 1998. You can also download this article from http://www.networkmagazine.com/magazine/archive/1998/04/9804poy.htm. To access this issue, however, you must complete an online membership form.)

Interestingly, Network Magazine admits that the label proxy server is essentially "obsolete. Novell has taken this product niche," the article explains, "and gone many levels above what anyone else is doing." The article goes on to say that BorderManager FastCache is only the beginning of Novell's offering and then devotes a paragraph to listing a few, but certainly not all, of BorderManager's other features--for example, NAT, firewall security features, and VPN capabilities. The new features available in BorderManager 3.0 further extend this list. In fact, next year,Network Magazinewill probably need more than a paragraph to list all of the features available in BorderManager 3.0.

Linda Boyer is a frequent contributor toNetWare Connection. She works for Niche Associates, an agency that specializes in writing and editing technical documents. Niche Associates is located in Sandy, Utah.

NetWare Connection,October 1998, pp. 6-21

Keep the Home Mini-Firewalls Burning

Few companies would consider attaching their corporate World-Wide Web sites to the Internet without first setting up firewalls for protection. Yet most companies feel perfectly comfortable leaving their internal web sites unprotected. Most companies seem to be under the impression that they are safe within their private networks. After all, they have installed firewalls to protect themselves from what they perceive as the real threat: attacks from outsiders. However, this perception is far from the truth.

The truth is that you would be better off leaving your Internet connections unprotected than leaving your internal web sites unprotected. According to the International Computer Security Association (ICSA), more than 80 percent of all security breaches involving someone gaining unauthorized access to information occur inside of firewall-protected borders. (See Firewall Buyer's Guide at http://www.icsa.net.)

The implication of this statistic is quite clear: You really need to protect your internal web sites. You need to set up mini-firewalls to protect your internal borders. BorderManager 3.0 is well-suited for the job of protecting internal borders.

WRAP YOUR INTERNAL WEB SERVERS

Novell recommends that you use BorderManager 3.0 as a "security wrapper" around your internal web servers. One way to create a security wrapper would be to place your internal web servers on a separate network segment and install a BorderManager 3.0 server in front of that segment. All traffic to and from those web servers would filter through the BorderManager 3.0 server.

To control access to the web servers, you could use the BorderManager snap-in module for the NetWare Administrator (NWADMIN) utility. Using this utility, you could grant users the necessary rights to access information on particular web servers. You could grant rights to Organization, Organizational Unit, Group, or User objects. Then only users to whom you had granted explicit rights could access the information on those web servers.

Using BorderManager 3.0 to protect your company's internal web servers enables you to make better use of those servers. You would no longer be limited to posting only information that anyone could access. Instead, you could post information that only certain users should access.

For example, you could post sensitive information such as designs for next year's products, payroll information, or your company's financial reports. You could post anything because using BorderManager ensures that the information you post is secure.

LEAVE IT TO NOVELL DIRECTORY SERVICES

In addition, by using BorderManager to control users' access to your internal web servers, you ensure that users lose rights to access those web servers the moment their Novell Directory Services (NDS) accounts are disabled. For example, suppose your company had several web servers, which were installed on a separate network segment. Also suppose you were front-ending that network segment with a BorderManager 3.0 server. If an employee were fired, you could simply disable this employee's Novell Directory Services (NDS) account, and he or she would immediately lose access to the BorderManager server and, therefore, to the protected network segment.

SUPPLY THE SPEED YOUR USERS NEED

If you use BorderManager to front-end your web servers, you can do more than secure access to those servers. You can also accelerate access to those web servers. For example, during a keynote address at BrainShare '98 in Salt Lake City, Drew Major, Novell's chief scientist and vice president of advanced development, invited Kent Anderson, director of Novell IS&T, on stage to explain how Novell uses BorderManager.

Anderson first discussed how Novell uses BorderManager to accelerate access at the company's Internet border. Anderson claimed that during the seven months preceding BrainShare '98, Novell had experienced a 400 percent increase in Internet web traffic. According to Anderson, the BorderManager servers that Novell had installed had easily handled this increase.

In addition, Anderson explained that Novell had enabled reverse caching on the BorderManager servers. By having BorderManager servers store information external users requested from internal web servers in cache, Novell hoped to reduce actual traffic on the internal web servers.

In fact, Anderson said, the BorderManager servers reduced the actual traffic on Novell web servers by 80 percent. "And do you know what that means?" Anderson asked Major. "I have saved internally over U.S. $200,000 in hardware upgrades because I'm still able to use the same web servers I bought over a year and a half ago."

Although Major was understandably impressed with Anderson's report on how Novell was using BorderManager to protect and improve performance at external borders, he was more interested in hearing about how Novell was using BorderManager to protect internal borders. Anderson explained that Novell essentially used BorderManager on internal borders in the same way it used BorderManager on external borders--that is, to secure and accelerate access.

Novell has a cluster of internal web servers collectively called InnerWeb. Novell front-ends InnerWeb with several BorderManager servers, which according to Anderson, has reduced actual traffic on InnerWeb by 50 to 60 percent. In addition, Anderson explained, "By using BorderManager in front of our web servers, I'm able to post really confidential information out there." Posting confidential information is now possible because that information is safe behind the BorderManager firewall on the internal border.

NetWare Connection, October 1998, p. 14

Take Your Work Home--Or Wherever

BorderManager 3.0 includes Virtual Private Network (VPN) services, which allow you to establish site-to-site tunnels between servers. To extend these VPN services, you can now purchase a Client VPN. This client-server software enables dial-up users to establish secure VPN tunnels from Windows 95 or Windows 98 clients to BorderManager 3.0 servers.

Using this secure client-to-site VPN tunnel, remote users can access other servers on the network to which the BorderManager 3.0 server is connected. In fact, users can access all of the network resources to which they have rights. In other words, once users have established a tunnel, they will feel right at home, or rather, right at work--just as if they were using their own workstation at the corporate office.

DOUBLE-CLICK YOUR WAY TO THE OFFICE

Novell designed the Client VPN software with ease-of-installation in mind. Novell ships the Client VPN software on CD-ROM. Users simply run the SETUPDOC.EXE file from the CD-ROM, and this file installs the Client VPN software. During this installation process, the SETUPDOC.EXE file also creates a Client VPN icon on the users' desktop.

To establish a secure tunnel with a BorderManager 3.0 server, users double-click the Client VPN icon. The first time users use the Client VPN software, they are prompted to enter a dial-up username and password for their Internet Service Provider (ISP) account. After entering this username and password, users are prompted to enter their Novell Directory Services (NDS) username and password.

This NDS authentication is identical to the NDS authentication that occurs on a local network, with one exception: The exchange of authentication information between a BorderManager 3.0 server and the Client VPN software occurs over Transmission Core Protocol (TCP) rather than over NetWare Core Protocol (NCP).

After this initial login, the Client VPN software provides a single sign-on. That is, after users have entered their dial-up username and password once--and only once--the BorderManager 3.0 server stores this information in NDS. The next time users attempt to login to the network by way of the Client VPN software, they need to enter only their NDS username and password. Users can then attach to the Internet (by way of their ISP) and authenticate to the remote NetWare network.

ENCRYPTION IS THE KEY

Once a user has been securely authenticated to NDS, the Client VPN software retrieves its private Rivest-Shamir-Edleman Algorithm (RSA) key. Ultimately, both the BorderManager 3.0 server and the Client VPN software have their private and public RSA key pair, which enables the client and the server to securely exchange Diffie-Hellman values. (Diffie-Hellman is a cryptographic algorithm.)

The Client VPN software uses the Diffie-Hellman values to generate Diffie-Hellman public and private keys, which the Client VPN software and the BorderManager 3.0 server then use to securely exchange RC2 keys. The Client VPN supports both 40-bit and 128-bit RC2 keys, which the client and server use to encrypt and decrypt data.

This process of establishing a secure session between the Client VPN software and a BorderManager 3.0 server occurs in just seconds. In fact, in a keynote address at BrainShare '98 in Salt Lake City, Drew Major, Novell's chief scientist and vice president of advanced development, demonstrated the Client VPN software on stage. Drew logged in to the Novell corporate network and established a secure session within seconds. (You can view Major's keynote address at http://www.novell.com/webcast/98/bs98/index.htm/#major. The Client VPN software demonstration begins about 24 minutes into Major's address.)

A CLIENT VPN UNLIKE ANY OTHER

The Client VPN software for BorderManager 3.0 offers two features not available with other Client VPN solutions:

NDS integration
Selective encryption

NDS Integration. Because the Client VPN software is fully integrated with NDS, you can control which User objects can use this software to log in to the BorderManager 3.0 server. Using the BorderManager 3.0 snap-in for the NetWare Administrator (NWADMIN) utility, you open the BorderManager Access Control detail to grant access control rights for the Client VPN software. You can grant an Organization object, an Organizational Unit object, a Group object, or a User object rights to access the network by way of the Client VPN software.

For example, suppose you set up a BorderManager 3.0 server for the marketing department and you wanted only users in this department to access the network by way of the Client VPN software. In this case, you could create a Group object for the marketing users and grant Client VPN rights only to that Group object.

Selective Encryption. Selective encryption enables you to specify the BorderManager 3.0 servers with which you want the Client VPN software to exchange encrypted data. With selective encryption, the Client VPN software doesn't have to encrypt data when exchanging data with other Internet servers. The Client VPN software encrypts data only when exchanging data with the BorderManager 3.0 servers you specify.

In contrast, when you use other Client VPN solutions, such as solutions that rely on the Point-to-Point Tunneling Protocol (PPTP), all data is encrypted, regardless of the server with which the client is exchanging data. As you might suspect, encrypting all data is far less efficient than encrypting only data that needs to be encrypted.

As with the NDS access control rights (and, in fact, all configuration options), selective encryption is configured at the BorderManager 3.0 server. To configure selective encryption, you use the BorderManager 3.0 snap-in module for the NWADMIN utility to create what is called a protected network list. In the protected network list, you type only the IP addresses of the servers with which you want the Client VPN software to exchange encrypted data. The Client VPN software will not encrypt data when exchanging information with servers that are not on the protected network list.

For example, suppose a client were using the Client VPN software to connect to a BorderManager 3.0 server at Novell. Although the client was accessing the Novell network through the Client VPN software, the client would actually connect to the Internet through an ISP. Thus, the client would not necessarily communicate only with Novell servers. The client might also access the Internet and browse World-Wide Web sites.

If the client accessed http://www.cnn.com, the information exchanged between the CNN server and the client would obviously not need to be encrypted. Only when the client was accessing Novell servers by way of a BorderManager 3.0 server would the data exchanged between the client and the server need to be encrypted. To ensure that data is encrypted only when exchanged between BorderManager 3.0 servers and a client accessing those servers via the Client VPN software, you would create a protected network list that contained the IP addresses for the BorderManager 3.0 servers.

The Client VPN software, like the BorderManager 3.0 site-to-site VPN, supports both IP and IPX traffic. One BorderManager 3.0 server can support up to 1,000 Client VPN connections using IP and up to 250 Client VPN connections using IPX.

* 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.