Transcript Firewall Rules

Firewalls at Stanford:
May 14, 2004
Sunia Yang
sunia@networking
The Group Formerly Known as Networking
1
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
2
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
3
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
4
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
5
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
6
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
7
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
8
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…"
9
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
10
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
11
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
12
Firewall Costs- #1
• Software & Hardware costs
–
–
–
–
firewalls, maintenance, support, spares
network analyzer
management/log/monitoring tools
management/log/monitoring servers
13
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
14
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)
15
VPN Specifics
• Common way to deal with application data
transparency by encrypting packets
• Another layer of authentication and
authorization
Note:Board Diagram
16
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
17
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
18
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
19
VPN Costs- #1
• Software & Hardware costs
–
–
–
–
VPN concentrator, maintenance/support, spares
VPN clients, maintenance, support
management/log/monitoring tools
management/log/monitoring servers
20
VPN Costs- #2
• Staff costs
–
–
–
–
–
–
Training
Monitoring traffic, vulnerabilities, breakins
VPN client support/upgrades
VPN user administration
Meetings and politics
Documentation, rule change processes
21
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
22
VPN Technical Issues- #2
Split 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
23
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
24
Living with Firewalls- Steps
•
•
•
•
•
Design topology
Firewall Rules
Enforce rules
Monitor, document, audit
Troubleshooting
25
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)
26
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
S1
S2
vlan 30
S3
S4
S5
SW2
S6
S7
S8
S9
27
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
28
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
29
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
30
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
31
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
32
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.
33
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!
34
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
35
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
36
Team Exercise/Lab
37
Questions and Feedback
38