ASA Lab Guide

SMB Security - ASA v1.0 Lab Guide L5698C-001-1 November 2008 by Global Knowledge

SNAF v1.0 Lab Guide L5698C-001-1 November 2008

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.

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] 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

SNAF v1.0 Lab Guide © Global Knowledge

TOC-1

Table of Contents

TOC-2 SMB Security - ASA v1.0 Lab Guide Global Knowledge

.1

Data-Srv 10.10.1.10

2K3

10.10.1.0/24 Data Center Subnet (5)

Management Subnet(6) 10.10.2.0/24

2K3 10.10.2.10

Security-Srv

DMZ-Srv (3) 172.16.1.15 NAT: 200.200.1.15 www.gkl.com

2K

DMZ Subnet 172.16.1.0/24

Perimeter Router

.1

GKL-ASA

XP

L3-Switch

User-PC 10.10.10.20

XP

(7)

10.10.10.0/24 End User Subnet

.1

Admin-PC 10.10.10.10

.1

.1

.2

(4)

10.10.0.0/24 Inside Perimeter

.1

.2

(2)

.1 (10) 100.100.1.0/30

Outside Perimeter 200.200.1.0/24

.2

SNAF 1.0 Topology

BT2

BackTrack2 (location & IP Varies)

.1

200.200.20.2

INTERNET

time.nist.gov 192.43.244.18

.1

(11)

www.sru.com

Services-R-Us

(16) 50.50.50.50

2K3

50.50.50.0/24

2K

Outside-PC 150.150.1.20 pc.outside.net

(Indicates VLAN #)

Site1-PC 10.20.10.10

XP

10.20.10.0/24 (13)

.1

150.150.1.0/24

.1

Data-Srv 10.10.1.10

2K3

10.10.1.0/24 Data Center Subnet (5)

Management Subnet(6) 10.10.2.0/24

2K3 10.10.2.10

Security-Srv

DMZ-Srv (3) 172.16.1.15 NAT: 200.200.1.15 www.gkl.com

2K

DMZ Subnet 172.16.1.0/24

Perimeter Router

.1

GKL-ASA

XP

L3-Switch

User-PC 10.10.10.20

XP

(7)

10.10.10.0/24 End User Subnet

.1

Admin-PC 10.10.10.10

.1

.1

.2

(4)

10.10.0.0/24 Inside Perimeter

.1

.2

(2)

.1 (10) 100.100.1.0/30

Outside Perimeter 200.200.1.0/24

.2

SNAF 1.0 Topology

BT2

BackTrack2 (location & IP Varies)

.1

200.200.20.2

INTERNET

time.nist.gov 192.43.244.18

.1

(11)

www.sru.com

Services-R-Us

(16) 50.50.50.50

2K3

50.50.50.0/24

2K

Outside-PC 150.150.1.20 pc.outside.net

(Indicates VLAN #)

Site1-PC 10.20.10.10

XP

10.20.10.0/24 (13)

.1

150.150.1.0/24

L0 Introduction to the Remote Lab System

L0-1 © Global Knowledge Training LLC

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.

Estimated Completion Time 20 minutes

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

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. L0-3 © Global Knowledge Training LLC


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.



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. 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 server’s 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 VM’s 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 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.



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.



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.



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 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

Note

User

Idle 00:00:00 Mode

Idle

Location

Peer Address

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 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


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



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 sanfran. 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.



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: 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] [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]

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 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 L1-4 © Global Knowledge Training LLC

Preparing the ASA for Administration 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-SSLmPLUS-2.01 IPSec microcode : CNlite-MC-IPSECmMAIN-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? ______________________

x

What is the ASA Model Number? ________________________________ L1-5

© Global Knowledge Training LLC


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: 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

Preparing the ASA for Administration hostname ciscoasa 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 mgcppat 0:05:00 timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sipdisconnect 0:02:00 timeout uauth 0:05:00 absolute dynamic-access-policy-record DfltAccessPolicy L1-7 © Global Knowledge Training LLC

Preparing the ASA for Administration 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. L1-8 © Global Knowledge Training LLC


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]? Firewall Mode [Routed]: Enable password []: san-fran Allow password recovery [yes]? Clock (UTC): Year [YYYY]: Month [Mmm]: Day [DD]: Time [HH:MM:SS]: 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 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 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 [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 GKL-ASA(config)# aaa authentication ssh console LOCAL


Preparing the ASA for Administration 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.



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. 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.

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 L1-14 © Global Knowledge Training LLC

Preparing the ASA for Administration 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 mtu inside 1500 no failover icmp unreachable rate-limit 1 burst-size 1 asdm image disk0:/asdm-603.bin 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 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 mgcppat 0:05:00 timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sipdisconnect 0:02:00 timeout uauth 0:05:00 absolute 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 snmp-server enable traps snmp authentication linkup linkdown coldstart 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 threat-detection statistics access-list ! class-map inspection_default L1-15 © Global Knowledge Training LLC

Preparing the ASA for Administration 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

Lab Complete


L2 Initial ASA Configuration


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 ASA’s configuration 6. The Packet Capture Wizard 7. Verify the ASA Configuration


Initial ASA Configuration 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

x

Select Use the Following IP Address



x

o

IP Address: 200.200.1.2

o

Subnet Mask: 255.255.255.0 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



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

x

o

IP Address: 172.16.1.1

o

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

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

x

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 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 *~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.

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. 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

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. 13. On the Admin PC, launch Firefox.



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 browser’s refresh button 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

x

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.

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 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.

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. 16.2. Return to the PHP-Kiwi Syslog display

.



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.



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.

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. L2-13 © Global Knowledge Training LLC

Initial ASA Configuration : 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 L2-14 © Global Knowledge Training LLC

Initial ASA Configuration icmp unreachable rate-limit 1 burst-size 1 asdm image disk0:/asdm-602.bin 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 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 mgcppat 0:05:00 timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sipdisconnect 0:02:00 timeout uauth 0:05:00 absolute 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 snmp-server enable traps snmp authentication linkup linkdown coldstart 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 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 rsh inspect rtsp inspect esmtp inspect sqlnet inspect skinny L2-15 © Global Knowledge Training LLC

Initial ASA Configuration inspect inspect inspect inspect inspect

sunrpc xdmcp sip netbios 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

Lab Complete


L3 Translations and Connections


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 ASA’s 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


Translations and Connections 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 after a lab reset. 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 and establish trust which will minimize the recurrence of security warnings during the lab operation, until the next reset operation is performed.

Prepare for this Lab This lab utilizes makes use of ASDM as well as the CLI. You must establish both an ASDM connection as well as an SSH connection to the ASA. 1. Launch ASDM on the Admin PC: 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. 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.

Understanding NAT Control and NAT 0 At this point, the ASA is allowing sessions to establish from higher security lower interfaces to lower security interfaces. But, there are two different mechanisms in place which are allowing this. One is that NAT Control has been disabled globally, the other is that a NAT 0 statement has been applied to the inside interface. In this section of the lab you will explore the differences between these two methods, as well as see how to view entries in the translation and connection tables.



3. Under the current configuration, the Admin PC can reach the DMZ Server, but it can’t reach anything on the outside. Well, actually, it can reach systems on the outside, but without NAT the systems on the outside don’t 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 doesn’t know how to get back to the Admin PC, this must be done from the Perimeter Router’s 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 PC’s untranslated 10.10.10.10 address: PERIM#show users Line User 0 con 0 admin *514 vty 0 admin Interface

Host(s) idle idle

User

Idle Location 00:13:23 00:00:00 10.10.10.10 Mode

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

Interface

User admin admin admin User


Host(s) idle idle idle

Idle Location 00:00:45 00:00:27 10.10.10.10 00:00:00 10.10.10.10 Mode

Idle

Peer Address


6.3. Examine the ASA’s 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 PC’s 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 PC’s 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 ASA’s connection table via the CLI: 6.4.1. Use the show conn command to view the ASA’s 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)

Note

You may find that there are more connections when you issue the command. Again, these are most likely from outbound NTP or DNS attempts.

Note

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 server’s public key to the client and passing of the encrypted session key from the client to the server.

Note

Show conn also displays flags. As with show xlate, including using the detail argument will display the meaning of the flags.



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.

Note

The count displayed (5 in use in the example above) doesn’t seem to correlate with the output (which only shows 2 connections). By default, show conn doesn’t display the connections to and from the ASA itself. To include the connections to and from the ASA, use show conn all.

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

Interface

User admin admin admin admin

Host(s) idle idle idle idle

User

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 Mode

Idle

Peer Address

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

There are translations from the inside 10.10.0.0 network space, but there is not a translation for 172.16.1.15.

Note

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 ASA’s configuration. There is no corresponding command associated with the dmz interface.

Note

The reason the DMZ Server has outbound access, without translation, is due to the no nat-control command in the ASA’s configuration. But this does not cause dynamic entries to be placed in the translation table.

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

Note

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 -

There should be at least 3 connections in the connection table: two telnet and one SSH connection to the Perimeter Router.


Translations and Connections Note

The connection from the DMZ Server is in the state table. Turning off nat-control does not turn off stateful inspection.

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.

Note

This translation entry will timeout after 3 hours of inactivity, or it can be removed immediately with the clear xlate command.

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 ASA’s 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 can’t 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

Original: o

Interface: inside

o

Source: 10.10.0.0/16 (Be careful not to select /24!)

x

Translated: o

Click Manage, then click Add.

o

Interface: outside

o

Pool ID: 1

o

Select Port Address Translation (PAT) using IP Address of the interface and click Add.

o

Click OK, click OK.

x

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

Original: o

Interface: dmz

o

Source: 172.16.1.0/24

x

Translated: o

x

Select Pool ID 1 defined previously. Click OK.

SNAF v1.0 Lab Guide © Global Knowledge Training LLC

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

tcp 0 0 udp 0 tcp 0 0 udp 0

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 ASA’s 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

Idle Location 00:04:11 200.200.1.2 00:00:00 200.200.1.2 Mode

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

Local Address 10.10.10.10:4728 10.10.10.10:6612 10.10.10.10:6671 127.0.0.1:1038

Foreign Address 10.10.0.1:22 10.10.0.1:443 100.100.1.1:23 127.0.0.1:47007

State ESTABLISHED ESTABLISHED ESTABLISHED CLOSE_WAIT

Note

There should be several entries in the Admin PC’s 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).

Note

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.

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.

Configure Dynamic NAT and NAT Exemption In this section of the lab you will configure dynamic NAT translation as is appropriate for other standard lab scenarios. You will allow all 10.10.0.0/16 addresses on the inside interface to be translated the pool 200.200.1.50 – 200.200.1.100 on the outside interface. You will also configure a NAT Exemption for the same range of addresses on the in the inside interface when communicating with the DMZ subnet. 15. Configure Dynamic NAT between the inside and outside interfaces: 15.1. In ASDM, verify that you are at Configuration > Firewall > NAT Rules. 15.2. Click Add > Add Dynamic NAT Rule. 15.3. Define the NAT Rule as follows: x

Original o

Interface: inside

o

Source: 10.10.0.0/16

x

Translated o

Note that Pool ID 1 on the outside interface translating to the outside interface address is still present. It isn’t required anymore. The easiest way to proceed is to edit it specifying a new pool:

o

Click Manage.

o

Select Pool ID 1 and click Edit.

o

Under Address Pool, select outside and click Delete.

o

Under IP Addresses to Add, select Range and enter 200.200.1.50 as the Starting IP Address and 200.200.1.100 as the Ending IP Address, then click Add.

o

Click OK, OK, OK.



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

Action: Exempt

x

Original o

Interface: inside

o

Source: 10.10.0.0/16

o

Destination: 172.16.1.0/24 (which becomes dmz-network/24)

x

NAT Exempt Direction: NAT Exempt outbound traffic…

x

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

Idle Location 00:00:30 200.200.1.50 00:00:00 200.200.1.51 Mode

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 server’s connection table: C:\WINNT\system32>netstat -n Active Connections Proto TCP TCP TCP TCP TCP TCP TCP Note

Local Address 127.0.0.1:1030 127.0.0.1:1032 127.0.0.1:1033 127.0.0.1:1034 127.0.0.1:1141 127.0.0.1:3307 172.16.1.15:22

Foreign Address 127.0.0.1:3307 127.0.0.1:3307 127.0.0.1:3307 127.0.0.1:3307 127.0.0.1:3307 127.0.0.1:1030 10.10.10.10:19284

State ESTABLISHED CLOSE_WAIT CLOSE_WAIT CLOSE_WAIT CLOSE_WAIT ESTABLISHED ESTABLISHED

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.

Configure Static NAT The purpose of the DMZ Server is to provide public services such as FTP, HTTP, DNS and SMTP to systems on the Internet. To perform this function, it must have a persistent IP address so the systems on the Internet have a stable destination to reach. Hence a static translation is required. You will configure and test such a static translation in this section of the lab. 18. Configure the Static Translation: 18.1. In ASDM on the Admin PC, under Configuration > Firewall > NAT Rules, click Add > Add Static NAT Rule. 18.2. Define the Static NAT Rule as follows: x

Original: o

Interface: dmz

o

Source: 172.16.1.15

x

x

Translated: o

Interface: outside

o

Use IP Address: 200.200.1.15 Click OK.

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

Idle Location 00:00:00 200.200.1.15 Mode

Idle

Peer Address

The source of the connection is the DMZ Server’s 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, it’s 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.

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. 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

Translations and Connections no nameif no security-level no ip address management-only ! passwd 9jNfZuG3TC5tCVH0 encrypted ftp mode passive dns server-group DefaultDNS domain-name gkl.local access-list inside_nat0_outbound extended permit ip 10.10.0.0 255.255.0.0 172.16.1.0 255.255.255.0 pager lines 24 logging enable logging trap warnings logging asdm warnings logging host inside 10.10.2.10 mtu outside 1500 mtu inside 1500 mtu dmz 1500 no failover icmp unreachable rate-limit 1 burst-size 1 asdm image disk0:/asdm-603.bin no asdm history enable arp timeout 14400 nat-control global (outside) 1 200.200.1.50-200.200.1.100 netmask 255.255.255.0 nat (inside) 0 access-list inside_nat0_outbound nat (inside) 1 10.10.0.0 255.255.0.0 static (dmz,outside) 200.200.1.15 172.16.1.15 netmask 255.255.255.255 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 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 mgcppat 0:05:00 timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sipdisconnect 0:02:00 timeout uauth 0:05:00 absolute dynamic-access-policy-record DfltAccessPolicy aaa authentication ssh console LOCAL http server enable http 10.10.2.0 255.255.255.0 inside http 10.10.10.10 255.255.255.255 inside 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 L3-20 © Global Knowledge Training LLC

Translations and Connections 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 threat-detection statistics access-list 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 ! 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 inspect sunrpc inspect xdmcp inspect sip inspect netbios inspect tftp ! service-policy global_policy global prompt hostname context Cryptochecksum:c647578460ab85a8bec8f9dc69368424 : end asdm image disk0:/asdm-603.bin no asdm history enable

Lab Complete




L4 ACLs and Object Groups


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


ACLs and Object Groups 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 after a lab reset. 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 and establish trust which will minimize the recurrence of security warnings during the lab operation, until the next reset operation is performed.

Prepare for this Lab This lab utilizes makes use of ASDM as well as the CLI. You must establish both an ASDM connection as well as an SSH connection to the ASA. 1. Launch ASDM on the Admin PC: 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. 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.

Configure Inbound HTTP Access In this section of the lab you will allow inbound HTTP access to the DMZ Server from the simulated Internet. You will start by viewing the default policy that is in place via ASDM. You will then use ASDM to implement a single line ACL permitting HTTP to the DMZ Server. You will then test the results. 3. In ASDM, select Configuration > Firewall > Access-Rules.



4. Examine the rules that are currently in place:

Note

All three interfaces show the implied deny ip any any at the bottom of their policies. If there isn’t a permit rule that applies above this implicit deny ip any any, the connection will be blocked.

Note

The dmz and inside interfaces also show an implied permit ip any any (less secure network). This allows outbound connections to establish. This rule doesn’t appear on the outside interface because it has a security level 0 - there are no less secure networks.

Note

These rules are all implicit – there are no configuration commands to explicitly define his policy.

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

Interface: outside

x

Action: Permit

x

Source: any

x

Destination: 200.200.1.15

x

Service: tcp/http

x

Check Enable Logging

x

Logging Level: Default

x

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 Server’s 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

Target: 200.200.1.15

x

Profile: Regular Scan

x

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 haven’t 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.

Complete Inbound Policy using Object Groups In this section of the lab you will complete the inbound policy configuration on the ASA. You will use an Object Group to complete this task. Allowed connections to the DMZ server will include HTTP, FTP, SMTP, DNS and ICMP echo. During execution of this section of the lab you will experiment with letting ASDM generate object groups for you as well as creating object groups manually. You will see that there are ramifications to readability and maintainability with both methods. You will finish this section of the lab implementing a pair of compromises between the two methods. 9. Implement a service object group, letting ASDM create it for you: 9.1. In ASDM, return to Configuration > Firewall > Access Rules. 9.2. Double click the service object (which currently only contains TCP/http) of the first line in the outside interface ACL:



9.3. Click the Ellipsis Note

button that appears. The Browse Service window opens.

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

The name of the object group starts with DM_INLINE. As you will see, this causes this object group to be masked out of ASDM’s normal object tables.

Note

Beyond DM_INLINE, ASDM doesn’t 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

Group Name: DmzServerServices

x

Description: Services permitted to the DMZ Server from the outside.

x

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.

x

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.3. Click the Ellipsis

button that appears. The Browse Service window opens.

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 isn’t working exactly correctly; SMTP transfers: 13.1. Launch Outlook Express on the Outside PC.

13.2. Send an email from the Outside PC to [email protected]: L4-10 © Global Knowledge Training LLC


13.2.1.Click Create Mail. 13.2.2.In the New Message window, enter [email protected] in the To: field and Test #1 in the Subject: field. Don’t 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 isn’t 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).

Configure Policy from the DMZ As you’ve just demonstrated, the DMZ Server can’t currently forward email received from the Internet to the Data Server on the inside (the Data Server is the email server for clients on the inside). You must configure policy on the dmz interface allowing these TCP connections. But, in general, you want to be restrictive with what connections are allowed from the DMZ Server. If it gets compromised, you don’t want an attacker to use it to launch other attacks. In this section of the lab you will configure an ACL to be applied to the dmz interface. Besides allowing the inbound SMTP connections, the only other service available from the DMZ server will be NTP requests to time.nist.gov. 14. Configure a policy for the DMZ interface that: x x x

Allows SMTP connections from the DMZ Server to the Data Server Allows NTP requests from the DMZ Server to time.nist.gov Denies all other connections originating on the DMZ interface



14.2. In ASDM, return to Configuration > Firewall > Access Rules. 14.3. Select the dmz interface in the table.

Note

Both rules currently applied to the dmz interface are implicit.

Note

The first allows connections to anywhere on less secure network interfaces (such as the outside interface with a security level 0)

Note

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

Interface: dmz

x

Action: Permit

x

Source: 172.16.1.15

x

Destination: 10.10.1.10

x

Service: tcp/smtp

x


x


x

Click OK.

14.5. Verify the rules for the dmz interface now appear like this:

Note

The new rule allowing SMTP connections from the DMZ Server to the Data Server appears.

Note

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

Interface: dmz

x

Action: Permit

x

Source: 172.16.1.15

x

Destination:192.43.244.18

x

Service: udp/ntp

x


x


x

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 [email protected] in the To: field and Test #2 in the Subject: field. Don’t 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. Don’t 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

Target: 50.50.50.50

x

Profile: Regular Scan

x

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 isn’t 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


16. Close any remaining open windows on the DMZ Server.

Configure ICMP Policy In an earlier section you allowed ICMP echo to the DMZ Server from the outside. You even tested that it worked by pinging the DMZ Server from the Outside PC. Configuring the ACL on the dmz interface, however, has broken this capability. In this section of the lab you will explore the behavior of ICMP through the ASA and configure a policy allowing the DMZ Server to be pinged from anywhere and to allow users on the inside to initiate ping requests. 17. Verify that an attempt to ping the DMZ Server (200.200.1.15) from the Outside PC now fails. 17.1. After attempting the ping from the Outside PC, return to the Admin PC. 17.2. In ASDM, select Home. 17.3. Look in the Latest ASDM Syslog Messages table on the ASDM home page. Verify there is a message similar to the following message, indicating that an ICMP echo reply (ICMP type 0) was blocked from the DMZ Server’s non-translated address (172.16.1.15). 4 Jun 09 2008 19:45:18 106023 172.16.1.15 150.150.1.20 Deny icmp src dmz:172.16.1.15 dst outside:150.150.1.20 (type 0, code 1) by access-group "dmz_access_in" [0x0, 0x0] Note

The echo requests are allowed from the outside to the DMZ Server, it is the echo replies from the DMZ Server that are being blocked.

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

Interface: outside

x

Packet Type: ICMP

x

Source IP Address: 150.150.1.20

x

Destination IP Address: 200.200.1.15

x

Type: echo

x

Code: 1

x

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

Interface: dmz

x

Packet Type: ICMP

x

Source IP Address: 172.16.1.15

x

Destination IP Address: 150.150.1.20

x

Type: echo-reply

x

Code: 1

x

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 Server’s 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.

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. : Saved : ASA Version 8.0(3) ! hostname GKL-ASA domain-name gkl.local enable password Rjwipa01sHSnXKAp encrypted names ! interface GigabitEthernet0/0 nameif outside L4-17 © Global Knowledge Training LLC

ACLs and Object Groups 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 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 www service-object tcp eq smtp service-object udp eq domain access-list inside_nat0_outbound extended permit ip 10.10.0.0 255.255.0.0 172.16.1.0 255.255.255.0 access-list outside_access_in extended permit object-group DmzServerServices any host 200.200.1.15 access-list dmz_access_in extended permit tcp host 172.16.1.15 host 10.10.1.10 eq smtp access-list dmz_access_in extended permit udp host 172.16.1.15 host 192.43.244.18 eq ntp pager lines 24 logging enable logging trap warnings logging asdm warnings logging host inside 10.10.2.10 L4-18 © Global Knowledge Training LLC

ACLs and Object Groups mtu outside 1500 mtu inside 1500 mtu dmz 1500 no failover icmp unreachable rate-limit 1 burst-size 1 asdm image disk0:/asdm-603.bin no asdm history enable arp timeout 14400 nat-control global (outside) 1 200.200.1.50-200.200.1.100 netmask 255.255.255.0 nat (inside) 0 access-list inside_nat0_outbound nat (inside) 1 10.10.0.0 255.255.0.0 static (dmz,outside) 200.200.1.15 172.16.1.15 netmask 255.255.255.255 access-group outside_access_in in interface outside access-group dmz_access_in in interface dmz 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 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 mgcppat 0:05:00 timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sipdisconnect 0:02:00 timeout uauth 0:05:00 absolute 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 snmp-server enable traps snmp authentication linkup linkdown coldstart 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 threat-detection statistics access-list 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 ! class-map inspection_default match default-inspection-traffic L4-19 © Global Knowledge Training LLC

ACLs and Object Groups ! ! 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 inspect icmp ! service-policy global_policy global prompt hostname context Cryptochecksum:aa187adca37f3ebfdad1e75f7e6e8f69 : end asdm image disk0:/asdm-603.bin no asdm history enable

Lab Complete


ASA Lab Guide

Recommend Documents