1 / 38

Firewalls at Stanford: May 14, 2004

Firewalls at Stanford: May 14, 2004. Sunia Yang sunia@networking The Group Formerly Known as Networking. Topics. Changing how we look at networking Security by protocol stack Why protect the network Specific pros & cons of firewalls Specific pros & cons of VPNs Living with firewalls

tarmon
Download Presentation

Firewalls at Stanford: May 14, 2004

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 at Stanford: May 14, 2004 Sunia Yang sunia@networking The Group Formerly Known as Networking

  2. Topics • Changing how we look at networking • Security by protocol stack • Why protect the network • Specific pros & cons of firewalls • Specific pros & cons of VPNs • Living with firewalls • Firewall topology • Firewall rules • User education, monitoring, documenting, auditing • Troubleshooting • Building firewall exercise

  3. Networks: Past & Future • Past • Just get the bits there! • Open highway system • Trust • Future • Patriot act • Who are you? What are you doing? • Make up for other layer's security weaknesses by centralizing security into network layer • More bureaucracy, process

  4. 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

  5. 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

  6. 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

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

  8. 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

  9. Why implement security? • Financial risks • loss of data and reputation • cost of cleaning hacked machines • Legal risks • Hipaa (medical data), Ferpa (student records) • Lawsuits • "Cuz they said so…"

  10. 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

  11. 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

  12. 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 • Hard to firewall if app uses random ports

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

  14. 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

  15. 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 (load balancers)

  16. VPN Specifics • Common way to deal with application data transparency by encrypting packets • Another layer of authentication and authorization Note:Board Diagram

  17. 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

  18. 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

  19. 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 • Has its own security issues

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

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

  22. 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

  23. 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

  24. Living with Firewalls- Mantras • "Know Thy Network Traffic" • If you don't know it now, you're going to learn it the hard way • "Know Thy Servers" • ditto

  25. Living with Firewalls- Steps • Design topology • Firewall Rules • Enforce rules • Monitor, document, audit • Troubleshooting

  26. Laying out Firewall Topology • Group servers by • Sensitivity and type of data • Security level (don't put petty cash in the safe) • Production vs development • Especially as projects are out-sourced, don't want our data somewhere else in the world • Sharing switches • Generally, databases or servers actually holding data should be on separate switch (no VLANs)

  27. Basic Firewall Topology FW = firewall SW = switch S = server Firewall can only filter between zones by IP address and port Applications often use a well-known port Zone 1 FW1 Zone 2 Ex. Web Servers Zone 3 Ex. App Servers Zone 4 Ex. Database Servers SW1 vlan 20 vlan 30 SW2 S1 S2 S3 S4 S5 S6 S7 S8 S9

  28. Rule requires the following pieces: Action: Permit, Deny, Tunnel Source IPs: Client, VPN Client, Admin, Hacker Destination IPs: Servers Destination Port: 80(web), 25(smtp), etc. Port Type: tcp, udp Firewall Rules- Part 1

  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. Categories of Rules - Part 1 • Host DNS, NTP • Administration Monitoring – snmp, email, icmp Remote session - telnet, ssh, rsh, citrix Authentication - sident, kerberos, MS auth Maintenance - upgrades, virus, rebuilds, backup, file transfer Central systems –Microsoft domains/AD, afs, nfs

  31. Categories of Rules - Part 2 • Application Client: Web services Server to server: db sharing, file transfer, app to db • Development Environments- training, development, etc Server to server: db sharing, file transfer, app to db Application build Developer access- in-house, remote

  32. Educating Users • Firewalls are inconvenient and bureaucratic • Can't ignore the network anymore • Develop process around requesting and approving rules • Application owner owns security of application? Security and firewall team may comment on quality of rules

  33. Enforcing Rules • When developing rules, usually last rule is • permit any to any on port any • Catches any unknown traffic • To enforce rules, disable or delete "permit any any" rule.

  34. Monitoring, Documentation, Auditing • Monitoring- alarm system is still on • Documentation- balance between usability and security- policy decision • Security auditing- make sure rules are good and rules still work!

  35. Troubleshooting • A can't reach B which is behind firewall • Try ping first (allowed by default at Stanford on FWs) • If fails, check IP addr, physical connection • Try telnet to desired port • If okay, then not a firewall issue- probably app layer • Message like "Connected to B" • If fails, depends on message: • "Connection closed by foreign host" or "Connection refused" means B rejects A • Hangs with message "Trying B", finally getting message like "Unable to connect to remote host: timed out" means that port is not reachable- possibly firewall • Run "netstat" on B to see if ports are open

  36. Common Problems • ~80% requests to check firewall show that firewall is not the problem • ~10% of time, previously unknown traffic ("know thy app") has no appropriate rule • Typos, miscommunication • Host IP changes, thus breaking rule

  37. Team Exercise/Lab

  38. Questions and Feedback

More Related