MUSC Internet Firewall Policy and Procedures

$Id: firewall-info.html,v 1.6 2001/09/27 17:02:36 gadsden Exp $

i. Confidentiality

These policies, procedures, and related documentation are strictly confidential. The contents of these documents may not be revealed to unauthorized users.

ii. Authorized Use

Individual MUSC faculty, staff and students are authorized to access these documents on a "need-to-know" basis. Authorization to access these documents does not imply authorization to share these documents or the information they contain with anyone else, either inside or outside of MUSC.

I. Firewall Policy

The MUSC Internet Firewall Policy is documented here.

II. Firewall Procedures

The MUSC Internet Firewall Procedures are documented here.

III. Current Firewall Status

The MUSC Network Infrastructure Committee developed the new MUSC Internet Firewall Policy over a period of several months beginning in March 2001. The Policy was finalized and adopted in July 2001.

With the emergence of the Nimda worm on Sep 18, 2001, came a crisis which significantly accelerated the implementation of the new Policy. Within an hour of Nimda's emergence, MUSC's existing border firewall failed under the massive Internet-bound traffic connection load imposed on it by internal servers which had been infected by the Nimda worm. A decision was made to replace the existing firewall with new components which were already being tested and planned for deployment under the new firewall policy. A decision was also made to start with a "clean slate" of firewall rules, rather than to simply re-implement all of the rules from the previous Internet firewall, most of which were no longer relevant to MUSC's current business needs.

As a result of this accelerated implementation, many aspects of the new Firewall Policy have not yet been implemented, and will be phased in over the coming weeks and months. Among these are the Perimeter Network infrastructure, the centralized event logging infrastructure, the process for formally evaluating requests for firewall rules against MUSC business needs, and the process for conducting network security audits of servers for which firewall rules are requested.

A. Deprecated Protocols

There are certain deprecated rules, which were active on the old firewall, which will not be activated on the new firewall, except perhaps in rare cases where there is no practical workaround. These deprecated rules involve the following Internet protocols:

Telnet is a problem mainly because it requires the cleartext transmission of a userid and password over the Internet, in addition to all session data being sent in the clear. Secure alternatives such as ssh provide a workaround.

Authenticated ftp has the same problems as telnet. Secure alternatives such as the scp protocol included in ssh implementations provide a workaround. For Homeroom access, the WebSMB service provides another workaround. Note that anonymous ftp is generally okay, at least for non-sensitive data, because no user password is sent in the clear over the Internet.

The IMAP protocol is required for remote e-mail access using Netscape and Mulberry. IMAP has the same basic problem as telnet, namely the cleartext transmission of the user password over the Internet. For Netscape and Mulberry users, the Webmail server provides at least a temporary workaround, until we can implement a secure IMAP proxy server to support Netscape and Mulberry users.

The IMSP protocol is used to support configuration preferences and address books for Mulberry. IMSP has the same basic problem as telnet, namely cleartext transmission of the user's password over the Internet. Webmail provides at least a temporary workaround until we can implement a secure IMSP service which will not expose plaintext passwords to the Internet.

The NetBIOS protocol is used by Microsoft Windows operating systems to support "Network Neighborhood" browsing and related functionality. It provides no required functionality except on a LAN, and therefore both inbound and outbound NetBIOS traffic is being blocked by the new firewall.

Due to a lapse in oversight, the old firewall allowed all of the protocols which support Microsoft NetMeeting, both inbound and outbound, for all network addresses on MUSC's internal network. The functionality provided by NetMeeting, although useful in certain contexts, exposed the entire MUSC network to significant risks. The NetMeeting protocols may be permitted through the firewall at some point in the future, e.g. if there are legitimate needs, and if funding for a proxy server can be secured.

PCAnywhere is a commercial software product used for remote control of Microsoft Windows operating systems. Although PCAnywhere sessions can be encrypted, the product does not provide all of the authentication and auditing features required by MUSC's security policies. MUSC's VPN service, still several weeks away from general availability, will provide a secure alternative.

B. Perimeter Network Migration Strategy

When the Perimeter Network infrastructure is in place, we will begin fully implementing the Firewall Policy as follows. Initially, the Perimeter Network will be empty, and all servers with existing firewall rules will still be on the Internal Network. We will work with the System Administrator of each Server to complete the steps outlined in the Firewall Procedures document, including scheduling of vulnerability assessment and configuration of remote event logging. If and only if these steps are completed, will the Server will be re-addressed onto the Perimeter Network.

Any Server which cannot meet, or whose System Administrator does not wish to meet, the requirements for the Perimeter Network, will not be permitted to continue to accept incoming connections from the Internet. Workarounds for any such cases which arise will need to be identified. For example, a Server on the Internal Network which requires remote administration via ssh, but which for one reason or another cannot or should not be re-addressed onto the Perimeter Network, may need to be reached indirectly, through a Server on the Perimeter Network. It is expected that the new VPN Server, which will be located on the Perimeter Network, can mediate many of these types of connections.

Some current Servers may have split personality problems, which the introduction of the Perimeter Network will reveal. For example, a particular Server might provide Web services to remote users on the Internet, so it must be moved to the Perimeter Network. That same Server might also provide file or database storage services for sensitive internal information, so it must stay on the Internal Network. Since no server can be on both networks, the two services will need to be re-engineered, e.g. distributed onto separate hardware.