Michael Chiles, Luby Liao, John Paul,
Jeff Wright
University of San Diego
San Diego, CA 92110
mchiles,liao,jpl,jhwright@sandiego.edu
Abstract. This paper presents our experiences of giving students open network access during exams while insuring against cheating. The practical information presented should be of interest to would-be practitioners and technological conservatives who can test their pedagogies with an aim to give their students the best education while ensuring academic integrity.
A
question frequently asked by instructors in an increasing number of disciplines
is how to give an exam that allows students limited and controlled access to
the Internet from classroom computers. The following question posted on the ACM
SIGCSE Forum mailing list on May 5, 2002 is typical:
'Has anyone tried giving a programming exam for some of your intro-level courses in a lab? I always get complaints from students that it is not fair to write code on a piece of paper without using the tools they normally use (and they are right about that).
So, I want to block a lab for 2 hours, and assign a few programming problems to work out, and let them do it. However, I want to somehow avoid them sharing efforts, so that might means having every machine disconnected from the network.
What other issues are there? Has anyone tried this? Has it worked? Do students do better than in paper exams? ...'
This paper details one possible solution to this problem in the context of an Engineering Math course. Our approach addresses the poster's problem without disconnecting machines from the Internet.
In the Spring semester of 2002, Jeff Wright taught two sections of Math 110A: Engineering Math using Maple 6, a well-known computer algebra system in a lab equipped with Apple Macintosh computers. To run Maple, each computer must obtain a license from a remote license server which limits the total number of Maple users on the USD network at any given time. While students use Maple in class and during exams, they are encouraged to access the class web site where Jeff maintains copies of relevant Maple worksheets and other items of interest. To summarize, Jeff's problem is to allow students access to the remote license server and the class web site, but disallow other uses such as chat, email, instant messaging, and other unauthorized Net access.
On the flip side, the ideas presented here may be useful to people who for one reason or another believe that giving students any network access during an exam is a bad idea. Our approach allows them to test their hypotheses, focusing on pedagogical issues without concern of student cheating.
Our
solution is outlined in the following steps:
Because the USD campus network uses a secure switched Ethernet, which effectively transforms the traditional Ethernet from a broadcast technology to a point-to-point technology, the solution described above will not work before the campus network administrator performs a configuration procedure known as port mirroring [2]. What is relevant is that the only traffic a machine can normally see is its own and broadcast packets that a computer sends to all computers on its local area network. Port mirroring copies packets in and out of all the monitored machines to the monitoring machine to make them visible to the latter. Separately, USD has a strong privacy policy that prohibits unauthorized sniffing of IP packets. To summarize, we need to
1.
First, we obtain a list of the Media Access Control (MAC) addresses of the classroom computers from the campus
network administrator. Every campus computer connects with the campus
network using an Ethernet card. Every Ethernet card has a permanent and
unique address called MAC address of the form hh:hh:hh:hh:hh:hh, where h is
a hexadecimal digit. Here is an example MAC number:
00:05:02:58:27:2F. Note that MAC should not be confused with the
Apple Macintosh computer. The relevance of MAC addresses lies with the fact
that our lab computers obtain their IP addresses from a DHCP server when they
are powered on. These IP addresses are dynamic as opposed to static
because they can potentially change from time to time rather than staying
fixed. MAC addresses, on the other hand, remain fixed and serve to
identify the computers and the students using them.
2.
Immediately before the exam, we run the following tcpdump command on a computer on the same local area network
running Redhat Linux 7.2:
tcpdump
ether host 00:05:20:C5:67:40 or
00:05:20:96:3F:2E or ...
Note that we use MAC addresses, rather than the potentially transient dynamic IPs to specify the monitored machines. Here '...' stands for the remaining long list of other MAC addresses. What follows the tcpdump command is an example of a filter expression. In practice, since the filter expression is very long, we use a more convenient form:
tcpdump -F tcpdump_exp
where tcpdump_exp is a file that contains the filter expression and -F instructs tcpdump to read the filter expression from the file. This command will capture all inbound and outbound packets from all the machines listed in tcpdump_exp.
Tcpdump is a freeware packet-sniffing program available for Unix and Windows machines. Tcpdump can be installed with the following simple rpm command on computers running Redhat Linux:
rpm -Uvh tcpdump-3.6.2-12.i386.rpm
A fragment of the output
from the tcpdump command
follows:
|
|
... 07:29:09.967237 xyz203.sandiego.edu.1612 > www.sandiego.edu.http: P 607407960:607408445(485) ack 2259258923 win 32768 (DF) 07:29:09.973142 xyz203.sandiego.edu.1611 > www.sandiego.edu.http: P 607340903:607341388(485) ack 2259236870 win 32768 (DF) 07:29:09.981277 xyz203.sandiego.edu.1610 > www.sandiego.edu.http: P 607262682:607263167(485) ack 2259192664 win 32768 (DF) 07:29:10.013620 www.sandiego.edu.http > xyz203.sandiego.edu.1611: . 1:1461(1460) ack 485 win 8760 (DF) 07:29:10.013667 www.sandiego.edu.http > xyz203.sandiego.edu.1611: P 1461:2023(562) ack 485 win 8760 (DF) 07:29:10.015540 xyz203.sandiego.edu.1611 > www.sandiego.edu.http: . ack 1461 win 32768 (DF) ... |
The first line says that at 7:29 AM, the machine xyz203.sandiego.edu sent a packet from its port 1612 to the USD web server machine www.sandiego.edu which listens on the well-known port 80, symbolically named http. '>' visually indicates the direction of the communication. For details of the meaning of the output line components, we refer the readers to the manual page and [1].
Even though we specify MAC addresses in the tcpdump command, the tcpdump output identifies machines using their DNS names and not MAC numbers. In a moment, you will see that at USD the DNS names of the monitored machines are programmatically mapped to their dynamic IPs in an intuitive way. For example, xyz203.sandiego.edu has IP address 192.215.84.203. Thus, we need a table that maps the MAC address of each machine to its dynamic IP during the exam. We use another freeware packet sniffing program called ettercap to produce this table. The command is
ettercap -Nl
The output columns, aside from the first, are IP address, MAC address, and fully qualified domain name of each lab computer:
|
|
... 14) 192.215.84.172 00:05:02:37:24:9F xyz172.sandiego.edu 15) 192.215.84.190 00:05:02:F5:2B:04 xyz190.sandiego.edu 16) 192.215.84.205 00:50:E4:05:DA:55 xyz205.sandiego.edu 17) 192.215.84.207 00:05:02:1E:D0:6F xyz207.sandiego.edu ... |
3. The final step is to analyze the tcpdump output. Visually scanning it is instructive, but since the readable output is megabytes in size, it is useful to write scripts to generate reports out of the tcpdump output file. We used the Python programming language to develop these scripts, but any language with strong text processing support, such as Awk or Perl, could be used. As an illustration, we show fragments of two HTML reports we generated. The next two tables in the first HTML file report on two machines, xyz157 and xyz159. These tables show outbound traffic of each machine. The three columns of the tables are the source port used, the destination machine and the destination port.
|
src port |
destination host |
dst port |
|
netbios-ssn |
lsanca1-ar22-4-33-006-054.lsanca1.dsl-verizon.net |
2463 |
|
1857 |
http |
|
|
netbios-ssn |
adsl-66-125-108-220.dsl.scrm01.pacbell.net |
2487 |
|
netbios-ssn |
66-105-104-140.customer.algx.net |
2843 |
|
1861 |
http |
|
|
Bootpc |
dhcp1.sandiego.edu |
bootps |
|
1865 |
http |
|
|
...
|
|
|
|
netbios-ssn |
63.238.255.255 |
17065 |
|
src port |
destination host |
dst port |
|
netbios-ssn |
lsanca1-ar22-4-33-006-054.lsanca1.dsl-verizon.net |
2459 |
|
netbios-ssn |
adsl-66-125-108-220.dsl.scrm01.pacbell.net |
2483 |
|
netbios-ssn |
66-105-104-140.customer.algx.net |
2839 |
|
http |
211.219.112.180 |
3267 |
|
Bootpc |
dhcp1.sandiego.edu |
bootps |
|
netbios-ssn |
HSE-Ottawa-ppp240974.sympatico.ca |
1798 |
|
netbios-ssn |
64.128.149.45 |
1875 |
|
http |
218.11.130.38 |
4820 |
|
...
|
|
|
|
netbios-ssn |
63.238.255.255 |
17056 |
Immediately we notice that the student machines contacted various targets that appear suspicious or require further investigation. To wit,
1.
on line
1, xyz159 talked to the server running on port 2459 of
sanca1-ar22-4-33-006-054.lsanca1.dsl-verizon.net. Is this a violation?
2.
on line 2, xyz157 talked to the USD web server
listening on port 80 (symbolically named http) of
www.sandiego.edu. In this case, further investigation is needed to decide
whether xyz157 was accessing Jeff's home page at
http://www.sandiego.edu/~jesper legally, or someone else's web site such
as http://www.sandiego.edu/~cheater
illegally.
Note that in the first case, xyz159 talked to its target using a privileged port 139, symbolically named netbios-ssn. This contact was not initiated by the student and therefore does not represent a violation. In the second HTML report we generated, such irrelevant records are filtered out.
To answer the second question, a simple programmed
scan of the USD web site access log will suffice. To emphasize the
importance of this simple but essential procedure, imagine the following
scenario. Student A prepared his cheating group by training the members
to use Netscape editor to publish to a common web site
http://www.sandiego.edu/~cheater. During an exam, all the group members
open Netscape editor to constantly publish their solutions to the site for their
members to see. A simple Unix command grep applied to the web
access log will catch this.
As promised, the next HTML report
excludes irrelevant information from the report.
|
src port |
destination host |
dst port |
|
1857 |
http |
|
|
1861 |
http |
|
|
1865 |
http |
|
|
1865 |
http |
|
|
1870 |
http |
|
|
1882 |
http |
|
src port |
destination host |
dst port |
|
49152 |
dns.sandiego.edu |
domain |
|
49158 |
ntp |
|
|
1367 |
http |
|
|
1363 |
http |
Line 1 of xyz159's table is the result of a contact to the Domain Name Server of USD, typically triggered by a web page request. Line 2 is a request from xyz159 to ftp08.apple.com, a time server, to synchronize time. Neither of these packets could be used by students to carry out clandestine communications.
After the post-exam analysis, we found no evidence of cheating. We feel that our method is effective for empowering students while preventing them from abusing their power. This practice enriches Jeff's teaching method and benefits his students. Our successes have encouraged us to continue to improve and streamline our approach and to experiment with new ones. The Python programs we have written to generate the reports are not refined enough to be published, but they can be useful to some people as examples. Feel free to email liao@sandiego.edu to request copies.
[1] S Northcutt & J
Novak, Network intrusion detection, New Riders, 2001
[2] R Seifert, The switch book, Wiley computer publishing, 2000