Projet Authentic (en)

AUTHENTIC netwok security system : only among friends

In an academic and research context user mobility is a must. People frequently work from home or participate in exchange programs, from where they still need to access the resources of the university of Lausanne. So the big question is: how to let in friends (authorized users), but keep out foes (hackers). Authentic is a user-friendly solution that contributes to a more secure network.

Today, it is impossible to imagine an university without any access to the Internet. In the same time, nobody can ignore anymore the related risks. But applying security is not an easy task in the academic world. People are so used to freedom and openness. The security parameter is most of the time inversely proportional to the user comfort one. The main challenge of Authentic (you will see later why we choose this name for our project) is not to introduce the highest level of security. Instead, we would like to push security in some direction as far as the user comfort can still afford, and to keep the door open to future evolutions.

Where are the dangers ?

The following elements are concerned by the security issue in a networking environment: the user applications (e.g. e-mail reader), the host operating system and the network infrastructure. Authentic focuses on the network level, coordinating with the efforts deployed by other groups inside the UNIL Centre Informatique (Ci) of the University of Lausanne (UNIL) which are dealing with the first two elements. It builds an additional line of defense for our machines against external threats and protects the user data which is traveling on the network.

Many studies claim that the majority of attacks (~70% !) originate from inside. This is not at all the case at UNIL. Until now, we have not received any report of users hacking one another. Even if we offer direct connections to several external organizations (e.g. Centre Hospitalier Universitaire Vaudoise) for them to access the Internet and our internal resources, we never experience hacking problems from them. So, it seems quite reasonable to trust the internal traffic and even to consider the connected organizations as being part of our network. Nevertheless, sometimes we have to deal with situations where somebody illegally unplugs a public accessible device e.g. a printer in a corridor, and connects his/her own laptop to get access to all UNIL resources including software distribution server. Fixing the MAC address on the corresponding switch would augment the central administrative task because adds and moves are frequent and done by institutes themselves. Instead, a low cost mechanical kit has been designed: a small part is installed inside the RJ45 connector and only the authorized local administrator can unplug it with a special tool.

As for outgoing activities, the only major problem concerns a few users downloading large files from the Internet. Each day, traffic statistics are analyzed by the Ci. If an abuse is noticed, the local administrator is directly contacted. With this procedure, the situation is quickly in control. This problem may increase our SWITCH bill, but actually does not endanger our network. Again, it is reasonable not to impose security constraint here.

On the other hand, one cannot be wrong to say that dangers are from the Internet. Concerning public access points (via wireless technology or RJ45 plugs), they should be considered as being part of the Internet, because there is no control of comings and goings on the campus and anybody can plug in to get connected. The primitive solution that consists in forbidding all externally initiated traffic is definitely unconceivable in an academic and research context where user mobility is a must. People frequently work from home or participate in exchange programs, from where they still need to access UNIL resources. So the big question is: how to let in friends (authorized users), but keep out foes (hackers).

A user-friendly solution

There is not a single universal solution to the security problem. After all, it is a matter of common sense. A bank has not the same concerns and stakes than an university. Even among people inside a same professional environment, security and dangers are perceived differently from one person to another.

In our approach, we would like to favour the user comfort (and productivity):

No special client software is needed for the main basic usage. Warranting interoperability of client software in a multi-platform context (PC, Mac and all UNIX flavors) with old and new versions of OS and hardware is a daunting task, especially when the involved machines do not belong to UNIL. Sometimes, people use a machine on which they may not load any extra piece of software, simply because they are not the owner.

Special services (e.g. encryption service) that require extra software must be optional.

The solution should be transparent to user applications and easy to use. User training should be kept to the minimum.

On the technical side, it is highly desirable:

To avoid proprietary solutions. The security system must interoperate with other existing elements. It will be obliged to evolve as future needs arise, and we would like to be able to mix and match products from several vendors if necessary.

To have a centralized solution where the Ci will bear the burden of ensuring the same level of security for everyone. Anyway, most people at UNIL are too busy with their own tasks to devote any time involved in security issues.

To have a low cost and easy to manage solution.

Authentic is based on the following idea: if we can verify that the person who is trying to access UNIL from outside is an authorized user, then we let him come in. Let's describe a typical scenario to illustrate this procedure (see also Figure 1):

A user from Internet tries to open a Web page hosted on a server of UNIL. His request is intercepted by the firewall (see phase 1) that seizes this opportunity to authenticate him.

During phase 2, an authentication dialog box is sent to the user screen (see Figure 2). The user enters the same username and password he currently uses for his e-mail account.

In phase 3, the firewall checks with the existing database that lists all authorized users. If the verification is positive, the initial request (and subsequent requests) is permitted to continue its normal trip and the user will have the desired Web page displayed on his screen. From now on, he has almost (See description of the red list below) the same access privileges to UNIL resources as if he is sitting inside the campus and all his usual applications behave as before.

Figure 1. Authentication procedure for users trying to acess the University of Lausanne from outside (UNIL)

Figure 2. Authentication window sent to the user screen during the Authentication procedure

This procedure requires a minor effort from the user. The authentication process is transparent: he has not to connect expressly to some server to get authenticated. He needs not an other username/password to remember. In order to make life still easier, the firewall also accepts a telnet or ftp session for authentication purposes. Most machines already possesses at least one of these three most popular applications, so no extra special software is needed.

Only authenticated traffic is permitted to get in. Hacking activities are stopped at the firewall fence. A hacker will not even know the existence of our machines: all scanning packets are dropped and will not get any response. because all protocol ports, including the http port (this should keep Code Red out), are closed to anonymous access. By default, machines at UNIL are placed in this list to be protected. We call it the orange list. Actually, there exist two additional lists to cover specific needs. The red list includes machines that are hidden from any external access, e.g. software distribution servers. Hosts in the green list are always visible (entirely or only for a few services) without authentication, e.g. www.unil.ch web server. They must be carefully secured in order to minimize the risk of being hacked and served as gateway for attacks aimed at the red and orange lists.

To encrypt or not?

These days, there are lots of talk about data being "sniffed" while traveling on the net. To understand the real risk level, let's look at the data path that lies down between two communicating nodes and comprises campus and ISP sections. Apart from technical staff, hacking network equipments e.g. routers to collect data by an outsider is very improbable. The UNIL campus uses Ethernet switches: each machine has its own port, and traffic on one port cannot be captured from an other port. Today ISP networks are considered quite immune from spying by a remote hacker. On the other hand, if you are on a campus that is still using a shared technology e.g. hubs, there exists a real risk: a sniffer program may be installed on a hacked host connected to the same local subnet. This is also true for wireless access which is based on a shared media.

Today, encryption is not yet a native service for most of operating systems and still needs some extra piece of software. In addition, administrative effort is required to distribute and revoke keys. As seen above, risk sources are mainly limited to technical staff and shared technology context. The non-commercial and highly specialized nature of data from most of our users further restricts the risk scope. How many times did we receive from users complaints about their data being intercepted on the network? None (contrast that risk with the much more common and easier theft of data off hard disks where data resides most of the time unencrypted!). So, it seems better to provide encryption as an optional service.

After a careful comparison, it appears that the open standard IPSec would be the best bet. Despite some interoperability problems, slowly but surely, it is finding its place as an integral part of new versions of operating systems e.g. Windows 2000. It lends itself to a centralized scheme where the firewall plays the role of the gateway. On the remote client side, once the software loaded and configured, the remote user sees no change at all. The authentication procedure remains the same. But now encryption is done transparently at the network level for all data (including the username/password used during authentication phase) and applications.

IPSec creates a definitely secure encrypted pipe between the remote host and the UNIL firewall. It offers a dependable protection for the sections of the data path on which UNIL has no control. There is no need to have extra software on the internal host whose clear text traffic to and from the gateway is already protected by a switched network.

Need a stronger authentication ?

There may exist critical servers that require a stronger authentication than the one described so far. Instead of introducing new tools, one can obtain the same result by making compulsory the pair username/password-encryption key. This two-factor scheme is highly secure. To be successfully authenticated, the remote user needs to prove he possesses the correct username/password and key. These two elements are stored at different locations (the username/password in the head of the user, the key in his PC) and protect each other. If the PC is stolen, the thief cannot access the critical servers because he does not know the username/password. The username/password (and all subsequent data) is encrypted by the key before traveling on the network in order to minimize spying risks. This solution also protects against Trojan keyboard sniffers that enable a hacker to capture the username/password while it is typed: the hacker still lacks the right key.

Presently, for all the reasons evoked above, we refrain to impose this scheme for general use. But this can change as soon as IPSec will become as popular as IP today. So wait and see.

Conclusion

We have dealt so far mainly with technical issues. Actually, we also realize that the human aspect must be taken into account: users and hackers are human beings with their rational and irrational behavior. A good technical solution alone is not a guarantee of success. We need to convince, inform and train the users to get them to play the game. To fight against hackers, we need to understand the psychological issues of their acts.

Authentic does not claim to be the final answer to all security problems. It only contributes to a more secure network. It should continue to evolve with time as new needs will arise and new technologies will be available. In the meantime, we are still learning to better understand the security issues. By keeping Authentic simple and coherent, we hope to make life easy for our users and ourselves.