intelligent address management and university network security
Download
Skip this Video
Download Presentation
Intelligent Address Management and University Network Security

Loading in 2 Seconds...

play fullscreen
1 / 30

Intelligent Address Management and University Network Security - PowerPoint PPT Presentation


  • 98 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Intelligent Address Management and University Network Security' - allistair-buck


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
intelligent address management and university network security

Intelligent Address Management and University Network Security

UNC-CAUSE 2004

Author: Joff Thyer

…Thanks to many UNCG IT colleagues for their contributions…

disclaimers
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
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
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 network1
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
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
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
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
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
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
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
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 technical1
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
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
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
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.
router configuration example 1
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
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
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
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
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
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
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
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
Thank you!
  • Feel free to share your questions/suggestions.
  • Email later if you would like to.

Joff Thyer, UNCG IT-Networks

[email protected]

ad