1 / 29

Firewalls and VPNs at Stanford: August 22, 2003

Firewalls and VPNs at Stanford: August 22, 2003. Steve Tingley & Sunia Yang tingley@networking, sunia@networking Networking Systems. Topics. Changing how we look at networking Security by protocol stack Why protect the network Costs Specific pros & cons of firewalls

duke
Télécharger la présentation

Firewalls and VPNs at Stanford: August 22, 2003

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Firewalls and VPNs at Stanford: August 22, 2003 Steve Tingley & Sunia Yang tingley@networking, sunia@networking Networking Systems

  2. Topics • Changing how we look at networking • Security by protocol stack • Why protect the network • Costs • Specific pros & cons of firewalls • Specific pros & cons of VPNs

  3. "Old" Way of Looking at Networks • Open access • Get all bits from here to anywhere ASAP • Packet loss is bad in all cases

  4. "New" Way of Looking at Networks • Only let in/out "good" known traffic • Block all bad traffic • Use network device (firewalls/vpns) to make up for insecure transports, insecure applications, unpatched systems • Use network to partially centralize IT admin in distributed environment

  5. Security by Protocol Stack • Firewalls and VPNs are just part of a total security approach • Firewall would not have caught bugbear-b virus • Firewall at Stanford border would not have prevented Windows RPC exploits

  6. Physical Layer Security (Fences) • "If you can touch it, you can hack it" • Lock up servers, network closets • Wireless- • firewall defeated if wireless behind firewall • allowing unencrypted wireless session through firewall defeats data security

  7. Data layer (bus vs star topology) • Switches as security device • isolates conversations- sniffer protection • may misbehave and "leak" • block by hardware address • not possible in all switches • hardcode hw address to port- tedious, unscalable

  8. Network/Transport Layers (Guardposts checking license plates) • Filter traffic by IP addresses and ports • Router ACLs (may be leaky) • Firewalls • Require secure protocols or vpn • data encrypted (ssl, ssh) • encrypted data could still be virus or worm

  9. Application Layer (Stuff inside car) • Design in security • good architecture- 3 tier • no clear text passwords • secure transports • Proxy "firewalls" • screens traffic at app layer before passing to real application • Good sys admins • patch, antivirus-software • turnoff unused services

  10. Why implement security? • Financial risks • loss of data and reputation • cost of cleaning hacked machines • Legal risks • Hipaa (medical data), Ferpa (student records) • lawsuits

  11. Why firewalls/vpns? • Physical and data layer security is critical • mostly implemented already (except wireless) • Too many badly architected apps on market • Often best return of security for given staff, time and money

  12. Costs • re-educate users accustomed to open net • training on protocols, apps, security • staff time • monitor vulnerabilities in firewalls/vpns • monitor traffic for break-ins • troubleshooting - good tight rules can break app if new revision, etc. • equipment- hardware and software • firewall, vpn concentrator, vpn client • traffic analysis tools, monitoring/log servers

  13. Firewall Specifics • Most common security deployed at network/transport layer • Helps restrict who talks to who

  14. Firewall Pros • For limited staff time and money, may get most amount of security • if firewall placed properly • if staff actively watching network • Ex.- slammer worm targets port 1434. • adding firewall or router rule to block 1434 is much faster than patching all machines

  15. Firewall Cons- #1 • Inconvenience to users • re-educate users • good rules > minor changes may break app • need good communication, docs and response • protective rules constrain traffic • ex. protecting workstations by denying incoming connections may break peering apps

  16. Firewall Cons- #2 • Incomplete security • Firewall does not protect needed server ports • 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 • Does not protect against email viruses/worms • May lead to complacency in Sys Admins, app developers, users

  17. Firewall Costs- #1 • Software & Hardware costs • firewalls, maintenance, support, spares • network analyzer • management/log/monitoring tools • management/log/monitoring servers

  18. Firewall Costs- #2 • Staff costs • Training • Traffic analysis and rule development • Monitoring traffic, vulnerabilities, breakins • Rule changes- proactive or reactive? • Meetings and politics • Documentation, rule change processes

  19. Firewall Technical Issues • Manageable rule set vs. many exceptions • False positives • ex. Monitoring pings might look like icmp attack • Hard to secure port-hopping apps- VPN? • Session timeout limits • Server initiates new session to client (AFS) • Reply to client from different IP

  20. VPN Specifics • Common way to deal with application data transparency by encrypting • Another layer of authentication and authorization

  21. VPN Pros • With limited staff time and money, may get most application layer security • Sometimes can be used to enforce patch level of client operating systems

  22. VPN Cons- #1 • Inconvenience • not all VPN clients compatible or can co-exist • VPN clients fiddle with host's tcp/ip stack • may break some apps • may break IP dependent services • split tunnel issues- discussed later

  23. VPN Cons- #2 • Incomplete security • Does not protect if client machine hacked • in fact, provides encrypted tunnel for hacker • May lead to complacency in users, Sys Admins, app developers

  24. VPN Costs- #1 • Software & Hardware costs • VPN concentrator, maintenance/support, spares • VPN clients, maintenance, support • management/log/monitoring tools • management/log/monitoring servers

  25. VPN Costs- #2 • Staff costs • Training • Monitoring traffic, vulnerabilities, breakins • VPN client support/upgrades • VPN user administration • Meetings and politics • Documentation, rule change processes

  26. VPN Technical Issues- #1 • Scalability issues • Encryption overhead affects throughput • VPN client picks up new IP • Software vs hardware VPN clients • cost vs convenience vs compatibility

  27. VPN Technical Issues- #2Split Tunnel • only traffic to specific servers is encrypted • pros- performance • less encryption overhead • less traffic to central VPN concentrator • cons- security • if client host is hacked, hacker can control VPN session

  28. Stanford VPN Beta • URL: • No free client for Mac OS 8 or 9 • Hostname: su-vpn.stanford.edu • Group Access Information • Group: Stanford • Password: Stanford Use SUNet ID and password when prompted

  29. Questions and Feedback • Thanks to Information Security Services for reviewing technical accuracy and completeness.

More Related