Download Firewalls

Living Behind Administrative
Firewalls at Stanford:
A Survival Guide
August 5, 2005
2-4 pm, Turing Auditorium
Sunia Yang
[email protected]
Networking Systems
1
Topics
• Security by protocol stack
– What's a firewall?
– What's a vpn?
– How secure are we?
• Stanford's deployment of firewalls and vpns
– How to get behind a firewall
– How to add/change/delete rules
• Troubleshooting
• Requesting rules - exercise (50 min)
2
Firewalls at Stanford
• Everyone, especially sys admins and
application folks, behind a firewall has to
learn more about networking
• Networking folks have to learn more about
systems and applications
• More process required- audit/authorization
trail
3
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
4
Security by Protocol Stack
• Firewalls and VPNs are just part of a total
security approach
– Firewall would not have caught bugbear-b virus
– Perimeter firewall or user vpn client would not
have prevented Windows RPC, Agobot, Sasser
5
Physical Layer Security
• "If you can touch it, you can hack it"
– Lock up servers, network closets
• Wireless- major physical security risk
– firewall defeated if wireless behind firewall
– allowing unencrypted wireless session through
firewall defeats data security
6
Data layer
• 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
• Filter traffic by IP addresses and ports
– Router ACLs (may be leaky)
– Firewalls (hardware, software)
– Host IP filters
• Require secure (not clear text) protocols or vpn
– data encrypted (ssl, ssh)
– encrypted data could still be virus or worm
8
Perimeter vs Server vs Dept
"Firewalls"
• Perimeter- at SUNet boundaries
– Protect entire network at boundary
• SUNet uses Routers and Packetshapers
– SUNet leaves most ports open, only blocking
particularly vulnerable ports (Windows, backdoors)
– Guard mostly against worms/viruses/script kiddies
– Does not guard against internal hacked machines
• Server- protect essential data/services
– Block all unused ports
• Departmental- at the network boundary
– still working out what we can support
9
Application Layer
• Very critical layer for security- starts in the design
–
–
–
–
–
–
good architecture- 3 tier (separate web, app, db)
no group accounts
good passwords
secure transports- no cleartext data or passwords
critical data only on secured hosts (workstations!!!)
separate production and development (data, too!)
• Good sys admins
– patch, antivirus-software
– turnoff unused services
• Monitoring– how to detect compromise
10
User/Political Layer
• The most important security layer
• Political
– Policy and mandate
– Funding
– Enforcement
• User
–
–
–
–
# 1 risk- disgruntled employees
data on workstations
bad passwords
usage - laptops, wireless, patching, AV
11
How secure are we and why do
we care?
• Computer security is among top financial
risks to Stanford
– loss of data and reputation
– cost of cleaning hacked machines
– legal liability- Hipaa (medical), Ferpa (student)
• Audit reports are grim
– many security issues at application layer
12
What is a firewall?
• Network/transport layer
• Passes traffic based on these basic criteria:
–
–
–
–
source IP
destination IP
destination port
session status- initiation, timeout
• Generally, default is block everything
13
Why firewalls/vpns?
• Physical and data layer security is critical
– mostly implemented already (except wireless)
• Too many badly architected apps on market
– many assume perimeter and server firewalls
• Often best return of security for given staff,
time and money
14
Firewall Issues
• No security on opened ports
• Manageable rule set vs. many exceptions
• Hard to secure port-hopping apps- VPN
instead
• Session timeout limits
• Hosts are unprotected from hacked hosts
behind firewall ( want personal firewall!!)
15
What is a vpn?
• Network/transport layer
• Establish session between two devices
– vpn client and vpn server/concentrator
– two firewalls
• Encrypt traffic- secure cleartext traffic
• Another layer of
authentication/authorization
16
VPN Pros
• With limited staff time and money, may get
some application layer security
• Sometimes can be used to enforce patch
level of client operating systems
17
VPN Cons
• May break IP dependent services
• Inconvenient- processing overhead
• Most vpn clients incompatible with each
other
• Incomplete security- allows encrypted path
for hacker
• Cost of vpn client support
18
VPN - 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
• no split tunnel allowed for admin apps
19
Stanford Public Vpn
Allows split tunnel
Two main uses:
-access Windows svrs from outside
-get Stanford IP for authorization
VPN Client
google.com
su-vpn
Windows svr
Library Resources
SUNet
20
Stanford Admin Vpn
No split tunnel allowed
Mainly to access firewalled servers
VPN Client
google
www.stanford.edu
server
firewall
firewall
vpnap
21
General Steps For Firewall Design
•
•
•
•
•
Design topology
Firewall Rules
Enforce rules
Monitor, document, audit (not in this class)
Troubleshooting
22
Firewall Process at Stanford
•
•
•
•
•
•
•
•
•
Process tries to make things easier but auditable
Contact firewall team (firewall-team@lists ASAP
Fill out form + application layout
Meet and design topology
Order hardware, cables
Move behind firewall
Rule requests and approval
VPN access
SLA and charges
• https://www.stanford.edu/group/networking/fwmaps/service_site/
23
New Firewall Form
• form gives list of the process and required
information
• application diagram
– hosts and required ports
– transport between hosts
– where's the data?
• what trying to protect- hosts, data, service
24
Application Architecture Diagram -
Citrix Users
Odd Users
drastically simplified
Stanford user- anywhere
Stanford user- anywhere
Developers- vpn client
Web1
Web2
Production Web
Service- Port 443
Production Web
Service- Port 443
Development Web
Service- Port 88
Odd1
Odd Application
Port 8572
App1
App2
Production App ServicePort 4572
Production App ServicePort 4572
Development App ServicePort 4573
DB1
Production DatabasePort 1521
Training
Database- Port 1550
Development
Database- Port 1560
DB2
Citrix App
Citrix1
Every Arrow Point is
Another Rule!
25
Meeting and Design
• meet with someone from firewall team and
information security
• review form, application diagram,
transports, data
• propose initial firewall topology and
schedule install
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
– Separate web from app/db layers
• 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
S1
S2
vlan 30
S3
S4
S5
SW2
S6
S7
S8
S9
28
Routing vs Transparent FWs
• Routing FWs
– extra security because of layer 3 separation
– standard for server firewalls
• Transparent FWs
– standard for departmental firewalls
– acts like a switch
29
Ordering
• firewalls- currently using Juniper/Netscreen
• switches
• cabling if in machine room
– fwteam assigns switch ports for servers
– sysadmin requests cabling from machine room
infrastructure support through HelpSU
30
Server Moves
• usually firewall is in routing mode
• fw team notifies project owner that firewall
ready
• sys admin moves server behind firewall by
unplugging old cable and putting in new
cable. Sys admin also takes care of any
needed NetDB changes if renumbering
server
31
Rule Request Form
• Ideally request initial rules before move
• Template rules = set of commonly requested rules
–
–
–
–
–
backup
windows administration
solaris administration
linux administration
database administration
• Rule request form
– https://tools.stanford.edu/cgi-bin/firewall-request
– reminder of required fields
– archived for audit purposes
• Requesters/approvers designated by app owner
32
Firewall Rules- Part 1
Rule requires the following pieces:
Action: Permit, Deny
Source IPs: Client, VPN Client, Admin
Destination IPs: Servers
Destination Port: 80(web), 25(smtp), etc.
Port Type: tcp, udp
33
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!!!!)
34
Types of Rules - Part 1
• Basic host functions - in template
– DNS, NTP, ping
• Remote host admin- mostly in template
Monitoring – snmp, email, icmp
Remote session - ssh, citrix
Authentication - sident, kerberos, MS auth
Maintenance - upgrades, virus, rebuilds, backup,
file transfer
Central systems –Microsoft domains/AD, afs, nfs
35
Types of Rules - Part 2
• Application specific
Client: Web services, front end ports
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
36
VPN access
• traffic from sysadmin or application folks to
servers should be over secure transports or over
vpn (unencrypted SQL, etc)
• authorization set by workgroups
• app owner sets membership with Workgroup
Manager (http://workgroup.stanford.edu)
• currently, delegated vpn approver must send email
to firewall-team to activate vpn account
37
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
– Ask us to log- see if traffic is coming thru or blocked
38
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
• Extra filtering on host itself
• Host IP changes, thus breaking rule
39
Exercise Goals
•
•
•
•
understand firewall terms
understand how to construct a rule
understand the types of rules
understand how topology affects rule
requests
40
Application Architecture Diagram -
Citrix Users
Odd Users
drastically simplified
16
Stanford user- anywhere
Stanford user- anywhere
4
13
Web1
1
2
Developers- vpn client
14
15
Web2
Production Web
Service- Port 443
Production Web
Service- Port 443
17
Development Web
Service- Port 88
Odd1
8
Odd Application
Port 8572
9
5
18
19
App1
App2
Production App ServicePort 4572
Production App ServicePort 4572
3
DB1
6
20
10
Production DatabasePort 1521
7
Development App ServicePort 4573
Training
Database- Port 1550
Development
Database- Port 1560
DB2
11
12
Citrix App
Citrix1
Every Arrow Point is
Another Rule!
41
System Administration & Development Diagram ( greatly simplified )
Sys Admins
Sys Admins
Mail Server
200.0.1.5
Bastion
21
terminal svcs
32
ssh- port
22
ssh- port
22
22
23
24
smtp- port
25
Web1
Web2
App2
App1
DB1
Windows PDCs200.0.0.20
200.0.0.30
smtp- port
25
25
33
26
DNSsvrs
Timesvrs
200.0.2.9
DB2
windows ports- 135,
137, 138, 139, 445
Odd1
Citrix1
UnixServers
pingICMP
29
27
Anyhost
28
afs
mounts
afs svrs
200.0.5.0/24
pingICMP
pingICMP
31
MonitoringServer
200.0.3.11
35
30
pingICMP
Anyhost
pingICMP
Switch1
Switch2
Every Arrow Point is
Another Rule!
Windows
Servers
telnet/ssh
37
Fw Admins
Switch3
Network
Devices
42
Network Topology
Wireless
User
VPN Clients
Hacker
SUNet
200.0.2.9
DNS/NTP
200.0.5.0/24
afs/nfs svrs
200.0.1.5
Hacker
Wired User
10.0.100.6410.0.100.126
SysAdmin
Developer
User
Internet
Monitoring
Developer
SysAdmin
200.0.3.11
Router
10.0.0.1/24
Mail Svrs
PDCs
200.0.0.20
200.0.0.30
10.0.0.2/24
Firewall
10.0.1.1/24
10.0.3.1/24
Zone =App
DB1
10.0.1.3/24
Switch1
Switch2
DB2
10.0.1.4/24
Bastion Host
10.0.4.2/24
10.0.2.1/24
Zone=DB
10.0.1.2/24
10.0.4.1/24
App1
10.0.2.3/24
Zone =Web
10.0.2.2/24
App2
10.0.2.4/24
Switch3
Web1
10.0.3.3/24
10.0.3.2/24
Web2
Citrix1
Odd1
10.0.3.4/24
10.0.3.5/24
10.0.3.6/24
43