CSI pres

Taming the BeastSecuring A Large University Network: 

Taming the Beast Securing A Large University Network Kevin T. Shivers IT Security Analyst Office of Information Technology University of Maryland, College Park kts@umd.edu

The University at a Glance: 

The University at a Glance Founded 1856 Flagship university of the University system of Maryland Top 20 public university Great athletic teams ;) On the web: http://www.umd.edu

The Issues: 

The Issues Trying to secure 1.6Gbps of bandwidth 30,000+ users of the network 20,000+ staff, faculty, commuters, grad students 10,000+ dorm residents Decentralized IT, every college manages their own IT

The Issues: 

The Issues Ever increasing number of threats Viruses Trojans (XDCC bots, spam relays, backdoors) Limited resources (our security staff: 2 people) State/University budget woes

The Issues: 

The Issues Freedom of information and usability vs. Security P2P madness Many different types of users No “one size fits all” security policy will work Not all computers are University property

The University Network: 

The University Network

The Campus Border: 

The Campus Border Four different pathways to the outside world: 95Mbps connection to Qwest 45Mbps T-3 to UUnet (normally only handles traffic to and from UUnet + their customers) Mid-Atlantic Crossroads (connects to hundreds of R+D sites) UMATS – network to other parts of the University System of Maryland IDS is watching these pathways for attacks

The Campus Border: 

The Campus Border We have been blocking port 135 (MS NetBIOS) both inbound and outbound since Summer 2002. This helped us block MS Blaster from coming in from the outside (although it still got in through other means) Also limits Windows File Sharing and copyright issues/complaints

Routers as firewalls: 

Routers as firewalls Due to the amount of bandwidth we have there is no firewall product to suit our needs, thus we use routers as firewalls Blackhole router blocks hosts we don’t want to have network access Typical packet filtering (block ports, IPs, etc)

The Network Core: 

The Network Core Central location of routers that distribute data to the far corners of the campus Most of this network is either Gigabit Ethernet or 100 Base T Placing IDS here is highly desirable for tracking viruses and internal attacks, but the volume of traffic is too high

The Network Core: 

The Network Core Packet Shaper Last year due to P2P clogging our network we implemented Packet Shapers to help prioritize traffic coming from the dorms Recreational users don’t overwhelm network capacity Arms race: P2P vs. Packet Shaper/Us

OIT Services: 

OIT Services Most critical systems are stored in one facility Systems have diverse security needs Some should not be directly exposed to the Internet Others store our main web site and other documents that need to be publicly accessible

OIT Services: 

OIT Services Network re-architecture is underway to segregate the network and protect machines that shouldn’t be open to the public Block people from getting in via firewalls or router ACLs. VPN access for administrators who need to get in Network and Host based IDS to be utilized here

Department LANs: 

Department LANs Each college or department handles their own IT needs (although some outsource right back to OIT) Cash registers, security card readers, video camera etc. are kept on an isolated network to protect them Sec-announce listserv to keep department IT administrators up to date with security threats. Working to add dept VLAN support to allow departments to set their own access policies

The Desktop: 

The Desktop Many threats begin and end at the desktop University has site licenses to protect the desktop (domino effect: desktop -> subnet -> UMD network -> internet) Site licences for: McAfee VirusScan (virus protection) ZoneLab’s ZoneAlarm (personal firewall) We promote the use of devices to lock computing equipment to heavy items to prevent theft.

User: 

User Education, Education, Educations! (Hey wait isn’t that our business?) User is a key part of a security architecture Keep passwords, etc secure Protect your system, be mindful of security! Education and outreach through programs and the media

Directory ID: 

Directory ID Part of middleware initiative LDAP Directory Removing use of Student ID (Social Security Number) Single sign on University of Texas incident

WAM ID: 

WAM ID WAM: Workstations at Maryland One of two systems that any University member can have an account on Until this Summer WAM account were student’s email account Used for logging into VPN and dialup modems Moving away from this to Directory ID

Wireless: 

Wireless Old system Homebrewed Registered MAC addresses Could steal an IP if you knew the network settings State of MD auditor blasted us for this So we got a new system

Wireless: 

Wireless New system Vernier Networks solution Links to Directory ID for authentication User must login via a web page every 24 hours

Wireless: 

Wireless Problem with new system: Incompatible with PDAs and Robots! Solution: hardwire in MAC addresses for these systems

Wireless: 

Wireless

VPN: 

VPN We currently utilize a Cisco 3000 VPN Concentrator Allows off campus users to access all services that are limited to on campus machines Users log in with their WAM ID (moving to Directory ID soon) Can also be used with the wireless network to provide encryption and more security.

Case Study: MS Blaster: 

Case Study: MS Blaster

Case Study: MS Blaster: 

Case Study: MS Blaster Two weeks before Blaster: dcom.c code ISS command line scanner Initial scans of our network: 5,000+ vulnerable boxes Several email warnings to department IT admins 8/11/03: IT’S HERE!!!

Case Study: MS Blaster: 

Case Study: MS Blaster We were already blocking port 135 at our border First infected machines came in via dialup lines Then came infected laptops the next day using both wired and wireless connections

Case Study: MS Blaster: 

Case Study: MS Blaster IDS Signature put into place to log infected machines Script written to automatically block machines that showed up in IDS First day: ~500 hosts blocked At the height of activity ~800 hosts were blocked

Case Study: MS Blaster: 

Case Study: MS Blaster Note from the NOC: After 2,000 hosts are on the blackhole router the network will crash! We have 10,000 students coming back to campus in a week! PANIC!

Case Study: MS Blaster: 

Case Study: MS Blaster Stopped auto-blocking hosts Created an additional web page on the dorm network registration system with info about Blaster, Nachi, and Sobig.F with links to removal tools and patches stored right on the registration system Blocked port 135 in and out to each subnet (minimize damage)

Vulnerability Scanning: 

Vulnerability Scanning We utilize Nessus (http://www.nessus.org) as our remote vulnerability scanner In addition we also use various white hat / black hat / custom scanning tools to scan our whole network for: RPC DCOM Web Dav Null Administrator passwords Etc.

IDS: 

IDS We currently have implemented 3 boxes running snort to monitor traffic coming from and heading to the outside world Due to the volume of traffic we are limited to monitor for the exploits and threats du jour. Currently no IDS out there to monitor the inside network traffic effectively

IDS: 

IDS These IDS boxes also give us a vantage point as to what’s going in an out of the network traffic tcpdump pcaprep: the ever growing tool My boss’s pet project Shows top 10 bandwidth users Nachi ICMP packets And more!

Spam and Virus Protection: 

Spam and Virus Protection Currently the University has multiple mail systems (WAM, Glue, Umail, ACCMail, Deans, etc) We are moving to a single enterprise system (@umd.edu) for all users to make like easier Built in spam (SpamAssassin)and virus protection

Spam and Virus protection: 

Spam and Virus protection Users of the new system report significantly less spam and viral email Kinks to work out: Bogged down system during heavy virus outbreaks (ex: Sobig.F)

Policy: 

Policy Until recently the University did not have a security policy Acceptable Use of Computing Resources (http://www.inform.umd.edu/aug/ IT Security Officer is crafting our security policy

Policy – Three types of systems: 

Policy – Three types of systems Student owned machines University owned machines Private companies TAP incubator Hinman CEOs One policy does not fit all

Policy – Student machines: 

Policy – Student machines Until recently we had a hands off approach to student machines. We couldn’t scan them or really do much to them since they are student owned machines Scanning: Null Administrator passwords Scanning: DCOM Vulnerability Scanning: Web Servers / Web Dav

Policy – Student machines: 

Policy – Student machines Illegal FTP/file sharing – until we received a DMCA complaint we couldn’t do much to students who hogged bandwidth New school year, new policy http://itsecurity.umd.edu/DormRules/

Policy – Student machines: 

Policy – Student machines IT department vs Resident Life Our idea: No inbound packets from connections that aren’t already established. Solves: File trading IIS/FTP exploits No more trojans/IRC bots/etc! Resident Life (the customer) says no :(

Policy – Student machines: 

Policy – Student machines Res Life We are a student’s ISP, they have no other option What if they want to run a web server to share photos with friends and family? Our answer: Ok they can run a server, but they can’t generate persistent volumes of traffic

Policy – faculty machines: 

Policy – faculty machines Faculty machines are owned by the University (with a few exceptions) so we can scan them and block their network access at will When University machines are hacked – notify the department that owns it Kludgy to track down owners Copyright violation? DELETED!

Policy – Incubator/Hinman : 

Policy – Incubator/Hinman These machines are used to run businesses The University wants these companies to succeed so have to let them do whatever they want on the network Hands off :(

Policy - Hinman: 

Policy - Hinman Program where students develop business plans and execute them Living/learning community – on campus Lab machines can be used to do whatever they need to so their business can succeed Machines in their room must adhere to student machine policy

Project NEThics: 

Project NEThics Created in 1998 to handle DMCA (Digital Millennium Copyright Act) notices Clearinghouse for copyright violations, spam complaints, harassment involving computers, hacking Project NEThics staff handle hundreds of copyright notices a semester

Project NEThics: 

Project NEThics Notifies student or department of copyright violation If student fails to comply, network access blocked until they comply With each subsequent violation penalties increase for students

User Education: 

User Education Virus/Security alerts from http://www.helpdesk.umd.edu/ Currently developing http://itsecurity.umd.edu to be a resource for security information Diamondback, TechKnow, FYI Forums

HIPAA: 

HIPAA Health Insurance Portability and Accountability Act of 1996 Must protect patient records University is the primary health care provider for many students and staff Several audits have been conducted to ensure that Health Center networks and University networks remain separate and all HIPAA requirements are met electronically and physically (I got to play secret agent!)

Conclusion: 

Conclusion Securing a University is much more difficult than a corporation Many different types of users Tons of different requirements for different groups (more exceptions than rules) Distributed everything Students with too much free time LESS CONTROL!!

Conclusion: 

Conclusion University network access is a combination of providing network access to a corporation (the faculty and staff) and acting as an ISP (for the students) Mix our interesting requirements with our budget and it’s a tough but doable job

Conclusion: 

Conclusion Be wise with your money and creative Having a boss who is a Perl guru is a good thing (pcaprep) Being flexible and adaptive let’s you get things done