1. Implementing Default-Deny while Enabling End-to-end Performance Damian Doyle Jack Suess

2. Worm slide Remind people of large scale worm attacks

3. State of the UMBC Network in 2007 Porous firewall - All traffic allowed in/out with very few exceptions – Most restrictions were from various worms and high risk ports Public IP addresses for all machines, everything was reachable Most machines did not have host based firewalls enabled

4. Campus Network Architecture

5. Common Network Security Problems Before Default Deny Every new attack compromised large quantities of machines Insufficient staff to chase down and triage compromised machines Massive disruptions to faculty and researchers due to attacks and crippled machines Campus business functionality was being impacted since entire departments could be infected by a new virus/worm

6. Jack CIO- what I needed in a solution to sell to the campus.

7. Needs of our Solution Maintaining all internet facing campus services without interruption or significant impact to users Developing a system that would not hinder our faculty or researchers accessing their resources from home or working with other institutions Allowing exemptions in real time so the researchers and staff did not have to wait on the IT department for changes Trying not to create a two-port model with all services forced over port 80 and 443 Avoiding so many exemptions that the policy was there in name only Residential access to gaming services were difficult to support. We also were adding a gaming track in CS.

8. Our Solution Communicate with the campus to explain the importance and determine what level of access was needed from the internet Create a website to allow faculty and staff to create exemptions for individual ports of a specific IP address – Very low risk to open single ports – Allows users to add or remove services as needed in real time – Empower faculty and researcher to control access into their machines and really think about security

9. Our Solution (Cont’d) Develop an administrative interface that can be used by campus IT admins to control large quantities of exemptions Use IP addresses as the identifier for all rules and only allow machines on subnets with static addressing to be exempted Leverage our campus identity management and WebISO systems to provide the authentication mechanism for all users All changes logged and weekly reports sent to the network administrators for review Design scripting to be scalable to large number of subnets and firewalls as needed

10. User Interface Easy to use interface to allow faculty or staff members to exempt specific ports for a given IP from the firewall Initial registration must be done from the IP address being exempted to ensure access to the machine being exempted Most standard ports can be added to the firewall in real-time, specialty requests must be processed by a staff member Access into the interface uses our standard campus sign on page, no additional user information or passwords are kept in this system

11. Demo of User Interface

12. IT Admin Interface Designed to allow central campus IT staff to manage all the exemptions needed for campus services Initial registration can be done from any machine by entering the IP address Standard ports are exempted in real time, specialty requests still require a staff member to process Access into the interface uses our standard campus sign on page, no additional user information or passwords are kept in this system

13. Demo of IT Interface

14. Modifying the Firewalls in Real-Time Done with Juniper SSG Netscreen firewalls Used SSH keys to avoid sending username/password information to the firewalls Script keeps list of which subnets are handled by which firewall so it only has to update a single firewall Created an IP group for each port or group of ports Each group had a firewall rule defined for its ports

15. Modifying the Firewall in Real-Time (cont’d) IPs can be added or removed from a group through a simple commands with almost no impact to the firewall No firewall rules were being added or removed during the addition/deletion process – The only change is an IP being added/removed from a group – Very low CPU hit on firewall since no rules being changed – Low risk even if something went wrong with the script since no rules being changed

16. Exemption Modifications Only the user who registered an IP can modify that IP – Group access coming in the next version Modification can be done through the site from any machine on campus or if the user is logged in through our VPN Most modifications can be done in real time IP addresses can be deactivated or reactivated as needed Provides a great deal of flexibility to the user

17. Website Coding The website is programmed in PHP Scripts to access the firewall are all PERL based The PERL code uses several modules including a module to simulate the Expect programming language to simplify sending commands to the firewall

18. Renewal Process – Audit Requirements Developed to prevent stale exemptions from existing years after they are no longer needed Yearly process that every rule is subjected to Can be done in a few clicks through the site If a user forgets to renew in time, the machine is simply deactivated, and can be reactivated through the site Automatic Scripts that determine if the registered owner of an exemption is no longer employed at the university – Scripts query each exemption for the user, then query current affiliations in LDAP to verify employment – In this case the department head is contacted to determine what should be done with the exemption

19. Demo of Renewal Process

20. Statistics of System Usage There are currently 73 users and 367 IP addresses with exemptions – In the first year we had around 55 users and 280 exemptions Currently over 20 faculty/staff outside of the central IT staff with exemptions – At launch we only had less than 10 users outside of central IT with exemptions Most exemptions are renewed but about 10% age out of the system Each year we have seen about 15% growth in the system

21. Lessons learned after Implementation Very hard to convey that only inbound connections were being blocked Don’t use the word Deny, it panicked people into thinking we were taking their internet access away Several researchers needed assistance determining what ports their services used and many did not come forward until the days before the go-live date Less exemptions needed than we originally thought Might have been able to cut down further on exemptions through centralization of services

22. Results of Implementing Default Deny Drastically reduced the rate machines were being compromised Increased use of the campus VPN services

23. Default Deny Implications for Residential Students Several games require multiple inbound ports or large ranges of inbound ports to function properly Several legitimate applications students wanted to work with required inbound connectivity

24. Residential Solution Webpage linked to our ResNet login page Allows a user to exempt their IP address on all ports for the length of their login Uses captcha software to prevent students from setting up auto-login bots Done in real-time and requires no interaction from IT staff Exemption is removed as soon as user logs off of the ResNet system

25. Demo of ResNet Solution

26. Future Plans for a Host to Host Exemption Will allow a faculty member to create an exemption that opens all ports from another host Leverage the Incommon authentication system to achieve this Allow the exemption to be triggered at a specific time or by a specific action

27. Federated – Goto My PC Number one reason people exempt their machine is to connect back from home. Could we have a federated approach where we grant a remote user the ability to have their current machine be granted access to a umbc internal machine.