Abstract

In the present paper we will describe the policy security of the institute and how it has been implemented using a firewall built with cheap PC hardware and free software. We will also describe how the users were educated and their reaction to the establishment of such a policy.

Context

Two universities share the Jussieu campus in Paris. It is the largest one in France with more than 60 000 students and about 7000 staff members. The "Laboratoire de Minéralogie-Cristallogaphie" is one of the research institutes. With about 120 members and 150 machines connected to a local area network it is a rather big institute. The Research Computing Center, which manages the campus network provides the connectivity to the outside world (Internet) and between the different institute sub-networks. Due to the size few controls can be performed at the campus level, so the security policy must be implemented at the institute level. The border between the institute Intranet and the outside world (Internet) is located at a unique point, the router connecting the institute to the campus network.

The members of the institute are ordinary users with no particular competence in data processing. The regulations, in France, practically prohibite the use of cryptography although they are changing. The users may have to connect from anywhere in the world. They do not use notebooks but use what computer or terminal is available on the site. We cannot rely on the fact that one particular software is implemented. We have already experimented intrusions from hackers.

We have a need to increase the security with minimum changes to the users habits.

Risk assessment
 
Before defining any security policy we have to assess the risks by examining the causes and the possible consequences of an incident.

When asked about security most people think to hackers coming from the Internet. The campus is connected to the Internet with a large bandwidth (155Mb/s) and academic organizations are known to be vulnerable, so the institute is a good target for hackers. This danger must no be minimized but hardware failures (disk crash), software failures, user mistakes (involuntary deletion of files) are more frequent. The malevolence can also come from the inside especially in a campus where buildings are largely open. The theft of computers is not rare. Catastrophic events as fire or flood must also be considered.

Very often a problem leads to data loss or data corruption. If the data can be restored from backups the damage is limited. In our context a few hours stop to restore data is not very serious. The most important issue is to have good backups and to detect the problem early enough before the tapes are recycled.

An intrusion or data theft can hurt very badly, so it is necessary to have good logs in order to detect them. A malicious person who gets access to the system can make many damages, especially if he/she connect from the outside. A particular concern is the hacker who connects from the outside using the stolen identity of a legitimate user and then use our network and this identity to perform illegal actions on the Internet. With one time passwords it is much harder to do this. Keeping good logs on the firewall of the traffic between the internal network and the Internet may help if a problem is discovered.

Generally members of academic organizations do not think that they have valuable information to protect.

Security policy

Whatever is the problem, good backups are essential to resume the service. All services that are legitimate (telnet, rlogin, FTP, HTTP, SMTP, POP, IMAP,) are allowed. On the other hand a strong authentication using one time password is performed for connections from the outside. New services are added as needed. A few useful services such as " talk ", well known for its problems are excluded. Everything not explicitly authorized is forbidden. When requested we add new services to the authorized ones. It is the safest method but it is very difficult to implement from a previous unrestricted situation. We routinely analyze the logs in order to detect possible problems. The major benefit from the firewall is certainly the logging of all the connections between outside and inside. We assume the inside as safe (although it is a too optimistic view) and the outside as unsafe. So we perform strong authentication only for the incoming connections and only log the outgoing connections. We use one time password in order to avoid the fact that a stolen connection can be replayed. Only machines and services that have to be known are reachable from the outside.

We routinely scan the logs in order to detect possible problems. We log a lot of events and keep them for a long period in order, when an incident arises, to reconstitute what happened. The log files are voluminous and we have to apply filters to analyze them. The rules must be adapted to the specific environment to extract only the pertinent information, focus on the possible problems and ignore normal traffic.

Implementation

The backups are performed each night and centralised through the network to a tape changer which has a capacity of 10 7Gbytes Exabyte tapes. We use the free software Amanda [1]. The load is automatically balanced between full and incremental backups in order to keep the size of data backed up each night roughly the same. All Unix machines are concerned. This also includes PC running both Windows and Linux. The PC with dual boot, by default boot under Linux. When running Windows a program called sleepy [2] automatically reboots the system at a predefined hour during the night so as to run Linux. When running Linux a command (lilo –R dos) put in the cron table allows to restart the PC under DOS so the user gets a Windows system when coming in the morning. The DOS partition is mounted under Linux and processed as a Linux one. The Macintosh are not backed up.

The firewall possesses three interfaces: one connected to the Internet, one to the internal network and one to a demilitarized zone (DMZ) for a Web and anonymous FTP servers. The machine is a PC running Linux. We use the Red Hat [3] distribution. The security is performed by a combination of IP filtering and proxies. IP filtering is performed using the Linux facilities (the ipfwadm command or the new ipchain one). Most proxies (telnet, rlogin, X11, FTP) come from the TIS toolkit [4]. We also use other free software: Bind [5] from the Red Hat distribution, Squid [6] for HTTP protocol (web), Postfix [7] for SMTP protocol (mail). More proxies can be found at [8]. TIS is a toolkit, not a black box, that the administrator must install and configure in order to implement the security policy. We consider that it is not a disadvantage because the most difficult part is to determine the security policy, test the rules and educate the users.

When connecting from outside, the user is first authenticated on the firewall using a one time password. The proxy ask for the user name, then send a challenge and the user must respond with a password that is a digest (MD5) of the challenge and a secret shared with the firewall. The firewall computes the password using the same algorithm and compares it to the received one. If there is no discrepancy the user is authenticated and relayed to the machine he wants to connect. Since the challenge is never the same, it cannot be replayed even if the communication was intercepted. To compute the one time password the user has three choices: 1) He may use a calculator running on the machine from which the connection is issued. By copying and pasting it is easy to transfer the challenge to the calculator and the password back to the application. 2) Some applications such as FTP or telnet include this feature. 3) Use of a paper list of passwords previously generated, and copy of the corresponding password. Any user wanting to connect from outside carries a password list or a diskette containing the calculator as well as versions of telnet or FTP applications that manage one time passwords. We distribute diskettes for Windows and Macintosh. This solution requests no specific hardware or software on the remote site.

The most vulnerable element and the target of all the attacks are the firewall. In order to control its integrity, the signatures of all the files are computed each night by the Tripwire program. Security fixes must be applied as soon as they are available.

Many attacks cannot reach the machines on the internal network because only some machines and, on these machines, selected protocols only are visible from the outside. This is especially useful for most of denial of service attacks.

Policy and users

The real challenge is not a technical one but a human one. Switching from a very open policy to a more restrictive is not so easy. Everything must work for the D-day. So exhaustive tests have to be performed. Education is the most important issue.

Establishing the best policy and using the best software is meaningless if it not accepted by the users. It took us six months to increase the level of security to its maximum. The firewall was first installed and tested on a small isolated network simulating the operations. Then it was operated using only logging functions. By modifying the MAC addresses and the ARP tables we are able to put or withdraw the firewall without disrupting the network traffic. Step by step we have added controls. This process took about six months.

Meanwhile we have written guides and made them available on the Web server. Regularly we have sent messages to the users to explain what was coming up. We have also organized several seminars. All this was not sufficient, so we had to give personal help to some users and to show them how to use the one time password. However, users who were abroad had no problem to connect with the only help of a paper copy of the guide sent by mail and a phone call to establish the initial password. All users are not equal in the use of the tools and we had to adapt to each one. Nowadays the safety procedures are accepted by all users, although they are not always very happy.

The security begins by following rules that may seem as trivial as having good passwords, changing them regularly, disconnecting the session when leaving the computer, always requiring an authentication to use a computer. It is not so easy to enforce these rules. We use automatic procedures because people accept more willingly to have is their account locked by the system rather than by a human intervention, which is often considered as a personal aggression. For a good acceptance the thing must be as simple as possible for the users. So whatever the machine he/she connects on the internal network the user gives always the same login name an password. The user as only once to authenticate on a machine. We avoid as much possible a second authentication to connect to another machine. The login names and passwords are shared among all the Unix systems using NIS. The Samba free software [9] allows a Unix server to act as a Windows NT domain server with the extra benefit to share the login name and password between Unix and Windows. For availability reasons we use two Samba servers. Using "poledit" the Windows policy editor and storing the configuration on the servers we require a user to first authenticate and we can control what he/she is allowed to do on his/her Windows computer. Login scripts are also stored on the server and are executed when the user logs in; they are used to perform several actions as to update the anti-virus with the last signatures.

Conclusion

The configuration of the firewall (Pentium pro 180Mhz, 64Mbytes RAM, 2Gbytes SCSI disk) and free software is rather cheap. But it requires a lot of work to implement it, although the most important part of the work is to define the security policy and to test it. We are connected at 10Mbits/s to the campus network and we experiment no performance problem. The main processor activity is logging the events.

Since the firewall is in use, it is astonishing to see the number of attempts to enter an academic network not only from hackers but also from institutional users. The firewall is running at maximum security level since one year about and we think that we have a good control of the use of our machines as well as the exchanged traffic. The LMCP is an institute of 120 persons about. We believe that it is the good level to establish all controls since the traffic remains rather limited and because it is possible to know and to guide each user. This would not be feasible at the level of the campus where personal contacts are always limited.

Bibliography

[1] http://www.amanda.org/
[2] http://www.jps.net:/shashazur/software/sleppy/
[3] http://www.redhat.com/
[4] http://www.tis.com/research/software/fwtk_readme.html
[5] http://www.isc.org/bind.html
[6] http://squid.nlanr.net/Squid/
[7] http://postfix.eu.org/
[8] http://www.freshmeat.net/appindex/daemons/proxy.html
[9] http://www.samba.org/

Address 

LMCP, case 115, 75252 Paris Cedex 05, France,
E-mail: Francois.Morris@lmcp.jussieu.fr
(a) Present address: IHP, 11 rue P.M. Curie, 75231 Paris Cedex 05, France