Professional Documents
Culture Documents
0 Lab Guide
L5698C-001-1
November 2008 by Global Knowledge
Copyright Information
Copyright 2008 by Global Knowledge Network (S) Pte Ltd
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.
190 Middle Road Fortune Centre, #20-02 Singapore Phone: +65 6332 2330 Email: enquiries@globalknowledge.com.sg www.globalknowledge.com.sg
Printed_in_Singapore
Table of Contents
Lab 0: Introduction to the Remote Lab System ..................................................L0-1 Lab 1: Preparing the ASA for Administration....................................................L1-1 Lab 2: Initial ASA Configuration .......................................................................L2-1 Lab 3: Translations and Connections..................................................................L3-1 Lab 4: ACLs and Object Groups ........................................................................L4-1
TOC-1
Table of Contents
Perimeter Router
.2
.1 (2) .2 .1 .1
10.10.0.0/24 Inside Perimeter GKL-ASA 200.200.20.2 Outside Perimeter 200.200.1.0/24
INTERNET
.1
2K
(4) .2 .1
L3-Switch
10.20.10.0/24 (13) XP
Security-Srv
2K3 10.10.2.10 .1 .1
BT2
Site1-PC 10.20.10.10
(7) XP
Admin-PC 10.10.10.10
2K3
XP
User-PC 10.10.10.20
Data-Srv 10.10.1.10
(Indicates VLAN #)
Perimeter Router
.2
.1 (2) .2 .1 .1
10.10.0.0/24 Inside Perimeter GKL-ASA 200.200.20.2 Outside Perimeter 200.200.1.0/24
INTERNET
.1
2K
(4) .2 .1
L3-Switch
10.20.10.0/24 (13) XP
Security-Srv
2K3 10.10.2.10 .1 .1
BT2
Site1-PC 10.20.10.10
(7) XP
Admin-PC 10.10.10.10
2K3
XP
User-PC 10.10.10.20
Data-Srv 10.10.1.10
(Indicates VLAN #)
L0
Introduction to the Remote Lab System
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.
Lab Procedures
1. Logging In 2. Controlling Your Pod 3. Using the Virtual Machines 4. Pseudo-Physical Device Access
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 x x The title and topology display for the lab that is currently set up. The current date and time, and how much time is left on your reservation. Various control and help links, which will be highlighted in this lab.
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.
L0-3 Global Knowledge Training LLC
7.3. Dont 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.
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. 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 VMs selected, click OK. The VMs should open one after the other, displaying a tab per VM at the top of the window. 10.4. From the VMware Server Console Menus, select View > Quick Switch.
10.5. The Remote Desktop Client window should now be optimized for use with the remote labs system: x x x x x The VMware servers menus should be hidden from view. Across the top of the window are a set of tabs from which the VMs can be selected. The current VMs tab is highlighted. The full desktop of the current VM is displayed (there should not be any scrollbars to move around within the VM desktop). The display should look similar to the following diagram:
10.6. The VMware Consoles menus are hidden, but can still be accessed by hovering the mouse pointer in the windows 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.
11.1. Select the Admin PCs tab. The Admin PCs 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 VMs. The Admin PCs quick launch bar is illustrated for an example:
11.2. x x x x x x x x
From left to right, the icons on the quick launch bar are for: Show Desktop Outlook Express (Email Client) Windows Command Prompt Windows Explorer Word Pad PuTTY (SSH Client) Internet Explorer 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, its 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 Daemons 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 Windows start bar.
15.1. x x x x x
Five options are available for each device. They are: HyperTerminal this will open a HyperTerminal window, connecting to the devices console port using a remotelabs.com access server. Default Telnet This will open a Tera Term Pro window, connecting to the devices console port using a remotelabs.com access server. Power Off This will power off the associated device. Power On This will power on the associated device. 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.
15.2.
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 Routers 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 Routers 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) * 0 con 0 admin idle Interface User Mode Idle 00:00:00 Idle Location
Peer Address
Note
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.
Lab Complete
L1
Preparing the ASA for Administration
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.
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 7. Verify the ASA Configuration
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.
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>
x x x x
What software version is running on the ASA? ______________________ Which version of ASDM is running? ______________________________ How long has the ASA been up and running? ______________________ What is the ASA Model Number? ________________________________
L1-5
x x x x x x x
How much RAM is installed? ___________________________________ How much flash is installed? ____________________________________ What type of Failover license is available? _________________________ Do you have DES, 3DES and AES encryption available? _______________ How many security contexts are available? ___________________________ How many (IPsec) VPN peers are licensed? __________________________ 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) ! L1-6 Global Knowledge Training LLC
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.
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 doesnt 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 hasnt 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 PCs 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 GKL-ASA(config)# http 10.10.2.0 255.255.255.0 inside
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 pix@10.10.0.1'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 GKL-ASA(config)# aaa authentication ssh console LOCAL
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 cant 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.
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 wont 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 ASAs digital certificate. 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.
Note
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. 28.2. Under the General tab, click Preview commands before sending them to the device.
L1-13 Global Knowledge Training LLC
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.
Lab Complete
L2
Initial ASA Configuration
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.
Lab Procedures
1. Launch ASDM 2. Execute the Startup Wizard 3. ASDM Device Setup 4. Configure Syslog 5. Test and Verify the ASAs configuration 6. The Packet Capture Wizard 7. Verify the ASA Configuration
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.
o o x
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 x x x x Interface Name: outside IP Address: 0.0.0.0 Mask: 0.0.0.0 Gateway IP: 200.200.1.1 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
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 x x x o o x Interface Name: dmz Security Level: 50 Check Enable Interface Select Use Static IP IP Address: 172.16.1.1 Subnet Mask: 255.255.255.0 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 ip address 172.16.1.1 255.255.255.0
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 x x x x x x x
L2-6 Global Knowledge Training LLC
IP Address: 192.43.244.18 Check Preferred Interface: outside Key Number: 1 Check Trusted Key Value: ntpkey Re-enter Key Value: ntpkey Click OK.
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 ntp ntp ntp server 192.43.244.18 key 1 source outside prefer authenticate authentication-key 1 md5 ntpkey trusted-key 1
7.3. ASDM doesnt 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 *~192.43.244.18 127.127.7.1 8 14 64 1 -0.2 23.08 * master (synced), # master (unsynced), + selected, - candidate, ~ configured disp 15890.
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.
L2-7 Global Knowledge Training LLC
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
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 auto-refresh the display once every 60 seconds. The autorefresh can be toggled on and off here . A manual refresh can also be
. Wait one minute for the completed at any time using the browsers refresh button refresh cycle to complete, there should be several severity 6 and severity 7 messages displayed. Investigate the Syslog messages: x x x You should see several 72500x messages associated with SSL negotiations. You should see some 605005 messages indicating login of the user admin via https. You should see some 111009 messages indicating that the user admin executed the command show access-list brief.
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.
Note
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 administrator with the password cisco, and quickly execute the next step.
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. The TCP connection number specified in this message matches the connection number specified in the previously highlighted message.
Note
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 x Select Include list. Enter 302013 and 302014 on separate lines in the Message Filter box.
Now the display should be much less busy. The only messages displayed are for TCP connection initiation and termination. 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 dont 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.
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.
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. 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. 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). 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.
x x
20.6.5.Why arent 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.
! 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
Lab Complete
L3
Translations and Connections
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 ASAs translation table and its connection table.
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 6. Verify the ASA Configuration
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. 2. Establish an SSH connection to the ASA from the Admin PC: 2.1. Launch PuTTY on the Admin PC.
2.2. Double click on the GKL-ASA saved session. 2.3. Log in as admin with the password admin$Pwd. 2.4. Use the enable command and the password san-fran to reach privileged mode. 2.5. Use the configure terminal command to reach global configuration mode.
3. Under the current configuration, the Admin PC can reach the DMZ Server, but it cant reach anything on the outside. Well, actually, it can reach systems on the outside, but without NAT the systems on the outside dont know how to respond back to the private 10. address space used on the inside. To facilitate the tests to be done in this section of the lab, configure a pair of static routes in the Perimeter Router, allowing it to be able to get back to the 10.10.0.0 subnet and the 172.16.0.0 network. Since the Perimeter Router doesnt know how to get back to the Admin PC, this must be done from the Perimeter Routers console port. 3.1. Go to the desktop of the Access-PC. 3.2. If necessary, launch Internet Explorer and connect to www.remotelabs.com and log in using your remotelabs.com credentials. 3.3. Expand the Perim-Rtr link and select Default Telnet. A Tera Term Pro window opens. (If you prefer HyperTerminal over Tera Term Pro, you could instead select HyperTerminal.) 3.4. The password challenge will be from the remotelabs.com access server, not the Perimeter Router. Enter your remotelabs.com password to access the Perimeter Router console port. 3.5. After authenticating to the access server, hit enter to stimulate the console port. admin and admin$Pwd are the credentials for the Perimeter Router. Gain access to privileged mode by using the enable secret of san-fran. 3.6. Add two static routes to the Perimeter Router as follows:
PERIM#conf t Enter configuration commands, one per line. End with CNTL/Z. PERIM(config)#ip route 10.10.0.0 255.255.0.0 200.200.1.2 PERIM(config)#ip route 172.16.0.0 255.255.0.0 200.200.1.2 PERIM(config)#exit
4. Verify the address translation configuration on the ASA via the CLI: 4.1. Return to the SSH connection to the ASA running on the Admin PC. 4.2. Verify that NAT control is disabled, that there is a nat 0 statement assigned to the inside interface that matches all source address, and that there are no other nat, global or static commands in place:
GKL-ASA(config)# sh run nat-control no nat-control GKL-ASA(config)# show run nat nat (inside) 0 0.0.0.0 0.0.0.0 GKL-ASA(config)# sh run global GKL-ASA(config)# sh run static
5. Verify the address translation configuration on the ASA via ASDM: 5.1. In ASDM, select Configuration > Firewall > NAT Rules. There should be one entry in the NAT Rules table associated with the nat 0 command:
5.2. At the bottom of the table, Enable Traffic thru the firewall without translations should be checked, associated with the no nat-control configuration. 6. Explore the behavior of connections from the Admin PC on the inside interface to the PERIM router on the outside interface: 6.1. Establish an SSH connection from the Admin PC to the Perimeter Router: 6.1.1. On the Admin PC, launch another instance of PuTTY. 6.1.2. This time double click on the PERIM saved session. 6.1.3. Authenticate with the credentials admin and admin$Pwd. 6.1.4. Use the show users command to verify that the connection is coming from the Admin PCs untranslated 10.10.10.10 address:
PERIM#show users Line User 0 con 0 admin *514 vty 0 admin Interface User Host(s) idle idle Mode Idle Location 00:13:23 00:00:00 10.10.10.10 Idle Peer Address
6.2. Establish another connection to the Perimeter Router from the Admin PC, this time via Telnet: 6.2.1. On the Admin PC, launch a Command Prompt window:
6.2.2. In the command prompt window issue the command telnet 200.200.1.1, and authenticate as admin with the password admin$Pwd. 6.2.3. Again, use the show users command. Now there should be 2 sessions from 10.10.10.10:
PERIM#sh Line 0 con 514 vty *515 vty users 0 0 1 User admin admin admin User Host(s) idle idle idle Mode Idle Location 00:00:45 00:00:27 10.10.10.10 00:00:00 10.10.10.10 Idle Peer Address
Interface
6.3. Examine the ASAs translation table via the CLI: 6.3.1. Use the show xlate command in the PuTTY connection to the ASA:
GKL-ASA(config)# sh xlate 2 in use, 2 most used Global 10.10.10.10 Local 10.10.10.10 Global 10.10.1.10 Local 10.10.1.10
Note You should definitely see the Admin PCs local address 10.10.10.10 translated to itself. You may see other entries in the translation table due to (currently unsuccessful) outbound traffic attempts for DNS or NTP.
6.3.2. Try again, this time adding the detail argument to the show xlate command:
GKL-ASA(config)# show xlate detail 2 in use, 2 most used Flags: D - DNS, d - dump, I - identity, i - dynamic, n - no random, r - portmap, s - static NAT from inside:10.10.10.10 to outside:10.10.10.10 flags iI NAT from inside:10.10.1.10 to outside:10.10.1.10 flags iI
Note Adding the detail argument changes the format of the output slightly and includes flags. The Admin PCs translation entry is both dynamic (i) and Identity I. Identity NAT is the name of the feature implemented with nat 0.
6.4. Examine the ASAs connection table via the CLI: 6.4.1. Use the show conn command to view the ASAs connection table.
GKL-ASA(config)# show conn
5 in use, 6 most used TCP out 200.200.1.1:23 in 10.10.10.10:5296 idle 0:00:09 bytes 453 flags UIO TCP out 200.200.1.1:22 in 10.10.10.10:5292 idle 0:00:21 bytes 3380 flags UIO
Note
There should be at least 2 connections in the table. Both originate from high numbered ports on 10.10.10.10. Both are to 200.200.1.1, but one is destination port 22 (SSH) and the other is destination port 23 (telnet) You may find that there are more connections when you issue the command. Again, these are most likely from outbound NTP or DNS attempts. Show conn displays the number of bytes transmitted in the connection. More bytes have been transferred in the SSH connection than the telnet connection. This is due to the relatively more complex connection negotiation for SSH which includes negotiating encryption protocols, passing of the servers public key to the client and passing of the encrypted session key from the client to the server. Show conn also displays flags. As with show xlate, including using the detail argument will display the meaning of the flags.
Note Note
Note
6.4.2. As you did with show xlate, try the show conn command again, with the detail argument added.
GKL-ASA(config)# show conn detail
5 in use, 6 most used Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN, B - initial SYN from outside, C - CTIQBE media, D - DNS, d - dump, E - outside back connection, F - outside FIN, f - inside FIN, G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data, i - incomplete, J - GTP, j - GTP data, K - GTP t3-response k - Skinny media, M - SMTP data, m - SIP media, n - GUP O - outbound data, P - inside back connection, q - SQL*Net data, R - outside acknowledged FIN, R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN, s - awaiting outside SYN, T - SIP, t - SIP transient, U - up, W WAAS, X - inspected by service module TCP outside:200.200.1.1/23 inside:10.10.10.10/5296 flags UIO TCP outside:200.200.1.1/22 inside:10.10.10.10/5292 flags UIO
Note
Now you can see the meaning of the flags. U indicates that the TCP connection is up (that is the 3-way handshake has completed. I indicates that data has been sent in the inbound direction. O indicates that data has been sent in the outbound direction. The count displayed (5 in use in the example above) doesnt seem to correlate with the output (which only shows 2 connections). By default, show conn doesnt display the connections to and from the ASA itself. To include the connections to and from the ASA, use show conn all.
Note
6.4.3. Use one more very useful command. Show local host combines aspects of both show xlate and show conn. Use the show local host command, specifying the IP address 10.10.10.10:
GKL-ASA(config)# sh local-host 10.10.10.10 Interface dmz: 1 active, 1 maximum active, 0 denied Interface inside: 2 active, 2 maximum active, 0 denied local host: <10.10.10.10>, TCP flow count/limit = 5/unlimited TCP embryonic count to host = 0 TCP intercept watermark = unlimited UDP flow count/limit = 0/unlimited Xlate: Global 10.10.10.10 Local 10.10.10.10 Conn: TCP out 200.200.1.1:23 in 10.10.10.10:5961 idle 0:00:29 bytes 433 flags UIO TCP out 200.200.1.1:22 in 10.10.10.10:5824 idle 0:00:56 bytes 2912 flags UIO Interface outside: 2 active, 3 maximum active, 0 denied
7. Explore the behavior of connections from the DMZ Server on the dmz interface to the PERIM router on the outside interface: 7.1. Initiate a Telnet connection from the DMZ Server to the PERIM router
L3-7 Global Knowledge Training LLC
7.1.1. Access the desktop of the DMZ Server. 7.1.2. Launch a Windows Command Prompt window. 7.1.3. In the command prompt window issue the command telnet 200.200.1.1, and authenticate as admin with the password admin$Pwd. 7.1.4. Again, use the show users command. Now there should be three sessions. Two from 10.10.10.10, and one from 172.16.1.15:
PERIM#sh Line 0 con 514 vty 515 vty *516 vty users 0 0 1 2 User admin admin admin admin User Host(s) idle idle idle idle Mode Idle Location 00:16:57 00:16:33 10.10.10.10 00:16:21 10.10.10.10 00:00:00 172.16.1.15 Idle Peer Address
Interface
7.2. Examine the translation table on the ASA via the CLI. 7.2.1. Return to the Admin PC desktop and access the SSH connection to the ASA. 7.2.2. Use the show xlate command in the SSH connection to the ASA:
GKL-ASA(config)# sh xlate Global 10.10.10.10 Local 10.10.10.10 Global 10.10.1.10 Local 10.10.1.10
Note Note There are translations from the inside 10.10.0.0 network space, but there is not a translation for 172.16.1.15. The reason the inside addresses appear in the translation table is due to the nat (inside) 0 0.0.0.0 0.0.0.0 command in the ASAs configuration. There is no corresponding command associated with the dmz interface. The reason the DMZ Server has outbound access, without translation, is due to the no nat-control command in the ASAs configuration. But this does not cause dynamic entries to be placed in the translation table.
Note
7.3. Examine the connection table on the ASA via the CLI. 7.3.1. Enter the show conn command in the SSH connection to the ASA:
GKL-ASA(config)# show conn 8 in use, 8 most used
TCP TCP TCP UDP out out out out 200.200.1.1:23 200.200.1.1:23 200.200.1.1:22 50.50.50.50:53 in in in in 172.16.1.15:1106 idle 0:00:41 bytes 1097 flags UIO 10.10.10.10:5296 idle 0:00:13 bytes 453 flags UIO 10.10.10.10:5292 idle 0:00:25 bytes 3380 flags UIO 10.10.1.10:1035 idle 0:01:53 flags -
Note
There should be at least 3 connections in the connection table: two telnet and one SSH connection to the Perimeter Router.
8. Terminate the Telnet connections and verify the results: 8.1. First, terminate the connection from the DMZ Server: 8.1.1. Access the desktop of the DMZ server and close the Command Prompt window running the Telnet connection. 8.1.2. Quickly return to the Admin PC and the SSH connection to the ASA. Enter the show conn command:
GKL-ASA(config)# sh conn 5 in use, 8 most used
TCP out 200.200.1.1:23 in 10.10.10.10:5296 idle 0:00:32 bytes 453 flags UIO TCP out 200.200.1.1:22 in 10.10.10.10:5292 idle 0:00:44 bytes 3380 flags UIO
Note
The connection from the DMZ Server to the Perimeter Router has already been removed from the state table. As soon as the ASA witnesses the TCP FIN exchange, it knows the connection has terminated and removes the connection from the state table.
8.1.3. On the Admin PC, close both the PuTTY window and the Command Prompt window that are running the connections to the PERIM router. 8.1.4. In the SSH connection to the ASA, use the show conn command again. Verify that the connections to the Perimeter Router from the Admin PC are no longer in the state table. 8.1.5. Also, use the show xlate command. The translation for the Admin PC should still be in the translation table, even though there are no connections associated with it. By default, the inactivity timeout for translation table entries is three hours. 9. Enable NAT Control on the ASA and explore the resulting connectivity: 9.1. Enable NAT Control on the ASA: 9.1.1. Using the SSH connection to the ASA running on the Admin PC, use the natcontrol command to enable NAT Control:
GKL-ASA(config)# nat-control
9.1.2. Access the desktop of the DMZ Server. Attempt to use a Command Prompt window and telnet to the Perimeter Router (200.200.1.1). This should now fail. NAT Control is enabled, so connections are only allowed when explicitly defined in the configuration.
10. Remove the Identity NAT configuration on the ASA and explore the results: 10.1. Return to the SSH connection to the ASA running on the Admin PC. 10.2. Remove the nat 0 statement assigned to the inside interface:
GKL-ASA(config)# no nat (inside) 0 0.0.0.0 0.0.0.0
10.3. View the current translation table with the show xlate command:
GKL-ASA(config)# sh xlate 2 in use, 2 most used Global 10.10.10.10 Local 10.10.10.10 Global 10.10.1.10 Local 10.10.1.10
Note The translation for the Admin PC remains, even after the nat command has been removed. Optionally, you can verify that the Admin PC can still telnet to the Perimeter Router. This translation entry will timeout after 3 hours of inactivity, or it can be removed immediately with the clear xlate command.
Note
10.4. Clear the translation table and then display it again to verify it is empty:
GKL-ASA(config)# clear xlate GKL-ASA(config)# sh xlate 0 in use, 2 most used
Note Optionally you can verify that neither the Admin PC nor the DMZ Server can reach the Perimeter Router. NAT Control is turned on and there are no explicit NAT rules in the ASAs configuration.
11. Return the Perimeter Router to its original state: 11.1. Return to the desktop of the Access PC and use the console connection to the Perimeter Router. 11.2. Remove the two static routes to the Perimeter Router as follows:
PERIM#conf t Enter configuration commands, one per line. End with CNTL/Z. PERIM(config)#no ip route 10.10.0.0 255.255.0.0 200.200.1.2 PERIM(config)#no ip route 172.16.0.0 255.255.0.0 200.200.1.2 PERIM(config)#exit
Configure PAT
In this section of the lab you will perform a quick experiment with PAT. Imagine the situation where you need to connect a network to the Internet when only residential class service is available from the ISP. You will have a single IP address to use, and you cant predict what
L3-10 Global Knowledge Training LLC
dynamically assigned address will be from day to day. This is the scenario for this section of the lab. You will configure PAT, and instead of specifying a PAT address, you will instead use the keyword interface. 12. Configure PAT using the IP address assigned to the outside interface: 12.1. Access ASDM on the Admin PC. 12.2. Since the configuration was changed by the CLI, ASDM does not represent the current configuration. To address this issue, click refresh in ASDM. 12.3. In ASDM, navigate to Configuration > Firewall > NAT Rules. Verify the NAT Rules table is empty and Enable traffic through the firewall without address translation is UNCHECKED. 12.4. Define PAT sourced from the inside interface. Under NAT Rules, select Add > Add Dynamic NAT Rule. Fill in the Dynamic NAT Rule as follows: x o o x o o o o o x Original: Interface: inside Source: 10.10.0.0/16 (Be careful not to select /24!) Translated: Click Manage, then click Add. Interface: outside Pool ID: 1 Select Port Address Translation (PAT) using IP Address of the interface and click Add. Click OK, click OK. Click OK.
12.5. Repeat this process, but define PAT sourced from the DMZ interface. Under NAT Rules, select Add > Add Dynamic NAT Rule. Fill in the Dynamic NAT Rule as follows: x o o x o x Original: Interface: dmz Source: 172.16.1.0/24 Translated: Select Pool ID 1 defined previously. Click OK.
L3-11
12.6. Verify that the NAT Rules table now looks like this:
12.7. Click Apply. The Preview CLI Commands window should display the following commands.. If what is shown appears correct click Send. If it is incorrect, click Cancel and retrace the past few steps.
nat (dmz) 1 172.16.1.0 255.255.255.0 nat (inside) 1 10.10.0.0 255.255.0.0 global (outside) 1 interface
Note
The nat commands associated with the dmz and inside interfaces specify which source IP addresses are valid for translation and specify the NAT ID 1. The global command on the outside interface uses the matching NAT ID 1 and specifies the keyword interface instead of an IP address or range of IP addresses.
13. Verify the resulting behavior of the PAT configuration: 13.1. Use a Command Prompt window on the Admin PC to telnet to the Internet Router (100.100.1.1). Authenticate as admin with the password admin$Pwd.
Note Translating to the 200.200.1.0 public address space (specifically 200.200.1.2 in this case) will now allow connections to resources on the simulated Internet.
13.2. Move to the desktop of the DMZ server, and use a Command Prompt there to telnet to the Internet Router. 13.3. In the Telnet connection from the DMZ Server, issue the show users command. Verify that both connections appear to be coming from the ASAs outside interface IP address (200.200.1.2).
InternetRouter>sh users Line User vty 194 admin * vty 195 admin Interface User Host(s) idle idle Mode Idle Location 00:04:11 200.200.1.2 00:00:00 200.200.1.2 Idle Peer Address
13.4. Verify translation table on the ASA. Return to the SSH connection to the ASA running on the Admin PC and use the show xlate command.
GKL-ASA(config)# sh xlate 2 in use, 4 most used PAT Global 200.200.1.2(1025) Local 172.16.1.15(1131) PAT Global 200.200.1.2(1024) Local 10.10.10.10(6671)
Note There should be at least 2 entries in the translation table. Note the translations are listed as PAT translations, and port numbers are listed.
13.5. Verify the port number in use on the Admin PC itself. Use a Command Prompt window to execute the command netstat n.
c:\>netstat -n Active Connections Proto TCP TCP TCP TCP
Note
There should be several entries in the Admin PCs connection table. One should be from a high numbered port on itself (10.10.10.10) to port 23 on the Internet Router (100.100.1.1). From the two example outputs above: The Admin PC is really using TCP source port 6671. The ASA is translating the source port to 1024. Hence, when the ASA receives and inbound packet destined for 200.200.1.2 port 1024, it knows to forward it to 10.10.10.10 port 6671.
Note
14. Clean up for the next section of the lab: 14.1. On the DMZ Server, close the Telnet connection to the Internet Router. 14.2. On the Admin PC, close the Telnet connection to the Internet Router and the command prompt used to verify the port via netstat. 14.3. In ASDM, clear the two dynamic NAT rules: 14.3.1.Highlight rule under the dmz interface and click 14.3.2.Highlight rule under the inside interface and click Delete. Delete.
14.3.3.Click Apply. The Preview CLI Commands window should display commands like those following. If what is shown appears correct click Send. If it is incorrect, click Cancel and retrace the past few steps.
no nat (inside) 1 10.10.0.0 255.255.0.0 clear xlate interface inside local 10.10.0.0 netmask 255.255.0.0 no nat (dmz) 1 172.16.1.0 255.255.255.0 clear xlate interface dmz local 172.16.1.0 netmask 255.255.255.0
Note This command transcript removed the two nat commands, and it cleared associated entries from the translation table. It did not, however, remove the global (outside) 1 interface command. This will be cleaned up in the next section of the lab.
o o o o
o
L3-14
15.4. Click Apply. The Preview CLI Commands window should display the following commands.. If what is shown appears correct click Send. If it is incorrect, click Cancel and retrace the past few steps.
no global (outside) 1 interface clear xlate interface outside global 200.200.1.2 nat (inside) 1 10.10.0.0 255.255.0.0 tcp 0 0 udp 0 global (outside) 1 200.200.1.50-200.200.1.100 netmask 255.255.255.0
16. Define the NAT Exemption for traffic between the inside interface and the dmz interface: 16.1. Under Configuration > Firewall > NAT Rules, click Add > Add NAT Exempt Rule. 16.2. Define the NAT Exempt Rule as follows: x x o o o x x Action: Exempt Original Interface: inside Source: 10.10.0.0/16 Destination: 172.16.1.0/24 (which becomes dmz-network/24) NAT Exempt Direction: NAT Exempt outbound traffic Click OK.
16.3. Click Apply. The Preview CLI Commands window should display the following commands.. If what is shown appears correct click Send. If it is incorrect, click Cancel and retrace the past few steps.
access-list inside_nat0_outbound line 1 extended permit ip 10.10.0.0 255.255.0.0 172.16.1.0 255.255.255.0 nat (inside) 0 access-list inside_nat0_outbound tcp 0 0 udp 0
17. Verify the functionality of the NAT Configuration 17.1. Use a Command Prompt window on the Admin PC to telnet to the Internet Router (100.100.1.1), authenticating as admin with the password admin$pwd. 17.2. Use a Command Prompt window on the Data Server to telnet to the Internet Router (100.100.1.1), authenticating as admin with the password admin$pwd.
17.3. From the Data Server originated Telnet session, use the show users command.
InternetRouter>show users Line User Host(s) vty 194 admin idle * vty 195 admin idle
Interface Note User Mode Idle Location 00:00:30 200.200.1.50 00:00:00 200.200.1.51 Idle Peer Address
The two connections are coming from two different addresses in the NAT pool range. Most likely they are the first two addresses in the range, but it is possible that another PC on the inside sent packets to the outside before the Telnet sessions were originated, and hence were assigned addresses in the NAT table first.
17.4. Return to the Admin PC and use PuTTY to launch an SSH connection to the DMZ Server. Authenticate as administrator with the password cisco. 17.5. In the SSH connection to the DMZ server from the Admin PC, use the netstat n command to display the DMZ servers connection table:
C:\WINNT\system32>netstat -n Active Connections Proto TCP TCP TCP TCP TCP TCP TCP
Note
There should be a connection to port 22 on the DMZ Server from a high numbered port on the Admin PC. The NAT Exemption rule specifies to not use translation for sessions between the inside and the DMZ.
17.6. In the SSH connection to the ASA on the Admin PC, use the show xlate command:
GKL-ASA# show xlate 2 in use, 4 most used Global 200.200.1.50 Local 10.10.10.10 Global 200.200.1.51 Local 10.10.1.10
Note The global address assigned to the Admin PC (10.10.10.10) and the Data Server (10.10.1.10) should match those seen connecting to the Internet Router.
17.7. In the SSH connection to the ASA on the Admin PC, use the show conn command:
GKL-ASA# show conn 5 in use, 8 most used
TCP out 172.16.1.15:22 in 10.10.10.10:19284 idle 0:00:03 bytes 4812 flags UIO TCP out 100.100.1.1:23 in 10.10.10.10:19036 idle 0:02:26 bytes 183 flags UIO TCP out 100.100.1.1:23 in 10.10.1.10:4048 idle 0:02:22 bytes 542 flags UIO
17.8. Close the Telnet connections to Internet Router on both the Admin PC and the Data Server. Also close the SSH connection to the DMZ server on the Admin PC.
18.3. Click Apply. The Preview CLI Commands window should display the following command. If what is shown appears correct click Send. If it is incorrect, click Cancel and retrace the past few steps.
static (dmz,outside) 200.200.1.15 172.16.1.15 netmask 255.255.255.255 tcp 0 0 udp 0
19. Verify that connections from the DMZ Server to the outside appear to be sourced from 200.200.1.15 to the systems on the outside: 19.1. Use a Command Prompt window on the DMZ Server to telnet to the Internet Router (100.100.1.1), authenticating as admin with the password admin$pwd.
19.2. Use the show users command on the Internet Router to verify where the connection is coming from:
InternetRouter>show users Line User Host(s) * vty 194 admin idle
Interface Note User Mode Idle Location 00:00:00 200.200.1.15 Idle Peer Address
The source of the connection is the DMZ Servers static translation address.
19.3. Close the Telnet connection on the DMZ Server. 20. Verify that the DMZ Server is not reachable from the outside: 20.1. Access the desktop of the Outside PC. 20.2. Launch Firefox on the Outside PC.
20.3. Attempt to browse www.gkl.com. This will fail. Note that while Firefox is attempting the connection, Looking up www.gkl.com is displayed in the lower left hand corner of the Firefox window. Not only is the DMZ Server the Global Knowledge Labs web server, its also the authoritative dns server for gkl.com domain. If the DMZ server is unreachable, DNS fails for gkl.com. 20.4. Attempt to browse again, except this time enter the translated address of the DMZ Server (200.200.1.15) instead of its hostname. This will also fail.
Note The DMZ Server is unreachable to systems on the outside because it requires traversing the ASA from a lower security interface (outside, security level 0) to a higher security interface (dmz, security-level 50). It requires the use of ACLs to allow exceptions to this policy. ACLs will be covered in a later SNAF lab.
22. You can graphically verify the NAT rules configuration by examining the NAT Rules table under Configuration > Firewall > NAT Rules. The table should look like this:
23. 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. 23.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 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 L3-19 Global Knowledge Training LLC
Lab Complete
L4
ACLs and Object Groups
Lab Overview
In this lab you will configure access policy through the ASA. The policy will allow access to the public services running on the DMZ Server from the outside. It will also be very restrictive on what connections are allowed to originate from the DMZ Server. Policy from the internal network will be unrestricted. While configuring and testing policy you will also be introduced to Object Groups, the Packet Tracer and ICMP Inspection.
Lab Procedures
1. Prepare for this Lab 2. Configure Inbound HTTP Access 3. Complete Inbound Policy using Object Groups 4. Configure Policy from the DMZ 5. Verify the ASA Configuration
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. 2. Establish an SSH connection to the ASA from the Admin PC: 2.1. Launch PuTTY on the Admin PC.
2.2. Double click on the GKL-ASA saved session. 2.3. Log in as admin with the password admin$Pwd. 2.4. Use the enable command and the password san-fran to reach privileged mode. 2.5. Use the configure terminal command to reach global configuration mode.
Note
All three interfaces show the implied deny ip any any at the bottom of their policies. If there isnt a permit rule that applies above this implicit deny ip any any, the connection will be blocked. The dmz and inside interfaces also show an implied permit ip any any (less secure network). This allows outbound connections to establish. This rule doesnt appear on the outside interface because it has a security level 0 - there are no less secure networks. These rules are all implicit there are no configuration commands to explicitly define his policy.
Note
Note
5. Add a rule that allows HTTP access to the DMZ Server from the simulated Internet: 5.1. Select the outside interface from the Access Rules table. 5.2. Click Add. The Add Access Rule window opens, with the outside interface already selected. Complete the definition as follows: x x x x x x x x Interface: outside Action: Permit Source: any Destination: 200.200.1.15 Service: tcp/http Check Enable Logging Logging Level: Default Click OK.
5.2.2. Verify that the rule appears as follows in the Access Rules table:
5.2.3. Click Apply. The Preview CLI Commands window should display commands like those following. If what is shown appears correct click Send. If it is incorrect, click Cancel and retrace the past few steps.
access-list outside_access_in line 1 extended permit tcp 0.0.0.0 0.0.0.0 host 200.200.1.15 eq http access-group outside_access_in in interface outside
Note The naming convention for ACLs that are generated by ASDM for application to interfaces is interface-name_access_direction-of-application
6. Test access to the DMZ Server from the Internet: 6.1. Go to the desktop of the Outside PC. 6.2. Attempt HTTP access: 6.2.1. Launch Firefox on the Outside PC.
6.2.2. Attempt to browse the DMZ Server using its static translation 200.200.1.15. The DMZ Servers web page (www.gkl.com) should be displayed. 6.3. Attempt FTP Access: 6.3.1. Launch a Command Prompt window on the Outside PC:
6.3.2. Attempt the command ftp 200.200.1.15. This should time out, only HTTP access is allowed by the ASA. Use the command bye to exit the FTP client application. 7. Run a port scan against the DMZ Server to verify only HTTP access is allowed: 7.1. On the Outside PC, launch the Nmap GUI via Start > Programs > Nmap > Nmap Zenmap GUI. 7.2. Configure the scan as follows: x x x Target: 200.200.1.15 Profile: Regular Scan Command: Add PN to the end of the command. This instructs Nmap not to require a ping (ICMP echo) response before scanning.
7.3. Click Scan. 7.4. Examine the output. It should indicate that the only open port is HTTP.
L4-5 Global Knowledge Training LLC
8. Attempt HTTP access via hostname: 8.1. Return to the Firefox window on the Outside PC. 8.2. Instead of browsing 200.200.1.15, attempt to browse www.gkl.com. This will fail.
Note You may notice during the attempt, Firefox displays Looking up www.gkl.com in the lower left corner of its window. It is attempting a DNS lookup. The DMZ server is the authoritative DNS server for the domain gkl.com. You havent allowed DNS queries to it yet!
8.3. Return to ASDM running on the Admin PC. 8.3.1. Select Home in ASDM. 8.3.2. Examine the Latest ASDM Syslog Messages section at the bottom of the ASDM Home page. You should see some messages similar to the following: 50.50.50.50 200.200.1.15 Deny udp src outside:50.50.50.50/1028 dst dmz:200.200.1.15/53 by access-group "outside_access_in"
Note The syslog messages offer more proof that lack of DNS support is to blame. 50.50.50.50 (the Services-R-Us Server which is the DNS server for the Outside PC) is attempting a DNS request (UDP port 53) to 200.200.1.15 which is the known authoritative DNS server for gkl.com.
For the services for which the ASA recognizes a port-literal name, the TCP services are grouped first, followed by UDP, followed by ICMP. Within a protocol grouping, the services are sorted alphabetically by the port-literal name.
9.4. Note tcp/http is already included in the Selected Service field. Double click on each of the following to add them to the list: TCP ftp, TCP smtp, UDP domain, and ICMP echo. 9.5. With tcp/http, tcp/ftp, tcp/smtp, udp/domain and icmp/echo in the Selected Service field, click OK. 9.6. ASDM should now display the rule applying for all of these services:
9.7. In ASDM, click Apply. 9.8. The configuration modification that ASDM is proposing should look similar to this:
object-group service DM_INLINE_SERVICE_1 service-object icmp echo service-object tcp eq ftp service-object tcp eq http service-object tcp eq smtp service-object udp eq domain access-list outside_access_in line 1 extended permit object-group DM_INLINE_SERVICE_1 0.0.0.0 0.0.0.0 host 200.200.1.15 no access-list outside_access_in line 2 extended permit tcp 0.0.0.0 0.0.0.0 host 200.200.1.15 eq http
Note Note The name of the object group starts with DM_INLINE. As you will see, this causes this object group to be masked out of ASDMs normal object tables. Beyond DM_INLINE, ASDM doesnt apply a very useful name (SERVICE_1 has little meaning to the administrator).
9.9. Click Send. ASDM should now display the rule applying for all of these services:
Note
The benefit of letting ASDM create object groups from within Access Rules definition is readability within the Access Rules table. It is very clear what services are being allowed to the DMZ Server.
10. Define your own service object group with ASDM that defines the same set of services: 10.1. In ASDM, navigate to Configuration > Firewall > Objects > Service Groups.
Note The object group DM_INLINE_SERVICE_1 is not displayed here. The fact that its name starts with DM_INLINE causes it to be masked out by ASDM.
10.2. Click Add > Service Group. 10.3. Define the new service group in the Add Service Group window as follows: x x x Group Name: DmzServerServices Description: Services permitted to the DMZ Server from the outside. One at a time, in the Existing Service/Service Groups table, select TCP ftp, TCP http, TCP smtp, UDP domain (DNS) and ICMP echo. For each, either double click or select and click Add to move them to the Members in Group table. Click OK.
10.4. On the Service Groups table, click the + icon to expand the service group definition. Verify that it appears as follows:
10.5. Click Apply. The Preview CLI Commands window should display commands like those following. If what is shown appears correct click Send. If it is incorrect, click Cancel and retrace the past few steps.
object-group service DmzServerServices description Services permitted to the DMZ Server from the outside. service-object icmp echo service-object tcp eq ftp service-object tcp eq http service-object tcp eq smtp service-object udp eq domain
11. Reference the new object group from the outside_access_in ACL: 11.1. In ASDM, return to Configuration > Firewall > Access Rules. 11.2. As before, double click the service object (where the service list is displayed) of the first line in the outside interface ACL:
11.4. In the Selected Service field, delete all the referenced services. 11.5. Scroll to the top of the table. Before the ASA Predefined services list are the Service Groups defined via Object Groups. Double click on DmzServerServices. 11.6. With only DmzServerServices in the Selected Service field, click OK. 11.7. The rule should now appear like this:
Note
An object group name DmzServerServices is much easier to understand than one named DM_INLINE_SERVICE_1 when reading the configuration from the CLI. However, it does not display in an expanded notation here in the Access Rules table, making it less easy to understand here.
11.8. As a compromise, ASDM can display the contents of object groups in the Access Rules table, but it can only display one at a time using a tool tip method. Hover your mouse pointer over DmzServerServices, the tool tip will pop up:
11.9. Click Apply. The Preview CLI Commands window should display commands like those following. If what is shown appears correct click Send. If it is incorrect, click Cancel and retrace the past few steps.
access-list outside_access_in line 1 extended permit object-group DmzServerServices 0.0.0.0 0.0.0.0 host 200.200.1.15 no access-list outside_access_in line 2 extended permit objectgroup DM_INLINE_SERVICE_1 0.0.0.0 0.0.0.0 host 200.200.1.15 no object-group service DM_INLINE_SERVICE_1
Note The ACL reference to the new DmzServerServices object-group is inserted and the ACL reference to the old DM_INLINE_SERVICE object group is removed and then the DM_INLINE_SERVICE object group is itself removed.
12. Verify the inbound policy using the Outside PC: 12.1. Return to the Outside PC: 12.2. Use Firefox to verify not only that HTTP is accessible, but also that DNS is functioning by browsing the hostname www.gkl.com. This should be successful. 12.3. Test FTP from a Command Prompt window on the Outside PC: 12.3.1.Access a Command Prompt window. 12.3.2.Enter the command ftp A ftp.gkl.com. This should succeed.
Note With the Windows FTP client, the A option automatically performs a login using the username anonymous. The option is case sensitive.
12.3.3.In the FTP session, use the dir command. If a directory list is displayed it means that FTP data connections are permitted. This should succeed. 12.3.4.Use the bye command to terminate the FTP client application. 12.4. From the command prompt window, use the command ping 200.200.1.15 to verify that ICMP echo is allowed to the DMZ Server. Replies should be received. 13. Uncover something that isnt working exactly correctly; SMTP transfers: 13.1. Launch Outlook Express on the Outside PC.
13.2.1.Click Create Mail. 13.2.2.In the New Message window, enter admin@gkl.com in the To: field and Test #1 in the Subject: field. Dont bother to enter any body text, simply click Send. 13.3. Verify status on the DMZ Server. 13.3.1.On the DMZ Server, select Start > Programs > hMailServer > hMailServer Administrator. 13.3.2.In the hMailServer Administrator application, select Status > Undelivered messages and click Refresh. 13.3.3.You should see a message from John Doe to Admin in the Undelivered Messages table. The DMZ Server is configured to forward email destined to gkl.com to the Data Server on the inside, but it isnt working. 13.3.4.For now, click Clear queue and Yes. Once things are properly configured, you will try to send email again from the Outside PC. 13.4. Return to ASDM on the Admin PC. 13.4.1.Select Home in ASDM. 13.4.2.In the Latest ASDM Syslog Message panel at the bottom of the window you should see some messages similar to the following:
Jun 09 2008 17:38:08 106001 172.16.1.15 10.10.1.10 Inbound TCP connection denied from 172.16.1.15/1060 to 10.10.1.10/25 flags SYN on interface dmz
Note The ASA currently does not allow connections from the dmz interface (security level 50) to the inside interface (security level 100).
14.2. In ASDM, return to Configuration > Firewall > Access Rules. 14.3. Select the dmz interface in the table.
Both rules currently applied to the dmz interface are implicit. The first allows connections to anywhere on less secure network interfaces (such as the outside interface with a security level 0) The second denies all other connections.
14.4. Click Add. The Add Access Rule window opens, with the dmz interface already selected. Complete the definition as follows: x x x x x x x x Interface: dmz Action: Permit Source: 172.16.1.15 Destination: 10.10.1.10 Service: tcp/smtp Check Enable Logging Logging Level: Default Click OK.
14.5. Verify the rules for the dmz interface now appear like this:
Note Note
The new rule allowing SMTP connections from the DMZ Server to the Data Server appears. The implicit rule permitting connections to all less secure networks has disappeared. The explicit rules will override that implicit rule.
14.6. Click Add. The Add Access Rule window opens, with the dmz interface already selected. Complete the definition as follows: x x x x x x x x Interface: dmz Action: Permit Source: 172.16.1.15 Destination:192.43.244.18 Service: udp/ntp Check Enable Logging Logging Level: Default Click OK.
14.7. Verify that the rules assigned to the dmz interface now appear as follows:
14.8. Click Apply. The Preview CLI Commands window should display commands like those following. If what is shown appears correct click Send. If it is incorrect, click Cancel and retrace the past few steps.
access-list dmz_access_in line 1 extended permit tcp host 172.16.1.15 host 10.10.1.10 eq smtp access-list dmz_access_in line 2 extended permit udp host 172.16.1.15 host 192.43.244.18 eq ntp access-group dmz_access_in in interface dmz
15. Verify the policy for the dmz interface: 15.1. Verify SMTP: 15.1.1.Return to the Outside PC. 15.1.2.Return to Outlook Express on the Outside PC 15.1.3.Click Create Mail. 15.1.4.In the New Message window, enter admin@gkl.com in the To: field and Test #2 in the Subject: field. Dont bother to enter any body text, simply click Send. 15.1.5.Return to the Admin PC. 15.1.6.Launch Outlook Express. 15.1.7.Select Inbox. The email should already be waiting for you. If not, try clicking Send/Recv.
15.1.8.Select the Test #2 email and click Reply. Dont bother editing the body, simply click Send. 15.1.9.Return to Outlook Express on the Outside PC. Click Send/Recv. The reply Re: Test #2 should appear in the Inbox. 15.2. Verify NTP: 15.2.1.Access the desktop of the DMZ Server. 15.2.2.Right-click on the Automachron icon in the status tray and select Properties.
15.2.3.Click the <> button to expand the display. 15.2.4.Click the Sync button. If data appears in the Reference, Originate, Receive and Transmit fields, then NTP communications are working. If those fields are blank, NTP is not functional. 15.2.5.Close the Automachron window. 15.3. Verify that other outbound connections are not allowed from the DMZ Server. 15.3.1.On the DMZ Server, launch the Nmap GUI via Start > Programs > Nmap > Nmap Zenmap GUI. 15.3.2.Configure the scan as follows: x x x Target: 50.50.50.50 Profile: Regular Scan Command: Add PN to the end of the command. This instructs Nmap not to require a ping (ICMP echo) response before scanning.
15.3.3.Click Scan. 15.3.4.Examine the output. It should indicate that there are no open TCP ports. The ASA policy isnt allowing any connections to the outside. 15.3.5.Modify the Target field to be the Data Server (10.10.1.10) and add the PN back to the Command field.
15.3.6.Click Scan. 15.3.7.Examine the output. The only open port that should be listed is 25/tcp, smtp.
L4-14 Global Knowledge Training LLC
18. Use the Packet Tracer to predict what happens with ICMP packets: 18.1. In ASDM, select Configuration > Firewall > Service Policy Rules. 18.2. Select the inspection_default policy, and then click Packet Trace 18.3. Define the first trace as follows: x x x x x x x Interface: outside Packet Type: ICMP Source IP Address: 150.150.1.20 Destination IP Address: 200.200.1.15 Type: echo Code: 1 ID: 1 .
18.4. Click Start. The Preview CLI Commands shows the packet-tracer command that will be deployed. Click Send. 18.5. The animation will show step by step how the ASA would process the packet. The end result should show that the packet is allowed. 18.6. Define the second trace as follows: x x x x x x x Interface: dmz Packet Type: ICMP Source IP Address: 172.16.1.15 Destination IP Address: 150.150.1.20 Type: echo-reply Code: 1 ID: 1
18.7. Click Start. The Preview CLI Commands shows the packet-tracer command that will be deployed. Click Send. 18.8. The animation will show step by step how the ASA would process the packet. The end result should show that the packet is dropped. 18.9. In the Packet Tracer window, expand the ACCESS-LIST phase. From the details displayed you can see the packet is denied by the Config via an Implicit Rule. 18.10. Click Show rule in Access Rules Table. The main ASDM window will be displayed, with the implicit deny ip any any rule on the dmz interface highlighted. 19. One option for addressing this would be to add a rule which explicitly permitted ICMP echoreply to the dmz interface. Until the PIX/ASA operating system 7.0, this was the only method available. Starting with 7.0, the ability to use stateful inspection for ICMP is available. It is not, however, enabled by default. Add ICMP to the default stateful inspection protocols as follows: 19.1. In ASDM, select Configuration > Firewall > Service Policy Rules. 19.2. Highlight the only policy in the table, named inspection_default, and click Edit. 19.3. In the Edit Service Policy Rule window, select the Rules Actions tab and then select the Protocol Inspection sub-tab. 19.4. The protocols that can be inspected are listed, with the ones that are being inspect checked. Check ICMP and click OK.
19.5. Click Apply. The Preview CLI Commands window should display commands like those following. If what is shown appears correct click Send. If it is incorrect, click Cancel and retrace the past few steps.
policy-map global_policy class inspection_default inspect icmp
20. Verify that the DMZ server is now, once again pingable. Also, verify that systems on the inside can ping systems on the outside: 20.1. Go to the Outside PC, and use a Command Prompt window to ping the DMZ Server (200.200.1.15). This should succeed. 20.2. Go to the Admin PC and use a Command Prompt window to ping the DMZ Servers internal IP address (172.16.1.15). This should also succeed. 20.3. Last, from the Admin PC, ping the Outside PC (150.150.1.20). This should also succeed.
Lab Complete