Transcript default-deny-web-jjs..

Implementing Default-Deny while
Enabling End-to-end
Performance
Damian Doyle
Jack Suess
Worm Threats
•
•
•
•
•
2001 – Code Red ( July 24, 2001)
2003 – Slammer (Feb 5, 2003)
2004 – MyDoom ( Feb 20, 2004)
2005 – Zotob (Aug 26, 2005)
2009 – Conflicker (Feb 13, 2009)
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
Campus Network Architecture
Common Network Security
Problems Before Default Deny
• Every new attack compromised large quantities of
machines
• Insufficient staff to chase down and triage
compromised machines
• 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
Gaining Campus Buy In
• Gaining faculty buy in.
• CIO held many discussions with faculty.
– Agreed that security problems were impacting
researchers.
– Agreed that security solutions can’t get in the way of
research.
• Found common ground in providing a
simple web-based solution to opt-out.
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
Needs of our Solution
• Web interface
• Integrated with myUMBC login
• Meet audit standards for firewall
exemptions.
• Not expose campus to undue risk.
Our Solution
• Create a website using myUMBC single signon 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
Our Solution (Cont’d)
•
•
•
•
Create an interface for system admins to use
Require static IP address for participation
Leverages IDMS and WEB-ISO for login
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
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
Demo of User Interface
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
Demo of IT Interface
Modifying the Firewalls in RealTime
• 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
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
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
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
Renewal Process – Audit
Requirements
• Every 365 days the firewall rule must be renewed.
• 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 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
Demo of Renewal Process
Statistics of System Usage
• Of 2000 faculty/staff and 6000 machines.
– There are currently 73 users and 367 IP addresses
with exemptions ( just 6% of the machines)
• Very well liked by central and departmental IT staff
who now don’t have to go through networks for
simple firewall requests.
• Most exemptions are renewed but about 10% age out
of the system
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
Results of Implementing Default
Deny
• Drastically reduced the rate machines were
being compromised
• Increased use of the campus VPN services
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
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
Demo of ResNet Solution
Future Plans for a Host to Host
Exemption
• Develop a “service” that can be connected to from
off-campus by leveraging InCommon.
• Entity creates an exception based on principal
name (e.g. user@domain) and access rights.
Email a url to person, when clicked connect to
firewall service, we request back principal name
and get IP address from header.
• Use that to provide access for some short duration.
Benefits
• Improved security without impeding research.
• Improved service responsiveness for sys admins
• Improved auditability, now every exemption
tracks who requested it and why.
• Lessened probability of user error in manually
updating firewall rules.
Questions
• Contact Information
– Damian Doyle
– [email protected]