Transcript Firewall Integration

Firewall Integration
Scope of Discussion
• Assumption:
You plan to install / re-architect / replace / upgrade
your perimeter security
• Question:
What issues will you face making your new solution
work, and what choices do you have?
Agenda
• Introduction
• Perimeter Security Models
• Firewall Types (review)
• Perimeter Design Issues
• Implementation choices
•
•
•
•
Network Separation
Routing
DNS
Sendmail
• Q&A
•
•
•
•
Public Servers
VPNs
Policy
Redundancy
Agenda
 Introduction
• Perimeter Security Models
• Firewall Types (review)
• Perimeter Design Issues
 Implementation choices
•
•
•
•
Network Separation
Routing
DNS
Sendmail
 Public Servers
 VPNs
 Policy
 Redundancy
Perimeter Security Models
Private
Networks
Firewall application
Private
Networks
Server O.S.
Private
Networks
Dedicated
Firewall
Private
Networks
Dedicated
Firewall
INTERNET
Private
Networks
Dedicated
Firewall
Load
Balancer
Public
Servers
Dedicated
Firewall
Dedicated
Firewall
Dedicated
Firewall
Load
Balancer
Private
Networks
Firewall Types (review)
• Filtering Routers
• fast
• multi-function routers
• filter on IP/TCP/UDP content
• pass protocol violations
• management scales poorly
• ‘Session-aware’ Gateways
• filter some protocol violations
• pass application-data violations
• slower than packet filters
• Application-level Gateways
• filter all protocol violations
• may lag in proxy rollouts
• filter application-data violations • more latency
• can host critical services
Static IP
Filter
Stateful
Inspection
Generic
proxy
Application-level
proxy
Split
Server
LOWER
Performance
HIGHER
Firewall Types Review
LOW
MEDIUM
Security
HIGH
HIGHEST AVAILABLE
Perimeter Design Issues Overview
• How much do you want the firewall to do?
• The more a firewall does, the more configuration it requires!
• What do you want it to do?
• Allow/deny based on:
– IP and destination port?
– And… session state?
– And… data content?
– And… user authentication?
– And… pre-defined groups of all these?
– And… securely host infrastructure services?
Physical Infrastructure Issues
• What is the span of each multi-cast / broadcast domain?
• All traffic on the cable is visible to all stations
• One compromised station compromises all others
• Are your routers and/or switches propagating multi-cast /
broadcast traffic; extending the risks?
• Physical separation in:
–
–
–
–
Cabling,
Switch ports,
Router ports,
Facilities
leads to subnet separation!
– more subnets (private addresses?)
– more routers?
– more cost?
Network Infrastructure Issues
• Routing – how will a firewall effect your routing?
• Reachability advertising
• Static routes
• DNS – what names do you want visible to whom?
• How many name-spaces
• What level of server availability / protection
• E-mail – what mail treatments do you require?
• Spam control, Relay control
• Virus Filtering
Policy Issues
• Is your security policy:
• Defined?
• Recorded?
• Explicit enough to implement?
• Possible?
• Practical?
Redundancy Issues
• Can you tolerate a single-point-of-failure?
– Cost vs. Need
– MTBF vs. MTTR
– Temporary workarounds?
• Implementation / Management complexity
– Additional vendor(s)
– Additional administration
– Additional vulnerabilities?
Agenda
• Introduction
• Perimeter Security Models
• Firewall Types (review)
• Perimeter Design Issues
 Implementation choices
•
•
•
•
Network Separation
Routing
DNS
Sendmail
•
•
•
•
Public Servers
VPNs
Policy
Redundancy
Implementation – Network Separation
• Physical separation of distinct user-communities
into distinct broadcast / multi-cast domains
•
•
•
•
Untrusted (Internet) clients / servers
Trusted (internal) clients / servers
“Public protected” (DMZ) servers
“Private shared” (VPN) servers
• Physical infrastructure:
• Does your cable-plant reflect your security requirements?
• Can you use VLANs to logically isolate distinct populations?
» What is the default management password on your
switches?
» What SNMP community name do you use on your
switches?
Implementation – Network Separation
• Can you isolate:
• “Public protected” servers into DMZs
• “Private shared” servers into network spaces which are:
– Policy-managed
– VPN-accessible
Public
Private
INTERNET
DMZ
VPN
Implementation – Network Separation
• What you probably already knew…
• Your cable-plant reflects no planned structure at all
• Connectivity and flexibility are as important as control
• If you add enough jumpers, anything can be connected to anything!
• What you may not have expected !
• At the hardware level, there is no visibility for security
– switch port / hub port labeling
– cable labeling
– connectivity ‘change control policy’
• Thoughtful use of switches and network-partitioning can
significantly enhance security
Implementation – Routing
• Firewall NAT allows you to use private addresses
10.0.0.0/8
internally (RFC1918)
172.16.0.0/12
192.168.0.0/16
• No limit on your internal IP addresses
• Internal IP addresses cannot be routed across the Internet
• Advertising ‘reachability’ for private addresses is unnecessary
• Registered IPs are still required:
• For your Internet presence
• For “public protected” servers you choose to make directly
available
• Dynamic routing will expose hidden address-spaces.
• Beware routed / gated running in your routers, your ISP’s
routers, and your firewall !
Implementation – Routing
• Static routing:
• any internal, routable, accessible subnets must be statically defined
in the external router, with the firewall as gateway
Destination gateway
12.27.48.0 12.27.47.177
12.27.47.177
10.1.1.1
10.2.1.254
INTERNET
10.1.1.254
12.17.48.x
Destination gateway
10.2.0.0
10.1.1.254
• any subnets not adjacent to the firewall must be statically defined in
the firewall, with the internal router as gateway.
Implementation – Routing
• What you probably already knew…
• Simple routing just works!
• Complex routing takes care
• What you may not have expected !
•
•
•
•
You have a GREAT many internal subnets
Not all static route definitions persist across a re-boot 
Not all routers propagate static routes by default
Attackers can/will probe private address-spaces
Implementation – DNS
• Very few of your systems require public names:
• Firewall
• Public name server, web server, FTP server, etc
• Mail Exchanger
– All other names should be hidden!
• Very few DNS implementations are resistant to:
• pollution
• illegitimate zone-file requests
• attacks
– Run your own named(s) on hardened platforms
Implementation – DNS
• Present two DNS images for your name-space
• Queries never flow ‘inbound’
forwarding
ISP
named
DNS ‘NS’ authority
Firewall
resolver
No DNS
authority
forwarding
queries
Internal
named
queries
DNS ‘NS’ authority
forwarding
forwarding
INTERNET
queries
Firewall Firewall
named resolver
queries
DNS ‘NS’ authority
forwarding
queries
Firewall Firewall
named named
DNS ‘NS’ DNS ‘NS’
authority authority
Internal
named
queries
DNS ‘NS’ authority
forwarding
Internal
named
queries
DNS ‘NS’ authority
Implementation – DNS
• What you probably already knew…
• DNS takes attention
• Every system needs a name-server
• Every name-server needs a query-escalation path
• What you may not have expected !
• Any server can be authoritative for any zone
• Slave servers can deliver zone files to other slaves!
• A name-server will not ‘forward’ a query about a domain it is
authoritative for (either master or slave)
• “dynamic” DNS servers need careful modeling (zone update
frequency/size against query frequency, size, & cache TTL)
Implementation – Sendmail
• Sendmail servers are popular targets:
• implement defense-in-depth
• use hardened platforms / implementations
• do not use your private internal server for
– spam-control
– relay-control
– Filtering
• Other messaging technologies are increasingly at
risk:
• AIM™ has attacks published against it
Implementation – Sendmail
POP
ISP’s
MX Mail Server
Private
Mail Server
Private
Mail Server
MX
Virus Scanner
INTERNET
MX
Private
Mail Server
Virus Scanner
MX
Private
Mail Server
Implementation – Sendmail
• What you probably already knew…
• SMTP is a very ‘liberal’ protocol
• Sendmail is extraordinarily flexible / configurable
• Sendmail is easily mis-configured
• What you may not have expected !
• A wealth of expertise is available on the web
• Anything you want to do, likely somebody has done already
• You don’t have to re-invent the wheel.
Implementation – Public Servers
• Public servers can be protected !
• The unavoidable risks are their ‘native’ protocols…
–
–
–
–
HTTP / HTTPS for web servers
FTP for FTP servers
ICA for Citrix servers
POP for mail servers
• And ‘backend support’ protocols (SQL, FTP, etc.)
• A public server is harder to compromise if:
• It’s real location is obscured
• Accesses to/from it are tightly regulated
• It has reduced access to other facilities (DNS, mail, etc.)
Implementation – Public Servers
• Your public servers should:
•
•
•
•
Be behind a firewall, enforcing traffic policy ‘in’ and ‘out’
Have private addresses, accessed by re-direction
Be isolated in one security-segment
Be hardened, dedicated, function-specific servers
Public
Private
10.3.1.x
VPN
12.27.47.177
INTERNET
DMZ
Implementation – Public Servers
• What you probably already knew…
• Public servers are a necessary evil
• Once a public server is compromised, whatever facilities it has
available will be used against you
– Treat your public servers as untrusted systems
• What you may not have expected !
• Public servers should be considered sacrificial systems with
disposable contents
• Attackers can and will probe private address-spaces
• You can enforce traffic policies on your public servers
Implementation – VPNs
• VPNs are the remote-access technology of choice
• Internet connectivity is low-cost & ubiquitous
• VPN implementations are common, and generally interoperate
• VPN termination is easier to secure than dial-in termination
• Integrating VPN termination and perimeter
defense can be tricky
• Encryption is computationally intensive
• VPN endpoints do not mix well with NAT, nor redundancy
• Risks include:
– “clear text” exposure
– identifying the user at the VPN’s other end...
Implementation – VPNs
clear & crypt
clear
clear
clear
crypt
clear
Private Networks
Private Networks
INTERNET
clear
clear
crypt
clear & crypt
clear
Private Networks
Private Networks
Implementation – VPNs
• What you probably already knew…
• VPN technology is unavoidably attractive
• VPNs are IP-specific, NAT introduces problems
• VPN clients / servers are likely to interoperate at some level,
although not all features may work...
• What you may not have expected !
• VPN setup authenticates the station at the other end, NOT the
user at that station
• ‘Extended Authentication’ (X-Auth) can be required during
Phase I negotiation. Together with one-time passwords, this
reliably authenticates the remote user.
• Some VPN clients allow ‘alternative gateway’ definitions,
enabling redundancy if other considerations allow.
Implementation – Policy Enforcement
• Your security policy must be:
• Defined
• Recorded
• Reconciled with your business necessities…
• Your perimeter security implementation must:
• Be able to enforce your stated policy
• Apply the constraints required
– authenticated user name?
– MAC address?
– Time-of-day?
• Supply the logs & reports required
• Balance cost and performance !
“Cost” is acquisition, maintenance,
and administration...
Implementation – Policy Enforcement
• Your firewall:
• defines ‘security regions’
• isolates user-populations into these ‘regions’
• enforces policy across the boundary between ‘regions’
Public
Private
INTERNET
DMZ
VPN
• Beware:
• Services dependent on broadcast & multi-cast protocols
• Services using random ports, or requiring fixed IPs
• Extreme traffic-profiles (HTTP v.s. FTP)
Implementation – Policy Enforcement
• What you probably already knew…
• Most common protocols are handled by most mature firewalls
• Application-level proxies are sensitive to application version
• What you may not have expected !
• Some common protocols (like PPTP) use non-TCP, non-UDP
protocols (like GRE)
• Firewalls that install ‘open’, or with many ‘standard’ allowrules, hide a multitude of unwanted protocols.
• Examine how your prospective firewall’s administration and
performance will scale to:
– dozens/hundreds of rules per firewall
– multiple firewalls per site
– multiple sites
Implementation – Redundancy
• A firewall is an ‘architected single point of failure’
• Balance incremental cost of solution against cost of downtime
• Un-interrupted protection can be achieved several
ways:
• “Manual switch” - simple, cheap, quick, limited, manual
• “Warm stand-by” - ‘partial automation’, unattended
• “Parallel live” complex, costly, fully automated, unattended
• All redundancy solutions require one-to-many
management, to assure coordinated policy
implementations
Implementation – Redundancy
active firewall
idle standby
active firewall
INTERNET
idle standby
load
balancer
active firewall
active firewall
load
balancer
Private
Networks
Manual
switch
Private
Networks
Warm
stand-by
Private
Networks
Parallel
live
Implementation – Redundancy
• What you probably already knew…
• Downtime is bad.
• Firewall downtime is very visible 
• What you may not have expected !
• Downtime is tolerable (in many environments).
• Automated redundancy solutions may introduce their
own problems
• Simple is best
Not all backups can be restored.
Test your recovery procedures.