Classroom and Lab Computing

Authenticated Network Firewall
(KarlBridge)

(This was written prior to the service going into production in 1997, and has not been updated since then.  Except I'll add this note in May 2003: the technology and hardware is obsolete and no longer sold by the manufacturer, and alternatives are being researched by network engineers at Penn State.)

Summary

There is a loosely-defined requirement for the availability of Ethernet ports to which users may attach their laptops. A number of such ports will be available in the Pollock mega-lab. The method of securing such ports may be used elsewhere, such as teaching labs where users bring their own computers. Two such locations are classrooms in 210 and 211 Keller, where the College of Business has ports to which students may connect their laptops.

Why

Students who live off-campus, or faculty without LAN connections in their office, may occasionally need fast backbone connections.  Users of such ports need to be identified for at least two reasons: (1) security -- they could do something bad on the network; and (2) printing -- in order to charge for laser printing.

DHCP

A DHCP (Dynamic Host Configuration Protocol) server -- available with NT Server and on other platforms -- will run on the LANs that have these public ports. A machine wishing to connect must have a TCP/IP installed with DHCP capability. Windows 95 and Apple's OpenTransport (?) have that. When the machine is plugged into the Ethernet, it is assigned an IP address and netmask by the DHCP server.

In a lab with permanently connected machines, DHCP is not necessary.

KarlBridge

A KarlBridge from KarlNet -- invented at Ohio State -- is used to filter packets from these public ports. It is setup to allow packets to and from (1) DNS server(s), (2) an authentication server, and (3) a DHCP server. It may also allow ICMP (e.g. Ping) packets through, but nothing else.

This is a small, inexpensive box that can do many things. There are various models. It is configured with a proprietary program that must run under DOS on a separate machine. Communication to it is via SNMP (Simple Network Management Protocol). IMHO, there is nothing simple about SNMP.

Authentication Server

At Ohio State, this is something apparently running on Unix that you telnet to. We're not sure our potential users know how to telnet anywhere, and think a WWW page would be better. Also, in order to print on a lab laser printer, a person also needs to log into PALS.

We currently have a page and a CGI program that verifies a user (by getting a ticket granting ticket from our Kerberos server) and sends a request to the appropriate bridge to bypass the current filters. Optionally (controlled by a configuration file on the server) the user will be logged into PALS too. A separate page is used for logout.

Note that this is on a Netscape secure server (SSL -- Secure Socket Layer enabled). The transmission of the user's password is encrypted, so if anyone might be sniffing on the network, they are not going to be able to see anything. The client's WWW browser must support SSL (Netscape Navigator and Internet Explorer do).

KarlBridge Advantages

• Robust control of network access.
• Large amount of flexibility.
• The idle time-out is good protection.
• Can restrict SNMP access (besides a password) to a list of IP addresses.
• Low cost.
• It works.

KarlBridge Disadvantages

• Hole: if a person doesn't log out, and the next person plugs in before the time-out and somehow knows what IP address the previous person was assigned, then the second person has network access without authentication.
• Configuring the KarlBridge can be difficult.
• The configuration program must run under DOS with a packet driver (and needs all of conventional memory).
• Limited bandwidth (newer models faster).
• Separate box to purchase and maintain in addition to a DHCP server.
• Poor or non-existent user support.
• Virutally no documentation on the firewall bypass feature (e.g., how server sets a bypass).
• The next version of bridge code will use MD5 encryption in setting a filter bypass. This may prove difficult for our server code.
• Saving the configuration to the bridge clears any filter bypasses.
• The idle time-out will inconvenience some users.
• It is a bit difficult to put an NT Workstation behind the firewall and still be able to connect to it and manage it (but doable, with some security sacrifice).

Our Authentication Server

Features

• Simple Web page that invokes a CGI program.
• Does these steps:
• validates Kerberos userid/password
• determines which bridge to talk to
• ask bridge to give you network access (bypass filters)
• (optionally) sends login record to PALS
• 32-bit NT program written in VB 4.
• An instance is launched for each login/logout.
• Small (54k) so it loads quickly.
• Bridge definitions in a simple text .ini file, which is automatically "compiled".
• Bridge passwords are encrypted in the "compiled" configuration file.
• Idle time-out is hardwired at 600 seconds -- easily changed or set per bridge.
• Logs all logins and logouts to a daily file.
• Keeps another file with a record for each IP address, with userid and date/time.
• Knows if you were logged in when you go to log out.
• Initial tests show it takes about 2 seconds to log in, where 1.2 seconds of this is the Kerberos part. Logout is about 0.5 seconds.

Advantages

• Relatively simple to code (once you know how).
• Most users have Netscape or another browser installed.
• Handles multiple KarlBridges.
• Would be relatively easy for others to install on their own WWW server.

Disadvantages

• Can handle 100's, but perhaps not 1000's, of different IP addresses.
• Multiple instances running at the same time can be a problem.
• A separate, continually running program that the CGI instances talk to, would remove these disadvantages.

Project Problems

The next version of bridge code will use MD5 encryption in setting a filter bypass. This may prove difficult.

Saving the configuration to the bridge clears any filter bypasses.

Historic Problems and Status

The box arrived late November, and had to be returned. They replaced the mother board.

We have defined filters that let packets through only to DNS server(s) and our authentication server.

The filtering features of the KarlBridge are not well documented, and there is no clue how the authentication server would tell it a particular IP address can bypass filtering.

Update 1/6/97: we have spoken to Doug Karl and received source code to the OSU authentication server. We found the object identifier. (NetXray does not decode the identifier correctly, so this was confusing.)

Nor is it documented how the bypass setting is removed when a person leaves. (Later: it isn't. The user is expected to log out. The bypass will time-out.)

Getting and setting values on the KarlBridge is done with SNMP, which does not use a simple set of ASCII commands such as POP3, NNTP, or SMTP. However, there are some choices of API libraries and custom controls we are looking into. The ActiveX SNMP control from Dart Communications works well.

Update 4/15/97: Can an NT workstation be behind the bridge and still log onto the domain?  Can we administer it?  Probably, if enough filters (holes) are setup.  Add a filter pair for the workstation(s) and the NT server(s).  Add all 3 NBT well-known sockets for both sides (probably only UDP versions needed).  Pass all packets for ports > 1024 because NBT will use any number of TCP ports above 1024.  Doesn't seem that you can predict which will be used when.

Update 4/16/97: still waiting for testing with real users. (!!)

Update 4/29/97: OTC demonstrates bandwidth limitations.  But, how many laptops, workstations, can be put behind one? This changes as models improve.