Date post: | 26-Dec-2015 |
Category: |
Documents |
Upload: | harry-hudson |
View: | 215 times |
Download: | 0 times |
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