War Games: Teaching Web Security Hands-On

Helen Ashman, University of Nottingham, U.K.
hla@cs.nott.ac.uk

Abstract

Introduction

The student group are final-year undergraduates of a Computer Science degree. The coursework provides 25% of the final mark toward the G53CAS Cryptography and Security, an optional module available only to final-year Computer Science students. The module comprises an approximate 50/50 split between cryptography and network and Web security.

There were 86 students registered for the module. They were divided into ten groups of 8 or 9 students each. While these were large groups, they were a suitable size for the exercise as there was a substantial amount of work involved in setting up services, researching, maintenance of services, regularly testing availalability of other groups' services, and attempting to compromise other groups' services while defending and recovering their own.

The exercise was carried out on the School's Network Laboratory. For the duration of the exercise, the Network Laboratory was physically isolated from all external networks. While this was sometimes a problem for students wishing to download software (although they could still use the CD-ROM drives), it was preferable to restrict them than to make it possible for accidental hacking (either real or imagined/accused) to be perpetrated on external networks.

Each of the machines was "dual boot", i.e. it could run either Linux or the Windows NT operating systems. Each group was assigned a machine for their sole use. Part of the exercise was for the groups to decide which operating system and Web server combination they wished to use to provide the services, and to justify this decision.

Because of the limitations of the size and configuration of the Networking Laboratory, there were some classes of security that students were not be able to study in-depth during this exercise. These included physical security of equipment and network and email.

The services groups were to provide were:

1. a Web server, providing plain HTML pages to any clients at all
2. password-protected Web pages, available only to authorised users
3. the Web server providing simple CGI scripts
4. an ftp server, for anonymous and authorised users
5. telnet for authorised users only

Students had to create new users, at least one such user for each of the other groups, telling them what their passwords are. These other users should have been able to access the group's machine as authorised users of ftp and telnet. Authorised users should also be able to access the password-protected Web pages. Anyone at all should be able to access the plain HTML pages, the CGI scripts and anonymous ftp.

Assessment

1. The first 15 marks (out of 25) for each student was defined by a group report. This report included a summary of the group's activities and decisions, including platform chosen and reasons for this choice; logs of all important "events", i.e. all attempted attacks on the group's machine and services, detected, inc;uding time and date, nature, origin of attack if known, action taken to prevent /deflect/recover from attack, the damage done including down time and loss of service, an assessment of how well you handled the event; logs of all the group's attempted attacks on other groups, including identify of group attacked, time, date and nature of attack, source of the idea for this attack, "success" of the attack, i.e. any apparent loss or degrading of services from that group's machines, any apparent defensive mechanisms already in place, action taken by attacked group to defend (if known, an assessment of how well the other group handled the attack; logs of your occasional attempts to make legitimate use of the services of other machines, including time and date of attempted normal (legitimate) usage, identity of host machine and services requested, response from host - speed or existence of response, quality of information retrieved (e.g. are they the "real" pages?).

2. The next 5 marks (out of 25) was decided by each student's individual report. Each individual had to hand in a short report detailing their own contribution, how they rated their own contribution and how they rated the contribution of other group members.

3. The remaining 5 marks (out of 25) was determined by the rating of that student by the other members of the group.

Warnings

You are ONLY permitted to perpetrate attacks on other machines:

ONLY during the time of this coursework (from today until 24 March 2000)

and ONLY within the environment of the B74 Networking Laboratory.

Another VERY IMPORTANT thing to keep in mind is that this is ONLY a software-based based exercise. You are NOT to interfere with the equipment in the B74 Networking Laboratory in any way.

If you are detected attacking any other machine or services, either within the University or outside, you could be expelled from the University.

If you interfere with the equipment or connections in the B74 Network Laboratory, this too could lead to expulsion from the University.

In other words, JUST DON'T DO IT.

Poachers or gamekeepers?

Even if a student's subsequent job does not directly entail securing machines and services, it is still important for them to realise how machines are vulnerable to attack, and how simple mistakes by ordinary users can defeat the best security measures.

White and Nordstrom dealt with accusations of "teaching students how to hack" in a similar class exercise (White and Nordstrom, 1996). They noted that:

There are scores of hackers operating throughout the Internet today. We believe that hiding their techniques from our students only leads to a generation of system administrators who are "sitting ducks" for the hackers that are out there. We use a knowledge of security holes to teach our students what must be done in order to secure their own systems.

The results of the class exercise at Nottingham support this. We have no evidence that students have mis-used the knowledge gained by this exercise. This may be in part due to the warnings, and in part due to the "class culture" promoted throughout lectures, which places both lecturer and students firmly in the "defending" position. The exercise reinforced this position by encouraging students to feel personally responsible for the success of defending their services and quickly reinstating them when necessary.

Side effects

Another beneficial side effect is that the students' reports are being circulated amongst the technical services staff in the School. At this stage, reports have only just been released to technical services staff, following marking and assessment, however, we envisage that 86 students' worth of research is bound to contain something of real interest to these staff. If nothing else, the exercise serves to educate and reiterate both technical and academic staff about these important issues.

Student opinions

The adversarial nature of the exercise had many useful effects, including the following which were noted by the students themselves:

• it made the exercise more interesting by giving them "real" attackers to practise their skills against;
• it promoted strong bonds between the group members without creating friction with other groups' members;
• it created a strong sense of personal responsibility for the success of the group's services;
• it encouraged them to research and put to use up-to-date materials;
• they learned and expect to retain a great deal more than might normally be expected in lectures

There were very few negative comments, these being that the exercise took place in the second semester which is when there are many competing demands on the students' time, and that the four weeks allowed for the exercise was not enough time. However this latter problem was partly due to the students' general lack of knowledge about setting up services, and should be addressed in future by covering that material in the co-requisite module.

Summary

References

Hypertext References

HREF1

http://www.cs.nott.ac.uk/~hla/G53CAS/

Copyright

[ Proceedings ]