Firewall Integration

1
Firewall Integration
2
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?

3
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

4
Agenda

• Introduction
• Perimeter Security Models
• Firewall Types (review)
• Perimeter Design Issues
• Implementation choices
• Network Separation
• Routing
• DNS
• Sendmail

• Public Servers
• VPNs
• Policy
• Redundancy

5
Perimeter Security Models
6
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

7
Firewall Types Review
8
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?
VPN gateway?
E-mail masquerading?
Authentication?
9
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

10
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

11
Policy Issues

• Is your security policy
• Defined?
• Recorded?
• Explicit enough to implement?
• Possible?
• Practical?

12
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?

13
Agenda

• Introduction
• Perimeter Security Models
• Firewall Types (review)
• Perimeter Design Issues
• Implementation choices
• Network Separation
• Routing
• DNS
• Sendmail

• Public Servers
• VPNs
• Policy
• Redundancy

14
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?

NOT !
15
Implementation Network Separation

• Can you isolate
• Public protected servers into DMZs
• Private shared servers into network spaces
  which are
• Policy-managed
• VPN-accessible

16
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-partitionin
  g can significantly enhance security

17
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 ISPs routers, and your firewall !

10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
18
Implementation 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.

19
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

It was there yesterday!
I know its there, but I cant reach it!
20
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

21
Implementation DNS

• Present two DNS images for your name-space
• Queries never flow inbound

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

Use allow-xfer
23
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

24
Implementation Sendmail
25
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 dont have to re-invent the wheel.

26
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
• Its real location is obscured
• Accesses to/from it are tightly regulated
• It has reduced access to other facilities (DNS,
  mail, etc.)

27
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

28
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

29
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 VPNs other end...

30
Implementation VPNs
31
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.

32
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...
33
Implementation 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)

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

35
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

36
Implementation Redundancy
37
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.