ASA Lab Guide

(1)

SMB Security - ASA v1.0

Lab Guide

L5698C-001-1 November 2008 by Global Knowledge

(2)

(3)

SNAF v1.0 Lab Guide

L5698C-001-1

(4)

The following publication, SNAF v1.0 Lab Guide, was developed by Global Knowledge Network. All rights reserved. No part of this publication may be reproduced or distributed in any form or by any means without the prior written permission of the copyright holder.

This courseware may contain images from Cisco Systems. All Cisco images are copyright Cisco Systems, Inc.

Products and company names are the trademarks, registered trademarks, and service marks of their respective owners. Throughout this manual, Global Knowledge has used its best efforts to distinguish proprietary trademarks from descriptive names by following the capitalization styles used by the manufacturer.

Global Knowledge Project Team Sunny Chan Project Coordinator Khor Hee Soo Product Manager Lee Kee Piao Development Manager

190 Middle Road

Fortune Centre, #20-02 Singapore Phone: +65 6332 2330

Email: [email protected]

(5)

SNAF v1.0 Lab Guide TOC-1 © Global Knowledge

INTERNET

Data-Srv 10.10.1.10 DMZ-Srv 172.16.1.15 NAT: 200.200.1.15 www.gkl.com Outside-PC 150.150.1.20 pc.outside.net .1 Perimeter Router Management Subnet 10.10.2.0/24 Security-Srv 10.10.2.10 Admin-PC 10.10.10.10

SNAF 1.0 Topology

.1

10.10.1.0/24 Data Center Subnet

10.20.10.0/24 200.200.20.2 Site1-PC 10.20.10.10 .1 L3-Switch GKL-ASA 10.10.10.0/24

End User Subnet

DMZ Subnet 172.16.1.0/24 Outside Perimeter 200.200.1.0/24 10.10.0.0/24 Inside Perimeter (13 (4) (3) (2) (7) (6) (5) (11 ) (10 ) 2K 2K3 2K XP 2K3 XP User-PC 10.10.10.20 XP Services-R-Us 50.50.50.50 www.sru.com

BackTrack2 (location & IP Varies)

BT2 .1 .1 .1 .2 50.50.50.0/24 .1 (16 ) 2K3 time.nist.gov 192.43.244.18 (Indicates VLAN #)

(8)

(9)

.2 .1 .1 .2 100.100.1.0/30 150.150.1.0/24 .1

INTERNET

Data-Srv 10.10.1.10 DMZ-Srv 172.16.1.15 NAT: 200.200.1.15 www.gkl.com Outside-PC 150.150.1.20 pc.outside.net .1 Perimeter Router Management Subnet 10.10.2.0/24 Security-Srv 10.10.2.10 Admin-PC 10.10.10.10

SNAF 1.0 Topology

.1

10.10.1.0/24 Data Center Subnet

10.20.10.0/24 200.200.20.2 Site1-PC 10.20.10.10 .1 L3-Switch GKL-ASA 10.10.10.0/24

End User Subnet

DMZ Subnet 172.16.1.0/24 Outside Perimeter 200.200.1.0/24 10.10.0.0/24 Inside Perimeter (13 (4) (3) (2) (7) (6) (5) (11 ) (10 ) 2K 2K3 2K XP 2K3 XP User-PC 10.10.10.20 XP Services-R-Us 50.50.50.50 www.sru.com

BackTrack2 (location & IP Varies)

BT2 .1 .1 .1 .2 50.50.50.0/24 .1 (16 ) 2K3 time.nist.gov 192.43.244.18 (Indicates VLAN #)

(10)

(11)

L0-1

L0

(12)

Lab Overview

The purpose of this lab is to introduce you to the features of the Global Knowledge Remote Labs system. A quick familiarization with the system will prepare you for the labs presented in this course.

Estimated Completion Time

20 minutes

Lab Procedures

1. Logging In

2. Controlling Your Pod 3. Using the Virtual Machines 4. Pseudo-Physical Device Access

(13)

L0-3

Logging In

Initial access to the Global Knowledge Remote Labs System is performed with a web browser connection to www.remotelabs.com.

1. On your local PC, open a web browser and connect to www.remotelabs.com.

2. Enter your credentials and click Log In.

3. The main remotelabs.com page displays several things:

x The title and topology display for the lab that is currently set up.

x The current date and time, and how much time is left on your reservation.

x Various control and help links, which will be highlighted in this lab.

Controlling Your Pod

One feature of the Global Knowledge Remote Labs System is the ability to reset your pod to the initial starting point for any of the labs for which your user id has privileges. You will be shown how to do this in this section of the lab.

4. To control your pod, expand the pod link, so the underlying options are displayed.

5. First, select the Information link. 5.1. The Pod Information window opens.

5.2. If there are any problems with your pod, this information must be provided to the Global Knowledge Helpdesk to identify the pod which is malfunctioning.

5.3. Close the Pod Information window. 6. Next, select the Setup Results link.

6.1. The Setup Results window will open.

6.2. It is expected that you will see the message “All setup activity for this reservation has been successful” highlighted in green. If you instead see a failure message highlighted in red, you should inform your instructor.

6.3. Close the Setup Results window. 7. Now, select the Reset To… link.

7.1. The Reset To… window opens.

7.2. Expand the Lab Document drop down menu. A list of all the labs for which your user id has privileges is displayed.

(14)

7.3. Don’t perform the operation now. Your pod should currently be prepared for either Lab 0 or Lab 1 of this class. Lab 0 and Lab 1 have identical reset settings, and are hence equivalent from a reset perspective. But understand, to reset to the starting point of any particular lab is as simple as selecting the lab from the Lab Document list and clicking the Reset button. When you do this, the reset operation will start. A progress indicator window will open. You must wait for the progress indicator to complete before accessing your pod. At the setup completion, a new Setup Results window will be displayed.

7.4. Click Cancel to close the Reset To… window.

Using the Virtual Machines

While control of the pod is performed from the remotelabs.com web page, the labs are performed from a VMware console. Like in most real world environments, administrators and users don’t usually interact directly with network devices. They use PC’s and workstations to access network devices and network services. You will use several virtual machine instances, placed strategically around the lab network topology, to complete the administration and testing of the lab scenarios.

8. Select a Graphical Firewall Method:

8.1. Expand the Graphical Firewall drop down list:

8.2. Select the appropriate option. In an instructor led class, unless your instructor provides other direction, RDP is the appropriate option.

A description of the 3 options available:

x RDP: This will use the native Remote Desktop Protocol. It will provide the

optimal user experience, but in some cases is blocked by firewalls between your location and the internet.

x RDP 443: This will still use the Remote Desktop Protocol, but it will connect to

TCP port 443 instead of the RDP standard TCP 3389. This will also provide an optimal user experience and may work where standard RDP does not. It will work when a stateful firewall permits TCP connections for HTTPS (TCP port 443). Note, it may not work if the firewall performs deep packet inspection or if a proxy server is in the network path. Both of these systems will recognize that it is not standard HTTPS.

x Tarantella: This option will work in most firewalled environments, even when

proxy servers are used. Tarantella will encapsulate the RDP connection within a standard HTTPS connection. If the other options fail, you should use this option. Tarantella is functional, but it is not as responsive as the two RDP methods above, hence the user experience is diminished.

(15)

L0-5

9. Connect to the VMware Server Console:

9.1. Click the PC-Console link. Depending on whether you are using Firefox or Internet Explorer, the behavior will be different.

x Internet Explorer: Internet Explorer will display the contents of an “rdp” file

which is a configuration file for the Remote Desktop Client. To launch the Remote Desktop Client, use File > Edit with Remote Desktop Connection.

x Firefox: Firefox will query whether you would like to open the file with the

default application or save it to disk. Firefox does not have a default application registered, so it will use whatever the base OS provides. With firefox, choose to Open with RDP.File (default).

9.2. Login to the Remote Desktop. The credentials are the same as the www.remotelabs.com

credentials.

10. Setup the VMware Server Console:

10.1. If the Inventory window is displayed, close it. It is not required when working

with the remote labs.

10.2. The VMware Console will be running in the Remote

Desktop Connection. However, none of the VMs will be open. Click the Open Existing Virtual Machine button.

10.3. A list of all the running virtual machines will be displayed. Select all of the VMs

by clicking the top VM in the list, then Shift-Clicking the last VM in the list. With all of the VM’s selected, click OK. The VMs should open one after the other, displaying a tab per VM at the top of the window.

(16)

10.5. The Remote Desktop Client window should now be optimized for use with the remote labs system:

x The VMware server’s menus should be hidden from view.

x Across the top of the window are a set of tabs from which the VMs can be

selected.

x The current VM’s tab is highlighted.

x The full desktop of the current VM is displayed (there should not be any

scrollbars to move around within the VM desktop).

x The display should look similar to the following diagram:

10.6. The VMware Console’s menus are hidden, but can still be accessed by hovering

the mouse pointer in the window’s title bar. Access the VMware Console menu and verify that the options Quick Switch, Autofit Guest and Tabs are all selected, and no other features under View are selected:

Warning One last note to be aware

of: Even though Autofit Guest is selected, sometimes the VMware console does not properly update the desktop of the VM to fit the console window. If this ever happens, select View > Fit Guest Now from the VMware console menu.

(17)

L0-7

11. Familiarize yourself with the VM desktops:

Note There are several ways to recognize which VM you are currently using. The highlighted tab at the top of the window is the most obvious. Also, the background color for each VM is unique. Most VM’s have identity information displayed in the center of their desktops. And, the Window’s based VMs have their “My Computer” icon renamed with the identity of the VM.

11.1. Select the Admin PC’s tab. The Admin PC’s desktop should be displayed. The

majority of the lab work will be done from the Admin PC. Think of it as the PC the network administrator has in their office. For efficiency, the most commonly used applications are included on the Windows quick launch bar. They are similar between VM’s. The Admin PC’s quick launch bar is illustrated for an example:

11.2. From left to right, the icons on the quick launch bar are for:

x Show Desktop

x Outlook Express (Email Client)

x Windows Command Prompt

x Windows Explorer

x Word Pad

x PuTTY (SSH Client)

x Internet Explorer

x Firefox

11.3. One other common item worthy of pointing out is the 3C Daemon. Many of the

VMs use the 3C Daemon as a Syslog Server, FTP Server and TFTP Server. When the 3C Daemon is operational, it’s icon shows up in the Windows status tray.

A common mistake in the lab environment, after using the 3C Daemon, is to close the 3C Daemon window. If you close the 3C Daemon window, you terminate the

application. Future steps which require the 3C Daemon’s services will fail. The correct operation is to minimize the 3C Daemon window. This will minimize it to the Windows status tray. If it is accidentally terminated, it can be restarted from the Window’s start bar.

(18)

Pseudo-Physical Device Access

While it is most common for network administrators to use protocols like SSH and HTTPS to administer devices remotely, there are times when physical access is necessary. When a device is unconfigured, it doesn’t have any IP addresses to accept connections. When a device has a problem with flash, it can’t load it’s operating system. When passwords are lost, password recovery requires power cycling the device. When you need direct access to a device’s console port or when you need to power cycle a device, you must use the Access PC.

12. Go to the desktop of the Access PC.

13. If necessary, launch Internet Explorer. If necessary, log in using your remotelabs.com credentials.

14. A different version of the remotelabs.com interface is displayed.

14.1. This time, instead of offering Graphical Firewall settings, it offers Character

Firewall settings. From the Access PC, this should always be set to Standard. Do not change it.

14.2. The Pod link is still available, but it does not offer the Reset To… option. This is

only available on the external remotelabs.com interface.

14.3. Below the Pod link, there are a series of links associated with different devices

such as the L3-Switch, Perim-Rtr and Internet-Rtr. The list of devices varies between classes.

15. For a demonstration, expand the Internet-Rtr link:

15.1. Five options are available for each device. They are:

x HyperTerminal – this will open a HyperTerminal window, connecting to the

device’s console port using a remotelabs.com access server.

x Default Telnet – This will open a Tera Term Pro window, connecting to the

device’s console port using a remotelabs.com access server.

x Power Off – This will power off the associated device.

x Power On – This will power on the associated device.

x Clear Line – If the Default Telnet and HyperTerminal options are not working,

it is likely that the remotelabs.com access server believes the line to the console port is already in use. Use clear line to reset the line and make it available for use.

(19)

L0-9

15.2. Connect to the console port of the Internet Router:

15.2.1.Click the Default Telnet link. A Tera Term window opens.

15.2.2.You are challenged for a password. At this point, you are not yet authenticating to the Internet Router’s console port. You are authenticating to the remotelabs.com access server. Enter your remotelabs.com password (the user ID is not required). 15.2.3.If the password was accepted, you are now connected to the Internet Router’s

console port. Hit <Enter> to stimulate the console line.

15.2.4.To log in to the Internet router, use admin for the username and admin$Pwd for the password.

15.3. Demonstrate that you are connected to the console port of the Internet Router.

15.3.1.Enter the command show users. InternetRouter>show users

Line User Host(s) Idle Location * 0 con 0 admin idle 00:00:00

Interface User Mode Idle Peer Address

Note The line to which you are connected is con 0.

15.3.2.From the remotelabs.com interface, under Internet-Rtr, select Power Off, and click OK to confirm you wish to power off the device.

15.3.3.Return to the Tera Term window. Try hitting <Enter> a few times. You will get no response. The Internet Router has been powered off.

15.3.4.From the remotelabs.com interface, under Internet-Rtr, select Power On. No confirmation is necessary.

15.3.5.Return to the Tera Term window. You will be able to watch the Power On Self Test messages as the Internet Router boots.

16. You do not have to wait for the Internet Router to fully boot. Close the Tera Term window, and move on to Lab 1. The Internet Router should be rebooted before it is required in Lab 1.

(20)

(21)

L1-1

L1

(22)

Lab Overview

The goal of this lab is to prepare the ASA for remote administration, by both SSH and HTTPS/ASDM. You will find the ASA currently has an unusable configuration. You will have to access it via its physical console port and reset the configuration back to factory defaults. You will then use the setup dialog to configure the inside interface and enable ASDM access via HTTP. You will also enable SSH from the CLI. You will then test SSH access from the Admin PC. You will also install and configure ASDM on the Admin PC and test initial access with ASDM.

Estimated Completion Time

30 minutes

Lab Procedures

1. Access the ASA Console Port 2. Clearing an Existing Configuration 3. Taking Inventory of the ASA 4. The Setup Dialog

5. Enable SSH 6. Setup ASDM

(23)

L1-3

Access the ASA Console Port

Currently the ASA has a tiny, dysfunctional configuration. There is no way to manage it across the network. Much of this lab will need to be completed from the ASA’s physical console port. Use the Access PC and the remotelabs.com interface to connect to the ASA’s console port. 1. Use the Access-PC to reach the remotelabs.com interface for access to the ASA’s console

port:

1.1. Go to the desktop of the Access-PC.

1.2. If necessary, launch Internet Explorer and connect to www.remotelabs.com and log in

using your remotelabs.com credentials.

1.3. In the remotelabs.com interface, expand the ASA link and select Default Telnet. A Tera Term Pro window opens. (If you prefer HyperTerminal over Tera Term Pro, you could instead select HyperTerminal.)

1.4. The password challenge will be from the remotelabs.com access server, not the ASA. Enter your remotelabs.com password to access the ASA console port.

1.5. After authenticating to the access server, hit enter to stimulate the console port. You should see TempConfig> as the prompt.

Clearing an Existing Configuration

At this point in the lab, the ASA is almost in a default configuration. Only two things are configured: A hostname (TempConfig), and an enable password (san-fran). In this section of the lab you will experiment with two ways of setting an ASA configuration back to factory default. The first is to use the clear configure all command. You will see that this clears most of the configuration. It leaves the enable password intact. The second method is by erasing the startup configuration (write erase), and rebooting the ASA (reload). This takes a little longer, but it guarantees that the configuration is truly factory default.

2. Establish yourself in privileged mode with the enable command, using the password san-fran. Then move on to configuration mode with the configure terminal command (abbreviated here as conf t):

TempConfig> enable

Password: san-fran

TempConfig# conf t

TempConfig(config)#

3. Use the clear configure all command to reset the configuration almost to factory default.

TempConfig(config)# clear config all

ciscoasa(config)#

Note The hostname has returned to the default of ciscoasa, as evidenced by the new command prompt.

(24)

4. Demonstrate that the enable password was not reset by the clear configure all command. Leave configuration mode and privileged mode, and then attempt re-entry. It will require the old enable password to reach privileged mode:

ciscoasa(config)# exit

ciscoasa# disable

ciscoasa> enable

Password: <Attempt just hitting Enter>

Invalid password Password: san-fran

ciscoasa#

5. Use the write erase command to clear the startup configuration from flash:

ciscoasa# write erase

Erase configuration in flash memory? [confirm] <Enter>

[OK]

6. Reboot the ASA with the reload command. DO NOT save the modified configuration (the whole point is to boot with a blank configuration)!:

ciscoasa# reload

System config has been modified. Save? [Y]es/[N]o: n

Proceed with reload? [confirm] <Enter>

7. After the reload finishes, there is no startup configuration, so the ASA offers to run the setup configuration dialog. You will run the setup dialog later, for now you should answer no. If you accidentally hit enter and the setup dialog has started, you can use <Ctrl-Z> to terminate the dialog.

Pre-configure Firewall now through interactive prompts [yes]? no

Type help or '?' for a list of available commands. ciscoasa>

Taking Inventory of the ASA

In this section of the lab you will use some simple show commands to determine the characteristics of the ASA that you are using.

8. The show version command shows much more than the OS version. Use the show version command and answer the questions that follow the example:

ciscoasa> show version

Cisco Adaptive Security Appliance Software Version 8.0(2) Device Manager Version 6.0(2)

Compiled on Fri 15-Jun-07 19:29 by builders System image file is "disk0:/asa802-k8.bin" Config file at boot was "startup-config" ciscoasa up 2 mins 9 secs

(25)

L1-5 © Global Knowledge Training LLC

Hardware: ASA5520, 512 MB RAM, CPU Pentium 4 Celeron 2000 MHz Internal ATA Compact Flash, 256MB

BIOS Flash AT49LW080 @ 0xffe00000, 1024KB

Encryption hardware device : Cisco ASA-55x0 on-board accelerator (revision 0x0)

Boot microcode : CN1000-MC-BOOT-2.00 SSL/IKE microcode: CNLite-MC-SSLm-PLUS-2.01

IPSec microcode : CNlite-MC-IPSECm-MAIN-2.04

0: Ext: GigabitEthernet0/0 : address is 0018.195b.d7dc, irq 9 1: Ext: GigabitEthernet0/1 : address is 0018.195b.d7dd, irq 9 2: Ext: GigabitEthernet0/2 : address is 0018.195b.d7de, irq 9 3: Ext: GigabitEthernet0/3 : address is 0018.195b.d7df, irq 9 4: Ext: Management0/0 : address is 0018.195b.d7e0, irq 11 5: Int: Internal-Data0/0 : address is 0000.0001.0002, irq 11 6: Int: Internal-Control0/0 : address is 0000.0001.0001, irq 5 Licensed features for this platform:

Maximum Physical Interfaces : Unlimited Maximum VLANs : 150 Inside Hosts : Unlimited Failover : Active/Active VPN-DES : Enabled VPN-3DES-AES : Enabled Security Contexts : 2 GTP/GPRS : Disabled VPN Peers : 750 WebVPN Peers : 2

Advanced Endpoint Assessment : Disabled

This platform has an ASA 5520 VPN Plus license. Serial Number: JMX1032K00G

Running Activation Key: 0xb10f664d 0x445025ed 0x8c61e184 0x823c68b0 0x093a9a82

Configuration register is 0x1

Configuration has not been modified since last system restart.

x What software version is running on the ASA? ______________________

x Which version of ASDM is running? ______________________________

x How long has the ASA been up and running? ______________________

(26)

x How much RAM is installed? ___________________________________

x How much flash is installed? ____________________________________

x What type of Failover license is available? _________________________

x Do you have DES, 3DES and AES encryption available? _______________

x How many security contexts are available? ___________________________

x How many (IPsec) VPN peers are licensed? __________________________

x How many WebVPN peers are licensed? _____________________________

9. Go to privileged mode so you can run some privileged show commands. Note the enable password is now blank:

ciscoasa> enable

Password: <Enter>

ciscoasa#

10. Verify how much memory is in use with the show memory command:

ciscoasa# show memory

Free memory: 433418720 bytes (81%) Used memory: 103452192 bytes (19%) --- ---

Total memory: 536870912 bytes (100%)

11. View the files in flash and determine how much free flash is available:

ciscoasa# show flash

--#-- --length-- ---date/time--- path

65 14524416 Feb 26 2008 15:31:04 asa803-k8.bin 66 6889764 Feb 26 2008 15:32:58 asdm-603.bin 2 8192 Jun 07 2003 22:36:18 log

6 8192 Jun 07 2003 22:36:30 crypto_archive 255426560 bytes total (231358464 bytes free)

12. View the running configuration with the show running-config command. Note, the

configuration is currently defaulted – all of the interfaces are shut down with no IP addresses configured. But, there is still many firewall configuration settings in place by default, including connection timers and inspection settings.

ciscoasa# show running-config

: Saved :

ASA Version 8.0(3) !

(27)

L1-7

enable password 8Ry2YjIyt7RRXU24 encrypted names ! interface GigabitEthernet0/0 shutdown no nameif no security-level no ip address ! interface GigabitEthernet0/1 shutdown no nameif no security-level no ip address ! interface GigabitEthernet0/2 shutdown no nameif no security-level no ip address ! interface GigabitEthernet0/3 shutdown no nameif no security-level no ip address ! interface Management0/0 shutdown no nameif no security-level no ip address !

passwd 2KFQnbNIdI.2KYOU encrypted ftp mode passive

pager lines 24 no failover

icmp unreachable rate-limit 1 burst-size 1 asdm image disk0:/asdm-603.bin

no asdm history enable arp timeout 14400 timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02 timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00

timeout sip 0:30:00 sip_media 0:02:00 invite 0:03:00 sip-disconnect 0:02:00

timeout uauth 0:05:00 absolute

(28)

no snmp-server location no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart

no crypto isakmp nat-traversal telnet timeout 5

ssh timeout 5 console timeout 0

threat-detection basic-threat

threat-detection statistics access-list !

class-map inspection_default match default-inspection-traffic !

!

policy-map type inspect dns preset_dns_map parameters message-length maximum 512 policy-map global_policy class inspection_default inspect dns preset_dns_map inspect ftp inspect h323 h225 inspect h323 ras inspect netbios inspect rsh inspect rtsp inspect skinny inspect esmtp inspect sqlnet inspect sunrpc inspect tftp inspect sip inspect xdmcp !

service-policy global_policy global prompt hostname context

Cryptochecksum:d41d8cd98f00b204e9800998ecf8427e : end

The Setup Dialog

Like IOS routers, ASA’s offer a setup dialog when they are booted without a startup configuration. Also, like IOS routers, you can run the setup dialog at any time. However, the purpose of the setup dialog is quite different. On an IOS router, the setup dialog will ask many questions and when done the IOS router is ready to act as a router (with a very simple

configuration). On the ASA, the setup dialog only sets up one interface, so the ASA won’t be configured to be a firewall after setup is complete. What it will be ready to do, however, is support ASDM.

(29)

L1-9

13. Use the configure terminal to reach global configuration mode.

ciscoasa# conf t

ciscoasa(config)#

14. Setup requires the inside interface to be assigned before it is executed from the CLI. Assign the interface Gi0/1 the name inside:

ciscoasa(config)# int g0/1

ciscoasa(config-if)# nameif inside

INFO: Security level for "inside" set to 100 by default.

15. Now run the setup dialog, responding as shown in this example:

ciscoasa(config-if)# setup

Pre-configure Firewall now through interactive prompts [yes]?

<Enter>

Firewall Mode [Routed]: <Enter>

Enable password [<use current password>]: san-fran

Allow password recovery [yes]? <Enter>

Clock (UTC): <Enter>

Year [YYYY]: <Enter>

Month [Mmm]: <Enter>

Day [DD]: <Enter>

Time [HH:MM:SS]: <Enter>

Inside IP address [0.0.0.0]: 10.10.0.1

Inside network mask [255.255.255.255]: 255.255.255.0

Host name [ciscoasa]: GKL-ASA

Domain name: gkl.local

IP address of host running Device Manager: 10.10.10.10

The following configuration will be used: Enable password: san-fran

Allow password recovery: yes Clock (UTC): 20:22:19 Jun 2 2008 Firewall Mode: Routed

Inside IP address: 10.10.0.1 Inside network mask: 255.255.255.0 Host name: GKL-ASA

Domain name: gkl.local

IP address of host running Device Manager: 10.10.10.10 Use this configuration and write to flash? yes

WARNING: http server is not yet enabled to allow ASDM access. Cryptochecksum: 7601acfa b7f02fac 1a944644 dc9d2772

2107 bytes copied in 3.350 secs (702 bytes/sec) GKL-ASA(config)#

Note You may see a WARNING like that above. This is spurious. You can verify that http server is indeed enabled in the next step of the lab.

(30)

16. View the configuration using the show run command. Amongst the default commands, you should also see the following commands configured:

GKL-ASA(config)# show run

<… default commands removed from output …> hostname GKL-ASA

domain-name gkl.com

enable password Rjwipa01sHSnXKAp encrypted interface GigabitEthernet0/1 nameif inside security-level 100 ip address 10.10.0.1 255.255.255.0 dns server-group DefaultDNS domain-name gkl.local http server enable http 10.10.10.10 255.255.255.255 inside

17. Note, the command http 10.10.10.10 255.255.255.255 inside indicates that 10.10.10.10 (the Admin PC) is trusted to make https connections to the ASA to run ASDM. But, at the moment, the ASA doesn’t know how to reach the 10.10.10.0 subnet. Configure a summary route for the 10.10.0.0 subnet on the ASA through the L3-Switch (10.10.0.2).

GKL-ASA(config)# route inside 10.10.0.0 255.255.0.0 10.10.0.2

18. Verify that the Admin PC (10.10.10.10) is now reachable from the ASA using ping:

GKL-ASA(config)# ping 10.10.10.10

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds: !!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms

Enable SSH

It will be convenient to have SSH enabled on the ASA for CLI access from the Admin PC in the coming labs. While it hasn’t been discussed in the course materials yet (enabling SSH is covered in the last lesson of SNAF), go ahead and enable it now.

19. Like the http command which was entered by the setup dialog, the ssh command is used to specify which addresses are trusted to establish SSH connections to the ASA. Set the Admin PC’s address as trusted by SSH:

GKL-ASA(config)# ssh 10.10.10.10 255.255.255.255 inside

20. Also allow systems on the Management Subnet (10.10.2.0/24) permission for both SSH and HTTPS access to the ASA:

GKL-ASA(config)# ssh 10.10.2.0 255.255.255.0 inside

(31)

21. Test SSH from the Admin PC:

21.1. Access the desktop of the Admin PC. 21.2. Launch PuTTY:

21.3. In PuTTY, enter 10.10.0.1 in the Host Name field, verify that the Port is 22 and the Protocol is SSH, and then click Open.

21.4. Putty will display a Security Alert. You must verify the public key that was presented by the ASA. Click Yes to continue.

Note When the Global Knowledge remote labs system is used to reset the lab environment to the beginning of a particular lab, the ASA will generate a new pair of RSA keys. As such, in this lab environment, it will be common for PuTTY to not have the current public key cached. It will not be documented on every future use of SSH, but when necessary, accept the keys presented to PuTTY.

21.5. You will be prompted for credentials. Use the username pix and the password cisco.

login as: pix

[email protected]'s password: cisco

Type help or '?' for a list of available commands. GKL-ASA>

22. As you have just demonstrated, there are default credentials on the PIX and ASA families. Obviously you should change these credentials:

22.1. Change the default SSH password to cisco123.

GKL-ASA> enable

Password: san-fran

GKL-ASA# conf t

GKL-ASA(config)# passwd cisco123

Note The password configured with the passwd command is used for both Telnet and SSH. At the moment, only SSH is enabled, so the fact that this password could also be used by Telnet is a moot point.

22.2. You will learn more about using AAA commands in later lessons and labs. For now, create the username admin with the password admin$Pwd, and configure the SSH console to use local authentication as follows:

GKL-ASA(config)# username admin password admin$Pwd privilege 15

(32)

Note Turning on AAA authentication for the SSH console supersedes the username pix with the passwd configured password. The credentials pix and cisco123 will no longer provide access.

22.3. While not recommended for a production environment, for convenience in the lab environment increase the SSH timeout to the maximum of 60 minutes (the default is 10 minutes):

GKL-ASA(config)# ssh timeout 60

23. Verify the configured SSH authentication:

23.1. Keep the current PuTTY window open, which will make it much easier to recover if you made a typographical error when entering the username command.

23.2. Attempt to authenticate with pix and cisco and pix and cisco123: 23.2.1.Launch a new PuTTY window, as you did previously.

23.2.2.In the new window, attempt to authenticate using pix and cisco. This should fail. 23.2.3.With PuTTY, you can’t enter a new username, but attempt cisco123 as the

password with the username pix. This should also fail. 23.2.4.Close this PuTTY window.

23.3. Verify that the credentials admin and admin$Pwd are accepted: 23.3.1.Again, launch a new PuTTY window.

23.3.2.Authenticate using admin and admin$Pwd as the credentials. This should succeed.

23.3.3.Use the enable command with the password san-fran to reach privileged mode. 23.3.4.Use configure terminal to reach global configuration mode.

23.4. Close the original PuTTY window.

Setup ASDM

In this section of the lab you will install ASDM on the Admin PC. You will also configure its preferences. The most important preference modification that you will make is to turn on command preview, so that ASDM will display all the commands it intends to send to the ASA for administrator review and approval.

24. On the Admin PC, launch Internet Explorer:

Note Most lab directions will specify to use Firefox. This is one exception. Internet Explorer allows you to run an application without downloading it first, which will save a step in this case.

(33)

L1-13

25. User Internet Explorer to browse https://10.10.0.1. Click Yes to accept the digital certificate presented by the ASA and proceed.

Note As was noted with SSH above, when the remotelabs.com system performs a lab reset, the ASA must generate a new RSA key-pair, and hence generate a new SSL identity certificate. Due to the dynamic nature, the lab directions will not specify to install the digital certificates in the web browsers. It won’t be documented on future HTTPS connection attempts, but expect to have to click Yes or OK as appropriate when presented with security warnings associated with the ASA’s digital certificate.

Note Also, Firefox is the default web browser and will generally be the browser specified for use in the lab directions. IE was used in this case because it provides a slight reduction in the number of steps required to install the ASDM Launcher.

26. Install the ASDM Launcher on the Admin PC, which will provide improved performance when using ASDM:

26.1. Click Install ASDM Launcher and Run ASDM.

26.2. Enter admin and admin$Pwd for the User Name and Password, and then click OK. 26.3. Click Run to run the asdm-launcher.msi installation file. Click Run again on the

security warning.

26.4. Execute the Wizard accepting the defaults as follows: 26.4.1.On the Welcome window, click Next.

26.4.2.On the Destination Folder window, click Next.

26.4.3.On the Ready to Install the Program window, click Install. 26.4.4.On the Wizard Completed window, click Finish.

27. There is now a Cisco ASDM Launcher icon on the desktop, and the Cisco ASDM Launcher is running. In the Cisco ASDM Launcher window, enter 10.10.0.1 for the Device IP Address,

admin for the Username, and admin$Pwd for the Password. Click OK. If a security

warning window opens up, click Yes to continue.

Note ASDM should start. You should start at Home > Device Dashboard. The Device Information section of this window contains the same information that appears with the show version CLI command. Other high level status information, such as interface status and traffic status are also displayed here.

28. A great feature of ASDM that is disabled by default is the preview of commands before they are sent to the ASA. Enable this feature:

28.1. In ASDM, select Tools > Preferences.

(34)

29. Another great feature of ASDM is its Packet Capture Wizard, which is made even better if it is configured to launch a local protocol analyzer application. Link ASDM to Wireshark: 29.1. Click Browse next to Network Sniffer Application.

29.2. Browse to Admin-PC > C: > Program Files > Wireshark and highlight the file

wireshark.exe. Click Select.

29.3. Click OK on the Preferences window.

Verify the ASA Configuration

The expected ASA configuration is provided in this section of the lab. To verify that you have properly completed the steps included in this lab, you should compare the configuration on the ASA with what is displayed here.

30. Use ASDM to display the running-config on the ASA. Compare its configuration to the following configuration. Note, many variables may cause minor discrepancies in the configuration. Pay closer attention to the highlighted lines as they refer to configuration changes made during this lab.

30.1. In ASDM, select File > Show Running Configuration in a New Window… You will have to authenticate with the username admin and the password admin$Pwd.

: Saved : ASA Version 8.0(3) ! hostname GKL-ASA domain-name gkl.local

enable password Rjwipa01sHSnXKAp encrypted

names ! interface GigabitEthernet0/0 shutdown no nameif no security-level no ip address ! interface GigabitEthernet0/1 nameif inside security-level 100 ip address 10.10.0.1 255.255.255.0 ! interface GigabitEthernet0/2 shutdown no nameif no security-level no ip address ! interface GigabitEthernet0/3

(35)

L1-15

passwd 9jNfZuG3TC5tCVH0 encrypted

ftp mode passive dns server-group DefaultDNS domain-name gkl.local pager lines 24 mtu inside 1500 no failover

no asdm history enable arp timeout 14400

route inside 10.10.0.0 255.255.0.0 10.10.0.2 1

timeout xlate 3:00:00

dynamic-access-policy-record DfltAccessPolicy aaa authentication ssh console LOCAL

http server enable

http 10.10.10.10 255.255.255.255 inside http 10.10.2.0 255.255.255.0 inside

no snmp-server location no snmp-server contact

no crypto isakmp nat-traversal telnet timeout 5 ssh 10.10.10.10 255.255.255.255 inside ssh 10.10.2.0 255.255.255.0 inside ssh timeout 60 console timeout 0 threat-detection basic-threat

(36)

match default-inspection-traffic !

!

policy-map type inspect dns preset_dns_map parameters message-length maximum 512 policy-map global_policy class inspection_default inspect dns preset_dns_map inspect ftp inspect h323 h225 inspect h323 ras inspect rsh inspect rtsp inspect esmtp inspect sqlnet inspect skinny inspect sunrpc inspect xdmcp inspect sip inspect netbios inspect tftp !

service-policy global_policy global

username admin password .jiVN8QGzNJQKSbV encrypted privilege 15

prompt hostname context

Cryptochecksum:55f3be3ef61afbbffe01c12350bf2e41 : end

(37)

L2-1

L2

(38)

Lab Overview

In this lab you will configure many of the basic settings on the ASA. You will configure the inside, outside and dmz interfaces as well as configure authenticated NTP support and Syslog support. You will then use different scenarios and features to test the behavior of the ASA with this simple configuration in place.

Estimated Completion Time

45 minutes

Lab Procedures

1. Launch ASDM

2. Execute the Startup Wizard 3. ASDM Device Setup 4. Configure Syslog

5. Test and Verify the ASA’s configuration 6. The Packet Capture Wizard

(39)

L2-3

Note When the remotelabs.com system is used to reset to the starting point of a new lab, the ASA must generate a new RSA key pair and a new SSL identity certificate. Due to this, there will be no association of trust with the ASA and the SSH clients and web browsers in the lab environment. As such, security warnings can be expected on connections to the ASA. It is not explicitly stated in the lab directions, but you must accept the keys and certificates presented by the ASA. You can choose to install certificates which will minimize the recurrence of security warnings until the next time a remotelabs.com reset operation is performed.

Launch ASDM

This lab utilizes ASDM to meet its objectives. Hence, the first thing to do is to launch ASDM. 1. Launch ASDM

1.1. Access the desktop of the Admin PC

1.2. Double click on the Cisco ASDM Launcher icon on the desktop.

1.3. Enter 10.10.0.1 in the Device IP Address/Name field, enter admin in the Username field and admin$Pwd in the Password field, then click OK.

1.4. The ASDM home page should now be displayed.

Execute the Startup Wizard

ASDM provides several wizards including the Startup Wizard which is intended to define a very simple configuration on the ASA. You will run this wizard in this section of the lab. Since some configuration has been completed during SNAF Lab 1, you will see that some portions of the wizard are already defined. You will configure the outside interface and a default route using the wizard, and you will see all of the other options that the wizard offers.

2. In ASDM, select Wizards > Startup Wizard. Execute the wizard as follows:

2.1. On the Starting Point window, select Modify existing configuration and click Next. 2.2. Note, the host name (GKL-ASA) and domain name (gkl.local) are already defined as

they were configured in SNAF Lab 1. Click Next.

2.3. On the Auto Update Server window, DO NOT check Enable Auto Update, simply click

Next.

2.4. On the Outside Interface Configuration window complete the panel as follows:

x Interface: GigabitEthernet0/0

x Interface name: outside

x Check Enable Interface

x Security Level: 0

(40)

o IP Address: 200.200.1.2

o Subnet Mask: 255.255.255.0

x Click Next.

2.5. On the Other Interfaces Configuration window, simply click Next. (You will configure the DMZ interface outside of the wizard.)

2.6. On the Static Routes window. Note there is a summary route for the 10.10.0.0/16 network already defined. It was defined in SNAF Lab 1. Add a default route via the Perimeter Router:

2.6.1. Click Add.

2.6.2. Fill in the Add Static Route panel as follows:

x Interface Name: outside

x IP Address: 0.0.0.0

x Mask: 0.0.0.0

x Gateway IP: 200.200.1.1

x Leave other values at their default and click OK.

2.6.3. Click Next.

2.7. On the DHCP Server window, simply click Next.

2.8. On the Address Translation (NAT/PAT) window, select Enable traffic through the

firewall without address translation, and then click Next.

2.9. On the Administrative Access window, note that access to both ADSM via HTTPS and the CLI via SSH are allowed from the Admin PC (10.10.10.10) and the entire

Management Subnet (10.10.2.0/24). This was configured in SNAF Lab 1. Click Next. 2.10. On the Setup Wizard Summary, review the summary and click Finish.

2.11. Because Command Preview is enabled, the Preview CLI Commands window appears. The commands displayed should be similar to those shown here. If the commands appear correct, click Send. If not, click Cancel and retrace your steps to determine the

underlying problem. Interface GigabitEthernet0/0 no shutdown nameif outside security-level 0 ip address 200.200.1.2 255.255.255.0 nat (inside) 0 0.0.0.0 0.0.0.0 route outside 0.0.0.0 0.0.0.0 200.200.1.1 1

(41)

ASDM Device Setup

In this section of the lab, you will tour the ASDM Device Setup Area. You will be able to verify the configuration items previously set as well as define the DMZ interface and set up

authenticated NTP.

3. In ASDM, select Configuration > Device Setup.

Note You previously accessed the Startup Wizard from the Wizards pulldown menu. The wizard is also available under Device Setup.

4. Under Device Setup, select Interfaces.

4.1. Verify that Gi0/0 is defined as the outside interface with a security level of 0 and an IP address of 200.200.1.2.

4.2. Verify that Gi0/1 is defined as the inside interface with a security level of 100 and an IP address of 10.10.0.1.

4.3. Define the DMZ interface:

4.3.1. Select GigabitEthernet0/2 and click Edit. 4.3.2. Fill in the Edit Interface panel as follows:

x Interface Name: dmz

x Security Level: 50

x Check Enable Interface

x Select Use Static IP

o IP Address: 172.16.1.1

o Subnet Mask: 255.255.255.0

x Leave other fields at their default and click OK.

4.3.3. Click OK on the Security Level Change notice. 4.4. Click Apply at the bottom of the Interfaces panel.

4.5. The following commands should be displayed in the Preview CLI Commands window. Examine the commands shown. If they appear correct, click Send. If not, click Cancel and retrace your steps to determine the underlying issue.

Interface GigabitEthernet0/2 no shutdown

nameif dmz

security-level 50

(42)

5. Under Device Setup, select Routing.

5.1. Several routing configuration components are expanded. Select Static Routes. 5.2. Verify that there is a summary route for the 10.10.0.0/16 network via the L3-Switch

(10.10.0.2) on the inside interface. This was configured in SNAF Lab 1.

5.3. Verify that there is a default route via the Perimeter Router (200.200.1.1) on the outside interface. This was configured with the Startup Wizard.

6. Under Device Setup, select Device Name/Password:

6.1. Verify, as you saw during the Startup Wizard, that the Hostname (GKL-ASA) and Domain Name (gkl.local) are defined.

7. Under Device Setup, select System Time. This should expand the Clock and NTP options. 7.1. Select Clock.

7.1.1. Verify the Time Zone is set to UTC. This is most appropriate for the Global Knowledge Remote Labs. Where the labs will be accessed from cannot be predicted, so the reset function sets time according to UTC.

7.1.2. Also note that the date and time can be set manually from this screen, but you will configure NTP in the next step of the lab.

7.2. Select NTP. The (currently empty) table of NTP servers is displayed. 7.2.1. Check Enable NTP authentication.

Note The lab environment has an NTP server at 192.43.244.18. This is the IP address of the real time.nist.gov. To demonstrate the use of Authenticated NTP, the NTP server in the lab is configured with the key string “ntpkey” as key number 1. Note, NTP authentication cannot normally be performed with public servers. It requires the use of a key that is only known between the server and the client. NIST is running a trial to provide authenticated NTP services. It is free, but requires registration. For more details see http://tf.nist.gov/service/auth_ntp.htm.

7.2.2. Add an NTP server by clicking Add and defining the server as follows:

x IP Address: 192.43.244.18

x Check Preferred

x Interface: outside

x Key Number: 1

x Check Trusted

x Key Value: ntpkey

x Re-enter Key Value: ntpkey

(43)

L2-7

7.2.3. Click Apply.

7.2.4. The following commands should be displayed in the Preview CLI Commands window. Examine the commands shown. If they appear correct, click Send. If not, click Cancel and retrace your steps to determine the underlying issue.

ntp server 192.43.244.18 key 1 source outside prefer ntp authenticate

ntp authentication-key 1 md5 ntpkey ntp trusted-key 1

7.3. ASDM doesn’t provide an easy way to directly verify the status of NTP. Use an indirect method as follows:

7.3.1. In ASDM, select Tools > Command Line Interface.

7.3.2. In the Command Line Interface window, overwrite – Type command or select from the list – with show ntp associations, then click Send. The resulting output should be similar to the following: Note the * signifying synchronization with the NTP master.

Result of the command: "show ntp associations"

address ref clock st when poll reach delay offset disp *~192.43.244.18 127.127.7.1 8 14 64 1 -0.2 23.08 15890. * master (synced), # master (unsynced), + selected, - candidate, ~

configured

7.4. Close the ASDM Command Line Interface window.

Configure Syslog

The use of Syslog is critical for managing security appliances. In this section of the lab you will configure the ASA to use the Security Server as its Syslog server.

8. In ASDM, select Configuration > Device Management. 9. Expand the Logging section.

10. Select Logging Setup.

10.1. Check Enable Logging and click Apply.

10.1.1.The following commands should be displayed in the Preview CLI Commands window. Examine the commands shown. If they appear correct, click Send. If not, click Cancel and retrace your steps to determine the underlying issue.

logging enable

11. Select Logging Filters.

11.1. Select the ASDM row and click Edit.

11.1.1.Select Filter on severity and set the level to Warnings. 11.1.2.Click OK on the Edit Logging Filters window.

(44)

11.2. Select the Syslog Servers row and click Edit.

11.2.1.Select Filter on severity and set the level to Debugging. 11.2.2.Click OK on the Edit Logging Filters window.

11.3. Click Apply at the bottom of the Logging Filters table.

11.4. The following commands should be displayed in the Preview CLI Commands window. Examine the commands shown. If they appear correct, click Send. If not, click

Cancel and retrace your steps to determine the underlying issue. logging asdm Warnings

logging trap Debugging

12. Select Syslog Servers. 12.1. Click Add.

12.2. In the Add Syslog Server window, define the new server as follows: 12.2.1.Interface: inside

12.2.2.IP Address 10.10.2.10

12.2.3.Leave all other fields at their default values and click OK. 12.3. Click Apply.

12.4. The following command should be displayed in the Preview CLI Commands window. Examine the command shown. If it appears correct, click Send. If not, click Cancel and retrace your steps to determine the underlying issue.

logging host inside 10.10.2.10

Test and Verify the ASA’s Configuration

At this point you have a very simple configuration on the ASA. The inside, outside and dmz interfaces have been configured and sessions are allowed from the inside interface to the less secure dmz and outside interfaces without the use of NAT. Also, NTP and Syslog have been configured. The NTP functionality was verified when it was configured. In this section of the lab you will verify inside to dmz connectivity and you will verify Syslog services.

(45)

14. Use the pre-defined PHP-Kiwi link to connect to the PHP-Kiwi service running on the Security Server. When challenged for authentication use admin and admin$Pwd for credentials.

Note Kiwi produces a very respected syslog server for Windows systems. There is a freely

distributable version and a licensed version. The licensed version is required to integrate Kiwi with relational database systems. The Security Server is running the licensed Kiwi Syslog server and it is integrated with the freely distributable MySQL and PHP-Kiwi packages. These allow web based access to the Kiwi Syslog database.

14.1. PHP-Kiwi is configured to refresh the display once every 60 seconds. The

auto-refresh can be toggled on and off here . A manual refresh can also be

completed at any time using the browser’s refresh button . Wait one minute for the

refresh cycle to complete, there should be several severity 6 and severity 7 messages displayed. Investigate the Syslog messages:

x You should see several 72500x messages associated with SSL negotiations.

x You should see some 605005 messages indicating login of the user admin via

https.

x You should see some 111009 messages indicating that the user admin executed

the command show access-list brief.

Note While ASDM is running, whether it is actively being used by a person or not, will handshake with the ASA approximately every 30 seconds. These messages are associated with this behavior.

x There are likely to be other messages besides those specified above.

15. Test inside to dmz connectivity and verify TCP connection auditing. You will establish an SSH connection from the Admin PC to the DMZ Server and then quickly refresh the Syslog display. The connection should be successful and it should be recorded with a Syslog message. You will then exit the SSH session and again quickly refresh the Syslog display. You should see the connection termination is also recorded with a Syslog message. 15.1. On the Admin PC, launch PuTTY.

15.2. In PuTTY, double click on the DMZ Server entry. Log in to the DMZ Server as

(46)

15.3. In the PHP-Kiwi interface, perform a manual refresh of the browser. You should see a message similar to the following:

%ASA-6-302013: Built outbound TCP connection 242 for

dmz:172.16.1.15/22 (172.16.1.15/22) to inside:10.10.10.10/19587 (10.10.10.10/19587)

Note This syslog message indicates a new TCP connection. The real and translated addresses

and ports are indicated (they happen to be the same in this case because NAT is not in use). Note, TCP port 22 is normally used for SSH.

15.4. In PuTTY, enter the exit command to terminate the SSH session and quickly execute the next step.

15.5. Again, in the PHP-Kiwi interface, perform a manual refresh of the browser. You should see a message similar to the following:

%ASA-6-302014: Teardown TCP connection 242 for dmz:172.16.1.15/22 to inside:10.10.10.10/19587 duration 0:05:31 bytes 3324 TCP FINs

Note As soon as the TCP FIN exchange completes, the ASA knows the TCP connection is terminated. It records the fact with a Syslog message and immediately removes the connection from its state table.

Note The TCP connection number specified in this message matches the connection number specified in the previously highlighted message.

16. Finding particular Syslog messages of interest can be quite tedious, especially when examining severity 6 and 7 messages from Cisco security appliances! Most Syslog servers have at least some filtering capabilities to help you find what you are looking for.

Demonstrate this with PHP-Kiwi:

16.1. In PHP-Kiwi, click Filter .

16.1.1.Under Filter Lists, click Add Filter. Filter (1) should now be added to the list. 16.1.2.At the bottom of the page, define the Message Filter section as follows:

x Select Include list.

x Enter 302013 and 302014 on separate lines in the Message Filter box.

16.1.3.Click Save.

(47)

16.3. Change the Applied Filter to Filter (1) .

Note Now the display should be much less busy. The only messages displayed are for TCP connection initiation and termination.

Note There will be more than just the messages associated with the SSH connection that you just demonstrated. There should be pairs of messages spaced approximately 30 seconds apart associated with the SSL connections made by ASDM to the ASA itself.

17. While some organizations are required to audit all network sessions leaving their networks, we don’t need to be at this level in the lab environment. Modify the Syslog configuration so only severity 4 Syslog messages (Warnings) and above are sent to the Syslog server.

17.1. Return to ASDM. You should still be under Configuration > Device Management >

Logging.

17.2. Select Logging Filters.

17.3. Select the Syslog Servers row and click Edit.

17.4. Filter on severity should already be selected, change the setting to Warnings, and click OK.

17.5. Click Apply.

17.6. The following command should be displayed in the Preview CLI Commands window. Examine the commands shown. If they appear correct, click Send. If not, click Cancel and retrace your steps to determine the underlying issue.

logging trap Warnings

18. Verify the logging settings change: 18.1. Return to PHP-Kiwi.

18.2. Wait about 40 seconds and manually refresh the browser. Verify that there are no new severity 7, 6 or 5 messages.

The Packet Capture Wizard

You’ve demonstrated that connections from the more secure inside interface to the less secure dmz interface work properly. In this section you will demonstrate that connections from the more secure inside interface to the less secure outside interface do not work properly. The problem is not that the ASA does not allow the connections. You may already have an idea of what the issue is. Whether you do or not, you will reveal the root problem with the Packet Capture Wizard. Addressing the actual problem will be a theme in SNAF Lab 3.

(48)

19. Prove the a web browser on the Admin PC cannot access systems on the external network: 19.1. Use the Firefox window that is currently displaying PHP-Kiwi. Browse the Outside

PC at http://150.150.1.20.

19.2. Wait 20 seconds. A connection timeout message should be displayed. 20. In ASDM, select Wizards > Packet Capture Wizard.

20.1. Click Next on the Overview window.

20.2. Select the inside interface on the Ingress Traffic Selector window, leave all other values at their default and click Next.

20.3. Select the outside interface on the Egress Traffic Selector window, leave all other values at their default and click Next.

20.4. You will only need to verify the packet headers to see the problem, so change the Packet Size to 64 on the Buffers window, and click Next.

20.5. Verify that the commands that will be used to implement this packet capture appear like this on the Summary window, and then click Next:

! inside

! Capture ip protocol traffic between 0.0.0.0 0.0.0.0 and 0.0.0.0 0.0.0.0. access-list asdm_cap_selector_inside permit ip 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

! Apply ingress capture on the inside interface.

capture asdm_cap_inside packet-length 64 buffer 524288 access-list asdm_cap_selector_inside

capture asdm_cap_inside interface inside ! outside

! Capture ip protocol traffic between 0.0.0.0 0.0.0.0 and 0.0.0.0 0.0.0.0. access-list asdm_cap_selector_outside permit ip 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

! Apply egress capture on the outside interface.

capture asdm_cap_outside packet-length 64 buffer 524288 access-list asdm_cap_selector_outside

capture asdm_cap_outside interface outside

20.6. On the Run Captures window: 20.6.1.Click Start.

20.6.2.Return to Firefox and click the Refresh icon to cause Firefox to attempt the

connection again. Wait 20 seconds for the attempt to time out once again. 20.6.3.Return to ASDM.

(49)

L2-13

20.6.4.Click Get Capture Buffer. Note the following about the capture:

x You will likely see more packets in the Ingress: inside table than in the Egress:

outside table. The ASDM traffic to the ASA itself will only be captured on the inside interface.

x You should see 3 packets from 10.10.10.10 and a high numbered port to

150.150.1.20 port 80. These are the connection attempts from Firefox.

x You may also see other outbound packets, most likely UDP port 123 packets to

192.43.18.123 (NTP requests to time.nist.gov) or UPD port 53 packets to 50.50.50.50 (DNS queries to the root hints DNS server).

x Look closer at the three connection attempt packets. Note the capital S followed

by a large integer. This indicates these are SYN packets with the large integer being the initial sequence number. Note the initial sequence number is the same for all of the packets. These are retransmissions of the same packet. No SYN ACK is received in response. The connection cannot complete.

20.6.5.Why aren’t replies received from the Outside PC? Hint: Should any system out on the internet be able to reach the 10. Private address space on any other network? 20.7. To demonstrate using another feature of the Packet Capture Wizard, click Launch

Network Sniffer Application next to Egress: outside.

20.7.1.Wireshark opens, allowing full protocol decode of the captured packets. 20.7.2.Close the Wireshark application.

20.8. Click Finish to gracefully close the wizard. It will remove the packet capture settings that it configured.

Verify the ASA Configuration

The expected ASA configuration is provided in this section of the lab. To verify that you have properly completed the steps included in this lab, you should compare the configuration on the ASA with what is displayed here.

21. Save the configuration on the ASA:

21.1. In ASDM, select File > Save Running Configuration to Flash. Click Save and click

Send.

22. Use ASDM to display the running-config on the ASA. Compare its configuration to the following configuration. Note, many variables may cause minor discrepancies in the configuration. Pay closer attention to the highlighted lines as they refer to configuration changes made during this lab.

22.1. In ASDM, select File > Show Running Configuration in a New Window… You will have to authenticate with the username admin and the password admin$Pwd.

(50)

: Saved : ASA Version 8.0(3) ! hostname GKL-ASA domain-name gkl.local

enable password Rjwipa01sHSnXKAp encrypted names ! interface GigabitEthernet0/0 nameif outside security-level 0 ip address 200.200.1.2 255.255.255.0 ! interface GigabitEthernet0/1 nameif inside security-level 100 ip address 10.10.0.1 255.255.255.0 ! interface GigabitEthernet0/2 nameif dmz security-level 50 ip address 172.16.1.1 255.255.255.0 ! interface GigabitEthernet0/3 shutdown no nameif no security-level no ip address ! interface Management0/0 shutdown no nameif no security-level no ip address management-only !

passwd 9jNfZuG3TC5tCVH0 encrypted ftp mode passive

dns server-group DefaultDNS domain-name gkl.local pager lines 24

logging enable

logging trap warnings logging asdm warnings

logging host inside 10.10.2.10

mtu inside 1500 mtu outside 1500 mtu dmz 1500 no failover

(51)

L2-15

no asdm history enable arp timeout 14400

nat (inside) 0 0.0.0.0 0.0.0.0

route outside 0.0.0.0 0.0.0.0 200.200.1.1 1

route inside 10.10.0.0 255.255.0.0 10.10.0.2 1 timeout xlate 3:00:00

dynamic-access-policy-record DfltAccessPolicy aaa authentication ssh console LOCAL

http server enable

http 10.10.10.10 255.255.255.255 inside http 10.10.2.0 255.255.255.0 inside no snmp-server location

no snmp-server contact

no crypto isakmp nat-traversal telnet timeout 5 ssh 10.10.10.10 255.255.255.255 inside ssh 10.10.2.0 255.255.255.0 inside ssh timeout 60 console timeout 0 threat-detection basic-threat

class-map inspection_default match default-inspection-traffic !

!

policy-map type inspect dns preset_dns_map parameters message-length maximum 512 policy-map global_policy class inspection_default inspect dns preset_dns_map inspect ftp inspect h323 h225 inspect h323 ras inspect rsh inspect rtsp inspect esmtp inspect sqlnet inspect skinny

(52)

inspect sunrpc inspect xdmcp inspect sip inspect netbios inspect tftp !

service-policy global_policy global

ntp authentication-key 1 md5 * ntp authenticate

ntp trusted-key 1

ntp server 192.43.244.18 key 1 source outside prefer

username admin password .jiVN8QGzNJQKSbV encrypted privilege 15 prompt hostname context

Cryptochecksum:55f3be3ef61afbbffe01c12350bf2e41 : end

asdm image disk0:/asdm-602.bin no asdm history enable

(53)

L3

(54)

Lab Overview

In this lab, you will work with configuring address translations through the ASA. You will begin by experimenting with nat 0 and no nat-control to understand the differences between the two. Next, you will implement a temporary PAT configuration. You will then move on to configure Dynamic NAT, NAT Exemption and Static NAT as

appropriate for the lab topology. At each step along the way, you will test and verify the results of the configuration, both on the host systems that are communicating as well as on the ASA. During this lab you will learn how to configure and monitor address translation and you will see the difference between the ASA’s translation table and its connection table.

Estimated Completion Time

60 minutes

Lab Procedures

1. Prepare for this Lab

2. Understanding NAT Control and NAT 0 3. Configure PAT

4. Configure Dynamic NAT and NAT Exemption 5. Configure Static NAT

ASA Lab Guide

SMB Security - ASA v1.0

Lab Guide

SNAF v1.0 Lab Guide

Table of Contents

INTERNET

SNAF 1.0 Topology

INTERNET

SNAF 1.0 Topology

L0

Lab Overview

Estimated Completion Time

Lab Procedures

Logging In

Controlling Your Pod

Using the Virtual Machines

Pseudo-Physical Device Access

L1

Lab Overview

Estimated Completion Time

Lab Procedures

Access the ASA Console Port

Clearing an Existing Configuration

Taking Inventory of the ASA

The Setup Dialog

Enable SSH

Setup ASDM

Verify the ASA Configuration

L2

Lab Overview

Estimated Completion Time

Lab Procedures

Launch ASDM

Execute the Startup Wizard

ASDM Device Setup

Configure Syslog

Test and Verify the ASA’s Configuration

The Packet Capture Wizard

Verify the ASA Configuration

L3

Lab Overview

Estimated Completion Time

Lab Procedures