Transcript Firewalls, VPNs, and Intrusion Detection Systems

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
INTERNET
PWR
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
OK
ACT/CH1
ACT/CH1
COL
IDS
Border Firewall
PWR
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
OK
ACT/CH1
ACT/CH1
COL
PWR
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
OK
ACT/CH1
ACT/CH1
COL
IDS
VPN
ERP
Academic/Staff
(non-ERP)
PWR
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
OK
ACT/CH1
ACT/CH1
COL
PWR
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
OK
ACT/CH1
ACT/CH1
COL
PWR
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
OK
ACT/CH1
ACT/CH1
COL
IDS
IDS
PWR
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
OK
ACT/CH1
ACT/CH1
COL
IDS
VPN
Datacenter
Students and/or ISP level security
PWR
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
OK
ACT/CH1
ACT/CH1
COL
IDS
PWR
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
OK
ACT/CH1
ACT/CH1
COL
Various Private Zones
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
Network IDS
Datacenter Firewall
Network IDS
Host Firewall
Tripwire
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
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
OK
ACT/CH1
ACT/CH1
COL
Campus VPN
129.74.9.0/24
PWR
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
OK
ACT/CH1
ACT/CH1
COL
IDS - sensor3
Campus
Network
Hesburgh
Switch/Router
Legacy Services
(VLAN 49,250)
EAFS
Switch/
Router
PWR
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
OK
ACT/CH1
ACT/CH1
COL
IDS - sensor8
Sidewinder
Datacenter Firewall
PWR
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
OK
ACT/CH1
ACT/CH1
COL
Cisco 3060
Group VPN
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
Datacenter
Sidewinder
Datacenter Firewall
Public Services/Proxies
PWR
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
OK
ACT/CH1
ACT/CH1
COL
Campus eMail
EDS - Public
WWW Services
BANNER SSB
BANNER CITRIX
NetApp Filer - Public
DMZ
PWR
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
OK
ACT/CH1
ACT/CH1
COL
IDS
IDS Admin DMZ
NNAT -DMZ
CORE
Admin DMZ -BBANNER INB
BANNER 1521 (Citrix)
System Monitoring
VPN
PWR
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
OK
ACT/CH1
ACT/CH1
COL
PWR
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
OK
ACT/CH1
ACT/CH1
COL
PWR
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
OK
ACT/CH1
ACT/CH1
COL
IDS
IDS
PWR
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
OK
ACT/CH1
ACT/CH1
COL
WIC0
ACT/CH0
WIC0
ACT/CH0
ETH
ACT
ACT/CH1
ACT/CH1
COL
IDS
VPN
VPN (OIT Admin)
PWR
OK
No Nat DMZ
Systems Monitoring
Tripwire, Jrodent,
What’s up gold
Core Campus Services
Database
INTERNAL
Machines that use
protocols that are
broken by NAT
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?