Firewalls at Stanford: May 14, 2004

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