Firewall Plant Design Process

Document Sample
Firewall Plant Design Process Powered By Docstoc
					Firewall Plant Design Process

Presenter: Peter Grina
           Morgan Stanley

Sunday, May 20, 2012

University of Illinois - CS498
Professor Susan Hinrichs
Siebel Center - Room 1111
Feb. 6, 2007 - 2pm


      One of the world's largest diversified financial services companies

55, 000 employees                                       600 offices in 30 countries

                             Founded in 1935,
                      Morgan Stanley and its people
                     have helped redefine the meaning
                           of financial services

                                                           Committed to
                                                         community service
                      Who is Peter Grina?

                                            Memorable Concerts
1983 University of Illinois graduate        Jethro Tull
                                            Joan Jett and the Blackhearts
                                            U2 (in the auditorium)
Worked 20 years in IT before coming to
Morgan Stanley                              Arcade Games
                                            Space Invaders
                                            Pac Man
                                            Donkey Kong
Morgan Stanley IT Security Department
since 2003                                  Other Happenings
                                            Reagan elected President
                                            Cable TV installed on campus
                                            Raiders of the Lost Ark
                                            2nd and 3rd Star Wars movies

               Firewall Plant Design Process

Topics for Discussion

   Firewall (FW) Concepts and Practical information
   • Firewalls and Networks
   • Design and Implementation
   • Firewall Management

    Refreshing Firewall Technology at Morgan Stanley
    • The Morgan Stanley Environment
    • The Issues we face
    • Assessing the problems to determine the best response strategy
    • Deploying the Solutions
    • Lessons learned

    Please ask questions!

                        Packet Filter Firewalls

An IP packet filter firewall allows you to create a set of rules that either discard or
accept traffic over a network connection.
 • Fast
 •   Stateful failover in higher-end products

                                                                          IP Filter
Evolution of Packet Filter Firewalls
• Rules originally defined only by
  SRC/DST addresses and ports
• Rules include TCP flags (SYN/ACK)
• Rules include connection tracking (keep
• Rules defined by interface or security          iptables         PIX

                                   Rules defined by SRC/DST Addresses and Ports

                          Example1: Permit telnet from Client to Server

    Rules by SRC/DST
    address and port

    Include TCP flags

    Connection Tracking


                        Security Concern:
                          • Server can connect to Client on any high port if it sets its source port to 23

                                  Include TCP Flags

                          Example 2: Permit telnet from Client to Server

    Rules by SRC/DST
    address and port

    Include TCP flags

    Connection Tracking


                          Security concern:
                           • Server can send unwanted packets to Client by setting source port to 23, and
                             playing with TCP flags.
                           • If Firewall (FW) rules include entire Client network, then Server can detect
                             (and possibly identify) all hosts.
                                  Include Connection Tracking (Keep State)

                          Example 3: Permit telnet from Client to Server
                          • Firewall maintains state table (hash) of connections in memory
                          • State for UDP and ICMP connections

    Rules by SRC/DST
    address and port

    Include TCP flags

    Connection Tracking


                          • Simpler rules - return traffic not defined explicitly (iptables is an exception)
                          • Security benefit - Server packets blocked, except when responding to Client.
                          • Security benefit – Unwanted UDP and ICMP connections easily blocked

                                 Rules defined by Interface or Security Zone

                          Example 4: Permit Telnet from Client to Server
                          • Security zones
                          • Faster - firewall only checks rules for relevant zone
                          • More secure – firewall performs sanity checks on rules

    Rules by SRC/DST
    address and port

    Include TCP flags

    Connection Tracking


                         Packet Filtering through Network Layers

                      Relevant Layers for TCP/IP

OSI Network Model

    1. Physical

    2. Data Link              Layer 2 – MAC (e.g. switches)

    3. Network                Layer 3 – IP (e.g. routers)

    4. Transport              Layer 4 – TCP/UDP (e.g. packet filters)

    5. Session

    6. Presentation

    7. Application            Layer 7 – Application (e.g. IDP, DI)

    • Packet filter rules typically protect at Layer 4 (e.g. allow 80/TCP outbound)
    • DI/IDP can raise protection to Layer 7
    • DI - Deep Inspection
    • IDP - Intrusion Detection and Prevention
    • IDP- sometimes called IDS (Intrusion Detection System) or IPS (Intrusion Protection System)

                               Transparent Packet Filter Firewall

Layer 2 Advantages
• Cannot receive packets
• Invisible to traceroute
• Harder to hack (?)
• Easier deployment
• Conserves address space
• Passes multicast

Layer 2 Disadvantages
• Some can not NAT
• Not all PF support L2
• Lacks 802.1Q tags on
  generated packets

Other Requirements
• Out-of-band management
• Out-of-band failover links

                   Address Translation

Network Address Translation (NAT) simply rewrites SRC and/or DST addresses

Port Address Translation (PAT) allows multiple IP addresses to share an IP address
via port mapping.

• NAT is sometimes called masquerading.
• PAT is sometimes called network address port
• NAT is often used generically to mean all forms of
• Some protocols and products can not NAT

                          Static 1-1 NAT Examples

                     NAT hides IP addresses – Client connects to Server

    Static 1-1 NAT
    Simple PAT

    Large PAT

                          Simple PAT: 6 Hosts sharing Linksys connection

                     Using PAT to hide several IP addresses

    Static 1-1 NAT
    Simple PAT

    Large PAT

                           Large PAT example: N Web proxies sharing 2 IP addresses

                      Using PAT to convert IPs into a new pool of addresses

    Static 1-1 NAT
    Simple PAT
                     Port Address Translation (Enterprise Case)
    Large PAT
                     • All Client HTTP requests go to Web Proxies
                     • Web Proxies are extremely popular (caching, logging, content filtering, AV)
                     • PAT device changes source IP address or

                     • Unfortunately, some websites will only allow traffic from certain IP addresses
                       for historical or “security” reasons.
                     • PAT device hides web proxy addresses, so more proxies can be added later
                       without introducing new traffic patterns into Internet cloud

Stateful Failover provides High-Availability (HA)

                  Packet Filters: Advantages and Disadvantages

         Advantages                               Disadvantages

• Fast                                       • Endpoint systems
                                               communicate directly
• Stateful failover is commonly
  available                                  • Must use PAT to hide internal
• Security zones prevent
  certain bad rule definitions               • IDS/DI is slow (better to
                                               install elsewhere?)
• Plenty of commercial and
  freeware products                          • Susceptible to tunneled traffic

                    Proxy Firewalls

A proxy firewall, in addition to blocking port access, acts as an intermediary for each
network request.

 • It terminates the connection from the requestor, and initiates a new connection
   to the destination server. The proxy becomes a “man-in-the-middle” for the flow.
 •   Also known as “Application Firewalls”




             Reverse Proxy                FWTK

                         Proxy – Two Distinct Connections per Flow

•   Client and Server never communicate directly.
•   Client and Server don’t see each others’ real IP addresses
•   A circuit proxy simply plugs connection without inspecting traffic
•   An application proxy verifies the protocol, and can perform content inspection.

                     Double-NAT Packet Filter pretending to be a Proxy

Client and Server don’t see each others’ real IP addresses

Big Difference!
• Client and Server communicate directly
    – IP addresses and port numbers changed, but SEQ and ACK numbers, TCP window size,
      TCP flags, etc., all pass between Client and Server.

             Proxy Firewall Notes

Application Proxies provide Layer 7 protection
• Protocol compliance enforced by proxy

Circuit Proxies effectively provide Layer 4 protection
• Connections simply patched through based on IP/port combinations

• Still has advantage of two connections.

Advantages of Proxy Firewalls
•   Endpoints never communicate directly
•   Can enforce strict protocol compliance
•   Much more detailed logs
•   Content caching in some cases
•   Decent selection of point products (i.e. single or limited protocols)

Disadvantages of Proxy Firewalls
• Slow and resource-intensive
• Lack stateful failover
• Limited commercial/freeware options for generic proxy firewall

                          Managing Firewalls

• Services/ policies / rules
    – Terms/definitions are blurry and depend on the management tool
         At Morgan Stanley:
         • A rule is usually a single permission (ACL),
         • A service is the collection of rules that define a service offering
         • e.g. 17k rules for 225 distinct services
    – Large-scale management is weakest link of Firewall products (IMO)
         •   Revision control system
         •   Inability to group rules into services
         •   Rule documentation – mandatory fields!
         •   Staging changes
         •   Correlating rules to usage (logs)
         •   Ability to handle multi-thousand rule systems (17k items in a listbox! Ouch!)
         At Morgan Stanley:
         •   Home-grown management system for 3 types of firewalls
         •   Point solutions for others

• Logging
    – Logs used in capacity planning, trending, troubleshooting, etc.
    – Auditors, regulators, SEC requirements
    – Growing market for log correlation with other systems’ logs and IDS

                             The Morgan Stanley Environment

Stability and reliability are paramount

Client Firewall Plants           Market Data Firewall Plants Internet Firewall Plants

For clients that pay us to use   We pay providers (e.g. stock   High-speed connections to
our services                     exchanges) for services        multiple tier-1 ISPs

• 4 major plants, each has 2     • Over 50 plants globally      • 5 major plants (2 sites
  sites                          • Some plants support            each), some smaller plants
• Leased lines (direct or          hundreds of applications
  aggregated)                                                   • Email is vital to business
                                 • Some firewalls have > 20k
• Several hundred clients in       rules                        • Growing number of
  a busy plant                                                    business applications
                                 • Latency is important
• Complex applications are                                      • Increasing number of
                                 • Relatively simple design       customers coming in via
  sensitive to latency
                                                                  Internet VPN
• Relatively simple design
                                                                • Very large and complex
                                                                • Familiar security concerns

                 Defining the Problems

• Disparate firewall technology and management tools
• Size (#plants, size of the plants, #rules/services, #users, etc.)
• Hard to change (Change Management process, Auditors, Business
  Units - real money at stake)
• Complexity
     – lots of NAT and PAT
     – lots of security zones
     – proxying where necessary
     – monitoring/alerting/logging/troubleshooting
• Firewall performance – we often bump into limits
• Constant growth and evolution
     – exceptions
     – compromises
     – working around design constraints
• Dynamic/changing environment

                          Attacking the Issues: Stage 1

• Assessment of current environment
• Agree on axioms and assumptions (examples on next slide)
• Start with clean whiteboard design
• Endless Cycle #1
    –   Document design
    –   Discuss with partners
    –   Refine design
    –   Repeat
• Endless Cycle #2
    –   Document migration plans
    –   Discuss with partners
    –   Refine plan
    –   Repeat
• Teamwork and communications
• Flexible design maybe too flexible? Avoiding pitfalls.

                          Axioms and Assumptions

Some of our philosophy:

• FW management is as important as performance
• No default route to internet
• No straight-thru traffic to internet
• Multiple layers of protection
• Separate security zones
• Flexible design
• Scalable design
• Do not design to vendor features
• Keep firewalls as simple as possible, but no simpler

                              Attacking the Issues: Stage 2

• Firewall vendor bake-off
    – Interesting results (1Gbs = 160Mbs ?)
    – Regression test of historical problems
    – Performance differences
    – CLI versus GUI, and access to raw data
    – All Vendors = Partners (mutually beneficial relationships)
• Management tool bake-off
• Training staff on new technology

                                Gig-capable, only with a disclaimer!

Scenario: A single UDP flow saturating a 1 Gbs pipe passed through various “Gig-
capable” firewalls.
 •    A single rule (permit any) defined on firewall
 •    These conditions should produce optimal results for a firewall

         Packet Size - Bytes       Vendor A – Mb/sec         Vendor B – Mb/sec     Vendor C – Mb/sec
                           64                          230                 155                   1,000
                          128                          405                 272                   1,000
                          256                          757                 508                   1,000
                          512                     1,000                  1,000                   1,000
                         1024                     1,000                  1,000                   1,000
                         1500                     1,000                  1,000                   1,000

Vendor bandwidth claims are somewhat misleading.
     • Some are only Gig-capable under favorable test conditions that may not represent real traffic
A better firewall performance benchmark is packets/second (PPS).
     • When a firewall failed to pass 100% of the generated packets, there was a fairly constant PPS
When vendors quote bandwidth numbers to us, we always ask about PPS instead.

                             Firewall Testing – Key Points

• SW-based solution requires full-blown OS underneath
• Appliance design choices
• Linear rule evaluation or hash
• Rules in software or hardware
• Features versus performance and supportability

• Standards compliance
• High Availability
• Product range
• Management, monitoring
• Transparency

                       Management Tool Bake-Off

• Single versus Multi-vendor Firewall support
    – Multi-vendor product provides leverage against FW vendors
    – Multi-vendor support presents different set of challenges
• Ease of use and supportability
• Revision control and audit history
    – How to rollback changes?
    – Who made which change?
• Services/rules abstraction
    – Don’t want to manage 17k rules on a FW
    – Prefer to manage 225 services
• Authentication
    – Not another password store to manage!
• Authorization
    – Not everyone needs full control
• Access to raw data
    – Unrealistic to believe that vendor has every analysis/report option.
    – Unrealistic to wait for vendor to provide new tool when need arises.
    – Raw data could be leveraged to fill in gaps in vendor’s product.

                     Deployment and Migration

• Approach depends on plant complexity
• Extensive lab testing for changes
• “Big bang" for simple plants
      – automated tools to convert old -> new technology (manual = error prone)
      – comprehensive testing of migration tools
      – after-hours testing wherever possible
• Slow migration for larger plants
      – each service migration requires separate planning/execution
      – upgrade half of the plant (i.e. 1 of 2 sites) to minimize risk
      – environment continues to evolve
      – old and new plants may co-exist for a long time
• Project is done when an old plant is turned off, but the new plants continue to evolve

                         Lessons Learned

    Projects are far                       Date and save all
    bigger than                            meeting minutes
    anyone expects

Over-communication is
far better than under-                     Document meeting results,
communication                              and email decisions and
                                           action item list to all

In Closing…


Shared By: