Policy on Standards for Management of Computer Systems at SSUET, Karachi

The Internet is an extremely valuable tool. Unfortunately its use carries with it corresponding responsibilities. There are a number of people, both at SSUET 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 SSUET 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.

Other Documents

The primary policy document for computing at SSUET is the Acceptable Use Policy and guidelines.

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.

Accountability

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 SSUET 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 SSUET Systems Manager 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 SSUET. 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 SSUET Systems Manager. 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 SSUET 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 SSUET Systems Manager. This may be done by contacting the Systems Manager. The Systems Manager will register addresses on request. They can also set up departmental staff to be able to register addresses themselves in the Systems Manager's database, using software supplied by the Systems Manager (if a software and system exists). This is recommended for departments that regularly add or change systems.
It is also possible for the Systems Manager 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 Systems Manager 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 Systems Manager 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 Systems Manager 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, Systems Manager will arrange to link that department's DNS software into the University's system.) All services provided by ACS assume that addresses are registered with DNS. If a system does not have a DNS entry, various services (e.g. email) at SSUET 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, ACS staff will contact the Network Liaison. However you should be aware that Network Liaisons are not currently visible outside SSUET, and have limited visibility even within SSUET. 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, ACS needs to be able to reallocate addresses that are no longer in use. Thus ACS 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 multi-user 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. 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 Academic Computing Services (from now on will be referred to as ACS), based on experience in handling problems.) Information from the logs must be made available to staff assigned to the ACS 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 SSNet 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 SSUET 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.

SSUET 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 owners are encouraged to take additional security precautions, such as use of a firewall or host-based firewall software. System owners must not log in to the systems using local domain admin account and password and must not allow any one to use their system with a local domain admin account.

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 NIC 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 NIC numbers, medical information, student records, and employee information. 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 accounts on ACS administrative or general-access campus systems) should protect transmission of the passwords using SSL or an equivalent technology.

We encourage departments to develop security plans for systems and information under their control. Staff from the ACS is available to discuss security recommendations for specific situations.

Also note the provisions in the Acceptable Use Policy and Guidelines regarding confidentiality and privacy. System owners 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.

ACS provides limited or no 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. This also includes computer systems not owned by the university.

All systems at SSUET 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 SSUET to get them to relay email to other systems outside SSUET.

Handling Problems

ACS reserves the right to take action when problems on an individual system affect other systems at SSUET or on the Internet as a whole. Examples of situations where ACS would take action include, but are not limited to

Where possible ACS will attempt to notify the owner of a system before taking action. As described above, ACS staff may 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 departmental network of which it is a part, may be disconnected from SSNet 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 ACS has referred a problem to a system administrator for action, a brief report on the resolution should be made. This will allow ACS 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, ACS 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 break-ins. However system administrators are expected to deal with the problems in a timely fashion, and report the results.

Use of Softwares on Computer Systems

System owners are asked not to install operating systems other than the operating systems recommended and provided by ACS. Support group will not be responsible to provide technical support of unsupported operating systems. Computer systems on dual boot are also not supported.

What is Spam?

Spam is any excessive, unwanted news group message or email message.

Why is Spam a Problem?

Spam is a problem for two reasons:
1) Spam sent by SSUET users can cause trouble for users elsewhere on the Internet. This creates a bad public image for SSUET, and could eventually lead to actions being taken by Internet sites to limit the ability of SSUET to communicate with them.
2) Spam sent to SSUET is annoying for our users, and can also cause excessive use of resources such as disk space.

Policies Regarding Spam

The following rules apply to any mail sent from a SSUET computer system, or involving a SSUET computer system (including the network) in any way, including using a SSUET system as intermediary, or listing an address on a SSUET system as a contact address in the message.

1) It is a violation of acceptable use to use SSUET facilities for commercial use.

The policies referred to prohibit any email doing advertising, even if that mail complies with the rest of the guidelines in this document.

2) You should be aware that there are a number of laws currently in force, and more proposed, that could result in legal problems in connection with any unsolicited commercial email, even for SSUET itself. Thus unsolicited commercial email is covered not only by the commercial use provision of the Acceptable Use Policy, but also by the provision requiring all use of SSUET facilities to be in accordance with the law. Even if there were not any other policy problems with it (and in many cases there are) anyone contemplating emailed advertising is responsible for doing whatever investigation is necessary to make certain that the contemplated actions are legal in all jurisdictions whose mail servers or users might be involved. Specific guidelines will not be given here, because the laws on this are changing.

3) It is a violation of acceptable use to send substantially the same message to more than 50 users, except via a mechanism such as listserv or netnews, where users can control their participation. There are exceptions for official University business, such as events sponsored by the university and its allied institutions.

4) It is a violation to send email that a reasonable person would consider harassment, including email to any person that has requested you not to send them email, or repeated email to someone you don't have a pre-existing relationship with.

5) All email must contain a valid From: field, identifying an email address to which questions and complaints may be directed.

System Owner / user Responsibilities Regarding Spam

1) System owners / users are expected to respond to complaints from users about spam sent from their system, or transmitted through their system.

2) If the system owner / user determines that spam was actually sent, they are expected to pursue administrative or disciplinary measures that can reasonably be expected to prevent further occurrences.

A number of spammers "bounce" messages off of systems other than their own, in an attempt to hide their identity. Most Internet system administrators expect systems to take action to prevent that. Thus:

3) System owners / users are expected to configure their systems so that they cannot be used as intermediaries to forward spam. The simplest way to do this is to configure your mail software so that it will not accept email from other systems unless it is directed to users on your system. Where you must relay messages from other systems, you should only relay mail from systems in your department. In no case should you relay mail from systems outside SSUET except to your own users.

What Can You Do About Spam Sent to You?
Unfortunately it is not always practical for support staff to follow up on all complaints of spam received by their users. Thus this section is intended to provide some help for users who want to follow up on spam themselves.

Email Spam

Avoiding unsolicited email is difficult. Included in the standards is a recommendation that unsolicited email include three asterisks (***) at the start of the subject field of such messages to enable users to readily recognize them as solicitations. This convention will allow consumers who use email software that enables message sorting to be able to sort these messages. Not all email software supports this feature, however and since this solution is voluntary, it's only of limited value.

You can also try writing to the sender's internet service provider. First you'll need to figure out what machine the message came from. You can't trust the "From" line of the email message, because that's too easily forged.

Once you know what machine the message came from, you're ready to use traceroute and/or whois to find out who the internet service provider is. Traceroute will show the route that packets take when they are routed to the target machine (the machine that sent you the email spam). If you look at the site just "upstream" from the target site, typically that will be the site's internet service provider, who may have some leverage over their behavior. Using "whois", you can sometimes get contact information for the ISP. Also, writing to "postmaster" or "abuse" at the ISP domain name will sometimes get through.

If you do send email to the Internet Service Provider, you're more likely to get a helpful response if you send a polite complaint.

What Not to Do About Spam?

Email bombing the sender or the ISP is not helpful - the return address is probably forged/phony. Also, email bombing can backfire on your own systems, and is a violation of Acceptable Use.

Also, don't be fooled by scams which solicit your email address in order to block future spam. One scam currently circulating is called the "REMOVE" list and promises to block many internet mass mailings. Instead, subscribers report receiving 10 - 15 junk mail messages a day.

Some Details for Unix Systems Administrators / Owners:

Wietse Venema, author of tcp-wrappers, portmap, and other security tools, has developed an access control patch for sendmail. This allows the sysadmin to designate hostnames from which mail will not be accepted. This can be effective against spam: after the first round of spam, simply type in the name/address of the spammer's email host. However, a few caveats:

In addition to this document, specific computers and labs may have their own rules. These should be posted clearly at the facility, or pointers included in the login message. Violations of those rules are considered violations of Acceptable Use, and may be reported using the procedure in this document.

Specific Interpretations
Interfering with Other Systems

Both the policy and guidelines documents indicate that computer resources may not be used to interfere with other users. However enough cases have come up recently that it seems worth an additional explanation.

Problems often occur when someone creates a program that does something lots of times. For example, if you write a program that looks at the same web page thousands of times, this will normally cause a problem. Both the servers that handle web pages, and the network that gets the pages to you, are designed for normal human use. They are not designed to cope with programs that ask for the same thing many times.

Similarly, sending the same request via email a large number of times (even in the same email message) will often cause problems. So will repeatedly opening and closing network connections, continuously sending "ping" packets, etc.

Networks can only handle a limited amount of traffic. SSUET has a fairly high-speed connection to the Internet. However smaller educational institutions and commercial sites may not have connections that are as fast. It is possible for a single person at SSUET to do things that will effectively shut down network access for a smaller site. If you do this, you are liable not only for University discipline, but prosecution. Generally you should be safe if you only use standard system tools in the way they are intended to be used: viewing web pages yourself, logging into a computer and using it, etc. If you start writing programs or scripts that use these tools repeatedly or in unusual ways, it is your responsibility to make sure that what you are doing will not cause trouble for the rest of the network.

While it is normally safe to use standard system tools, the same does not necessarily apply to tools you get from others. For example, certain members of the IRC community distribute programs for disrupting IRC connections. Such a tool is in itself suspicious, since disrupting someone else's activity is generally a violation of Acceptable Use. What's worse, some of these tools work by creating a network overload. Thus they may not only disrupt the person you are trying to disrupt -- it may interfere with the entire machine or the network itself.

Commercial Use

Commercial use is covered in both the policy and guidelines document. It is being mentioned here simply because commercial use is one of the most common violations of acceptable use. Here are some of the most common examples of things we consider commercial use:

There are often ambiguities about what is permitted. In such cases please feel free to send a query to help, or to consult with the ACS staff on campus.

Use in support of other organizations

ACS resources should not be used to provide services for organizations that are not part of SSUET without permission of a responsible SSUET official.

This is worth a bit of explanation, because it's often hard to separate your personal use from organizational use. The causes in which they are involved often involve outside organizations. This is often appropriate. What is not appropriate is running an official organizational web site, recruiting members for the organization, providing office, email or other operational support for the organization, or other functions that one would normally expect to be done by the organization itself.

One way to frame the question is whether the primary purpose is describing your personal activities or opinions, or whether it is support for the organization.

Email-related problems

Special issues apply to email to large numbers of people. This is a potential problem, for both policy and technical reasons. Therefore, it is considered a violation of acceptable use to send substantially the same email message to more than 50 users. Exceptions are:

While this document covers only ACS facilities. It covers all SSUET facilities. It has rules consistent with those in this section.

Even for email to fewer than 50 users, you must abide by other restrictions. This includes the restriction against commercial use, use in support of non-SSUET organizations, and the general requirement that all activities must abide by the law. There are now laws against unsolicted commercial email in some areas.

Issues with IRC

Many of our complaints from other sites involve users of IRC (Internet Relay Chat). Here are some of the most common:

People often think that nuking is a harmless prank. Unfortunately the software used to do this often operates by overloading the network on the other end. SSUET has a very fast network. We can easily generate enough network traffic to take another institution or company off the Internet.

Issues with netnews

We expect our users to follow community standards in use of netnews. This includes (but is not limited to):

In some other areas it is hard to codify acceptable behavior in a policy such as this, because certain standards differ from group to group. These standards often include the level of personal attack and strong language that are allowed. In certain groups there are other standards. We expect our users to follow prevailing standards. If you consistently violate those standards, readers may complain to the system administrator. If a system administrator or other ACS staff person instructs you that your postings are inappropriate, we will expect cooperation. (See the next section.) This policy is intended to deal with violations of group charters or similar standards for a group. Thus this rule may not be used by staff to control what views may be expressed by users.

Cooperation with System Administrators

From time to time activities may interfere with operation of the system, even though they may not clearly be prohibited by the Acceptable Use Policy. In such cases, the network administrator or other ACS staff person may contact you and ask you to stop doing something. You are expected to comply with such instructions. Once you have received such a warning, any further activity of the same kind will be treated as a violation of Acceptable Use.

This is intended to allow staff to intervene when immediate action is required to stop a concrete problem, such as overloading a system or network, interfering with other users' normal use of the system, or a security breach. It is not intended to give network administrators arbitrary authority. If you think a staff member has acted inappropriately in asking you to stop something, you may ask for the decision to be reviewed, in accordance with University policies and procedures. However you will be expected to comply with the ruling of the staff while this review is happening.

How to Report Infractions Involving ACS Systems

The majority of reports should be made through normal ACS support channels. This is the Information Center or Help Desk supporting the campus where the violation occurred. Where one of the central ACS systems is involved, the report may also be sent via email to "help" at the system involved which can be an ACS staff member in person, telephone number or email address specially created for this purpose.

For more serious incidents, you may prefer to contact the Systems Manager, the IT Advisor or the University Registrar.

Note that ACS has no disciplinary authority except over its own staff. ACS staff may issue warnings, and may ask users to stop behavior that is disruptive. ACS may close accounts temporarily, disconnect computer systems from network when that is the only reasonable way to stop a serious ongoing problem, or to get a user to contact ACS staff or a head of department. But in order to take any actual disciplinary action, ACS operates through normal University procedures. For students ACS works with the appropriate head of department; for staff ACS will contact the individual's department or supervisor. (For certain guest users, there may be no unit with disciplinary authority. In such cases, ACS may have no alternative but to close an account permanently when substantial problems occur.)

For certain kinds of incidents, special reporting channels are appropriate. However if you have trouble determining what approach to use, it is always appropriate to consult normal ACS support channels, or the Systems Manager. In particular, Systems Manager maintains contact with other groups throughout the University, and can forward reports to the appropriate person or group.

Additions to the existing policies:
From time to time Systems Manager with consultations from the Senior University Management may implement rules regarding use of university computing resources including printers and other accessories. Details of which may be obtained from the ACS or network support staff. These rules will also be treated as part of this policy.

No Liability Clause:
The technical remedies mentioned in this document are based on documents written by several authors of different companies around the world. Sir Syed University of Engg. & Tech, Karachi. is not responsible for that content.