Firewalls at Stanford: May 14, 2004

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