University of Washington Computing


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

University of Washington Computing

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