Transcript SAN Hardware

Intelligent Address Management
and University Network Security
UNC-CAUSE 2004
Author: Joff Thyer
…Thanks to many UNCG IT colleagues for
their contributions…
Disclaimers!
• According to pseudo-random neuron activity, this
material may seem like a good idea for the
moment.
• There are a million assumptions contained within
of which I will recall maybe 50,000.
• Nirvana always seems just another fingertip reach
away….
• I don’t claim to have a handle on the “be all and
end all” of network management.
Background – 2004 Enrollment.
•
•
•
•
•
•
11,497 undergraduate students.
3,217 graduate students.
14, 714 total headcount.
Largest freshman class (2,158)
Residence halls at capacity! (approx. 3,800)
Approx. 2000 employees (Faculty/Staff)
Background – Data Network!
• End to end Cisco network (IP only)
• 700 network switches
– 200 in residence halls (10m/bit ports)
– 500 in campus general population (100m/bit ports)
• Approx. 25,000 ports.
• Approx. 7000 active MAC addresses
–
–
–
–
–
3,400 workstations in Residence Halls
500 IT managed workstations in public labs
Approx. 150 non-IT managed workstations in departmental labs
Approx. 1800 faculty/staff workstations
Balance is application servers, switches, routers, printers, HVAC
devices and other misc. network connected devices.
Background – Data Network!
• 50 buildings connected to the campus network via Gigabit
single mode fiber to one of four core routing points.
• A collapsed core model!
– Predictably the 4 core routers are Catalyst 6500 series
• Primary segment (VLAN) deployed per building
• VLAN’s deployed per IT managed lab
• VLAN’s deployed per IT server groupings (O/S based)
How do we provide IP addressing?
• Manual address assignment is clearly not an
option.
• Desktop ownership is in the hands of various
groups.
• Early in our network deployment (years ago) we
adopted a policy that all network communications
devices must be “registered” with IT.
MacMaster – Our own SQL database
appl.
• We grew our own system to manage all computer
workstation registrations
• Web driven, LDAP authenticated role based users.
• Data from SQL tables gets extracted to campus DHCP /
DNS servers on a periodic basis.
• Reporting ability shows data on:
–
–
–
–
–
DHCP lease requests
Workstation names within individual VLANS (buildings)
Address assignments
Last seen on network – switch/port attached to.
Track a MAC address to a port.
MacMaster gives us flexibility
• You don’t get an IP in the DHCP table unless you
are registered in this database
• We can re-address a sub-network if we need with a
simple router and database change.
• We associate names and locations with
workstations.
• Effective (though loose) MAC address level
access control.
Why give everyone public IP space?
• This is a historical issue that we are faced with.
• It used to be a promotional point that all
workstations on campus were full fledged Internet
members.
• It effectively promotes fiefdoms within your
network!
Security – starting from an open
network.
• It’s a University – quit now while you’re still alive.
– Not acceptable folks! Start out by securing things you can reach
out and touch.
• We have a diverse population but there are some defined
groups based on subnet/VLAN segmentation
• Some of these groups are:
–
–
–
–
Residence Hall buildings
IT managed labs
IT managed application servers
Servers subject to our Enterprise Systems Policy
Initial Steps – Policy
• UNCG created an Information Security
Committee and asked for IT staff consulting
assistance.
• As of this year, we have executive level approval of a new set
of policies.
• This is of critical importance! You may view our policies at:
http://www.uncg.edu/itp/
(see the New Policies section of the page)
Initial Steps - Technical
• Protect your perimeter using router ACL’s.
– Common sense protections:
• Allow only your address block to transit the perimeter
– In our case 152.13.0.0/16
• Filter RFC-3330/1918 – Private/Reserved address blocks
– (eg: 192.168.0.0/16, 10.0.0.0/8… etc)
• Filter protocols/ports used for network management
– UDP/TCP 161 and 162 (snmp/snmp trap)
– UDP 69 (tftp), UDP 67/68 (dhcp/bootp)
– If your Policy statements allow for it:
• Filter Netbios/SMB protocols
– TCP/UDP ports 445, 135-139
• Send email traffic only to legitimate email relay hosts
Initial Steps – Technical
• Protect your campus from the Residence Hall traffic using
router ACL’s.
– Obtain buy in from Residence Hall staff.
• UNCG RESNET – Highest Priority is literally 99% uptime. They are
highly supportive of tightening security.
– UNCG RESNET security measures to date look a lot like the
perimeter filtering
• Filtered network based protocols
• Allowed email traffic only to legitimate relay hosts
• Filtered SMB/Netbios protocols
• Deploy a server farm firewall and begin securing servers
incrementally.
– Deploy intrusion prevention technology in front of servers.
– Use router ACL’s to log activity on commonly abused TCP/UDP
ports
Security for clients – a la carte?
• What do we do with the rest of the general client
workstation population?
• Let them handle it themselves / workstation centric?
– This can work but we really want a “defense in depth” strategy.
– Can also depend on how much desktop management control IT
professionals have. In most Universities, this control is limited.
• We can secure things by VLAN using some policy routing
tricks.
Traffic routing by policy?
• We could customize traffic routing on a per subnet, or per
user basis
• What about destinations of communications?
–
–
–
–
Primarily driven to two locations – either server farm or Internet.
All servers actually live in XX bits of the class B address space.
This masks easily as: 152.13.0.0/**censored**
One large subnet? No – actually a collection of smaller subnets.
The client perspective
• A policy route-map can be placed on any router
interface to control traffic destinations.
• Our servers nicely fall into one block
• The concept for “a la carte” security is to
– Route Internet bound traffic through a firewall
– Route enterprise server traffic directly to the server
address block.
– Don’t allow “other” subnets to communicate back to
secured client subnets.
152.13.55.0/30
Router configuration example 1
route-map CLIENT-SECURED permit 10
match ip address CLIENT-SECURED
set ip next-hop 152.13.55.1
ip access-list extended CLIENT-SECURED
deny
ip any 152.13(SERVER BLOCK)
deny
udp any any eq bootps
permit ip any any
Router configuration example 2
interface Vlan512
description Forney Building (Secured Testing - Joff)
ip address 152.13.145.254 255.255.255.0
ip helper-address 152.13.1.60
no ip redirects
ip pim sparse-dense-mode
ip cgmp
ip policy route-map CLIENT-SECURED
!
Firewall Configuration
hostname ScapeGoat
nameif gb-ethernet1 inside security100
nameif gb-ethernet0 outside security0
ip address inside 152.13.55.1 255.255.255.252
ip address outside 152.13.60.1 255.255.255.0
global (outside) 1 152.13.60.3-152.13.60.252 netmask 255.255.255.0
global (outside) 1 152.13.60.253
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
route inside 152.13.145.0 255.255.255.0 152.13.55.2 1
route outside 0.0.0.0 0.0.0.0 152.13.60.254 1
Firewall Config – ACL’s
access-group inside in interface inside
access-group outside in interface outside
access-list
access-list
access-list
access-list
access-list
access-list
access-list
inside permit tcp any range 1024 65535
inside permit tcp any range 1024 65535
inside permit tcp any range 1024 65535
inside permit tcp any range 1024 65535
inside permit tcp any range 1024 65535
inside permit icmp any any echo
outside permit icmp any any echo-reply
any
any
any
any
any
eq
eq
eq
eq
eq
www
https
ftp
ssh
aol
Separate clients at layer 2
• Optionally we can use a Cisco switch feature which
separates layer 2 traffic on a per port basis.
• This is called “protected” ports and is available on Cat.
2950/3550 switches and later.
– Traffic coming into a “protected” port within a single VLAN
cannot communicate at layer 2 with another “protected” port.
– Make your uplink port (link to router) be non-protected and then
all access ports be “protected”.
– Client machines communicate with the router but not each other!
What if all my clients in one subnet
don’t want this?
• Even though we have segmented things nicely, the people
don’t all fit nicely into the VLAN/subnet boundaries!
• Choices….
– Policy routing allows us to select clients by logical address within
an ACL.
– Apply layer 2 traffic separation.
– Segment into smaller pieces – the power of VLANs!
• Caution! – KISS principle should be kept in mind.
– Too much VLAN segmentation can be administratively
burdensome. You have to find a balance.
Summing it all up
• Actively manage logical addressing.
• Segment network using both physical and administrative
boundaries.
• Begin deploying security measures:
–
–
–
–
Secure the perimeter
Secure the RESNET
Secure the servers
Secure the clients
• Just throw in a database, a web server, a router, a couple of
firewalls, some programming work and season to taste.
Future steps for UNCG
• Enhance our database application for general campus
workstation registration
– If someone moves a workstation, we want it “de-registered”
automatically.
– When you first plug in, you will be driven to an automatic
registration application
• The auto-registration app. will allow clients to select their preferred
security profile.
• Offer “customer self service” for network communications
profiles.
– Try to get our customers to “buy in” to a more secure profile at
registration time.
– Directly negotiate higher security communications profiles with
specific business units. (They will become VLAN’s – surprise!)
Thank you!
• Feel free to share your questions/suggestions.
• Email later if you would like to.
Joff Thyer, UNCG IT-Networks
[email protected]