General discussion

  • Creator
    Topic
  • #2201876

    Step by Step Guide- Managing Cisco (PIX to ASA) Firewall Migration Projects

    Locked

    by mbbay21 ·

    Step by Step Guide to Managing Cisco (PIX to ASA) Firewall Migration Projects

    Overview

    This paper is designed as a guide for IT project managers to better understand Cisco PIX to ASA Firewall migrations and help orchestrate success firewall migrations. Firewall in general are the most prolific IT security product in use. Firewall migrations from PIX to ASA are the most prominent happening in this day and age. Cisco has more firewalls deployed than any other vendor in the market place. The original Cisco PIX firewall has reached End-of-Life (EOL) and all models will become obsolete in the near future as support costs are higher, no new features are supported, and support will go away entirely in due time. Many customers have or will at some point in time migrate to the Cisco ASA (Adaptive Security Appliance) firewall. Firewall migrations are usually short-term professional security services (PSS) engagements, however, large organizations may contract out large scale firewall migrations. Manage security services providers (MSSP) may carry out the bulk of firewall migrations, since they are the largest entities that companies outsource to (i.e. Verizon, AT&T). The fact is that firewall migrations are a complex task, and that many firewall migrations result in failure, which translates to lost profit, lost customers, and overall liability of staff. Failure rates have been identified in particular agencies as low as a 40% success rate. This is not acceptable. The reason firewall migrations fail are mainly due in part to poor management, poor planning, poor communication with customers’, and a lack of technical knowledge and experience.

    In firewall migrations, the project manager is critical to ensuring successful migrations. Pure technical knowledge in and of itself is not sufficient for success. In order to prevent failure, the project manager needs to understand the firewall migration process from a technical overview, and more specific firewall vendor and platform knowledge, so that project management techniques such as controlling risk can be applied. A project manager without product knowledge is insufficient, as project controls cannot be applied if the processes and procedures are not well understood. This paper is designed for the IT project manager to better understand how to make a firewall project successful. It will not ensure a 100% success rate, but will drastically improve success rates if the following methodologies are applied.

    The author has several years of IT security related engineering and project management experience in Cisco firewall migrations, and even program level experience in multi-million dollar firewall design & implementation.

    This paper focuses on the PMP processes as it applies to firewall engineering migrations, but does so in manner that is best suited for the project manager when facing these opportunities and challenges.

    1. Initiating

    The goal of the initiating phase is to gain customer commitment and authorization for a custom PIX to ASA migration project. In order to gain authorization from the customer involves several stages, and there is a likelihood that the Initiating phase may never be established, or can take a length of time, even up to a year. This can happen for multiple reasons that are our of your control. Examples are provided below.

    ? The prospect is in an evaluation phase and is not yet committed
    ? The prospect wants to perform this work, however they don’t have budget money until a future quarter
    ? The prospect may have vague goals, objectives, and expectations, which leads to indecision
    ? Conflicting directives in management; company politics
    ? The prospect has decided on a higher priority objective, downgrading the need for this project, or the higher priority objective solves their problem and voids this project

    Note, the scenarios above are out of your control. However, when engaging a prospect, it is important that you understand the areas that are within your control, and it is also important that you find the “time robbers”. Time robbers are prospects that have little to no interest in your services, and are only looking to gain valuable information from you at a zero cost, which translates to wasting your time.

    Note that time robbing is usually a necessary part of doing business, and a risk you need to take. It can’t be said for how many times, and how much time invested into pre-sales is spent without a customer commitment to sign-off and authorize the project. Getting past the Initiating phase is the single most important phase. However, you win some, lose some. Just understand what you’re getting yourself into, and try and not expend too much resources with a prospect/customer until you feel they are ready to commit. In many cases, you must perform assessment work in order to develop a budgetary quote for hardware and for professional services. If the account manager has sold to the customer before, and has a good reputation with the customer, this trust increases the probability of success for this particular project engagement, versus a brand new prospect.

    Kick-off Meeting / Con-Call

    During the initial kick-off meeting/con-call, the following preliminary qualification questions that should be asked to help qualify a prospect are below, and are designed to help weed out the time robbers. The Account Manager and Project Manager need to be present on this call. The Firewall Engineer does not need to be on this call or present during this meeting, but it can’t hurt to engage the Firewall Engineer early on. These questions are more business and process oriented, versus the technical assessment that follows.

    Customer Qualification Questions
    Q1) Ask the prospect/customer to describe an overview of the scope of work encompassing their PIX to ASA firewall migration project. See if the customer can have their security engineer on the call, since that person will be able to convey the details better than management. (Take Notes)
    Deductions: The response will reveal whether the customer has a clear set of expectations, or whether their goals and objectives are vague. Also, the wording of their response will determine a level of technical aptitude. This depends on the person(s) answering the questions. If it’s an engineer, or engineering lead manager, this can set the stage as to the difficulty level of performing this work with this particular client, since if the engineers come off as ignorant, you should expect more hand holding, added overhead, and additional training. Also portrayed during this call should be the customer’s personality in terms of are they easy going, moderate, or very strict. This is important to know when approaching scenarios in the execution phase, and how this customer is going to handle risk scenarios, and if they are going to be difficult to work with during project execution.
    Q2) Ask the customer what the driving factors are behind upgrading to the ASA platform. (Take Notes)
    Deductions: The motivations behind the upgrade can be of varying reasons, some technically, some politically focused. Politics and management directives are usually the #1 driving factor behind upgrades, especially if you’re working with a federal customer. There are however, technical solutions in the ASA platform that solve business problems or can streamline processes. Here are some of the many drivers behind PIX to ASA migrations:
     phase out old technology, and replace with leading edge
     management directive, or federal mandate (i.e. HSPD12) requires an Intrustion Prevention System (IPS), and we want to integrate the solution (AIP hardware converged service module) into our firewall solution to meet this mandate (this is strictly politically driven)
     we are exceeding the throughput and need a faster firewall and have a requirement for 1 Gigabit firewall interfaces (speeds and feeds)
     we want to increase our ROI and lower our TCO by trading in old PIX, VPN3000 concentrators, and IDS appliances, and converging these services into a 2-node high-availability ASA cluster. We want to take advantage of lower SMARTnet support costs as well as leverage new features such as SSL VPN. (note: this reply is coming from a very well-informed customer with a clear set of objectives)
    Q3) Ask the customer what their timeline is for this project and if they have a deadline that they have to meet. (Take Notes)
    Deductions: If the customer responds with a vague timeline, heads up, this may be a time robber. If the customer says that they have a deadline 1 month away, then you must prepare to jump on this opportunity and get the customer everything they need in the Planning stage and get sign-off. If they say their timeline is next quarter, then get the budget quoting together for hardware, software, support, and professional services. If they say their timeline is next calendar year, or next fiscal year, you have a good sense of their positioning, and how readily they are willing to act. The AM should be persistent, and follow-up with the customer, in order to win this business down the road. If the AM is not persistent, it can be a lost project that gets awarded elsewhere.
    Q4) Ask the customer what other imminent projects they have going on. (Take Notes)
    Deductions: If the customer responds promptly and says that project x is taking place now, and must be completed before we can begin this firewall migration project, that can be taken as a bonafide statement. If the customer is vague, this means they are holding back information, or do not have a clear set of goals and expectations. The response should again signal the priority of this project, and once again iterates the probability of materializing. This question is a follow-on to Q3. It is designed to determine the customer’s commitment level.
    Q5) Ask the customer how much they know about the ASA platforms new features, and if they are aware of the reduced SMARTnet costs and trade-in options available, as well as brand new features just released. (Take Notes)
    Deductions: The goal here is to persuade the customer into making this project a higher priority agenda. If the customer comes off as knowing everything, this close-minded mentality does not bode well and acts as a communication barrier. If the customer says that they are comfortable, they would like more information regarding these options, you can let them know that you can provide them a presentation that underscores all the options, features that are up-to-date and available to help them make the most educated decision. Please see APPENDIX A for this presentation.
    Q6) Inform the customer that a budgetary quote for hardware and Professional Services can be provided so they can see the cost associated to the project, and will need to answer a technical questionnaire and provide a sanitized network security topology drawing (if they can, some federal agencies cannot even provide a sanitized network drawing, but always try and get one). This is very important. (Take Notes)
    Deductions: A customer may be willing to answer a technical questionnaire if they need to determine the cost of the project, whether immediate, or in the distant future. You should already know whether this project is imminent, or is being planned for a later date. Answering a technical questionnaire and furnishing a sanitized network security topology drawing (typically in Visio) takes time on the customer’s part. If they are ready and willing, you are closer to gaining their buy-in and commitment to the project.

    In order to fully qualify the customer, a short brief Technical Assessment must be performed, which takes effort on both parties. Once the Technical Assessment has been performed, a budgetary quote for hardware, software, support, and professional services should be provided to the customer. If this is amenable to the customer, then you have gained their buy-in and commitment to the project and can proceed to the Planning phase.

    Technical Assessment

    The information necessary to assess a PIX to ASA firewall migration project can be broken down into two (2) sections.

    1. PIX to ASA Technical Questionnaire
    2. Sanitized Network Security Topology Diagram

    PIX to ASA Technical Questionnaire

    Q1) What model PIX(s) are currently deployed, what firmware code are they running?

    Example: We currently have 4 PIX UR 525 models, all running code 6.3.5
    Q2) Are the PIXs configured Standalone units, or in High-Availability mode (HA). If HA, Active/Standby, or Active/Active

    Example: 2 HA Active/Standby pairs
    Q3) Check Any and All Platform/Feature/Encryption Licenses you have

    Example: UR, FO, VPN-3DES licenses

    Q4) Describe the network topology and geographical placement of the Firewalls

    Example: 1 HA Pair for Internet, 1 HA Pair for Extranet – Single Site Model

    Q5) How many interfaces are being used on each firewall / what is their function / what media type are they?

    Example: Internet Cluster (3 Fast Ethernet Copper – Outside, Inside, DMZ)
    Extranet Cluster (2 Fast Ethernet Copper – Outside, Inside)
    + 2 additonal interfaces per FW Cluster for Stateful Failover

    Q6) How many Internet Providers do you have? How are these configured?

    Example: 2 diverse Internet Providers (AT&T & Verizon)
    Internet Head-End routers are configured for eBGP and iBGP
    load sharing. The Internet FW Cluster points to an HSRP VIP.

    Q7) How much Public Address Space is assigned to your PIX(s)

    Example: 2 /24 on the Internet FW Cluster, 1 /24 from each provider

    Q8) How many Static NATs are configured? What function do the Static NATs provide?

    Example: /15 Static NATs on the Internet FW Cluster
    13 for DMZ Servers mapped to Outside
    2 for Internal Mail Server and Web Mail mapped to Outside

    Q9) Approximately how many firewall rules are configured on each FW or FW Cluster?

    Example: 360 rules on the Internet Cluster, ~600 rules on the Extranet Cluster

    Q10) It is assumed you are performing Ingress Filtering. Are you performing any Egress/Outbound filtering on the firewalls or firewall clusters?

    Example: We filter outbound for port 25 only on the Internet Cluster
    We perform strict outbound filtering on the Extranet Cluster

    Q11) Are there any Site-2-Site or Lan2Lan Tunnels configured. If so, how many, and roughly how many subnets are encrypted at each endpoint? If there are multiple sites, will they need to access each other?

    Example: 2 L2L Tunnels on the Internet FW Cluster to Remote Site #1 and #2
    12 subnets at Corporate and 6 subnets each for both remote sites
    Remote Sites only need to access resources at the corporate site

    Q12) Do you have Remote Access IPSec configured? If so, how many concurrent users do you have? Do you have any hardware remote access clients (i.e. EZVPN), and will remote access users need to talk to each other

    Example: up to 50 concurrent Cisco VPN Clients (IPSec software based)

    Q13) Are any firewalls running a dynamic routing protocol? Is there a routing protocol being run on the network that the firewall attach to? How is the routing configured?

    Example: The Internet FW Cluster runs OSPF with the rest of the network, and
    injects a static default route that is learned. The partner Extranet FW
    employs static routing, in which static routes to remote networks are
    injected into OSPF.

    Q14) What is the size of your userbase

    Example: roughly a total of 500 employees, contractors, and partners

    Q15) Where do your internal/external DNS Servers Reside? How are they configured?

    Example: DNS Servers reside internally, DHCP/DNS is provided by Active
    Directory Domain Controllers. We host our own external DNS,
    in which BIND servers reside in the DMZ and are mapped to the
    the outside. This enables Internet Provider redundancy in the
    case that a Internet Provider goes down.

    Q16) Do you have any plans for growth of userbase, adding additional remote sites, increasing staff, increasing teleworkers, increasing partners, that could affect the overall firewall throughput for Stateful Inspection and VPN throughput, in which a higher capacity ASA should be evaluated?

    Example: We don’t plan to scale more than 200 additional total users in the
    next 2 years.

    Q17) Is there any other pertinent information regarding your firewall configuration that is relevant?

    Example: None

    Sanitized Network Security Topology Diagram (provided by the customer)

    Final Initiating Con-Call with the Customer

    After the Technical Assessment material has been received and forwarded to the Firewall Engineer that will perform the migration, a final initiating con-call should be held with the customer stakeholders that includes the Account Manager, Project Manager, and Firewall Engineer. The agenda for this call is to confirm the information received by the customer, and the Firewall Engineer should discuss with key stakeholders any lose ends, and also gather information concerning any additional hardware converged service modules and software features that the customer is looking for in the ASA. Please use APPENDIX A to help the customer identify any and all features that may be of interest. In a typical scenario, the customer will want to see in the BOM a list of options and prices associated with the options so that they can choose what is best for them. The Firewall Engineer is responsible for developing a LoM (List of Materials) with options. The Account Manager and Project Manager should review the LoM submitted, and the Account Manager should generate a BoM (Bill of Materials) including options, with all pricing for hardware, software, and SMARTnet maintenance support. Once the BoM has been solidified, it should forwarded to the Firewall Engineer to create a time estimation, which will be translated into a quote for Professional Services, including a SOW (Statement of Work).

    Once the customer is content with the BoM submitted, including Professional Services pricing and conditions stated forth within the SOW, the customer can now sign-off. Once the sign-off occurs, the Initiating phase is completed.

    2. Planning

    Since a confidentiality agreement is signed by both parties in the SOW, it’s now time to begin planning for the project execution. At this time, the customer is now required to forward all actual firewall configurations, and actual non-sanitized network topology drawings, as well as processes and procedures relevant to this project. Since this information is sensitive, the customer is recommended to send it in an encrypted email archive using GPG or PGP keys for the highest security. ZIP/RAR encryption is second to PGP, and strong password entropy should be employed for the encryption key, and the encryption key can be communicated over the phone from the customer to the Project Manager. The Project Manager should be the recipient of this information, and disseminate the contents to the Firewall Engineer and Account Manager. Note that the Project Manager is now ultimately responsible for the success or failure of this project, and the Account Manager has performed his/her job and should not be involved further. The Project Manager should be the liaison between the customer stakeholders and the Firewall Engineer performing the work.

    Scope of Work

    The scope of work described below can be applied to any PIX-ASA firewall project. The example below is relevant to this particular scenario, however, can be replicated. The configuration used in this example is the most common configuration in today’s ASA deployments.

    The scope of work contains the following elements:

    ? Migrate the PIX Active/Standby Internet Firewall Cluster (PIX firmware v6.3.5) to ASA 5520s configured in Active/Standby (ASA firmware v8.2), with copper Gigabit interfaces
    ? Configure two LAN2LAN (site-2-site) tunnels from the Internet Firewall Cluster to Remote Site A and Remote Site B
    ? Configure IPSec Remote Access VPN on the new ASA Internet Firewall Cluster
    ? Migrate the PIX Active/Standby Extranet Firewall Cluster (PIX firmware v6.3.5) to ASA 5520s configured in Active/Standby (ASA firmware v8.2), with copper Gigabit interfaces
    ? Provide User training for the ASDM and CLI

    The WBS, if hardware can be pre-configured off-site, the WBS can be broken down into 2 categories – off-site pre-configuration, and onsite activities.

    This includes granular details of off-site and on-site activities. In many cases, when old firewalls are being replaced with new firewalls, if the new firewalls are not yet already in the hands of the customer, in order to avoid risk, all new hardware should be shipped to the seller, and all hardware appliances, modules, software, licenses, etc. should be pre-configured in a lab and then shipped to the customer post pre-configuration and proof-of-concept (POC) testing. In this particular example, the new ASA hardware has not already been ordered and is in the hands of the customer, which is the most ideal scenario. If it is the case that the customer has already ordered and received the new hardware, the new configurations should be built in a lab with ASAs (5505s will work for most intensive purposes), and routers/switches necessary to perform a Proof-of-Concept (POC) before going onsite. One other alternative, if the customer agrees to it, and should only be done in a complex scenario is to have the customer ship the new ASA firewalls to the seller in order for pre-configuration and POC testing. This way, the new configurations are all ready to go and configured on the ASA appliances, and reduces onsite Professional Services time which reduces cost and risk to both the seller and the customer, since less time needs to be spent onsite. Troubleshooting efforts are immensely reduced because a POC was performed in a lab prior to the actual cutover.

    Off-Site Pre-Configuration (Firewall Prep)
    WBS Element Code Estimated Hours WBS Element Name
    A 6 Prepare all four (4) ASAs with latest Firewall code and ASDM code

    A) Prepare all four (4) ASAs with latest Firewall code and ASDM code

    1. The Account Manager makes the order for all contents within the BoM from distribution
    2. All customer PIX configurations, network topology drawings, and process procedural documentation is handed over to the Firewall Engineer from the Project Manager
    3. The order is received by the seller and all boxes and contents are handed over to the Firewall Engineer
    4. Firewall Engineer unboxes all equipment
    5. Loads 4 AIP-SSM modules in each of the 4 firewalls
    6. Puts Rail Kits on all 4 firewalls
    7. Download latest Firewall code from Cisco’s site using valid CCO account (asa821-k8.bin) and associated ASDM code (asdm-621.bin)
    8. Obtains all license keys and BoM order spreadsheet
    9. Registers 4 AIP-SSMs with Cisco to obtain activation keys
    10. Registers AnyConnect Essentials license with Cisco to obtain activation key
    11. Registers Advanced Endpoint Posture Assessment license with Cisco to obtain activation key
    12. Check email and download all received activation keys into a local folder (Customer Name/Activation Key)
    13. Stacks 2 ASA 5520s on top of one another
    14. Create labels that read “Internet FW Primary” and “Internet FW Secondary” and place labels on ASA appliances.
    15. Obtains a straight-thru cable out of one of the bags and connects it to Interface GigabitEthernet0/3 on both ASA appliances for LAN/STATE Failover Interface
    16. Obtains 2 power cables for each firewall in the Internet Cluster and plugs them both in
    17. Connect Laptop USB-2-Serial or direct Serial port to Console cable to Primary Internet ASA
    18. Open HyperTerm or terminal emulation software on the correct COM port with Baud Rate set to 9600, Data bits set to 8, Parity set to None, Stop bits set to 1, and Flow control set to None.
    19. Connect Laptop from Ethernet RJ45 port to Primary ASA Interface Gigabit1/0 (inside)
    20. Power on the ASA, and watch it boot up on the Terminal Emulation Software
    21. Configure Laptop NIC to IP address 1.1.1.1 netmask 255.255.255.0
    22. Configure ASA Primary Interface GigabitEthernet0/1 with IP 1.1.1.2 and 255.255.255.0 and perform a “no shut”, the standard out should say the security level is 100.
    23. From the Primary ASA, ping the laptop NIC IP 1.1.1.1 (if you get echo replies continue)
    24. Load the TFTP Server on the Laptop and ensure (asa821-k8.bin) and (asdm-621.bin) are in the root directory pertaining to the TFTP server. Start the TFTP Server.
    25. On the Primary ASA, type “copy tftp flash” set the TFTP Server IP to 1.1.1.1 and the filename to asa821-k8.bin, and start the transfer
    26. Set the ASA boot variable to boot off the new code “boot system disk0:/asa821-k8.bin”
    27. Now TFTP over the asdm image and set the boot variable “asdm image disk0:/asdm-621.bin”
    28. Now do a “wr” to save the config
    29. Now reload the box “reload”
    30. When the Primary Internet ASA boots up, do a “sh ver” and verify that it booted off of and is running the latest ASA and ASDM code
    31. Perform housekeeping and remove the old ASA and ASDM code from flash; use the “delete flash:/” command
    32. Repeat Steps #14 through #31 for Secondary Internet FW
    33. Take the other 2 ASAs for Extranet Firewall Cluster and stack the Primary on top of the Secondary
    34. Create labels that read “Extranet FW Primary” and “Extranet FW Secondary” and place labels on both ASA appliances.
    35. Repeat Steps #14 through #31 for both Extranet FW Primary and Extranet FW Secondary

    Internet ASA FW Cluster (Off-Site Pre-Configuration)
    WBS Element Code Estimated Hours WBS Element Name
    A 0.5 Configure Interfaces (Primary ASA)
    B 0.5 Configure Passwords & Enable Inband Access (Telnet/SSH) and enable ASDM (Primary ASA)
    C 2-3 Configure NAT (Primary ASA)
    D 0.5 Configure Routing (Primary ASA)
    E 3-4 Configure Outside Ingress Access-List & Rule Tuning (Primary ASA)
    F 1 Configure Inside Egress Access-List (Primary ASA)
    G 2 Configure IPSec for Remote-Access VPN and LAN2LAN VPNs (Primary ASA)
    H 1 Configure Split-Tunnel Access Lists (Primary ASA)
    I Configure NAT Exemption Access Lists and Tunnel-Groups and Group-Policies for VPN Users
    (Primary ASA)
    J 0.5 Configure Remaining functions (Primary ASA)
    K 1 Configure Active/Standby Failover
    L 0 Perform Proof-of-Concept (POC) Testing
    (if necessary)

    A) Configure Primary & Standby Interfaces (Primary ASA)

    1. Bring up the customer’s PIX Internet FW Cluster CLI config
    2. Console into the Internet Cluster Primary ASA
    3. Assign Primary and Standby IP addresses to GigabitEthernet0/0, GigabitEthernet0/1, and GigabitEthernet0/2 per the addresses per the PIX config
    4. Assign Security Levels – 0 for outside, 100 for inside, and 50 for dmz
    5. issue the “nameif” command within interface mode to name “outside”, “inside”, and “dmz” addresses
    6. issue “no shut” on all interfaces within interface mode
    7. perform a “show ip” and verify the IP address assignments are correct
    8. Console into the Internet Cluster Secondary ASA
    9. Repeat Steps #2 through #7

    B) Configure Passwords & Enable Inband Access (Telnet/SSH) and enable ASDM (Primary ASA)

    1. Console into the Internet Cluster Primary ASA
    2. Configure “passwd” and “enable passwords” to “cisco” for temporary assignment
    3. enter the following commands:
    username cisco password cisco
    aaa authentication enable console LOCAL
    aaa authentication http console LOCAL
    aaa authentication ssh console LOCAL
    aaa authentication telnet console LOCAL
    http server enable
    http 0 0 inside
    telnet 0 0 inside
    ssh 0 0 outside
    ssh 0 0 inside
    management-access inside

    C) Configure NAT (Primary ASA)
    1. Now that inband access is enabled, disregard the console connection
    2. Set the Laptop NIC IP address to a random IP within the subnet of the “inside” interface
    3. Plug the straight-thru cable connected to the laptop into the “inside” interface GigabitEthernet0/1
    4. Bring up the customer PIX configuration for the Internet FW Cluster
    5. Identify all NAT types being used (static nat, static identity nat, dynamic nat, policy nat, nat exemption). If you are unsure about the different types of NAT, please see Cisco’s website for examples.
    6. Replicate all NAT configurations except NAT Exemption (aka nonat).

    D) Configure Routing (Primary ASA)
    1. Bring up the customer’s PIX Internet FW Cluster CLI config
    2. Make sure you have Telnet inband connectivity to the Primary ASA
    3. Configure static routes and static default route per the PIX config
    4. Configure OSPF exactly as the PIX was configured

    E) Configure Outside Ingress Access-List & Rule Tuning (Primary ASA)
    1. Bring up the customer’s PIX Internet FW Cluster CLI config
    2. You should be still Telnet’d into the Primary ASA
    3. Take all “conduit” statement and/or “outside access-lists” and copy them into notepad
    4. Perform a CTRL+H in notepad, and replace whatever conduit statements list name or the access-list name and replace the name with “outside_access_in” preceding the actual rules. This is the most accurate naming convention to use
    5. Take all “object-groups” and “service-groups” from the PIX config and copy them into a separate Notepad instance
    6. Evaluate all object-groups, service-group, and inbound rule definitions and determine if there are duplicates, and pair it down as much as possible – make the new configuration more streamlined than how it was configured in the PIX. This usually can be done as FW administrators in general do not keep clean, defined rulesets. This will be difficult to determine if certain rules are not being used, but the best you can do is streamline the given ruleset in the config.
    7. Copy & Paste all ratified object-groups and service-groups into the ASA via Telnet.
    8. Copy & Paste all “outside_access_in” access-lists into the new ASA config. You are dealing with a high volume of rules, in the hundreds of the full count, so take chunks in 100 or so at a time, and copy/paste them in. Do not perform this using a Console connection, because out-of-band console is extremely slow and can much up the configuration real easily. With Telnet, you can safely transfer at least a 100 rules at a time.
    9. After the Rules have been added, perform a “sh ru” and take the rules and paste them into a program like VIM, UltraEdit, or a text program that counts the lines. Compare the line count versus the original PIX config. Note, you should have been able to pair down some rules, and tune the ruleset in the order of “most used to least used” or “most general to most specific” as a rule of thumb.
    10. After the new ruleset has been transferred, add the “access-group outside_access_in in interface outside” to apply the ruleset to the outside interface

    F) Configure Inside Egress Access-List (Primary ASA)
    1. Bring up the customer’s PIX Internet FW Cluster CLI config
    2. You should be still Telnet’d into the Primary ASA
    3. All that the customer filters outbound is SMTP (TCP Port 25) from the Mail Server
    4. Copy the “conduit” or “access-list commands” into notepad
    5. In notepad rename the “conduit” or ACL name to “inside_access_out”
    6. It should permit the mail server IP first, and secondly, deny “tcp any any eq 25”, and third, permit ip any any
    7. Copy the new ACL into the Primary ASA
    8. Bind the ACL to the “inside” interface by way of “access-group inside_access_out in interface inside”

    G) Configure IPSec for Remote-Access VPN and LAN2LAN VPNs (Primary ASA)
    1. Bring up the customer’s PIX Internet FW Cluster CLI config
    2. You should be still Telnet’d into the Primary ASA
    3. Copy & Paste the following configuration into the Primary ASA
    crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
    crypto ipsec transform-set ESP-AES-192-SHA esp-aes-192 esp-sha-hmac
    crypto ipsec transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac
    crypto ipsec transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac
    crypto ipsec transform-set ESP-AES-192-MD5 esp-aes-192 esp-md5-hmac
    crypto ipsec transform-set ESP-AES-128-MD5 esp-aes esp-md5-hmac
    crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
    crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
    (note: the above transform-sets can be paired down to be very specific. This is
    an example of all the phase 2 encryption parameters that will be accepted.)
    crypto ipsec security-association lifetime seconds 28800
    crypto ipsec security-association lifetime kilobytes 4608000
    crypto dynamic-map dmap 1 set transform-set ESP-AES-256-SHA ESP-AES-192-SHA ESP-AES-128-SHA ESP-AES-256-MD5 ESP-AES-192-MD5 ESP-AES-128-MD5 ESP-3DES-SHA ESP-3DES-MD5 (note: this line is wrapped twice)
    crypto dynamic-map dmap 1 set security-association lifetime seconds 28800
    crypto dynamic-map dmap 1 set security-association lifetime kilobytes 4608000
    crypto dynamic-map dmap 1 set reverse-route
    crypto map cmap 1 ipsec-isakmp dynamic dmap
    crypto map cmap interface outside
    crypto isakmp identity address
    crypto isakmp enable outside
    crypto isakmp policy 1
    authentication pre-share
    encryption 3des (note: can replace “3des” with “aes”)
    hash sha
    group 2 (note: group “2” can be replaced with a higher group such as “5”)
    lifetime 86400

    H) Configure Split-Tunnel Access Lists (Primary ASA)
    1. Bring up the customer’s PIX Internet FW Cluster CLI config
    2. You should be still Telnet’d into the Primary ASA
    3. Find all the split tunnel network access-lists that need to be accessible by remote-access users for IPSec and SSL VPN. The name “access-list with split-tunnel in the name is a dead giveaway”. If remote-access software VPNs (IPSec/SSL AnyConnect) are the same, it would be recommended to copy the entire ACL into “UltraEdit”
    4. UltraEdit is a text editor on steroids, and it’s “ruler” feature is extremely useful for making inline edits. For example sake, this is original name of some of the ACEs in the ACL. This ACL can be very long, but only 5 ACE entries are included below:
    access-list Split-Tunnel-ACL standard permit 10.1.1.0 255.255.255.0
    access-list Split-Tunnel-ACL standard permit 10.1.2.0 255.255.255.0
    access-list Split-Tunnel-ACL standard permit 10.1.3.0 255.255.255.0
    access-list Split-Tunnel-ACL standard permit 10.1.4.0 255.255.255.0
    With UltraEdit, use the “ruler” feature to select “Split-Tunnel-ACL” and change it to
    “ST”. This will keep the new ruleset “very clean”. Here’s the modified example below.
    access-list ST standard permit 10.1.1.0 255.255.255.0
    access-list ST standard permit 10.1.2.0 255.255.255.0
    access-list ST standard permit 10.1.3.0 255.255.255.0
    access-list ST standard permit 10.1.4.0 255.255.255.0
    Note: Split-Tunnel Access-lists should be defined as Class C subnets, using standard
    ACLs and not extended ACLs.

    I) Configure NAT Exemption Access Lists and Tunnel-Groups and Group-Policies for VPN Users (Primary ASA)
    1. NAT exemption must be configured for each Split Tunnel network. The reason for this is that VPN Client traffic that is destined for corporate internal networks requires return traffic to be no-nat’d, or nat-exempt, so that it doesn’t get NAT’d on the “outside” interface. NAT exemption uses the following syntax to configure it: nat (inside) 0 access-list [ACL_NAME_FOR_NAT_EXEMPT_SUBNETS]
    I prefer to use the following for the definition and for the ACL name:
    nat (inside) 0 access-list inside_nat0
    2. Add all Split Tunnel networks using the following format:
    access-list inside_nat0 extended permit ip any 10.1.1.0 255.255.255.0
    access-list inside_nat0 extended permit ip any 10.1.2.0 255.255.255.0
    Note: all nat exemption ACLs must be entered as Extended ACLs, not Standard ACLs
    3. Configure NAT exemption for all internal networks that need to be accessed by LAN2LAN VPNs in the form of SRC NET being corporate to DST NET being remote subnets. Configure 1 way access lists for remote access users so the SRC is ANY and the DST is reflective of the Split-Tunnel networks that need to be accessed.
    4. Configure L2L tunnel-groups for remote sites
    5. Configure tunnel-groups and group-policies for Remote Access
    6. Configure IP Pool(s) for each remote access group

    J) Configure Remaining functions (Primary ASA)
    1. This includes any remaining parameters that are left that don’t fall under a specific category
    2. set login banner (create a generic one if none exists)
    banner login To protect the system from unauthorized use and to insure that the system
    banner login is functioning properly, system administrators monitor this system.
    banner login Individuals using this system without authority, or in excess of their
    banner login authority, are subject to having all of their activities on this system
    banner login monitored and recorded by system personnel. In the course of monitoring
    banner login individuals improperly using this system, or in the course of system
    banner login maintenance, the activities of authorized users may also be monitored.
    banner login Anyone using this system expressly consents to such monitoring and is
    banner login advised that if such monitoring reveals possible evidence of criminal
    banner login activity, system personnel may provide the evidence of such monitoring to
    banner login law enforcement officials.
    3. set clock appropriately for the timezone
    4. set ntp server (if necessary)
    5. configure logging host to syslog server (if one exists)
    6. set dns
    7. set hairpinning configuration
    same-security-traffic permit inter-interface
    same-security-traffic permit intra-interface

    K) Configure Active/Standby Failover
    Note: Failover should be the last preparatory configuration that is performed.
    1. Primary and Standby IP addresses should be configured on the Primary ASA as follows:
    interface GigabitEthernet0/0
    nameif outside
    security-level 0
    ip address N.N.N.N 255.255.255.0 standby N.N.N.N
    !
    interface GigabitEthernet0/1
    nameif dmz
    security-level 50
    ip address N.N.N.N 255.255.255.0 standby N.N.N.N
    !
    interface GigabitEthernet0/2
    nameif inside
    security-level 100
    ip address N.N.N.N 255.255.255.0 standby N.N.N.N
    Note: the standby IPs are not used, and only serve the purpose for failover and state synchronization.
    2. Configure failover (Primary ASA)
    failover
    failover lan unit primary
    failover lan interface state_failover GigabitEthernet0/3
    failover key *****
    failover replication http
    failover link state_failover GigabitEthernet0/3
    failover interface ip state_failover 1.1.1.1 255.255.255.252 standby 1.1.1.2
    Note: Use the failover configuration above for the Primary ASA in the Internet Cluster. Make note of the “lan unit primary”, the interface used for failover, in this case G0/3 should have a lateral cable link to the Standby ASA. Choose a key “XXXX” for the failover cluster and make note of it. Also, configure IP addresses with a /30 subnet mask and use IPs that are not used elsewhere on the network.
    3. Configure failover (Standby ASA) – Use the exact same commands as was done on the Primary ASA, using the same key. The only command that changes is “failover lan unit secondary”. Now, boot the Standby ASA, and the Primary ASA should say “replicating configuration to mate”. Perform a backup before of everything configured on the Primary ASA. One of the things that can occur if not done correctly is if the Secondary/Standby ASA failover is not configured right, it will copy and overwrite a non-existent firewall policy onto the Primary ASA. Specifying the “failover lan unit secondary” ensures that this won’t happen. The ASA Internet FW Cluster is now finished its pre-configuration.

    K) Perform Proof-of-Concept Testing (if necessary)
    Note: Depending upon the Firewall Engineer’s experience and confidence with any given Firewall Migration plan, POC testing should be performed for any functions in which there is any uncertainty (i.e. implementing new features that have never been done before, very complex configurations should be tested in a lab). In this particular case, POC testing does not need to be configured since this is a pretty vanilla cutover installation.

    Extranet ASA FW Cluster (Off-Site Pre-Configuration)
    WBS Element Code Estimated Hours WBS Element Name
    A 0.5 Configure Primary & Standby Interfaces (Primary ASA)
    B 0.5 Configure Passwords & Enable Inband Access (Telnet/SSH) and enable ASDM (Primary ASA)
    C 3.5 Turn off NAT-Control, Modify PIX NAT Configuration (Primary ASA)
    D 0.5 Configure Routing (Primary ASA)
    E 4-5 Configure Ingress and Egress Access-Lists (Primary ASA)
    F 0.5 Configure Remaining functions (Primary ASA)
    G 1 Configure Active/Standby Failover
    H 0 Perform Proof-of-Concept (POC) Testing
    (if necessary)

    A) Configure Primary & Standby Interfaces (Primary ASA)
    1. Bring up the customer’s PIX Extranet FW Cluster CLI config
    2. Console into the Extranet Cluster Primary ASA
    3. Assign Primary and Standby IP addresses to GigabitEthernet0/0, GigabitEthernet0/1, and GigabitEthernet0/2 per the addresses per the PIX config
    4. Assign Security Levels – 0 for outside, 100 for inside, and 50 for dmz
    5. issue the “nameif” command within interface mode to name “outside”, and “inside” addresses
    6. issue “no shut” on all interfaces within interface mode
    7. perform a “show ip” and verify the IP address assignments are correct
    8. Console into the Extranet Cluster Secondary ASA
    9. Repeat Steps #2 through #7

    B) Configure Passwords & Enable Inband Access (Telnet/SSH) and enable ASDM (Primary ASA)
    1. Console into the Internet Cluster Primary ASA
    2. Configure “passwd” and “enable passwords” to “cisco” for temporary assignment
    enter the following commands:
    username cisco password cisco
    aaa authentication enable console LOCAL
    aaa authentication http console LOCAL
    aaa authentication ssh console LOCAL
    aaa authentication telnet console LOCAL
    http server enable
    http 0 0 inside
    telnet 0 0 inside
    ssh 0 0 outside
    ssh 0 0 inside
    management-access inside

    C) Turn off NAT-Control, Modify PIX NAT Configuration (Primary ASA)
    1. If a FW cluster does not sit on an Internet edge, as this specific Extranet FW Cluster does not, the ASA has a feature called “nat-control”, which is a hidden command. By default, nat-control is on. If you are not performing NAT, it is best practice to turn it off. On the Extranet FW Cluster, perform the command “(config)#no nat-control”.
    2. Once NAT is turned off, any static identity nats “(inside,outside) X.X.X.X Y.Y.Y.Y netmask 255.255.255.255 can be removed”
    3. Keep track of the newly modified configuration in a notepad text file and make sure it’s saved to a file.

    D) Configure Routing (Primary ASA)
    Bring up the customer’s PIX Extranet FW Cluster CLI config
    Make sure you have Telnet inband connectivity to the Primary ASA
    Configure the static default route first, from the PIX Extranet FW configuration
    Configure all the static routes used to reach partner destinations, and inside destinations (all routes statements should remain the same and be prefixed by “route inside *” and “route outside *”. Expect there to be a high number of static routes considering the network diagram that shows a number of partner sites, in which each partner may have a number of static routes in and of itself.

    E) Configure Ingress and Egress Access-Lists (Primary ASA)
    1. If the “outside_access_in” and the “inside_access_out” ACLs are named differently, consider renaming them, and leverage notepad CTRL+H (replace) or UltraEdit to make these changes.
    2. Paste in the Ingress ACLs first (via an inband telnet session). Paste in about 100 lines at a time, until finished.
    3. Paste in the Egress ACLs second (via an inband telnet session). Paste in about 100 lines at a time, until finished.

    F) Configure Remaining functions (Primary ASA)
    8. This includes any remaining parameters that are left that don’t fall under a specific category
    9. set login banner (create a generic one if none exists)
    banner login To protect the system from unauthorized use and to insure that the system
    banner login is functioning properly, system administrators monitor this system.
    banner login Individuals using this system without authority, or in excess of their
    banner login authority, are subject to having all of their activities on this system
    banner login monitored and recorded by system personnel. In the course of monitoring
    banner login individuals improperly using this system, or in the course of system
    banner login maintenance, the activities of authorized users may also be monitored.
    banner login Anyone using this system expressly consents to such monitoring and is
    banner login advised that if such monitoring reveals possible evidence of criminal
    banner login activity, system personnel may provide the evidence of such monitoring to
    banner login law enforcement officials.
    10. set clock appropriately for the timezone
    11. set ntp server (if necessary)
    12. configure logging host to syslog server (if one exists)
    13. set dns
    14. set hairpinning configuration
    same-security-traffic permit inter-interface
    same-security-traffic permit intra-interface

    G) Configure Active/Standby Failover
    Note: Failover should be the last preparatory configuration that is performed.
    4. Primary and Standby IP addresses should be configured on the Primary ASA as follows:
    interface GigabitEthernet0/0
    nameif outside
    security-level 0
    ip address N.N.N.N 255.255.255.0 standby N.N.N.N
    !
    interface GigabitEthernet0/1
    nameif dmz
    security-level 50
    ip address N.N.N.N 255.255.255.0 standby N.N.N.N
    !
    interface GigabitEthernet0/2
    nameif inside
    security-level 100
    ip address N.N.N.N 255.255.255.0 standby N.N.N.N
    Note: the standby IPs are not used, and only serve the purpose for failover and state synchronization.
    5. Configure failover (Primary ASA)
    failover
    failover lan unit primary
    failover lan interface state_failover GigabitEthernet0/3
    failover key *****
    failover replication http
    failover link state_failover GigabitEthernet0/3
    failover interface ip state_failover 1.1.1.1 255.255.255.252 standby 1.1.1.2
    Note: Use the failover configuration above for the Primary ASA in the Extranet Cluster. Make note of the “lan unit primary”, the interface used for failover, in this case G0/3 should have a lateral cable link to the Standby ASA. Choose a key “XXXX” for the failover cluster and make note of it. Also, configure IP addresses with a /30 subnet mask and use IPs that are not used elsewhere on the network.
    6. Configure failover (Standby ASA) – Use the exact same commands as was done on the Primary ASA, using the same key. The only command that changes is “failover lan unit secondary”. Now, boot the Standby ASA, and the Primary ASA should say “replicating configuration to mate”. Perform a backup before of everything configured on the Primary ASA. One of the things that can occur if not done correctly is if the Secondary/Standby ASA failover is not configured right, it will copy and overwrite a non-existent firewall policy onto the Primary ASA. Specifying the “failover lan unit secondary” ensures that this won’t happen. The ASA Extranet FW Cluster is now finished its pre-configuration.

    H) Perform Proof-of-Concept Testing (if necessary)
    Note: Depending upon the Firewall Engineer’s experience and confidence with any given Firewall Migration plan, POC testing should be performed for any functions in which there is any uncertainty (i.e. implementing new features that have never been done before, very complex configurations should be tested in a lab). In this particular case, POC testing does not need to be configured since this is a pretty vanilla cutover installation.

    Once satisfied with pre-configuration, re-package and ship all four (4) ASAs to the customer installation site.

    Additionally, create a pre-configuration checklist based upon the WBSs performed above. Make multiple copies, enough for all customer stakeholders as well as the PM, AM, and Firewall Engineer.

    On-Site Activities

    Scheduling & Resources

    The Firewall Engineer should arrive onsite and meet with all customer stakeholders. Make a note of all names, titles, responsibilities, and phone and email contact information. It may be appropriate to dress business causal on the first day, and check with the lead customer POC to see what dress code is required. Typically, working in data centers, the dress is usually causal. Also, when working with system and network owners, it’s best project management practice to dress as they do, not more (i.e. wearing a tie), and not less (if they are wearing slacks you should not wear jeans).

    Gantt Chart

    The following Gantt Chart has been created to define onsite activities, and specifically the preparation, staging, and cutovers.

    Gantt Ordered Tasks

    Gantt Timeline

    3. Executing

    The execution phase has been clearly defined in the Gantt Chart, and should be carried out as such. Note that slack/float time may be accounted for per customer sign-off. Each task is dependent upon the previous task. Minimal slack/float time can likely be accounted for, which allocates time to handle risk. During such cutovers, beginning with the Internet Cluster, rollback abilities are possible almost instantaneously, due to the design and cutover plan. If a rollback is necessary, power off the new ASA appliances, and power on the PIXs. The staging of VLANs makes this possible, however, rollback is the worst type of disaster for a firewall project. Note that all interface connections *must* be cut over at once, and not one at a time. This example here is pretty vanilla in design and assumes that both Internet and Extranet Firewall Clusters can be cutover one right after the other. However, should there be some issue where all remote site functionality is not working, it is recommended that the Firewall Engineer first troubleshoots the problem as fully as can be. When all testing has failed, immediately open a TAC Case, and pre-register this contract number beforehand. TAC can assist in risk mitigation by transferring the risk to Cisco TAC.

    Also, the scheduling shows that at 12am all should be finalized. However, The Internet Cluster should be cut over first. If the customer resources agree to a slack/float time allocation, and can work past 12am, then by all means work up until 2am in the morning at the latest, or however late the customer network administrators can accommodate. If only the Internet Cluster can be successfully cutover in time, then schedule the next maintenance window for Wednesday, the day after as early as possible (for the Extranet Cutover). There should be a contingency reserve (slack/float day) built into the risk management plan, and communicated and agreed to by both parties.

    4. Monitoring and Controlling

    Since this project is not that complicated, short in duration, and contains two major pieces (the Internet FW Cluster, and the Extranet FW Cluster), monitoring progress should be quite easy to do. The Gantt chart is very accurate and somewhat aggressive. It is important to develop a risk management plan that contains the following:

    Risk Avoidance

    Risk can totally averted by rolling back to the PIX cluster and troubleshooting why the new configuration did not work. When the issue(s) is/are isolated, the team can try cutting over again.

    Risk Transfer/Mitigation

    Risk transfer in this project is taking a non-working function on a new ASA Cluster, and opening a TAC Case with Cisco, and letting a TAC engineer observe and help resolve the problem.

    Schedule Risk

    If it is not possible to cutover 2 FW Clusters in one night, there should be 1 day of slack/float time allocated to the project in case of risk. This allows for 1 full afternoon of planning and a late evening into the night to cutover a single FW Cluster. If monitoring the technical performance and associating scheduling risks, it may be necessary to use the next day as a slack day to cutover the second FW Cluster.

    Customer Training

    If the first maintenance cutover window goes to far and it can be seen that there is not enough time left to begin cutting over the second firewall cluster, plan for the slack day, and use the daytime to assist the customer as much as possible with the first ASA cutover, and ensuring they have all the tools necessary, and make sure that they are comfortable with managing the new ASA Internet FW Cluster while waiting for the next cutover maintenance window. This way, schedule risk can be mitigated by training the customer beforehand, rather than after the fact. There are different ways to juggle the tasks, but always understand the customer priorities, and make sure they are in agreement with the entire plan, with risk contingencies, before executing the project.

    5. Closing

    After the project has been completed, verify that the scope of work has been fully completed per the customer’s satisfaction. Ensure that the customer understands their new network security architecture, and how to manage it going forward. Adequate training should have been provided, and any questions the customer stakeholders have should be answered. Once the scope of work has been completed, the customer should sign-off on an Acceptance Form provided by the Firewall Engineer or PM that indicates that each scope of work activity and milestone was met and completed satisfactorily. It may be the case that there are subtleties, or attempted scope creep that was not part of this scope of work, and requires further work. Ensure that this is addressed, and that this can be planned for a later date, following a new SOW that is negotiated by both parties. In a perfect world, everything should work as planned, and the project can be closed.

    Lessons Learned

    This is a very important section that applies to the seller or provider, and not the customer. During project execution, in the Monitoring and Controlling section, it can clearly be told how the project went. If all went well according to plan, it can be said that the project was accurately assessed. If both Firewall Clusters could not be cutover during a single maintenance window, and the Extranet FW Cluster had to wait until the next evening maintenance window, and the slack/float time was implemented, from an engineering perspective, and PM perspective, it needs to be told why the slack/float day had to be implemented. Was it purely a technical deficiency on the end of the seller that resulted in much added troubleshooting. Did the customer not provide adequate information, and there were scope items part of the critical path that were not taken into account? Or were their customer related issues, such as the customer having logistical problems, such as late night access, poor communication, unrealistic expectations, etc. In every single project, there are lessons to be learned. The idea here is to understand specifically what did not go according to plan and can it be prevented in the future. SOWs need to be written to detail, and to avoid any such problems that could arise, and be preventative in nature. If the project was underscoped, take this into account for future Firewall Projects, so that they can be more accurately assessed going forward, and prevent any such issues that did arise during this project, and try and avoid and prevent them in future work. Most Firewall migration projects, and IT technical projects almost never 100% going according to plan. It’s important to learn from each and every project how you can fine tune and better improve your planning initiatives, as well as risk management initiatives seen during the monitoring and controlling phase of the project.

    APPENDIX A – The Benefits of Cisco ASA 5500 Series

    Reasons to Upgrade

    ? Potential Trade-in Allowance
    ? Eliminate all Firewall Related Single-Points-of-Failure
    ? Take advantage of new Hardware Converged Service Modules & New Software Features
    ? Take advantage of reduced SMARTnet costs
    ? Take advantage of new Firewall code and future code releases
    ? Take advantage of the Cisco ASA roadmap for further code releases, feature enrichment, and longevity (extending EOL and EOS dates)

All Comments

Viewing 0 reply threads