next up previous
Next: Conclusion Up: Challenges in Operating System Previous: Research and Development Areas

Poger, Baker: Secure Public Internet Access Handler

Different network environments need different approaches for security and access. This paper describes the design and implementation of a system called SPINACH that was created according to requirements of a university department. At Stanford University, the computer science department provides public ports to access the internal LAN inside their building. Because of security concerns, a system has been developed that establishes a "prisonwall" around the public ports. All packets leaving this subnet are filtered by a specific router. Only traffic from authorized users is allowed to pass the router, other packages are dropped. With minimal requirements both for users and the system software, this design provides a reasonable protection against attacks without unnecessary restrictions. The SPINACH system consists of a number of public network ports building a public subnet and a router that runs slightly specialized software to grant or refuse access to the department network. A user who wants to connect to the network plugs his laptop into a port and has to authenticate himself. Afterwards, all packets coming from this host are allowed to go through the router. The current security policy of the system filters only outgoing traffic. Traffic into the public subnet is considered to be not critical because unauthorized users can not initiate a connection. Traffic inside the subnet is also not affected. That means that every user that uses a public port has to know that his environment might be hostile. SPINACH distinguishes between three different kinds of users: department users, university users, and guests. Whereas department users have full access to all resources as if they would be logged in a terminal, university users are not allowed to get access although authorizing them would be very similar to department users. Guests, who want to log in, need to get a pair of $<$userid, one-time password$>$ to get access. The connection works as follows: If a client has DHCP (Dynamic Host Configuration Protocol) installed, all important parameters like his IP number are set automatically. Otherwise, the user has to configure his computer manually. There are two different ways to authorize a user: University users are identified by a unique university identifier and can authenticate themselves when they have a Kerberos client installed. Otherwise, and in the case of guests, the user has to open a telnet session to connect to the router. A modified telnet server on the router asks for username and password and disconnects the telnet session immediately afterwards. If the user input is accepted access is granted. This new session is then valid for a specific amount of time. After that time, the user has to re-authenticate himself. On the client, a telnet is sufficient for authorization. On the router, some software has to be installed. A DHCP server makes it possible to easily configure the client. A modified telnet server is needed to authorize users with passwords. Authorization clients administrate the router to enable/disable network access and to generate guest passwords. Furthermore, a so-called prisonguard is needed, that is a process running at user-level that maintains the database about users and modifies the packet filter rules dynamically. Finally, there is a packet filter that it part of a Linux kernel. The packet filter has to work according to rules that specify which packets are allowed to pass. All packets leaving through the SPINACH router are assumed guilty until proven innocent. That is, either they are destined for the trusted departmental DNS server (may be needed to find the Kerberos server), they are destined for the trusted Kerberos server, or they come from an authorized user. The authors are well aware that this system does not provide high security. But it may be appropriate for environments where it is not possible (for example because of money constraints) to install specialized hardware or software to provide protection or where this kind of protection is sufficient. It doesn't prevent an authorized user to attack the system, but it denies access to the network for unauthorized users. Furthermore, SPINACH seems to be a system that is easy to install, configure, and maintain. On the other hand, several attacks against SPINACH are possible. Because traffic inside the subnet is not filtered, in a shared Ethernet environment it is possible to eavesdrop both IP address and hardware address of a machine. With this information, spoofing attacks are possible. Furthermore, SPINACH is vulnerable to denial-of-service attacks against the Kerberos or DNS server. Nevertheless, is seems to be a good balance between the need of temporary access to a network and protection of the network against malicious use.
next up previous
Next: Conclusion Up: Challenges in Operating System Previous: Research and Development Areas
Tim Wellhausen
2000-01-20