Intelligent Address Management and University

Network Security

UNC-CAUSE 2004Author: 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 Configurationhostname 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 inside permit tcp any range 1024 65535 any eq www

access-list inside permit tcp any range 1024 65535 any eq https

access-list inside permit tcp any range 1024 65535 any eq ftp

access-list inside permit tcp any range 1024 65535 any eq ssh

access-list inside permit tcp any range 1024 65535 any eq aol

access-list inside permit icmp any any echo

access-list outside permit icmp any any echo-reply

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

jsthyer@uncg.edu