Campus Firewall. Bruce Campbell, IST Trevor Grove, CSCF

Transcription

1 Campus Firewall Bruce Campbell, IST Trevor Grove, CSCF

2 2012 Information Security Architecture Review Part of 2012 Audit Plan as approved by (Board) Audit Committee Information Security Architecture Review University wide scope 26 recommendations assigned a D First recommendation is Implement an enterprise firewall solution to protect the campus network from the Internet and other untrusted zones (e.g. wireless and resident networks).

3 Management Comments and Action Plan A project to deploy a firewall to protect the general campus network will be initiated. The deployment of a campus firewall will require broad consultation with the campus community as it will have significant consequences to the way network services are offered, and involve a considerable culture change.

4 Project Overview Campus Firewall Project initiated Objectives: deploy a campus perimeter firewall which blocks new inbound connections (by default) from untrusted zones (off campus, residence, wireless) develop a mechanism and approval process to permit certain hosts (e.g. Servers) to be exempted from the default inbound deny firewall policy. December 2013 completion

5 Project Team Project Leader Project Team Bruce Campbell, IST Steve Bourque, IST Hari Chotara, Math Brent Clerk, AHS Trevor Grove, CS Dave Hinton, IST Mike Patterson, IST Bernie Rutter, ENV Sean Speers, Arts Ray White, Engineering

6 Stateful Packet Filter The perimeter firewall will have no impact that originates from the trusted zone (on campus). (e.g. Any activity that originates from your desktop computer or a campus server, web browsing, skype, youtube, ssh, updates, etc). A stateful firewall supports this by maintaining a state table of traffic that originates from the trusted side (protocol,source/dest ip,source/dest port) and allowing return traffic from source ip/port in the state table.

7 Stateful Packet Filter

8 Pre Firewall Topology

9 Post Firewall Topology

10 Existing Firewalls IST Machine Room (Juniper SRX 3600) Wireless (NATed) (Juniper SRX 3600). CSCF (Netscreen) Civil (Sonicwall) Numerous smaller firewalls Router based Access Control Lists (ACLs) (non stateful) also used widely.

11 Firewalls Elsewhere Educause Survey indicates 75% of higher education institutions in Canada 86% of higher education institutions in the US have deployed firewalls at the border between their internal networks and the Internet. Safe to assume almost all commercial and home networks have a firewall (or NAT device)

12 Staged Deployment The topology and equipment will allow faculty/departmental/building routers to be migrated to behind the firewall in a staged manner. We will start with Academic Support areas, these areas already have router based client only ACLs applied, and should be more straightforward to migrate.

13 Communications October Daily Bulletin item September 2012 UCIST update November 2012 UCIST update Project page

14 Implementation strategies The implementation challenges: Balancing security versus usability Provide security without impacting the mission of the institution Organizing networks to be firewall ready Protecting client workstation is a different problem from protecting public-facing servers And then there s instructional labs and publicfacing workstations

15 Organizing for firewalls Organizing networks by system function helps in firewall deployment Client systems like desktops generally need outbound traffic only; do not offer services Remote access the typical exception (rdp, ssh) Servers usually provide public-facing services: web, , application-specific Firewall rules are subnet-based, so separating function is required

16 Case study: CS networks CS deployed a departmental firewall in 2003 and reorganized its networks into several firewall zones: Client networks (graduate student workstations, admin staff) Server networks (CS web, , file-server, Unix/Linux general-purpose computing) Undergraduate teaching labs

17 CS firewall subnets The existing CS subnet organization makes a clear distinction between system function and should make transition easier Campus network Non-firewalled networks Client networks (outbound only) Research server networks (restricted; allow custom rules) Undergraduate teaching (client + on-campus restrictions CSCF staff network

18 What if a system changes? In CS we adopted a hard line on the placement of systems onto networks In our research environment, it is commonplace for a client workstation to want to run a server Must move (re-address) the system to the appropriate network

19 Custom rules and exceptions Whatever the rules, there are inevitably requests for exceptions and customization Creating firewall exceptions Takes effort to manage Creates complexity and can create performance issues diminishing returns from security perspective (e.g.10,000 unique exceptions is pointless)

20 So how do I get around it? As noted: default deny to inbound from untrusted We ve had a limited set of such restrictions for years, e.g. SMB, X, and RDP more recently But what do we do if we need to get to systems on campus? In nearly all cases: use the VPN

21 Use the VPN to access on-campus systems Use the VPN to build an authenticated connection from the untrusted zone: From off-campus From wireless and resnet Who can use the VPN? Faculty, staff, grad, undergrad, vpn-users ; pretty much everyone New/coming soon: NetID for externals

22 What about exceptions? There will need to be networks that permit common public-facing services But what is common? In CS, research community considers many protocols standard (notably ssh) And research (CS and elsewhere) depends on being able to use arbitrary ports

23 No really: will there be custom exceptions? At this moment, it s a definite maybe Current investigations show over 9,000 systems with open ports offering services Many don t need to be, eg printers Managing 9,000 exceptions is not feasible If this can be reduced to e.g. 1,000 maybe Research needs must be accommodated

24 Accountability for exceptions One of the motivations for the firewall is risk management, particularly for information security (Policy 8) Information stewards/custodians need to understand the risk of exempted systems Systems containing only research data may be lower risk Exempted systems should not host > public

25 Summary A campus perimeter firewall is to be deployed by December 2013 It will be default deny for inbound traffic, with the need for exception mechanisms recognised (and to be determined) The VPN will be the standard technique for individuals to gain access

26 Contact Bruce Campbell, x38323 Trevor Grove, x34679