1 / 30

Intelligent Address Management and University Network Security

Explore UNC-CAUSE 2004 insights on managing 14,714 student and staff devices on a Cisco network, with a focus on IP addressing, security policies, and technical protections. Dive into the MacMaster database, VLAN segmentation, and firewall deployment for robust network defense strategies.

skelton
Download Presentation

Intelligent Address Management and University Network Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Intelligent Address Management and University Network Security UNC-CAUSE 2004 Author: Joff Thyer …Thanks to many UNCG IT colleagues for their contributions…

  2. 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.

  3. 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)

  4. 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.

  5. 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)

  6. 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.

  7. 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.

  8. 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.

  9. 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!

  10. 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

  11. 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)

  12. 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

  13. 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

  14. 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.

  15. 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.

  16. 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.

  17. 152.13.55.0/30

  18. 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

  19. 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 !

  20. 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

  21. 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

  22. 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!

  23. 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.

  24. 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.

  25. 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!)

  26. Thank you! • Feel free to share your questions/suggestions. • Email later if you would like to. Joff Thyer, UNCG IT-Networks jsthyer@uncg.edu

More Related