fwvpnclass2004.ppt

191
-1

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
191
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

fwvpnclass2004.ppt

  1. 1. Firewalls at Stanford: May 14, 2004 Sunia Yang [email_address] The Group Formerly Known as Networking
  2. 2. Topics <ul><li>Changing how we look at networking </li></ul><ul><ul><li>Security by protocol stack </li></ul></ul><ul><ul><li>Why protect the network </li></ul></ul><ul><ul><li>Specific pros & cons of firewalls </li></ul></ul><ul><ul><li>Specific pros & cons of VPNs </li></ul></ul><ul><li>Living with firewalls </li></ul><ul><ul><li>Firewall topology </li></ul></ul><ul><ul><li>Firewall rules </li></ul></ul><ul><ul><li>User education, monitoring, documenting, auditing </li></ul></ul><ul><ul><li>Troubleshooting </li></ul></ul><ul><li>Building firewall exercise </li></ul>
  3. 3. Networks: Past & Future <ul><li>Past </li></ul><ul><ul><li>Just get the bits there! </li></ul></ul><ul><ul><li>Open highway system </li></ul></ul><ul><ul><li>Trust </li></ul></ul><ul><li>Future </li></ul><ul><ul><li>Patriot act </li></ul></ul><ul><ul><li>Who are you? What are you doing? </li></ul></ul><ul><ul><li>Make up for other layer's security weaknesses by centralizing security into network layer </li></ul></ul><ul><ul><li>More bureaucracy, process </li></ul></ul>
  4. 4. Security by Protocol Stack <ul><li>Firewalls and VPNs are just part of a total security approach </li></ul><ul><ul><li>Firewall would not have caught bugbear-b virus </li></ul></ul><ul><ul><li>Firewall at Stanford border would not have prevented Windows RPC exploits </li></ul></ul>
  5. 5. Physical Layer Security (Fences) <ul><li>&quot;If you can touch it, you can hack it&quot; </li></ul><ul><ul><li>Lock up servers, network closets </li></ul></ul><ul><li>Wireless- </li></ul><ul><ul><li>firewall defeated if wireless behind firewall </li></ul></ul><ul><ul><li>allowing unencrypted wireless session through firewall defeats data security </li></ul></ul>
  6. 6. Data layer (bus vs star topology) <ul><li>Switches as security device </li></ul><ul><ul><li>isolates conversations- sniffer protection </li></ul></ul><ul><ul><ul><li>may misbehave and &quot;leak&quot; </li></ul></ul></ul><ul><ul><li>block by hardware address </li></ul></ul><ul><ul><ul><li>not possible in all switches </li></ul></ul></ul><ul><ul><li>hardcode hw address to port- tedious, unscalable </li></ul></ul>
  7. 7. Network/Transport Layers (Guardposts checking license plates) <ul><li>Filter traffic by IP addresses and ports </li></ul><ul><ul><li>Router ACLs (may be leaky) </li></ul></ul><ul><ul><li>Firewalls </li></ul></ul><ul><ul><li>Host IP filters </li></ul></ul><ul><li>Require secure protocols or vpn </li></ul><ul><ul><li>data encrypted (ssl, ssh) </li></ul></ul><ul><ul><li>encrypted data could still be virus or worm </li></ul></ul>
  8. 8. Application Layer (Stuff inside car) <ul><li>Design in security </li></ul><ul><ul><li>good architecture- 3 tier </li></ul></ul><ul><ul><li>no clear text passwords </li></ul></ul><ul><ul><li>secure transports </li></ul></ul><ul><li>Proxy &quot;firewalls&quot; </li></ul><ul><ul><li>screens traffic at app layer before passing to real application </li></ul></ul><ul><li>Good sys admins </li></ul><ul><ul><li>patch, antivirus-software </li></ul></ul><ul><ul><li>turnoff unused services </li></ul></ul>
  9. 9. Why implement security? <ul><li>Financial risks </li></ul><ul><ul><li>loss of data and reputation </li></ul></ul><ul><ul><li>cost of cleaning hacked machines </li></ul></ul><ul><li>Legal risks </li></ul><ul><ul><li>Hipaa (medical data), Ferpa (student records) </li></ul></ul><ul><ul><li>Lawsuits </li></ul></ul><ul><li>&quot;Cuz they said so…&quot; </li></ul>
  10. 10. Why firewalls/vpns? <ul><li>Physical and data layer security is critical </li></ul><ul><ul><li>mostly implemented already (except wireless) </li></ul></ul><ul><li>Too many badly architected apps on market </li></ul><ul><li>Often best return of security for given staff, time and money </li></ul>
  11. 11. Firewall Cons- #1 <ul><li>Inconvenience to users </li></ul><ul><ul><li>re-educate users </li></ul></ul><ul><ul><li>good rules > minor changes may break app </li></ul></ul><ul><ul><li>need good communication, docs and response </li></ul></ul><ul><ul><li>protective rules constrain traffic </li></ul></ul><ul><ul><ul><li>ex. protecting workstations by denying incoming connections may break peering apps </li></ul></ul></ul>
  12. 12. Firewall Cons- #2 <ul><li>Incomplete security </li></ul><ul><ul><li>Firewall does not protect needed server ports </li></ul></ul><ul><ul><ul><li>e.g., if running IIS server, need to open hole for http. IIS vulnerability still must be patched. But may prevent hacker from reaching backdoor </li></ul></ul></ul><ul><ul><li>Does not protect against email viruses/worms </li></ul></ul><ul><ul><li>May lead to complacency </li></ul></ul><ul><ul><li>Hard to firewall if app uses random ports </li></ul></ul>
  13. 13. Firewall Costs- #1 <ul><li>Software & Hardware costs </li></ul><ul><ul><li>firewalls, maintenance, support, spares </li></ul></ul><ul><ul><li>network analyzer </li></ul></ul><ul><ul><li>management/log/monitoring tools </li></ul></ul><ul><ul><li>management/log/monitoring servers </li></ul></ul>
  14. 14. Firewall Costs- #2 <ul><li>Staff costs </li></ul><ul><ul><li>Training </li></ul></ul><ul><ul><li>Traffic analysis and rule development </li></ul></ul><ul><ul><li>Monitoring traffic, vulnerabilities, breakins </li></ul></ul><ul><ul><li>Rule changes- proactive or reactive? </li></ul></ul><ul><ul><li>Meetings and politics </li></ul></ul><ul><ul><li>Documentation, rule change processes </li></ul></ul>
  15. 15. Firewall Technical Issues <ul><li>Manageable rule set vs. many exceptions </li></ul><ul><li>False positives </li></ul><ul><ul><li>ex. Monitoring pings might look like icmp attack </li></ul></ul><ul><li>Hard to secure port-hopping apps- VPN? </li></ul><ul><li>Session timeout limits </li></ul><ul><li>Server initiates new session to client (AFS) </li></ul><ul><li>Reply to client from different IP (load balancers) </li></ul>
  16. 16. VPN Specifics <ul><li>Common way to deal with application data transparency by encrypting packets </li></ul><ul><li>Another layer of authentication and authorization </li></ul>Note:Board Diagram
  17. 17. VPN Pros <ul><li>With limited staff time and money, may get most application layer security </li></ul><ul><li>Sometimes can be used to enforce patch level of client operating systems </li></ul>
  18. 18. VPN Cons- #1 <ul><li>Inconvenience </li></ul><ul><ul><li>not all VPN clients compatible or can co-exist </li></ul></ul><ul><ul><li>VPN clients fiddle with host's tcp/ip stack </li></ul></ul><ul><ul><ul><li>may break some apps </li></ul></ul></ul><ul><ul><li>may break IP dependent services </li></ul></ul><ul><ul><li>split tunnel issues- discussed later </li></ul></ul>
  19. 19. VPN Cons- #2 <ul><li>Incomplete security </li></ul><ul><ul><li>Does not protect if client machine hacked </li></ul></ul><ul><ul><ul><li>in fact, provides encrypted tunnel for hacker </li></ul></ul></ul><ul><ul><li>May lead to complacency in users, sys admins, app developers </li></ul></ul><ul><ul><li>Has its own security issues </li></ul></ul>
  20. 20. VPN Costs- #1 <ul><li>Software & Hardware costs </li></ul><ul><ul><li>VPN concentrator, maintenance/support, spares </li></ul></ul><ul><ul><li>VPN clients, maintenance, support </li></ul></ul><ul><ul><li>management/log/monitoring tools </li></ul></ul><ul><ul><li>management/log/monitoring servers </li></ul></ul>
  21. 21. VPN Costs- #2 <ul><li>Staff costs </li></ul><ul><ul><li>Training </li></ul></ul><ul><ul><li>Monitoring traffic, vulnerabilities, breakins </li></ul></ul><ul><ul><li>VPN client support/upgrades </li></ul></ul><ul><ul><li>VPN user administration </li></ul></ul><ul><ul><li>Meetings and politics </li></ul></ul><ul><ul><li>Documentation, rule change processes </li></ul></ul>
  22. 22. VPN Technical Issues- #1 <ul><li>Scalability issues </li></ul><ul><li>Encryption overhead affects throughput </li></ul><ul><li>VPN client picks up new IP </li></ul><ul><li>Software vs hardware VPN clients </li></ul><ul><ul><li>cost vs convenience vs compatibility </li></ul></ul>
  23. 23. VPN Technical Issues- #2 Split Tunnel <ul><li>only traffic to specific servers is encrypted </li></ul><ul><li>pros- performance </li></ul><ul><ul><li>less encryption overhead </li></ul></ul><ul><ul><li>less traffic to central VPN concentrator </li></ul></ul><ul><li>cons- security </li></ul><ul><ul><li>if client host is hacked, hacker can control VPN session </li></ul></ul>
  24. 24. Living with Firewalls- Mantras <ul><li>&quot;Know Thy Network Traffic&quot; </li></ul><ul><ul><li>If you don't know it now, you're going to learn it the hard way </li></ul></ul><ul><li>&quot;Know Thy Servers&quot; </li></ul><ul><ul><li>ditto </li></ul></ul>
  25. 25. Living with Firewalls- Steps <ul><li>Design topology </li></ul><ul><li>Firewall Rules </li></ul><ul><li>Enforce rules </li></ul><ul><li>Monitor, document, audit </li></ul><ul><li>Troubleshooting </li></ul>
  26. 26. Laying out Firewall Topology <ul><li>Group servers by </li></ul><ul><ul><li>Sensitivity and type of data </li></ul></ul><ul><ul><li>Security level (don't put petty cash in the safe) </li></ul></ul><ul><ul><li>Production vs development </li></ul></ul><ul><ul><ul><li>Especially as projects are out-sourced, don't want our data somewhere else in the world </li></ul></ul></ul><ul><li>Sharing switches </li></ul><ul><ul><li>Generally, databases or servers actually holding data should be on separate switch (no VLANs) </li></ul></ul>
  27. 27. Basic Firewall Topology FW = firewall SW = switch S = server FW1 S1 S2 S3 SW2 S7 S8 S9 Zone 2 Ex. Web Servers Zone 4 Ex. Database Servers Zone 1 Firewall can only filter between zones by IP address and port Applications often use a well-known port S4 S5 S6 Zone 3 Ex. App Servers vlan 20 vlan 30 SW1
  28. 28. Firewall Rules- Part 1 <ul><li>Rule requires the following pieces: </li></ul><ul><li>Action : Permit, Deny, Tunnel </li></ul><ul><li>Source IPs : Client, VPN Client, Admin, Hacker </li></ul><ul><li>Destination IPs: Servers </li></ul><ul><li>Destination Port: 80(web), 25(smtp), etc. </li></ul><ul><li>Port Type : tcp, udp </li></ul>
  29. 29. Firewall Rules- Part 2 Examples: Allow 10.0.1.5 to 171.64.7.77 on udp port 53 (DNS) Allow 10.0.1.0/24 to 10.0.2.10 on tcp port 25 (SMTP) Deny 10.0.1.0/24 to any on tcp port 25 (SMTP) Sources: servers, clients, vpn clients, hackers (remember the last one when you are writing rules!!!!) Rules applied in order To document or not to document- that is the question! Note: Board Diagram
  30. 30. Categories of Rules - Part 1 <ul><li>Host </li></ul><ul><ul><li>DNS, NTP </li></ul></ul><ul><li>Administration </li></ul><ul><ul><li>Monitoring – snmp, email, icmp </li></ul></ul><ul><ul><li>Remote session - telnet, ssh, rsh, citrix </li></ul></ul><ul><ul><li>Authentication - sident, kerberos, MS auth </li></ul></ul><ul><ul><li>Maintenance - upgrades, virus, rebuilds, backup, file transfer </li></ul></ul><ul><ul><li>Central systems –Microsoft domains/AD, afs, nfs </li></ul></ul>
  31. 31. Categories of Rules - Part 2 <ul><li>Application </li></ul><ul><ul><li>Client: Web services </li></ul></ul><ul><ul><li>Server to server: db sharing, file transfer, app to db </li></ul></ul><ul><li>Development </li></ul><ul><ul><li>Environments- training, development, etc </li></ul></ul><ul><ul><li>Server to server: db sharing, file transfer, app to db </li></ul></ul><ul><ul><li>Application build </li></ul></ul><ul><ul><li>Developer access- in-house, remote </li></ul></ul>
  32. 32. Educating Users <ul><li>Firewalls are inconvenient and bureaucratic </li></ul><ul><li>Can't ignore the network anymore </li></ul><ul><li>Develop process around requesting and approving rules </li></ul><ul><li>Application owner owns security of application? Security and firewall team may comment on quality of rules </li></ul>
  33. 33. Enforcing Rules <ul><li>When developing rules, usually last rule is </li></ul><ul><ul><li>permit any to any on port any </li></ul></ul><ul><ul><li>Catches any unknown traffic </li></ul></ul><ul><li>To enforce rules, disable or delete &quot;permit any any&quot; rule. </li></ul>
  34. 34. Monitoring, Documentation, Auditing <ul><li>Monitoring- alarm system is still on </li></ul><ul><li>Documentation- balance between usability and security- policy decision </li></ul><ul><li>Security auditing- make sure rules are good and rules still work! </li></ul>
  35. 35. Troubleshooting <ul><li>A can't reach B which is behind firewall </li></ul><ul><ul><li>Try ping first (allowed by default at Stanford on FWs) </li></ul></ul><ul><ul><ul><li>If fails, check IP addr, physical connection </li></ul></ul></ul><ul><ul><li>Try telnet to desired port </li></ul></ul><ul><ul><ul><li>If okay, then not a firewall issue- probably app layer </li></ul></ul></ul><ul><ul><ul><ul><li>Message like &quot;Connected to B&quot; </li></ul></ul></ul></ul><ul><ul><ul><li>If fails, depends on message: </li></ul></ul></ul><ul><ul><ul><ul><li>&quot;Connection closed by foreign host&quot; or &quot;Connection refused&quot; means B rejects A </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Hangs with message &quot;Trying B&quot;, finally getting message like &quot;Unable to connect to remote host: timed out&quot; means that port is not reachable- possibly firewall </li></ul></ul></ul></ul><ul><ul><li>Run &quot;netstat&quot; on B to see if ports are open </li></ul></ul>
  36. 36. Common Problems <ul><li>~80% requests to check firewall show that firewall is not the problem </li></ul><ul><li>~10% of time, previously unknown traffic (&quot;know thy app&quot;) has no appropriate rule </li></ul><ul><li>Typos, miscommunication </li></ul><ul><li>Host IP changes, thus breaking rule </li></ul>
  37. 37. Team Exercise/Lab
  38. 38. Questions and Feedback
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×