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

Firewalls and VPNs at Stanford: August 22, 2003

  • Upload
    duke

  • View
    50

  • Download
    1

Embed Size (px)

DESCRIPTION

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 - PowerPoint PPT Presentation

Citation preview

Page 1: Firewalls and VPNs at Stanford:   August 22, 2003

1

Firewalls and VPNs at Stanford:

August 22, 2003

Steve Tingley & Sunia Yangtingley@networking, sunia@networkingNetworking Systems

Page 2: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 3: Firewalls and VPNs at Stanford:   August 22, 2003

3

"Old" Way of Looking at Networks• Open access

• Get all bits from here to anywhere ASAP

• Packet loss is bad in all cases

Page 4: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 5: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 6: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 7: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 8: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 9: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 10: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 11: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 12: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 13: Firewalls and VPNs at Stanford:   August 22, 2003

13

Firewall Specifics

• Most common security deployed at network/transport layer

• Helps restrict who talks to who

Page 14: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 15: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 16: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 17: Firewalls and VPNs at Stanford:   August 22, 2003

17

Firewall Costs- #1

• Software & Hardware costs– firewalls, maintenance, support, spares– network analyzer– management/log/monitoring tools– management/log/monitoring servers

Page 18: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 19: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 20: Firewalls and VPNs at Stanford:   August 22, 2003

20

VPN Specifics

• Common way to deal with application data transparency by encrypting

• Another layer of authentication and authorization

Page 21: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 22: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 23: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 24: Firewalls and VPNs at Stanford:   August 22, 2003

24

VPN Costs- #1

• Software & Hardware costs– VPN concentrator, maintenance/support, spares– VPN clients, maintenance, support– management/log/monitoring tools– management/log/monitoring servers

Page 25: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 26: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 27: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 28: Firewalls and VPNs at Stanford:   August 22, 2003

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

Page 29: Firewalls and VPNs at Stanford:   August 22, 2003

29

Questions and Feedback

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