The Internet is an extremely valuable tool. Unfortunately its use carries with it corresponding responsibilities. There are a number of people, both at Rutgers and throughout the world, who attempt to use the Internet in ways that are abusive or that interfere with operation of other systems.
All organizations that attach to the Internet are expected to adopt policies to deal with this situation. This document outlines the policies that apply to individual Rutgers departments, organizational units, and system administrators.
This document will use the term "department" to refer to any unit within the University that operates computer systems. This includes both units with central computing support staff and those where computing support is done more informally, including units in which individuals are responsible for the computer on their own desk.
The primary policy document for computing at Rutgers is the Acceptable Use Policy and guidelines. See the Computing Policies page for these documents.
Under the Acceptable Use Policy, system administrators have the "responsibility of ensuring the integrity, confidentiality, and availability of the resources they are managing." This document outlines some of the implications of that.
See the RUSECURE web page for additional information about relevant policies and laws, as well as best practices in the areas of information protection and security.
The most basic requirement for responding to problems is this: We must be able to identify a responsible person to deal with problems for all activities on the Internet. That has the following implications:
Allocation of IP addresses
[This section applies to subnets that are intended to communicate with the rest of Rutgers and the Internet. It is possible to set up a subnet that is not connected with any other network. In this case the procedures described here are technically not applicable. However in order to avoid confusion, we strongly recommend contacting the Rutgers Hostmaster to request an official range of IP addresses even for disconnected networks.]
Typically reports of problems are identified by the IP address of the source. Thus we need some way to identify a contact who can pursue problems for any IP address at Rutgers. This is done through a process of assigning and registering IP addresses.
There are two levels of address assignment/registration. The first is for a subnet. A subnet is a specific physical network connected to a single router port. (Technically, it is a "broadcast domain".) Generally there will be one or more subnets per department. Each subnet has a range of IP addresses allocated to it. This range is assigned by the Rutgers Hostmaster, firstname.lastname@example.org. As part of the process for address assignment, the department must designate one or more "Network Liaisons." The Network Liaisons will be the contact for any questions about the network. This specifically includes problems caused by computers on the network. The Network Liaison will be expected to arrange for problems to be dealt with, and to report back on its disposition. (However the initial responsibility for dealing with problems rests with the person designated as the RP. See below.)
The second level of address assignment is individual IP addresses. In order to communicate with the rest of Rutgers and the Internet, a computer must be given an IP address. There are several ways to do this. The simplest approach is to assign a permanent address to each system. However it is also possible to use software that allocates addresses dynamically. In any case, the IP address assigned to a computer must be within the range authorized for the subnet to which it is connected.
The most common procedure is for IP addresses to be assigned by and registered with the Rutgers Hostmaster. This may be done by contacting the hostmaster at email@example.com. The hostmaster will register addresses on request. They can also set up departmental staff to be able to register addresses themselves in the hostmaster's database, using software supplied by the hostmaster. This is recommended for departments that regularly add or change systems.
It is also possible for the Hostmaster to delegate responsibility for address allocation to a department. In this case the department is required to maintain records so that it can identify what computer is using any given IP address. If the department has chosen to assign addresses dynamically, records showing how addresses were in use should be kept for at least 60 days.
It is important to make sure that you contact Hostmaster to get a registered IP address before using a computer on the network, unless responsibility for address allocation has been delegated to your department.
Whether addresses are allocated by the Hostmaster or the department, it is expected that each address will have a description in the Domain Name System (DNS). These descriptions are created by the Hostmaster as part of assigning an address. Most software that departments would use to maintain addresses will provide DNS data for the department. (As part of delegating responsibility for address maintenance to a department, Hostmaster will arrange to link that department's DNS software into the University's system.) All services provided by OIT assume that addresses are registered with DNS. If a system does not have a DNS entry, various services (e.g. email) at Rutgers and elsewhere will not work.
It is important for each unit to consider what contacts should be used to report abuse and other network problems. The DNS system can maintain an entry called the "Responsible Person" (RP) for each IP address. Normally departments are asked to specify the RP for each address that is assigned. Where responsibility for address maintenance has been delegated to a department, the department should create RP entries for all hosts in its DNS system.
If RP entries do not exist for a given address, OIT staff will contact the Network Liaison. However you should be aware that Network Liaisons are not currently visible outside Rutgers, and have limited visibility even within Rutgers. Thus most network managers will expect to find RP records for every host. They may take unpredictable actions if they are having problems from a host that does not have an RP record.
Departments are responsible for keeping both Responsible Person and Network Liaison information up to date as staff and systems change.
The University is currently very near to running out of IP addresses, at least in the pool of addresses that are visible to the Internet. In order to allow for new systems, OIT needs to be able to reallocate addresses that are no longer in use. Thus OIT will poll Network Liaisons on a regular basis to verify that the address ranges assigned to them are still in use.
Logging on individual systems
System administrators need to think about how they would deal with reports of problems from their system. In many cases they will need to keep logs that will allow them to tie Internet activities to identifiable people. For many systems, this is not a problem: the system is located in an individual's office, and is used primarily by that person. In such cases, that individual would normally be responsible for all use of the system, whether their own or others that they permit to use the system.
For multiuser systems, or systems in public areas, there must be some mechanism for identifying users. One common approach is that all users must login with a username and password. Where this is not possible, less formal mechanisms may be used. For example, some public labs check ID cards of users and keep a log of usage by system. Every system for which Internet access is possible must have good enough mechanisms that the system administrator can deal with any reports of problems.
Logs must be kept for at least 60 days. (This interval may be adjusted from time to time by the Information Protection Division, based on experience in handling problems.) Information from the logs must be made available to staff assigned to the Information Protection Division if it is needed to investigate network security problems or abuse. Staff should also give thought to a maximum lifetime for logs. Be aware that any log is subject to subpeona or other legal process. This may be burdensome if logs are kept for a long period of time.
Departments may be asked to describe their logging procedures as part of getting authorization for a subnet to be enabled for access to the Internet.
No mechanism for identifying users is perfect. However departments need a place to start investigations when a problem occurs.
Administration of Individual Systems
There are currently active attacks being made throughout the Internet. Any system connected to RUnet can expect to be the subject of a variety of attacks. In many cases the goal of an attacker is to compromise a system, and then use that system as a base for attacks on other systems.
All systems must have someone who plays the role of system administrator. (In many cases the owner of the system is effectively acting as system administrator.) The system administrator is responsible for software installation and configuration, as well as monitoring the system for inappropriate use, and use of "best practices" in protecting their system from compromise. These responsibilities also apply to individuals connecting systems at home or elsewhere to the Rutgers network via dialups, wireless networks, publicly accessible ports, VPN's, etc.
One of the major responsibilities of the system administrator is to keep software up to date. Most vendors issue security-related patches on a regular basis. Systems that do not install these patches are much more likely to be compromised.
Rutgers University has licensed anti-virus software on a site-wide basis. For system architectures where viruses are common, system administrators are expected to install anti-virus software and keep it up to date,
System administrators are encouraged to take additional security precautions, such as use of a firewall or host-based firewall software. OIT has made arrangements to purchase one common host-based firewall product (Zonealarm) at a substantial discount.
Note that the Acceptable Use Policy and Guidelines charges computing and information technology providers throughout the University with preserving the integrity and security of resources. The preceding paragraphs outline minimal security precautions, which we believe apply to all systems. However many systems need additional security work. This includes particularly systems holding data such as social security numbers, medical information, and other information where confidentiality is required by law or University policy.
Under the Acceptable Use Policy, staff are responsible for assessing the nature of information and services on their systems and following best practices at an appropriate level. These will often include additional precautions not listed here.
In particular, data whose compromise could produce significant dangers to a user or the University should be transmitted using SSL or similar encryption techniques, and it should be stored on systems whose security has been carefully reviewed by security professionals. This includes (but is not limited to) personal data such as SSN's, medical information, student records, and credit card information. In some cases, techniques should be used to avoid storing this information at all (e.g. using an external service to handle credit card-based transactions).
Passwords and other authentication information should be protected at the same level as the data which they control. Any application dealing with standard University passwords (those associated with the NetID, or with accounts on OIT administrative or general-access campus systems) should protect transmission of the passwords using SSL or an equivalent technology.
In addition to overall system security, administrators are expected to control the access to confidential data provided to individual users. Access to confidential data should be provided only as needed for the person's job function, or for non-Rutgers employees, a function delegated to them by a unit at Rutgers. We recommend that units have explicit policies, so that users' obligations with respect to confidential data is clear. One example of such a policy is the Agreement for Accessing University Information.
Please note the NetID/Email policy. This policy mandates transition away from use of the SSN for authentication. No new applications may be written using the SSN for authentication, and existing applications must be transitioned. While the document states that the NetID must be used, this does not apply to internal departmental applications, where the department has its own usernames. However even departmental applications may not use the SSN for authentication.
We encourage departments to develop security plans for systems and information under their control. Staff from the Information Protection division are available to discuss security recommendations for specific situations.
Also note the provisions in the Acceptable Use Policy and Guidelines regarding confidentiality and privacy. System administrators are expected to abide by those policies. We encourage departments to develop privacy policies consistent with the Acceptable Use Policy, and share those policies with their users and other customers. Two examples of privacy policies within OIT are available on the Computing Policies web page. These may serve as models for departments.
OIT provides limited support for system administrators of common system types (Windows, Macintosh and the most common forms of Unix). This includes web areas, email lists, and regular meetings. Security issues are regularly discussed there.
All systems at Rutgers are expected to control mail relaying. This is an issue only for systems that are running software that delivers email. Normally this includes all Unix systems. It is not an issue for Windows and Macintosh system unless software such as Mercury or Exchange has been installed. Note that the software we're talking about is software that delivers mail, not mail reading software such as Netscape Communicator, Pegasus, or Outlook Express.
Systems that run mail delivery software must be set up to reject attempts by systems outside Rutgers to get them to relay email to other systems outside Rutgers. For a specific discussion of this issue, see Dealing with Spam Being Forwarded by Your System
OIT reserves the right to take action when problems on an individual system affect other systems at Rutgers or on the Internet as a whole. Examples of situations where OIT would take action include, but are not limited to
- systems are compromised by a hacker, and are then used as a base to launch attacks against other systems
- systems are used to relay spam
- users on a system send abusive email, or post information (e.g. as web pages) that violates University policy or copyright laws.
Where possible OIT will attempt to notify the owner or administrator of a system before taking action. As described above, OIT staff will use the RP records and Network Liaison to locate staff to notify.
However immediate action may be necessary when there is an ongoing attack against other systems, or when the problem is seriously interfering with the performance of the network. Depending upon the nature of the problem, the system in question, or the entire departmentl network of which it is a part, may be disconnected from RUnet or the Internet.
When immediate disconnection is not necessary, system administrators will still be expected to take prompt action, to diagnose the problem, to stop any ongoing abuse, and to make whatever changes are needed to prevent reoccurrence. Generally this will involve adopting "best practices" for security. This process should preserve any evidence that might be needed to locate the source of the problem and take any legal or disciplinary action that might be appropriate.
When OIT has referred a problem to a system administrator for action, a brief report on the resolution should be made. This will allow OIT staff to verify that all problems are dealt with, and to maintain statistics on the types of problems that are occurring. System administrators are also encouraged to notify the Information Protection division of problems that they discover themselves.
From time to time, OIT also conducts scans for problems, in an attempt to discover security weaknesses before someone uses them to break into systems. System administrators will be notified of problems discovered by this process. Normally this notification will be accompanied by advice on how to remedy the problem. Remedying problems of this sort is not as time-critical as dealing with actual breakins. However system administrators are expected to deal with the problems in a timely fashion, and report the results.