Cisco
CCSP - Cisco Certified Security Professional
SNAA - Securing Networks with ASA Advanced
SNAA - Securing Networks with ASA Advanced
Duration: 5 days Cisco Course v1.0 | Cisco Security Appliance Software v8.0 | Prepares you for Cisco Exam 642-515 SNAA 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. We have added depth to the existing Cisco-developed hands-on labs for SNAA. Our advanced hands-on labs, delivered on an enhanced topology designed to simulate a typical production network, guide you through exercises such as managing digital certificates for IPSec and SSL VPNs, deep packet inspection, and using the 5505 in the SOHO environment. Our labs utilize ASA 5520 security appliances, though this course and lab content is applicable across the ASA and PIX families of security appliances. This course covers the features and syntax of Cisco Security Appliance Software v8.0. Note: The sections covering SSL VPN and the Security Services Modules are ASA-specific, as these features are not supported on the PIX firewall. E-Labs Included for Post-Class Lab Practice Following classroom instruction, you will receive 5 e-Lab credits for post-class lab practice, allowing you to hone your skills using the same hands-on lab equipment you used in the classroom.
1. Advanced ASA NAT
2. Advanced Protocol Handling
3. Dynamic Routing and Switching
4. IPsec VPNs
5. SSL VPNs
6. Security Services Modules
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
No details for the moment
|
||||||||
|
|
||||||||


