PicLan-IP for NT Security and Performance Notes

April 18, 1998

Updated September 5, 1999

A number of users have made inquiries about security and performance issues when running PicLan-IP services (particularly web services) on MultiValue Windows NT host systems such as mv*Base, D3, and Universe. While there are no perfect answers for all configuration questions, this document discusses some approaches that can be used to insure a reliable, secure, and fast configuration.

Most of the discussions of this document concern aspects of implementing a public web site using PicLan-IP as a primary web server. Public sites are particularly vulnerable to security issues, as well as performance issues due to the wide variability of public internet access patterns.

Security Considerations

When deploying a public internet web site, there are a number of aspects that you should be concerned with. There are actually several issues here that lie beyond the issues of deploying a web server.

Securing the Network in General

When you connect to the internet, whether by dial-up modem or T-3 fibre, you are creating a bi-directional connection between your computer systems and the world. This connection allows any user, anywhere in the world to send and receive IP-formatted network packets to any addressable computer on your local network. This scenario can obviously lead to undesirable consequences.

In an attempt to secure the local network, there are five general approaches that can be taken:

Secure each individual system element with effective passwords and access controls.
Run local system elements on a different protocol than TCP/IP.
Insert a packet-filter (FIREWALL) between the internet and the local network.
Insert an address translation router (NAT) between the internet and the local network.
Insert a proxy server or servers between the internet and the local network.

Each of these techniques has their place.

Secure each individual system element with effective passwords and access controls

This is the old-fashioned security approach. Make sure that every resource on the local network has effective passwords and protections against access. If you are running a very simple network, this approach can be very effective. Just make sure that you don't forget something.

Run local system elements on a different protocol than TCP/IP

This is sometimes referred to as a poor man's firewall. By electing to run as many local functions as possible over non-TCP/IP protocols (such as IPX), you can eliminate most exposures to external accesses without resorting to more expensive solutions. As a side benefit, functions like file and print sharing are often faster over IPX than they are over TCP/IP.

With both Windows and Novell networks, you can elect to run standard file and print sharing over IPX instead of TCP/IP as a transport protocol. This effectively thwarts internet hackers from gaining access to file and print sharing resources over a protocol that does not reach them. With Novell networks, the use of IPX is the default. With Windows networks, this configuration requires that you "unbind" the TCP/IP protocol stack from the server components of your Windows 95 and Windows NT systems.

Insert a packet-filter (FIREWALL) between the internet and the local network

Probably the most common option for securing a local network is to insert a device that filters packets between the local network and the internet. This is a firewall. A firewall is a device (often a PC-based computer system with two network cards) that is configured to only allow some types of TCP/IP packets in and out of the local network. You can configure a firewall to allow HTTP requests into your local web server, but discard the UDP packets that are used by Windows NT that share network files.

Firewalls are very effective in securing a network, but require a bit of expertise to setup and maintain. The problem with setup and maintenance is not really the firewall itself, but the concept of what a firewall does. A firewall is a packet filter. It is up to the system administrator to determine what must be filtered. If you filter too much, then you may not be able to fully use your internet connection. If you filter too little, then you may be vulnerable to attack.

Insert an address translation router (NAT) between the internet and the local network

Another technique that can be used to secure a local network is through a TCP/IP specification called NAT or Network Address Translation. A NAT server is similar to a router that takes TCP/IP traffic in one network interface port and puts it out another. Where a NAT box is different is in the way that TCP/IP addresses are managed.

If you have a workstation directly connected to the internet, that workstation will have a publicly available IP address. "Publicly available" means that the IP address is a part of the global internet's addressing structure and any other computer system on the internet can send data to your workstation and that data will reach it's destination. If you have a workstation behind a NAT box, then the addressing is different. The NAT box has a publicly available internet address assigned to it, but the workstations behind the NAT box have private IP addresses that are not visible to the rest of the internet. These "locally administered" IP addresses still allow workstation users outbound access to internet functions like browsing the web, but disallow outside users reaching in.

Traditional NAT boxes are "one-way". They take a single IP address and let a network use that address for client appellations like web browsers. Some newer NAT boxes also allow "static" NAT table entries that allow you to create single "locally administered" IP addresses that can be reached from the outside. This allows you to place internet servers, like web servers, behind the NAT box.

Insert a proxy server or servers between the internet and the local network

The last technique used to secure a network is to place internet servers behind reverse-proxy servers. A proxy server is a computer system, again with two network adapters, that accepts high-level application requests like HTTP web requests and then retransmits these requests to it's destination server. The most common type of proxy server is an HTTP proxy, although proxy servers for FTP, NNTP, and general sockets usage are also available.

Proxy servers are probably the most bullet-proof isolation mechanism in that the only communication that occurs through the proxy is regenerated by the proxy server. This means that even mal-formed IP packet attacks will not reach your internal network.

What Technique Should you use with PicLan-IP

Which technique you use depends on the scope of your network environment as well as your needs. Small sites can effectively use a combination of setting good passwords and running local traffic on another protocol. Most medium and large sites should use a firewall type of solution, perhaps in conjunction with NAT and/or proxy servers. In any case, if you carefully look at your configuration and needs, it is not that difficult to secure your local network while still allowing public internet access into your PicLan-IP host server.

Securing PicLan-IP

Once the underlying network is secure, the next consideration involve the actual internet application. With the PicLan-IP web server, web security is in the control of your application code that resides in active server pages on the PicLan-IP web server. It is your code that controls which web application access which MultiValue data files, call which subroutines, and execute which TCL commands. As a practical matter, web application security is no different than terminal application security. You must restrict users from accessing areas of the application without proper passwords and audit logs. This is really no different than any terminal application that you have running.

In terms of web security impacting system security, there are several points that you should keep in mind:

All web applications run in the context of a single account named PICLAN-IP

If you wish your application to access MultiValue data files, you must setup a q-pointer to those data files. The web server will not access anything that you do not specifically allow for in your web page coding.

Web application cannot get to TCL

The design of the PicLan-IP web server is such that there is no connection between the TCP/IP stream connection that HTTP is running over and any TCL login terminal stream. Even if the web server crashes and burns, the user will not reach a command or debugger prompt. Furthermore, because PicLan-IP processing runs on phantoms, if a process does trap to TCL or the debugger, the system will log it off.

PicLan-IP Performance Techniques

When deploying PicLan-IP as a public internet server, many users have asked about performance issues. The underlying reason here is the misnomer that the MultiValue environment must be a slow web server. Modular Software has done a lot of testing in this area and there are a few things that you need to keep in mind.

PicLan-IP Performance with Dynamic Pages

The performance of dynamic pages, meaning those pages that execute your MultiValue application code, is very good. In fact, if your application is doing more than very simple formatting operations, your code will have more overall impact on system performance and throughput than does the web server.

PicLan-IP Performance with Static Pages

The performance of static pages with the PicLan-IP web server is somewhat slower than a non-MultiValue web server running on the same hardware. On the other hand, it is still not bad. We have run benchmark tests that 100% saturate 10 megabit Ethernet networks from single-processor hosts and even saturate 100 megabit Fast-Ethernet networks with fast multi-processor hosts.. While pegging the network is not always possible depending on factors such as page size and content distribution, PicLan-IP is still quite respectable. Also in terms of internet servers, typical internet lines like T-1 1.5Megabit circuits are really no big deal.

So What do you do about Performance

In most cases, you will not need to do anything. The PicLan-IP web server is fast enough (on modern hardware) to fully saturate the internet connections that most businesses are using for their public web site. If you really think that you need a full T-3 (and are willing to pay the $50K/month for it), then there are some techniques that you should be aware of that can offload a lot of the work from PicLan-IP to increase total throughput (in fact, these techniques can be used with most web servers and are not peculiar to PicLan-IP).

Offload static content to other web servers

A web site does not need to store all of it's content on a single server. Static elements such as images can easily be stored with a different base URL and served by a completely seperate (and not necessarily MultiValue) web server.

Use a reverse proxy server to improve performance

Another very effective option is to place a proxy server between the internet and the primary web server. The proxy server is not only a very effective security tool, but it can also dramatically improve web server performance.

HTTP proxy servers can keep local cache content. This allows them to respond to HTTP requests for static pages without even communicating with the actual web server. This environment allows the proxy server to service nearly 100% of the static page content leaving the primary web server open to server dynamic pages. In fact, the current SPECweb96 single-processor benchmark holder for best web server performance is for a web server through a proxy server running on a single system. The web server is Netscape Enterprise server and the proxy server is Novell Border Manager running on NetWare 4.11.

A public example of this approach is www.novell.com which is running a single Pentium-II proxy server driving the entire site with multiple inbound T-3 lines.

Run a server farm

I personally think that this is the worst approach. Strangely, most public sites use this technique (probably because reverse-proxy servers are a new phenomenon). What is working here is the deployment of multiple parellel systems, each with identical content, that all have the same domain name. This works because of how the internet Domain Name Server system works. It is perfectly legal to have multiple IP addresses assigned to a single domain name. Users that access the domain then will randomly share the assigned servers from the server farm.

The problem with server farms is that they can get out of hand pretty quickly. Not only do you have to deal with multiple systems, you also have the added complexity of running parellel systems and the synchronization issues of your web application that this entails. In general, if you can avoid a server farm, you should. Before creating a group of servers with identical content, you should use the "normal" distribution tactics. Divide the application where it makes sense to divide it. Keep multiple applications off of a single system. This should sound just like the approach used for "normal" MultiValue applications, and it is. The web is just a different view of the same data model.

A public example of this approach is www.microsoft.com with 19 active servers.

Summary

This paper is intended to help you look at options at securing and enhancing your internet connections when you use PicLan-IP. With proper planning, you can safely, securely, and with good performance deploy an internet presence from your single MultiValue host system.