All existing lab workstations and servers connect to the campus network directly, through a wall jack managed by UW Computing and Communications (C&C), or indirectly through a hub or switch, which is then connected to the C&C wall jack.
Here is a simple representation of the network:
Incoming and outgoing network traffic is beyond our control once it crosses that line of demarcation, the wall jack. Lack of control means:
Since there is no incoming protection from external network attacks on our computers, all computers are constantly being probed for security holes, and unsolicited advertising and other messages from outside of the campus can appear on our computers.
Web information is predominantly incoming traffic. It is interesting to note that one faculty member (Conlen) requested that web access be disallowed during exams held in the labs, presumably to minimize cheating.
For outgoing traffic, once a computer is compromised with a virus or a worm, it can act as a sender of that virus/worm to other computers on the Internet, often tying up all network bandwidth in the process, denying service to everyone else on campus.
In addition, it is just a matter of time before some CSS student or class of students intentionally or unintentionally floods the network with excess packets.
Students bring in personal laptop or even desktop computers, most of the time without our knowledge. While we spend a lot of time securing lab computers and advocating that other faculty and staff secure their own, we cannot secure the students' computers. Students will attach to an available or even an already used network port if it is to their benefit. We don't know if they have secured their computer; it could be open to attacks or already compromised.
We already have experienced problems:
Several faculty-administered and student-administered computers have been compromised in the past. If that computer is hampering the network and C&C network operations can determine which wall jack is associated with that computer, they will shut down the network connection on that jack, which may disable one or several other computers if the offending computer is using a network hub.
To our knowledge, none of the staff-administered computers have been compromised because we try to keep up with the latest security holes and patches. It takes a lot of time to be vigilant and proactive, and even we don't feel that we do enough to secure the systems -- it would take far too much time. Faculty and students are not full-time system and network administrators, but hackers don't care about that -- when a computer is on the network, no matter how long, it is subject to attack.
Recently, all network traffic for one of our labs (SCI113) was intentionally blocked for several days. Campus computer services personnel, at home for the holiday weekend, were told by people on campus that the connection to the internet was extremely slow. Because the computer services personnel were remotely diagnosing the problem and the problem was narrowed down to the Science Building, they presumed that it emanated from our labs (because it had happened that way the week prior). Consequently, they asked C&C network operations to shut down all wall jacks in that lab and told campus security personnel to unplug all network connections.
It took several days to convince them that, even though it did occur in one of our labs (SCI108), it wasn't due to our computers or the fact that we allow students to administer lab computers in SCI113. Rather, it was due to a compromised laptop being plugged into our hub, which could have happened -- and has happened -- anywhere on campus.
This is going to raise the awareness and bravado of some of our students, who may try to infiltrate our servers or hack into another student's workstation.
Computer Services personnel see the compromises as a consequence of allowing students and faculty to administer computers (includes personal laptops). They trust their professional peers (Institute lab staff) to administer computers, but are leery of trusting anyone else; they have had too many bad experiences to trust everyone.
Computer Services is demanding that we take some action to prevent this from recurring. One faculty member (Chung) said he would redesign project assignments. However, telling people not to do something doesn't prevent them from doing it, even if it is for the good of everyone else as well.
I don't agree that the ability to administer computers is the root of the problem, and I think self-administration is very important academically as well as for one's own computer. Therefore, if we are going to continue to allow administration of lab computers and personal computers to be used, it is imperative to protect our part of the network from attacks, both internal -- intentional (student hacking) or not (e.g., a compromised computer) -- and external.
A honeywall is a novel network architecture used in network intrusion detection and control, advocated by people interested in intrustion detection.
Basically, the honeywall architecture is a way of constructing a gateway or firewall that records and constrains network access. It allows incoming and outgoing network traffic to pass through a filter that is undetectable by the network user.
Network control is all about identifying what is being sent across the network as packets of information, and determining what should pass. Firewalls do this at a high level; they block ports from receiving network packets; such ports are specific to a transport protocol such as the Transmission Control Protocol (TCP).
Routers generally look at network data at a lower level than firewalls, although some modern routers are able to peek at packets at various levels of the network, from the standard data layer (layer 2) up to the network (layer 3) or transport (layer 4) layers. They do this primarily to enforce security rules and to route traffic more efficiently.
A computer acting as a honeywall has three network cards or NICs in it:
Here is what a honeywall looks like, conceptually:
Computers on the lab's network aren't aware of the bridging of the network traffic -- it is transparent to them. In addition, those computers can get internal IP addresses (i.e., those not routable to the internet), and the honeywall can perform address translation (viz., NAT) on incoming and outgoing traffic. This provides an extra level of protection and frees up scarce external IP addresses.
Evaluate then implement honeywall computers to constrain network access.
We are not concerned with what is passing through the network, and therefore don't need to record the packets. In addition, we are not concerned about network intrusions. What we are concerned about is control of the data flow through the network. Specifically, we want to:
There are no additional costs for evaluating this proposal.
Implementing this proposal would cost about $1000 per Institute-managed lab room, or about $6000. This covers the cost of the computer/honeywall, upgraded NIC cards (to 100Mb from the evaluation's 10Mb), cables, and new network switches with more ports (to funnel all data to one honeywall per lab).
In Cherry-Parkes, total control of the lab networks is possible due to the way the cables run. However, new networking equipment, including honeywalls, will still need to be purchased, but that is a planned, initial infrastructure cost, as opposed to this proposal, which is a retrofit to the existing infrastructure.