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. Private Networks Private Networks Firewall application Private Networks Private Networks Server O.S. INTERNET Dedicated Firewall Dedicated Firewall Dedicated Firewall Dedicated Firewall Dedicated Firewall Dedicated Firewall Load Balancer Load Balancer Private Networks Private Networks Public Servers 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. Static IP Filter Stateful Inspection HIGHER Generic proxy Application-level proxy Performance Split Server LOWER LOW MEDIUM HIGH HIGHEST AVAILABLE Security 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. Public Private INTERNET VPN DMZ 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-partitioning 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 ISP’s routers, and your firewall ! 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16

18. Destination gateway 12.27.48.0 12.27.47.177 10.2.1.254 12.27.47.177 10.1.1.1 INTERNET 10.1.1.254 12.17.48.x Destination gateway 10.2.0.0 10.1.1.254 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 it’s there, but I can’t 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. forwarding ISP named Firewall resolver Internal named forwarding queries queries DNS ‘NS’ authority No DNS authority DNS ‘NS’ authority forwarding forwarding Firewall named Firewall named Firewall named Firewall resolver Internal named INTERNET queries queries queries DNS ‘NS’ authority DNS ‘NS’ authority forwarding forwarding Internal named queries queries DNS ‘NS’ authority DNS ‘NS’ authority DNS ‘NS’ authority 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. POP ISP’s Mail Server Private Mail Server MX Private Mail Server MX Virus Scanner INTERNET MX Private Mail Server Virus Scanner MX Private Mail Server 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 don’t 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: • It’s real location is obscured • Accesses to/from it are tightly regulated • It has reduced access to other facilities (DNS, mail, etc.)

27. Public Private 12.27.47.177 INTERNET VPN DMZ 10.3.1.x 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 VPN’s other end...

30. clear & crypt clear Private Networks clear clear Private Networks VPN VPN VPN VPN clear crypt INTERNET clear clear Private Networks crypt clear & crypt Private Networks clear 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. Public Private INTERNET DMZ VPN 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 firewall’s 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. active firewall active firewall active firewall Manual switch active firewall idle standby idle standby switch switch Private Networks Warm stand-by Private Networks switch switch INTERNET Private Networks load balancer load balancer Parallel live 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.