Firewalls, VPNs, and Intrusion Detection Systems in a University Environment

Bob Winding, CISSP Information Security

University of Notre Dame

Copyright Robert Winding 2005. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To

disseminate otherwise or to republish requires written permission from the author.

Introduction

• History and Culture• Security Zones• A layered approach

– Network and host firewalls– Network and host IDS– VPNs to group users and provide remote access

• Implementation• Issues, outcomes, and evolution• Q&A

History and Culture

• 12,000 Students, 3,000 employees, private institution

• Notre Dame launched its network with a Class B address space and no perceptible border

• Culture values the notions of convenience, “Unfettered access”, and privacy

• Security is not perceived to be an issue

History and Culture

• 3 years ago ND created an InfoSec group• First step was to look at the network

– Hacked servers– Viruses– Endless probing

• We had some near misses

Security Zones

• OIT decided that it would first protect assets it owned, and/or, that were housed in the datacenter

• The datacenter is considered one of several security zones

• Secure the datacenter with an eye on applying appropriate security to other campus entities

Zone Approach

Datacenter

Border Firewall

Students and/or ISP level security

ERP

INTERNET

Academic/Staff(non-ERP)

PW R

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL VPN

PW R

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL VPN

PW R

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL IDS

PW R

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL IDSPW R

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL IDS

PW R

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL IDS

PW R

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL IDS

Various Private Zones

PW R

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL IDS

PW R

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL VPN

Policy

• Ideally security controls would support specific policies

• ND has made some significant progress in this area, including a password strength policy, clear text credential policy, etc.

• As more specific policies are developed we rely on the acceptable use policy as the basis of our controls

Layered Approach

Border Router

Datacenter Firewall

Network IDS

Host Firewall

Trip-wire

Network IDS

Tripwire @ ND

• Tripwire is termed both a host IDS and host integrity assurance tool

• It has both an open source variant, Tripwire Academic Source Release (ASR) and a commercial version

• The commercial version has security features that prevent the compromise of tripwire itself and provide central management

Tripwire @ ND

• Tripwire works by applying a tripwire policy to the file system of a server

• This policy can be thought of as extended file attributes

• Tripwire policies can monitor many attributes of files or directories

Tripwire @ ND

• Many compromises (rooting) of servers often change system files or registry settings

• Things like netstat, dir/ls, ps, etc. • This is done to cover the hacker’s tracks• The complexity in Tripwire is in the policy

construction and management• ND uses Tripwire as an after-the-fact alert that

our other protections have failed

Firewalls

• Packet Filtering• Stateful Inspection• Application Proxy• Host

– McAfee Desktop Firewall– Windows 2003 IP Security– IP filters

• Network – Sidewinder and PIX

Host Firewalls

• Host based firewalls were selected and implemented for each platform used in the datacenter

• Host firewalls were implemented by individual support engineers based on templates developed in consultation with InfoSec

• The rulesets were designed to be liberal with outbound traffic and strict with inbound traffic

Host Firewalls

• Ruleset templates were developed for servers that would reside behind the firewall

• The desire was to simplify the ruleset and govern intra-zone peer traffic

• The basic principles are– Trust the firewall– Drop local LAN traffic not explicitly permitted

(peer dependencies)

Datacenter Security

Internet

PWR

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL IDS - sensor3

PWR

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL

IDS - sensor8

EAFSSwitch/Router

PWR

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL

Campus VPN129.74.9.0/24

CampusNetwork

HesburghSwitch/Router

PWR

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL

Cisco 3060Group VPN

Legacy Services(VLAN 49,250)

SidewinderDatacenter Firewall

The Datacenter Firewall

• Secure Computing Sidewinder G2, in High Availability configuration

• Balance security and ruleset complexity– Highly constrained public service access– Group related services to reduce rules– All servers have basic net services outbound.– Monitoring and SysAdmin zones have special

privilege

• Alerting and auditing detect problems early, ease management

Datacenter Security

VPN (OIT Admin)

SidewinderDatacenter Firewall

No Nat DMZ

Machines that use protocols that are

broken by NAT

Public Services/Proxies

Campus eMailEDS - Public

WWW ServicesBANNER SSB

BANNER CITRIXNetApp Filer - Public

Core Campus ServicesDatabase

INTERNAL

PWR

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL VPN

NNAT -DMZ

CORE

DMZ

Datacenter

System Monitoring

Systems MonitoringTripwire, Jrodent,

What’s up gold

VPN

PWR

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL IDSPWR

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL IDSPWR

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL IDS

PWR

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL IDS

PWR

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL IDS

Admin DMZ -BBANNER INBBANNER 1521 (Citrix)

Admin DMZPWR

OK

WIC0ACT/CH0

ACT/CH1

WIC0ACT/CH0

ACT/CH1

ETHACT

COL IDS

VPN-SA and Monitor Zone

• The VPN for System Administrators• Access granted by 2 factor authn/authz• Can access any server via admin protocols or

through an IP KVM • Monitoring zone can access any server with

defined monitoring protocols, snmp icmp, etc.• Systems in these zones have no inbound public

access

Core Services Zone

• This zone provides services to other servers• Some direct database connections by “fat” client

applications and “power user” administrators are allowed

• Backups via this zone are permitted• To provide a compensating control access to

these services are restricted by group VPN and or subnet

Admin-DMZ Zone

• This zone houses servers that support the administrative operations of the University

• Servers in this zone have some form of restricted access, by VPN or subnet

• The address restriction is tied to the audience, ex. Administrative Offices, Health Services, etc.

DMZ Zone

• This zone houses the publicly accessible services

• By public we mean there is no source address restriction

• These services can be accessed from anywhere in the world

NO-NAT DMZ Zone

• This zone houses servers whose services/protocols are broken by NAT

• All other “internal” zones are privately addressed

VPNs

• VPNs are used to group user traffic, provide remote access, and insure confidentiality where no other cryptography is employed

• A Cisco 3060 concentrator and FreeRADIUS server are integrated into our Enterprise Directory to provide Authentication and Authorization for VPN Groups

• The result is a trusted address that is used by the firewall to provide location independent access

Issues (General)

• Most early issues were the result of diverse opinions and philosophies among our engineering and security staff regarding security

• The tuning and management of Tripwire was problematic

Issues (FW)

• Knowledge of networking and host firewalls was limited among some our system administrators and the learning curve was a significant challenge

• Knowledge of how products work at the port/protocol level can be problematic

• ND’s unfamiliarity of FW performance and reliability

Issues (networking)

• Components of our network were designed for speed and or availability without consideration of security

• Retrofitting security devices like firewalls and IDS sensors is not always easy or completely effective.

Outcomes

• ND implemented major components of its security architecture

• We’ve migrated over 100 servers behind the firewall including ND’s new ERP system

• There have been no servers compromised behind the datacenter firewall

• ND has adopted build standards for servers and a fairly robust change control process

Outcomes

• IDS has become instrumental in detecting hacked machines and viruses

• IDS in conjunction with other devices is used to suppress viruses and encourage users to fix their machines through “SoftDisco”

• Security is becoming a proactive part of system design

Outcomes

• There is still some friction when security issues threaten a project deadline

• Areas like Operations, Networking, and Security need to work much more closely and complementary

• Policy development remains an area that requires a lot of effort

Evolution

• ND is implementing additional security zones with Cisco PIX and Sidewinder firewalls– Ticketing office– Police station and Hotel– Academic services

• We are still debating the issue of a general border firewall

• There is still debate over implementing a separate administrative network

Evolution

• SSL Termination• Failover in the event of a major component

failure, router, BigIP, Firewall• Re-architecting the IDS

Questions?