Title: Firewall Integration
1Firewall Integration
2Scope 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?
3Agenda
- Introduction
- Perimeter Security Models
- Firewall Types (review)
- Perimeter Design Issues
- Implementation choices
- Network Separation
- Routing
- DNS
- Sendmail
- Q A
- Public Servers
- VPNs
- Policy
- Redundancy
4Agenda
- Introduction
- Perimeter Security Models
- Firewall Types (review)
- Perimeter Design Issues
- Implementation choices
- Network Separation
- Routing
- DNS
- Sendmail
- Public Servers
- VPNs
- Policy
- Redundancy
5Perimeter Security Models
6Firewall Types (review)
- Filtering Routers
- fast
- multi-function routers
- filter on IP/TCP/UDP content
- Session-aware Gateways
- filter some protocol violations
- Application-level Gateways
- filter all protocol violations
- filter application-data violations
- can host critical services
- pass protocol violations
- management scales poorly
- pass application-data violations
- slower than packet filters
- may lag in proxy rollouts
- more latency
7Firewall Types Review
8Perimeter 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?
Idle hands need no direction
Content filtering?
VPN gateway?
E-mail masquerading?
Authentication?
9Physical 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 leads to subnet
separation! - Cabling, more subnets (private addresses?)
- Switch ports, more routers?
- Router ports, more cost?
- Facilities
10Network 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
11Policy Issues
- Is your security policy
- Defined?
- Recorded?
- Explicit enough to implement?
- Possible?
- Practical?
12Redundancy 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?
13Agenda
- Introduction
- Perimeter Security Models
- Firewall Types (review)
- Perimeter Design Issues
- Implementation choices
- Network Separation
- Routing
- DNS
- Sendmail
- Public Servers
- VPNs
- Policy
- Redundancy
14Implementation 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?
NOT !
15Implementation Network Separation
- Can you isolate
- Public protected servers into DMZs
- Private shared servers into network spaces
which are - Policy-managed
- VPN-accessible
16Implementation 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-partitionin
g can significantly enhance security
17Implementation Routing
- Firewall NAT allows you to use private addresses
internally (RFC1918) - 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 ISPs routers, and your firewall !
10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
18Implementation Routing
- Static routing
- any internal, routable, accessible subnets must
be statically defined in the external router,
with the firewall as gateway - any subnets not adjacent to the firewall must be
statically defined in the firewall, with the
internal router as gateway.
19Implementation 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
It was there yesterday!
I know its there, but I cant reach it!
20Implementation 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
21Implementation DNS
- Present two DNS images for your name-space
- Queries never flow inbound
22Implementation 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)
Use allow-xfer
23Implementation 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
24Implementation Sendmail
25Implementation 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 dont have to re-invent the wheel.
26Implementation 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
- Its real location is obscured
- Accesses to/from it are tightly regulated
- It has reduced access to other facilities (DNS,
mail, etc.)
27Implementation 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
28Implementation 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
29Implementation 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 VPNs other end...
30Implementation VPNs
31Implementation 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.
32Implementation 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...
33Implementation Policy Enforcement
- Your firewall
- defines security regions
- isolates user-populations into these regions
- enforces policy across the boundary between
regions - Beware
- Services dependent on broadcast multi-cast
protocols - Services using random ports, or requiring fixed
IPs - Extreme traffic-profiles (HTTP v.s. FTP)
34Implementation 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 allow-rules, hide a multitude of
unwanted protocols. - Examine how your prospective firewalls
administration and performance will scale to - dozens/hundreds of rules per firewall
- multiple firewalls per site
- multiple sites
35Implementation 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
36Implementation Redundancy
37Implementation 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.