Firewall Integration. Scope of Discussion Assumption: You plan to install / re-architect / replace / upgrade your perimeter security Question: What issues

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 ServersVPNsPolicyRedundancy

Perimeter Security Models

INTERNET

PrivateNetworks

PrivateNetworks

DedicatedFirewall

LoadBalancer

LoadBalancer Dedicated

Firewall

DedicatedFirewall

PrivateNetworks

PrivateNetworks

Server O.S.

Firewall application

DedicatedFirewall

PrivateNetworks

PublicServers

DedicatedFirewall

PrivateNetworks

DedicatedFirewall

Firewall 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

Application-levelproxy

StatefulInspection

SecurityLOW HIGHEST AVAILABLEMEDIUM HIGH

Genericproxy

Static IPFilter

SplitServer

Firewall Types ReviewP

erfo

rman

ceL

OW

ER

HIG

HE

R

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?

“Idle hands need

no direction”

Content filtering?

E-mail

masq

uerading?

VPN gateway?

Authentication?

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: leads to subnet separation!– Cabling, – more subnets (private addresses?)

– Switch ports, – more routers?

– Router ports, – more cost?

– Facilities

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?


• Can you isolate:• “Public protected” servers into DMZs

• “Private shared” servers into network spaces which are:– Policy-managed

– VPN-accessible

INTERNET

Public Private

DMZ VPN


• 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 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 ISP’s

routers, and your firewall !

10.0.0.0/8172.16.0.0/12192.168.0.0/16

10.0.0.0/8172.16.0.0/12192.168.0.0/16


• 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.

Destination gateway12.27.48.0 12.27.47.177


INTERNET

10.1.1.1

10.1.1.254

10.2.1.254

12.17.48.x

12.27.47.177




• 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 it’s there, but I can’t reach it!”

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


• Present two DNS images for your name-space

• Queries never flow ‘inbound’

Internalnamed

forwarding

queries

DNS ‘NS’ authority

Firewallnamed

Firewallnamed

DNS ‘NS’ authorityDNS ‘NS’ authority

queries

forwarding

ISPnamed

Firewallresolver

Internalnamedqueries

forwarding

queries

No DNSauthority

forwarding

DNS ‘NS’ authority DNS ‘NS’ authority

Internalnamed queries


Firewallresolver

Firewallnamedqueries


forwarding

queries

forwardingINTERNET


• 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”

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


INTERNET

PrivateMail Server

MXVirus Scanner

PrivateMail Server

MX

Virus Scanner

PrivateMail Server

MX

PrivateMail Server

ISP’sMail Server

POP

MX


• 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.)

INTERNET

Public Private

DMZ VPN10.3.1.x

12.27.47.177


• 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


• 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...


INTERNET

Private Networksclearclear & crypt

Private Networksclearclear & crypt

Private Networksclear

crypt clear

clear

Private Networksclear

crypt

clear


• 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...


• 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)

DMZ

Public Private

VPN

INTERNET


• 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 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


INTERNET

Parallellive

active firewall

active firewall

PrivateNetworks

loadbalancer

loadbalancer

Warmstand-by

PrivateNetworks

active firewall

idle standby

Manualswitch

PrivateNetworks

active firewall

idle standby


• 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.

Documents

Firewall Integration. Scope of Discussion Assumption: You plan to install / re-architect / replace / upgrade your perimeter security Question: What issues