firewalls at stanford: may 14, 2004
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
1
Firewalls at Stanford:
May 14, 2004
Sunia Yangsunia@networkingThe 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 = firewallSW = switchS = server
FW1
S1 S2 S3
SW2
S7 S8 S9
Zone 2Ex. Web Servers
Zone 4Ex. Database Servers
Zone 1
Firewall can only filter between zones by IP address and portApplications often use a well-known port
S4 S5 S6
Zone 3Ex. App Servers
vlan 20 vlan 30SW1
28
Firewall Rules- Part 1
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
29
Firewall Rules- Part 2Examples: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
• AdministrationMonitoring – 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
• ApplicationClient: Web services
Server to server: db sharing, file transfer, app to db
• DevelopmentEnvironments- 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