In this Authorized Cisco course, you will take your knowledge and skills on configuring, maintaining, and operating Cisco ASA 5500 Series Adaptive Security Appliance to the next level. Recommended training for the Cisco Certified Security Professional (CCSP) certification, SNAA takes over where SNAF leaves off, covering advanced topics of the Adaptive Security Appliance.
Labs
Our investment in enhanced and exclusive lab content means you get the experience you need using current software and hardware. No other training company offers a unique, real-world lab solution like ours.
In our lab descriptions, an enhanced lab exercise contains a significant addition to the standard labs and may or may not be offered by other providers, while an exclusive lab exercise contains material that is not offered by any other provider.
We provide an unparalleled lab infrastructure for CCSP-oriented courses. For SNAA, each pod has a 2811 router, a 3560 switch, an ASA 5520 with an AIP-SSM (IPS) module, an ASA 5505, a VMware Server with ten VM systems, and an 1841 router that simulates the Internet environment. These devices are organized in a real-world fashion and are configured to work together to provide a complete security solution. The ten PCs are strategically placed in the topology to provide interesting and realistic functional demonstrations. For example, the Admin PC is treated as the Security Administrator's office desktop PC. Management connections to the ASA, including SSH to the CLI and HTTPS to ASDM, are performed from the Admin PC. The Data Server is an Active Directory Domain Controller. Included in its duties are user and group management, DNS, e-mail, and Certificate Authority services. The Security Server runs security applications such as Cisco Secure Access Control Server and the PHP Kiwi Syslog system. The DMZ server is partially exposed to the Internet and provides HTTP, FTP, DNS, and SMTP services. The Outside PC is connected to the simulated Internet and can be used as an external web/FTP server, the source of inbound connections to the DMZ server, an attack source, or as a trusted VPN client, depending on the current scenario. The Services-R-Us server acts as a public DNS, e-mail, web/FTP, and certificate server. The BackTrack2 PC is a Linux system with hundreds of security tools installed, the User PC is another internal PC system, the Site1 PC is connected to a small remote network, and the Site2 PC is connected to another small remote network behind the ASA 5505.
The SNAA courseware and Cisco's standard SNAA labs focus mainly on the ASDM GUI. Our SNAA labs also demonstrate the use of ASDM and pay respect to the CLI as well. For all operations completed using the GUI, the corresponding CLI commands are always displayed in our SNAA lab guide. Also, the full, final configuration is displayed at the end of each lab with the configuration commands that were entered during the lab highlighted. This helps to make our lab guide a valuable reference long after you have completed the lab exercises.
Lab 1: Advanced NAT
In this lab you will work with various advanced NAT configurations. You will begin by verifying the basic pre-existing NAT setup. From there you will work with the DNS keyword in static NAT entries, and then set up Policy NAT for outbound as well as inbound communications. Lastly, you will set up net static NAT from the inside to the outside network. At each step along the way, you will test and verify the expected results.
- Verify Existing NAT Configuration
- Exclusive - Demonstrate the DNS keyword for a Static Command
- Configure Outbound Policy NAT
- Configure Inbound Policy NAT
- Exclusive - Configure Net-Static
- Verify the ASA Configuration
Lab 2: Modular Policy Framework: FTP and HTTP
In this lab you will work with Advanced Protocol Inspection for both FTP and HTTP, implementing two scenarios each. The first advanced FTP inspection scenario will mask the DMZ Server's FTP greeting banner and control which FTP commands are allowed to the DMZ server. The second advanced FTP inspection scenario is to defend against a buffer overflow attack by blocking change working directory requests where the directory specified is greater than a specified length. The first advanced HTTP inspection scenario will involve blocking internal hosts from accessing GIF files on external sites. The second HTTP inspection scenario will involve the detection of and blocking of a particular HTTP tunneling application.
- Advanced Inspection: FTP Command Enforcement
- Exclusive - Advanced Inspection: FTP Buffer Overflow Mitigation
- Advanced Inspection: HTTP Content Enforcement
- Exclusive - Advanced Inspection: HTTP Tunnel Detection and Block
- Verify the ASA Configuration
Lab 3: Dynamic Routing: EIGRP and OSPF
In this lab you will work with routing protocols on the ASA. At the start of the lab, as is quite common in firewalls on network perimeters, routes are configured statically. In this lab you will configure an OSPF-routed network on the outside, an EIGRP-routed network on the inside, and route redistribution between the two.
Note: The scenario presented in this lab is intended to demonstrate the function of dynamic routing protocols on the ASA. It's not to demonstrate optimal routing design within the lab topology.
- Configure Non-ASA Devices for EIGRP and OSPF
- Modify the ASA in preparation for Dynamic Routing
- Configure OSPF On The ASA
- Configure EIGRP On The ASA
- Verify the Results
- Enable Route Redistribution and Verify the Results
- Verify the ASA Configuration
Lab 4: Site-to-Site VPN with Digital Certificates
In this lab you will configure a Site-to-Site VPN using digital certificates for peer authentication. This will require enrolling the ASA with the Services-R-Us certificate authority (CA). You will see how to properly authenticate the CA, how to enroll with the CA via SCEP, how to issue the certificate from the CA, and how to verify enrollment success. The VPN peer is the Site1 router (simulated with a loopback interface on the Internet Router). It has already enrolled with the Services-R-Us CA and is configured to accept a connection from the ASA. You will use the IPsec VPN Wizard to configure the Site-to-Site VPN policy on the ASA. Once things are configured, you will verify tunnel operation and monitor the tunnel from both ASDM and the CLI.
- Examine Current SSL Identity Certificate
- Authenticate the External CA
- Enroll with the External CA via SCEP
- Configure Site-to-Site VPN
- Verify Site-to-Site VPN
- Verify the ASA Configuration
Lab 5: Remote Access VPN with Digital Certificates
As this lab starts, ASA has two identity certificates installed: One that is self-signed and used for SSL connections to ASDM, and a second from the Services-R-Us CA that is used for extra-net VPN connections. In this lab you will enroll the ASA with the internal CA residing on the Data Server. The intent is to use this certificate for Remote Access VPN. A twist on the enrollment methodology used is that you will perform a manual enrollment instead of a SCEP-based enrollment. SCEP-based enrollment is more convenient, but it requires direct connectivity between the appliance and the CA. If this is not available, manual enrollment must be used. Even though there is direct connectivity available between the ASA and the internal CA, you will use the manual method to demonstrate the process.
You will also install and configure the Cisco Easy VPN Client on the Outside PC. The client will also need to enroll with the internal CA. To facilitate this, you will create a Remote Access VPN tunnel group, which uses pre-shared keys and extended authentication to provide access to the internal CA. Using this tunnel, the VPN client will enroll with the internal CA. You will then create another tunnel group providing full internal access. This tunnel group will require an identity certificate and extended authentication. Once configured, you will verify its operation and monitor the sessions using ASDM and the CLI.
- Exclusive - Enroll the ASA with the Internal CA Server
- Configure a Tunnel Group for CA Access
- Install and Configure the Cisco Easy VPN Client
- Enroll the VPN Client with the Internal CA Server
- Configure a Tunnel Group for Full Network Access
- Exclusive - Enable Hub and Spoke VPN Connectivity
- Monitor Remote Access VPN Activity
- Verify the ASA Configuration
Lab 6: ASA 5505 Hardware Client
In this lab you will explore the use of a hardware-based VPN client. The ASA 5520 at the main site will be the VPN server, and the ASA 5505 at Site2 will be the hardware client. In keeping with the theme of SNAA VPN exercises, ISAKMP authentication will be performed with digital certificates. The ASA 5520 is already enrolled with the Services-R-Us CA. You will enroll the 5505 with the Services-R-Us CA. Once basic VPN connectivity has been established, you will experiment with using Network Extension Mode, a feature that can only be done with hardware-based clients. You will also explore the various authentication modes available with hardware client systems.
- Initial Configuration of Easy VPN Server
- Enroll the 5505 with the Services-R-Us CA
- Easy VPN Remote on the 5505
- Exclusive - Easy VPN Network Extension Mode
- Exclusive - Easy VPN Extended Authentication Options
- Verify the ASA Configuration
Lab 7: SSL VPN: Clientless and Thin Client
This lab focuses on truly clientless SSL VPN as well as thin client applications that require Java support in the client browser. Clientless SSL VPN works well for web-based applications and file access (FTP and Windows CIFS Shares). Providing arbitrary access to single channel TCP connections can be accomplished with Port Forwarding. Port Forwarding uses Java to open a port for listening on the client PC, and connections to that port on the local PC are forwarded through the SSL connection to the configured IP address and port on the protected network. Smart tunnels provide a similar capacity but may be more intuitive to the end users. With smart tunnels, specified applications have access to resources on the protected network via the SSL tunnel. Lastly, SSL VPN plug-ins push capabilities to the browser for certain application protocols. This will allow the browser itself to act as a client for supported applications. Each of these methods will be explored in this lab.
- Enable Basic Clientless SSL VPN Access
- Test Basic Clientless SSL VPN Access
- Exclusive - Implement and Test Port Forwarding
- Exclusive - Implement and Test Smart Tunnels
- Exclusive - Implement and Test SSL VPN Plug-Ins
- Verify the ASA Configuration
Lab 8: SSL VPN: AnyConnect Client
In this lab you will work with the AnyConnect client. You will first implement the AnyConnect client requiring only a username/password for authentication. You will perform both a manual install and a web launch of the AnyConnect client, and you will verify connectivity and monitor the AnyConnect connections. After accomplishing basic connectivity, you will migrate to requiring a digital certificate as well as username/password for authentication. You will prepare the Local CA Server on the ASA for this purpose. You will enroll the SSL user with the CA and install their certificate on the Outside PC. You will then verify connectivity and session status using digital certificates and username/password-based authentication.
- Local CA on the ASA
- Configure AnyConnect Client Support
- Enroll with the ASA Local CA
- Install the Stand Alone AnyConnect Client
- Configure and Verify the Web Launch AnyConnect Client
- Verify the ASA Configuration
Lab 9: Cisco Secure Desktop and Dynamic Access Policies
In this lab you will work with the Cisco Secure Desktop (CSD) and Dynamic Access Policies (DAP). Clientless and AnyConnect Client support is already configured on the ASA. You will start from this base configuration and require that SSL connections from non-trusted IP addresses (addresses outside those used by the Site1 partner) use CSD. You will explore the operations of CSD on the remote clients. You will then fine-tune the CSD configuration to look for a watermark on the client system. Both watermarked and non-watermarked clients from untrusted IP space will require the use of CSD, but the restrictions will be greater on the non-watermarked systems. You will finish with an exploration of DAP. Depending on even finer criteria, connectivity can be restricted or denied.
- Enable the Cisco Secure Desktop
- Configure Policies for the CSD
- Verify the Cisco Secure Desktop Operation
- Configure a Dynamic Access Policy
- Verify the DAP Operation
- Verify the ASA Configuration
Lab 10: The AIP-SSM
In this lab you will take an AIP-SSM from an unknown state to a working state. The first step will be to recover the AIP-SSM's operating image, which will return it to a factory default state. You will then perform the initial setup of the AIP-SSM. As you work with the AIP-SSM it will become apparent that it really is a Cisco IPS Sensor. It runs the same code and works the same way as the stand-alone 4200 series sensors do. There are just some extra hooks to let it work with the ASA. Its monitoring interfaces are connected to the backplane of the ASA, so you will have to configure the Modular Policy Framework to forward traffic to the sensor. You will configure the ASA to send all traffic passing through the DMZ interface to the AIP-SSM inline. Once things are configured, you will verify the IPS operation with a couple of scenarios. You will also tune a set of signatures to deny offending traffic in-line and demonstrate the results.
- Recover the AIP-SSM Image
- Initial Setup of the AIP-SSM
- AIP-SSM Management Connection Options
- Configure the ASA's MPF to use the AIP-SSM Inline
- Exclusive - Verify IPS Operation
- Exclusive - Tune a Signature and Verify the Result
- Verify the ASA and AIP-SSM Configurations
