university of washington computing
DESCRIPTION
TRANSCRIPT
University of Washington Computing & Communications
Firewalls for Open Networks
Terry GrayDirector, Networks & Distributed Computing
University of Washington
08 May 2002
University of Washington Computing & Communications
Conventional Security Wisdom
• Popular Myth: “The network” caused the problem, so “the network” should solve it:– Border firewalls and border VPNs will save us!
• Unpopular Reality: In a large, diverse enterprise such as UW, security is not achieved by either one.
University of Washington Computing & Communications
Gray’s Network Security Axioms
• Network security is maximized…when we assume there is no such thing.
• Firewalls are such a good idea…every host should have one. Seriously.
• Remote access is fraught with peril…just like local access.
University of Washington Computing & Communications
Perimeter Protection Paradox
• Firewall value is proportional to number of systems protected.
• Firewall effectiveness is inversely proportional to number of systems protected.
– Probability of compromised systems existing inside– Lowest-common-denominator blocking policy
University of Washington Computing & Communications
Credo
• Open networks*
• Closed servers
• Protected sessions
*With one exception: DDOS attacks require
network-level blocking
University of Washington Computing & Communications
“Inverted Networks”
• New trend in big companies (e.g. DuPont)
• Ditch the border firewall
• Assume LANs are “dirty”
• Use VPNs from each workstation to servers
• Hey, an open network, with closed servers and E2E encryption!
• Why didn’t we think of that? :)
University of Washington Computing & Communications
Heroic (but futile) Endeavors
• Getting anyone to focus on policies first
• Getting any consensus on border blocking
• Patching old end-systems
• Pretending that clients are only clients
• Securing access to older network gear
University of Washington Computing & Communications
Properties of ALL Firewalls Inserted between UN-trusted (outside) and trusted (inside) nets "All" traffic between inside and outside flows through them
The more restrictive the rules, the more protection offered If rules are too restrictive, users may bypass them
Increase complexity, complicate debugging No protection between hosts on trusted (inside) network Little protection from attacks against permitted services Your vulnerability is proportional to both the number of hostile
hosts able to connect and the number of vulnerable servers to connect to.
Firewalls improve security primarily by reducing the number of hosts able to connect. You still need to reduce the number of vulnerable servers by applying patches
University of Washington Computing & Communications
Where do firewalls make sense?• Pervasively: (But of course we have a firewall…:)
– For blocking spoofed source addresses
• Small perimeter/edge:– Cluster firewalls, e.g. server sanctuaries, labs– OS-based and Personal firewalls
• Large perimeter/border:– Maybe to block an immediate attack?– Maybe if there is widespread consensus to block
certain ports? (Aye, and there’s the rub…)
– And then again, maybe not...
University of Washington Computing & Communications
Good Uses for a Firewall Reducing exposure of vulnerable services on hosts you can't patch
because they are: Certified by the FDA for only one particular revision of software; Old and no longer supported by the vendor; Devices with code in ROM, such as a printer or terminal server; Embedded in a device with a service contract where the service technician
routinely wipes out any custom configuration Protecting a new computer or service while you bring it up (even if you don't
intend it to be firewalled in production). Preventing the spread of worms and exploitation of back-doors. As insurance against misconfigured hosts (defense in depth). Explicitly blocking specific troublesome traffic. Meeting due-diligence security requirements. Limiting access to network-attached printers and devices.
University of Washington Computing & Communications
Fundamental Firewall Truths...
• Bad guys aren’t always "outside" the moat
• One person’s security perimeter is another’s broken network
• Organization boundaries and filtering requirements constantly change
• Perimeter defenses always have holes
University of Washington Computing & Communications
The Dark Side of Border Firewalls It’s not just that they don’t solve the problem very well;
large-perimeter firewalls have serious unintended consequences
• Operational consequences– Force artificial mapping between biz and net perimeters– Catch 22: more port blocking -> more port 80 tunneling– Cost more than you think to manage; MTTR goes up– May inhibit legitimate activities– May be a performance bottleneck
• Organizational consequences– Give a false sense of security– Encourage backdoors– Separate policy configuration from best policy makers– Increase tensions between security, network, and sys admins
University of Washington Computing & Communications
Mitnick’s Perspective
"It's naive to assume that just installing a firewall is going to protect you from all potential security threats. That assumption creates a false sense of security, and having a false sense of security is worse than having no security at all."
Kevin Mitnick
eWeek 28 Sep 00
University of Washington Computing & Communications
Do You Feel Lucky?
• QUESTION: If a restrictive border firewall surrounds your --and 50,000 other-- computers, should you feel safe?
• ANSWER: Only if you regularly win the lottery!
University of Washington Computing & Communications
Distributed Firewall Management• Given the credo of:
– Open networks– Closed servers– Protected sessions
• What about all the desktops?– Organizations that can tolerate a restrictive border
firewall usually centrally manage desktops
– Thus, they can also centrally configure policy-based packet filters on each desktop and don’t need to suffer the problems of border firewalls
– Centrally managing desktop firewalls possible even if desktops generally unmanaged
University of Washington Computing & Communications
UW’s Logical Firewall• A response to pressure for dept’l firewalls in our
communication closets• Plugs into any network port• Departmentally managed• Opt-in deployment• Doesn’t interfere with network management• Uses Network Address Translation (NAT)• Intended for servers; can be used for clients• Web-based rules generator• Gibraltar Linux foundation
University of Washington Computing & Communications
UW Logical Firewall - How it Works
Ethernet allows two completely separate subnets to share a single wire.
As per RFC 1918, our campus routers block all 10.x.y.z traffic.
LFW clients are given 10.x.y.z unroutable network addresses.
By changing just the first octet to 10, address allocation becomes trivial.
Firewalled hosts can talk directly only to each other or their LFW.
LFW does Network Address Translation (NAT) for every packet in/out.
• Note that the LFW is not physically between the outside network and protected hosts but all traffic between the outside network and protected hosts must go through it.
University of Washington Computing & Communications
LFW Traffic Flow
University of Washington Computing & Communications
LFW Advantages• No re-wiring necessary
• Opt-in (easy to add/remove clients)
• Firewalls (plural) can live anywhere on the subnet
• Can have different administrators or policies, etc.
• Does not interfere with managing network infrastructure
• Software is available for free
• Requires only a PC with floppy, NIC and CDROM (no hard drive, keyboard, mouse, monitor)
• Use your favorite linux or use "Gibraltar" (boots & runs from CDROM)
• Web-based firewall rule-generator supports hand-crafting rules too
• Stateful firewall rules (more expressive and simpler to write)
• Remotely and securely manageable (via SSH login)
• Supports IPSEC tunneling between subnets
University of Washington Computing & Communications
LFW Disadvantages• Potentially more vulnerable from hacked un-firewalled box on subnet
• A hacked box might be able to sniff traffic from the 10.x.y.z net
• A skillful intruder might be able to configure a 10.x.y.z virtual interface
• But this added threat is only from hosts on your own subnet
• You're always more vulnerable to arp-spoofing, IP spoofing and hijacking attacks from your subnet anyway.
• Traffic through firewall (off subnet) travels your switch twice --unless you use a second NIC and rewire (which _is_ supported)
• With a full-duplex switched network connection, this may not reduce throughput significantly
• Clients must be re-configured with a new IP address
• A few protocols don't NAT well (or at all)
• Public and private IP addrs on one wire makes DHCP difficult
University of Washington Computing & Communications
LFW - Setup Overview• Download the "Gibraltar" CDROM image and burn it onto a CDROM
• Boot the Gibraltar CDROM
• Copy "uw-setup" script to a floppy, run it on Gibraltar, answer questions
• Visit LFW "Rule Generator" webpage to specify firewall rules and clients
• SSH into Gibraltar, copy/paste output of "Rule Generator" into Gibraltar
• Save configuration to floppy
• Once you have the CDROM, the remaining steps take under 5 minutes
• More detail at the LFW homepage: http://staff.washington.edu/corey/fw/
University of Washington Computing & Communications
LFW Results
• Largest installation: Appled Physics Lab– 5 LFWs on 5 subnets– 219 protected clients– IPSEC tunnels between them
• Publication Svcs: LFW protects hi-end printers
• FTP performance: 7.1MB/s vs. 8.6MB/s without
• Local policy-making a big win: minimizes admin distance between policy definition and policy enforcement.
University of Washington Computing & Communications
Is it enough?
• Hard to find anyone who believes all end-systems can be properly managed/secured
• Server sanctuaries, centrally-managed personal firewalls, logical-firewalls… are they enough?
• Do we need a dual-policy network?
• What about DDOS attacks?
University of Washington Computing & Communications
Resources
• http://staff.washington.edu/gray/papers/credo.html
• http://staff.washington.edu/corey/fw/
• http://staff.washington.edu/dittrich • http://www.sans.org/
Thanks to Corey Satten for several of the LFW slides used in this presentation.
University of Washington Computing & Communications
Best Security Practicesfor eclectic enterprises
Terry GrayDirector, Networks & Distributed Computing
University of Washington
08 May 2002
University of Washington Computing & Communications
UW Environment
• $1.5 B/yr enterpise (75% research/clinical)• 55,000 machines• Infinite variety and vintage of computers• Incredibly complex/diverse org structure• Relatively little centralized desktop mgt• Every dept’s middle name is Autonomous• C&C provides core I.T. infrastructure• Depts responsible for end-system support
University of Washington Computing & Communications
Unconventional Security Wisdom
“If you think technology can solve your security problems, then you don't understand the problems and you don't understand the technology. “
Bruce Schneier
Secrets and Lies
University of Washington Computing & Communications
Security Elements• Architectural
– Authentication & Authorization – Encryption– Packet filtering
• Operational– Prevention– Detection– Recovery
• Policy– Risk Management– Liability Management
University of Washington Computing & Communications
Bad Ideas
• Departmental firewalls within the core.
• VPNs only between institution borders.
• Over-reliance on large-perimeter defenses...e.g. believing firewalls can substitute for good host/application administration...
University of Washington Computing & Communications
Good Ideas• Two-factor authentication• End-to-End encryption: IPSEC, SSH/SSL/K5• Proactive vulnerability probing• Centrally managed desktop computers• Centrally managed personal firewalls• Logical firewalls• Bulk email virus scanning• Server sanctuaries
University of Washington Computing & Communications
Jury Still Out
• Intrusion Detection Systems
• DDoS trackers
• Thin Clients
University of Washington Computing & Communications
Server Sanctuaries
• Cluster sensitive/critical servers together…
• But don’t forget geographic-diversity needs
• Then provide additional logical and physical security
University of Washington Computing & Communications
Technical Priorities
• Application security (e.g. SSH, SSL, K5)
• Host security (patches, minimum svcs)
• Strong authentication (e.g. SecureID)
• Net security (VPNs, firewalling)
University of Washington Computing & Communications
Start with a Security PolicyNow there’s an idea...
• Define who can/cannot do what to whom...
• Identify and prioritize threats
• Identify assumptions, e.g.– Security perimeters– Trusted systems and infrastructure– Hardware/software constraints
• Block threats or permit good apps?
• Minimize organizational distance between policy definition, configuration, and enforcement points
University of Washington Computing & Communications
Policy & Procedure• Policy definition & enforcement structure• Education/awareness: it’s everyone’s job• Standards and documentation• Adequate resources for system administration• High-level support for policies• Pro-active probing• Security consulting services• IDS and forensic services• Virus scanning measures• Acquiring/distributing tools, e.g. SSH
University of Washington Computing & Communications
When do VPNs make sense?
• E2E:– Whenever config cost is acceptably small
• Non-E2E:– When legacy apps cannot be accessed via
secure protocols, e.g. SSH, SSL, K5.and
– When the tunnel end-points are very near the end-systems.
University of Washington Computing & Communications
Network Risk Profile(notwithstanding recent SNMP exploits)
University of Washington Computing & Communications
Risk & Liability Issues• Liability over network misuse?
– Policies define acceptable use– Post-audit strategy for enforcement– Wireless perimeter control?– Are networks an “attractive nuisance”?
• Risk of server compromise?– Strong preventive stance– Pre-audit via proactive probing– Greater sensitivity -> greater security
University of Washington Computing & Communications
Reality Check
• John Gilmore: “The Internet deals with censorship as if it were a malfunction and routes around it”
• Isn’t this also true of other forms of policy-based restrictions, including Kazaa clamping and border port blocking?
University of Washington Computing & Communications
Worrisome Trends
• Increasing sophistication of attacks
• Increasing number of attacks
• Tunneling everything thru port 80
• Partially connected Internets
• Increasing complexity anddiagnostic difficulty
University of Washington Computing & Communications
Encouraging Trends
• Enterprise decision makers are engaged
• Vendors are paying more attention
• Software is slowly getting better
• ?
University of Washington Computing & Communications
Conclusions• Central network services: think of as an ISP• Conventional wisdom won’t work in our world• Border firewalls can actually be harmful• We can’t afford to settle for fake security• There are no silver bullets• The hardest problems are non-technical• It’s still going to be a long, up-hill battle• Don’t forget disaster preparedness and recovery
(e.g. High-Availability system design)