Firewalls in an Academic Environment

1. Firewalls in an Academic Environment Jason A. Testart, Computer Science Computing Facility

2. Traditional (Corporate) Firewall Assumptions • Threats are external • Centralized control of all computers on Intranet • Company policies can be specific re: use of Internet • External access is typically limited to DMZ network (some exceptions, such as VPN) Un-trusted Internet firewall Semi-trusted DMZ Trusted Intranet WatITis | Collaboration in a Distributed Environment | December 2, 2003 | Batten down the hatches

3. The Reality at UW (CS) • We are a public institution, aren’t we? • Academic Freedom • SCS doesn’t own all computers on its networks, and CSCF doesn’t manage them all either • We have public computer labs: students unplug terminals and plug-in laptops • We have to protect the Internet from us WatITis | Collaboration in a Distributed Environment | December 2, 2003 | Batten down the hatches

4. Disable services that are not used Windows 2000 IPSec policies Windows XP ICF Software firewalls Regular OS Updates/Patches Many in-use protocols are not Internet-safe Crude and only moderately effective Great for client-only, unmanaged workstations Difficult to manage Not everybody does it Bad patches Day-Zero exploits Security Without Firewalls WatITis | Collaboration in a Distributed Environment | December 2, 2003 | Batten down the hatches

5. The Question So how do keep our network secure whilepreserving the mission of the school/university? WatITis | Collaboration in a Distributed Environment | December 2, 2003 | Batten down the hatches

6. Some Basic Observations • We have three classes of computer use: research, teaching, and administration • We have three classes of computers: servers, workstations, and thin clients (X11, RDP) • Each class has different access requirements, as well as different security threats. WatITis | Collaboration in a Distributed Environment | December 2, 2003 | Batten down the hatches

7. A Solution: Divide the network into zones • Each zone contains one or more subnets • A subnet can only be a member of one zone • Each zone is protected by a virtual firewall • Traffic between zones will cross more than one virtual firewall • Each zone will have a default set of firewall rules applied to all computers in the zone UW Network and Internet firewall firewall firewall firewall Zone A Zone C Zone B Zone D WatITis | Collaboration in a Distributed Environment | December 2, 2003 | Batten down the hatches

8. CS can be divided into 7 zones • CSCF Staff • Central CSCF-maintained servers • Thin Clients • Teaching Lab PCs and Macs • Office PCs and Macs (client only) • User-maintained computers (researchers) • Roaming Workstations WatITis | Collaboration in a Distributed Environment | December 2, 2003 | Batten down the hatches

9. Only allow X11, RDP to the X11/RDP servers Perhaps allow web access to the world Deny any other traffic to and from this zone Once the the firewall policies are in place, they shouldn’t change Firewall policies will be fairly unrestrictive Firewall policies are expected to change often, by user request Most rules will be machine specific rather than subnet specific Zone Examples Thin Clients User-Maintained Hosts WatITis | Collaboration in a Distributed Environment | December 2, 2003 | Batten down the hatches

10. Implementation Challenges • Enumerating all the protocols in use • Auditing the subnets (stale TXT and HINFO records) • Shuffling computers between subnets • We currently use class C subnets so we may need to move to classless network blocks (CIDR) • User acceptance and education (teaching about secure alternatives) • Keeping firewall rulesets current WatITis | Collaboration in a Distributed Environment | December 2, 2003 | Batten down the hatches

11. The End Feel free to contact me with any questions and/or comments: Jason A. Testart Computer Science Computing Facility jatestart@cs.uwaterloo.ca WatITis | Collaboration in a Distributed Environment | December 2, 2003 | Batten down the hatches