Passed the CCNA Security

I took and passed the CCNA Security yesterday!  I haven't completed the writeup yet for my site-site VPN lab but am still planning on posting it soon.  After I finish a few more of my CCNA Security related notes, I'm aiming to move on to working for the CCNP Security, and sharpening my programming abilities as I'd like to go for offensive security's OSCP.

Lab Reconfiguration
I've also decided to do some major reconfiguration to the lab that I designed originally.  I am fairly irritated with the slow speeds that I am stuck with using the 2600's and serial links, so I am currently overhauling my cisco lab.  I have decided to try using GNS3 to virtualize mostly everything, but with a twist.  I'll be using multiple GNS3 hosts within ESXi, and on a second physical host.  Following this method, I should be able to construct even more complex topologies without being limited on physical problems such as WIC cards and memory resources, and break out the virtual connections to my physical layer 3 switches and other physical devices such as my ASA and IPS 4260 appliance (yes I added another piece to my lab..)

Clearing Cisco Self Signed Certificates and Keys

Quick post here, for future reference for myself and anyone else with this issue.  As you know (or will find out), if you copy a config from one device to another, you'll need to generate new keys or certificates for both your SSH connection and HTTPS.  Another issue is if you are using CCP and accidentally happen to deny the use of one of your managed devices because you didn't trust the self signed cert with the CCP pop up window (I did this accidentally)  If you don't want to hunt for the cert in IE, and are using lab equipment, here are the quick and easy fixes for removing existing self signed RSA keys for both HTTPS and for SSH/general purpose keys:

First, launch a show run to find out the name of your self signed certificate.  This is for the example of regnerating your HTTPS certificate.  Then when you find the name, you can append a "no" in front of it.  If you need to generate a new SSH key,  I recommend doing this over a console connection so you don't lose your SSH connection.  Afterwhich you can regenerate the new keys.

My show run displayed this for the name, along with the beginning of key used for SSH

!
crypto pki trustpoint TP-self-signed-815397456
 enrollment selfsigned
 subject-name cn=IOS-Self-Signed-Certificate-815397456
 revocation-check none
 rsakeypair TP-self-signed-815397456
!
!
crypto pki certificate chain TP-self-signed-815397456
 certificate self-signed 01

  30820243 308201AC A0030201 02020101 300D0609 2A864886 F70D0101 04050030

I then used the following commands to wipe my existing self signed certificate and generate new RSA keys

ISP_1(config)#no crypto pki trustpoint TP-self-signed-815397456

% Removing an enrolled trustpoint will destroy all certificates

 received from the related Certificate Authority.

Are you sure you want to do this? [yes/no]: y

% Be sure to ask the CA administrator to revoke your certificates.

ISP_1(config)#crypto key zeroize rsa

% All RSA keys will be removed.

% All router certs issued using these keys will also be removed.

Do you really want to remove these keys? [yes/no]: y

ISP_1(config)#crypto key generate rsa

The name for the keys will be: ISP_1.isp.com

Choose the size of the key modulus in the range of 360 to 2048 for your

  General Purpose Keys. Choosing a key modulus greater than 512 may take

  a few minutes.

How many bits in the modulus [512]: 1024

% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]

ISP_1(config)#ip http secure-server

% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]

ISP_1(config)#

The issue I experienced, was I swapped hardware for my ISP and datacenter edge lab routers-my ISP router has a more advanced IOS image and more RAM, and with it I can run IOS IPS and the zone based firewall.  I just need the ISP router to route, and I wanted these security functions for my lab purposes.  So when I swapped the config files, I didn't paste in the keys (I'm using putty, and generally pasting in that much information causes..fun things to happen) but realized I needed to wipe my existing self signed cert and SSH keys and create new ones for both devices.

Lab Part 3: Secure the Routers

Overview
This part of the lab assumes that all of the routers in the topology below have configured routing protocols.  All three of the "corp owned" routers branch off the ISP_1 router (I know, no redundancy but I only have so many WIC cards to play with).  As seen in the more focused topology below, the corp owned routers and ISP_1 routers use OSPF area 1 for their routing protocol.  An area 0 backbone will later be added to expand the topology.  The corp_border router also runs EIGRP for the 207.100.100.0/27 network, and this route is redistributed into OSPF area 1.  Since this mostly delves back into basic CCNA R/S, I won't be reviewing how the routing was configured, but instead will be focusing on CCNA Security implementation topics.  The lab assumes completed routing, where the ASA can ping all of the external router interfaces.  Internal subnets will all utilize NAT to simulate a real world environment, as the ISP will be filtering all RFC1928 addresses from entering its interfaces.

Topology:

Security Policy
To give a roadmap or outline to the configurations, here is the basic security policy for the lab:
-Only administrators from the IP address 172.16.100.10 should have management access to corporation owned network equipment
-All network management tools and protocols will use encryption whenever possible
-Centralized authentication, authorization, and accounting must be used
-All edge routers will be hardened from outside attacks
-There will be no plaintext passwords stored on network config files
-All edge routers will shield their internal networks through the use of IOS software firewalls
-All logging will be centralized and encrypted in transit to the logging server
-A full mesh site to site VPN tunnel will be used across the enterprise edge routers

Lab Topics
This part of the lab covers the following:
Implement AAA
Implement security on Cisco routers
Implement zone based firewall policy using CCP
Implement IP ACLs
Implement secure network management

Implement AAA
We'll start by doing a mock configuration of AAA using CCP on the Corp border router.  Then we will implement a local user AAA config on all of the routers.  Remember from the CCNA that in order to use CCP, you need to have HTTP (preferably HTTPS) running, a local user on the router, and set http to authentication local.

CORP_BORDER(config)#ip http secure-server
CORP_BORDER(config)#ip http authentication local
CORP_BORDER(config)#username admin pri
CORP_BORDER(config)#username admin privilege 15 password cisco
CORP_BORDER(config)#do wr

Now we should be able to login via CCP and mock a setup of AAA using a TACACS+ server.  Throughout this lab, I am connected behind the Corp Border ASA.

A few bits of advice here in getting CCP to run correctly-I'm using Windows 7 64bit and IE 10 for my lab computer.  You need to install the java plugin for IE.  Additionally, you need to enable compatibility view on IE for CCP by adding your localhost address to the compatibility page (tools->compatibility view settings).  Last, you must launch CCP as administrator.  Otherwise you will be greeted by CCP freezing on "finding ports".

So first, when you get CCP running, you're presented with the select/manage community window.  Enter in the IP address for the router, followed by user/password, select the "connect securely" checkbox to connect over HTTPS (and for commands to be relayed via SSH and not telnet..), and click Ok.

After you add the device, you'll need to discover it by clicking the discover box at the bottom of the page.

Mine discovered with warnings-my routers are fairly old (2600XMs) so not everything within CCP is functional, but I have enough functionality for this lab.  To create the AAA configuration, select the Configure button and browse down to Router->AAA->AAA Summary.  Click on the Enable AAA button.

There will be a brief pause, followed by a second pop up window displaying the commands that will be sent over to the devices running configuration.  Click Deliver.  Now that there is a backup AAA command set in place, we'll configure the TACACS+ server line, and then create a method list for login and authentication via TACACS.  Click on the AAA Servers and Groups drop down folder in the navigation pane, and then select Servers.  Select Add.  You can then enter in an IP for the TACACS+ server, along with the secure key for authenticating the router against TACACS.  If you click Ok, it will show you that it will deliver the commands to the router:

tacacs-server host 172.16.100.105 key 0 ********

no ip tacacs source-interface

no tacacs-server timeout

I clicked cancel here, as I do not have a TACACS+ server, but to complete the mock configuration, you would next need to create the method list for authentication and exec authorization using TACACS+ as a method (and preferably local as a second method incase the TACACS server is unreachable..), and apply that method list to the desired interfaces.  You can do so by clicking "add" under AAA->Authentication-> Login and AAA->Authorization->Exec.  You simply define the methods you'd like to use, give it a name, and click ok.  To apply your custom method lists, you'll have to select Router Access->VTY and select your custom method lists to apply them against the VTY lines. 

I'm going to use a basic AAA configuration to use local authentication on all the routers.  First I'll create a local user, then I'll use the following 3 commands to apply the default method list against the console, VTY, and aux lines.  Don't forget to create a local user-it's never a fun experience to enable AAA, copy run start, exit the router, and have no local user to login with-or if you are using TACACS, not to have local defined as a second method.  Don't ask me how I know this.

CORP_BORDER(config)#aaa new-model

CORP_BORDER(config)#aaa authentication login default local

CORP_BORDER(config)#aaa authorization exec default local

Next, we'll harden and secure the edge routers.

Securing the Router with CCP
For certification purposes, I'll first cover securing the router with CCP.  You can either use the command line auto-secure command, use CCP's security Audit and then fix items individually, or use one step lock down to secure the router.  Using CCP, navigate down to Security->Security Audit

The wizard itself for the audit is fairly self explanatory.  At the end, you will be presented with your audit report.

You can either use one-step lock down, or fix the items individually.  If you were in a production environment, you'd probably want to just check the items individually to verify CCP doesn't break anything that you do in fact need.

I selected all, except enabling the firewall as this would enable the CBAC firewall on my older routers.

Implement Zone Based Firewall with CCP
Unfortunately, only one of my routers has the capability to run the ZBF.  The others only support CBAC.  So I'll walk through the configuration of the ZBF but will not be implementing it at this time.

To configure the ZBF in CCP, navigate to Security->Firewall->Firewall.

The wizard is fairly self explanatory-select your trusted inside and untrusted outside interfaces. For my purposes, I set all of but one of the serial interfaces to trusted.  Next you are presented with a screen with a slider bar to determine what level of security for the firewall to run.

Before completion, the wizard will display what commands will be relayed to the firewall.

Implement IP ACLs
Our mock ISP has a policy of prohibiting IRC traffic.  As a basic mitigation, ACLs will be applied inbound on all serial interfaces to try deny irc traffic following the commonly used TCP port number of 194.  Of course using something that inspects at the application layer (like the ZBF) would be more effective here, but this is just a refresh on configuring access lists.

ISP_1(config)#ip access-list extended PACKET-FILTER
ISP_1(config-ext-nacl)#deny tcp any any eq irc log
ISP_1(config-ext-nacl)#permit ip any any
ISP_1(config-ext-nacl)#exit
ISP_1(config)#int s1/0
ISP_1(config-if)#ip access-group PACKET-FILTER in
ISP_1(config-if)#int s1/1
ISP_1(config-if)#ip access-group PACKET-FILTER in
ISP_1(config-if)#int s1/2
ISP_1(config-if)#ip access-group PACKET-FILTER in
ISP_1(config-if)#int s1/3
ISP_1(config-if)#ip access-group PACKET-FILTER in

Now, the ISP has also decided to to block any inbound addresses that match those listed in RFC 1918 across all interfaces.  All RFC 1918 blocks as the source or destination will be denied.  Since the permit ip any any list is line number 20, we will configure these lines as 11-16.  Remember that ACL's use wildcards.  This would be simpler with the creation of object groups, but this router IOS does not support object-groups.

ISP_1#show ip access-lists
Extended IP access list PACKET-FILTER
    10 deny tcp any any eq irc log
    20 permit ip any any
ISP_1#conf t
ISP_1(config)#ip access-list extended PACKET-FILTER
ISP_1(config-ext-nacl)#11 deny ip 10.0.0.0 0.255.255.255 any log
ISP_1(config-ext-nacl)#12 deny ip 172.16.0.0 0.15.255.255 any log
ISP_1(config-ext-nacl)#13 deny ip 192.168.0.0 0.0.255.255 any log
ISP_1(config-ext-nacl)#14 deny ip any 10.0.0.0 0.255.255.255 log
ISP_1(config-ext-nacl)#15 deny ip any 172.16.0.0 0.15.255.255 log

ISP_1(config-ext-nacl)#16 deny ip any 192.168.0.0  0.0.255.255 log
ISP_1(config-ext-nacl)#exit
ISP_1(config)#exit
ISP_1#show ip acces
Extended IP access list PACKET-FILTER
    10 deny tcp any any eq irc log
    11 deny ip 10.0.0.0 0.255.255.255 any log
    12 deny ip 172.16.0.0 0.15.255.255 any log
    13 deny ip 192.168.0.0 0.0.255.255 any log
    14 deny ip any 10.0.0.0 0.255.255.255 log
    15 deny ip any 172.16.0.0 0.15.255.255 log
    16 deny ip any 192.168.0.0 0.0.255.255 log
    20 permit ip any any

ISP_1#wr

Implement Secure Network Management
So far, an audit has been run on all of the edge routers, unnecessary services have been disabled, and the routers have been hardened.  Hypothetically, a ZBF has been implemented on each border router, and AAA with TACACS has been configured (for this topology, you would either need a VPN setup, or have individual TACACS servers at each site).  The ISP router is filtering out any traffic sourced or destined to a private IP address, along with any IRC traffic.  So far, we've met a few items for the security policy.  I've highlighted the items in red which are still not in compliance:

-Only administrators from the IP address 172.16.100.10 should have management access to corporation owned network equipment
-All network management tools and protocols will use encryption 
Only SSH and HTTPS are being used to manage remote devices
-Centralized authentication, authorization, and accounting must be used
AAA with a centralized TACACS server was hypothetically configured
-All edge routers will be hardened from outside attacks
CCP audit was run, which disabled unused services, and enabled numerous security features on untrusted interfaces
-There will be no plaintext passwords stored on network config files 
CCP audit enabled service password encryption, along with forcing the creation of an enable secret
-All edge routers will shield their internal networks through the use of router firewalls
ZBF was hypothetically created on all edge routers
-All logging will be centralized and encrypted in transit to the logging server
-A full mesh site to site VPN tunnel will be used across the enterprise edge routers


The last three items will be covered in the next lab, which will configure the full mesh site to site VPN tunnels between the remote sites.  The management access will be restricted by an access-class applied to the VTY lines and the http server.  Logging will be encrypted within the VPN tunnels across the public WAN links, and SNMPv3 will be used whenever possible.  A network monitoring system will be setup to collect these logs.

Lab Part 2: ASA and the ASDM

Configuring the ASA with ASDM

Now that we have basic access to the ASA, we'll continue on with the configurations through ASDM.  From reading the study material and the exam blueprints, it looks like you are expected to know how to configure basic access lists, NAT, PAT, and some setup through ASDM.  So in this lab, we'll cover exactly that.

Assuming you followed the first part of the lab, you should be able to reach the ASA at https://172.16.100.1

Since you restricted management access only from 172.16.100.10, your PC will need this address.

Either run ASDM by downloading it locally and running it, or by using the java web start option.  Since I was battling some java issues at the time, I used the java web start app. (You can click on these images to expand them)

Now that we have entered ASDM, it's time to perform some basic configurations.

Review Firewall Configuration

Lets start by reviewing our CLI commands, and seeing what that looks like within ASDM (you should know how to configure that here as well).  We'll look at our interfaces, security levels, and associated VLANs.  Click on the configuration tab, and then on the panel on the left, click on interfaces.

Here we can see the interface names on the first column.  The first row has no name, as these interfaces are all assigned to VLAN 1 by default (we didn't set them up-eth0/1 was reserved for the DMZ, and none of the others were configured).  The switchports will be shut down by default.  We will go ahead and disable this interface for now.

Click edit, which brings up this window.  

You can see that eth0/1, and eth 0/3-7 are assigned to this interface (VLAN 1).  You should be able to see from here how you would configure this if you had just setup the ASA with a barebones configuration for accessing it via ASDM-an IP address assigned to VLAN 1, an ifname, and bringing up say eth0/0 or whichever switchport you wanted to use for the inside.  Then within ASDM, you could configure your other interfaces (SVIs for those of us with the 5505), assign the name, security level, and assign switchports.  If you were to create a new interface, you could set its VLAN ID under the advanced tab. 

A special note for the ASDM-generally speaking, when you configure something within an edit window, it will not apply this configuration to the running-config until you click the Apply button at the bottom of the window.  If you click the Save tab on the menu bar (with home, configuration, monitoring, etc), it will backup the running config to startup config.

Now, select the Switch Ports tab.

Here you can verify the configuration we implemented with the CLI- switchports 0/0 and 0/2 are up.  0/0 is assigned to interface VLAN 10 (outside), and 0/2 is assigned to VLAN 100 (inside).  All other interfaces are set to their default configurations of VLAN 1, disabled.

I have the basic ASA license, so I am unable to fully configure a DMZ at this point in time, so lets move on to configuring our static routes.

Configure Routing

If we want our traffic to go anywhere, we will need to set some default routes for the ASA.  Lets get to the routing configuration tab by clicking on Device Setup>Routing>Static Routes

We have an empty table-we need to configure some routes.  Now according to our overall topology, we have our corp border router connected to our ASA. (not setup yet, but will be in the next lab).  The interface facing us is on the 207.100.100.0/27 block, with IP address 207.100.100.30.  We will configure a default route to that gateway IP address.  With our simple configuration, the ASA will know to send traffic addressed to the inside address range of 172.16.100.0/24 out its directly connected interface, VLAN 100.

Click the add button, and you will see the static route configuration window.

This can be slightly confusing at first.  Which interface should you add the default route to?  The answer, is that it is quite similar to configuring a static route on a regular IOS device.  Remember on a router, the command is ip route <destination network> <destination mask> <gateway IP> OR <forwarding interface>

In this case, the command on the ASA CLI  is route <ifname> <destination net> <destination mask> <gateway IP> 

So keep this in mind while within the GUI-the interface name is the one by which the traffic will be routed out, following the configured route settings.  So in this instance, our default route should be added to the outside interface, as configured below

Make sure to click apply, and then save to your startup config if desired by clicking the Save icon.  Now, on to understanding behavior regarding security levels and configuring access rules.

Access Rules and Security Levels

Start by clicking on Firewall under device setup, while still within the configuration pane.

By default, the firewall will use its security levels for stateful filtering.  

Any traffic sourced from higher security interfaces is permitted out to lower security interfaces

Reply traffic from lower security interfaces is permitted back to higher security interfaces

Any traffic from lower security -> higher security interfaces is denied implicitly.

Since we assigned the outside interface to security level 0, and the inside interface to security level 100, only traffic initially sourced from the inside to outside, and its associated reply traffic from the outside, will be permitted.  What is important to keep in mind, is if we create an access rule, what happens to this filtering behavior in regards to the security levels.  If you create an access rule for the inside, say filtering any IRC traffic from exiting, the ACL will add an implicit deny any at the end of the statement.  This can cause some confusion as the behavior changes from the above security level rules, to using the ACLs.  The stateful reply traffic will remain the same however.  

I will use the packet tracer tool to demonstrate this behavior.  The packet tracer tool is a very useful feature which can act as a policy review to let you know what types of traffic will be denied or permitted, without having to send actual traffic through the firewall.

Start by configuring your inside incoming ACL to filter any IRC traffic.

Now you will see your access rule icons change from the "any, any less secure networks" to deny any any IRC.

  There is an associated global deny any any rule attached onto this ACL-we can confirm that all of the remaining traffic will be denied (probably something we don't want to happen) by using the packet tracer tool.  The tool is located under Tools.  We'll emulate a user attempting to browse out to their favorite business site, facebook (simulated IP).

As you can see, the traffic would be denied.  You can drill down into the Access-List phase and see which rule denied this traffc.

See how it says "Config Implicit Rule".  Remember our rule with access lists?  There is always a implicit deny rule at the end of every access rule.  To correct this, we will need to add a permit any at the end of our inbound filtering statement for the inside interface.  Make sure you add the rule after your deny rule-same logic with standard/extended ACLs on IOS systems, the rules are processed in order and processing will end at the first matched statement.  Don't forget to click the apply button and save the configuration to running config.

After you do so, lets run the packet tracer rule again.

So going out, according to packet tracer, our configuration will work.  We still have a problem, however.  How will traffic from our facebook browser be returned to that inside address of 172.16.100.58?  Since there is no NAT or PAT configured yet, our traffic will likely be filtered out within the ISP to begin with-this is an unroutable, private IP.  Lets fix this issue.

Configure NAT/PAT

You can see the nat configuration directly below Access Rules in the pane on the far left.  Click on NAT Rules to get started.

Now, to fix our NAT issue.  We will click on the add drop down button, and select add NAT rule.  We want to configure PAT for our entire 172.16.100.0/24 block of addresses, with PAT overload so all of our inside hosts can have their IPs translated using the ASA's outside interface IP.

We'll set the source interface to inside, the destination interface to outside, the source, destination, and service fields to ANY.  Now under the translated packet, we will select source NAT type of Dynamic PAT (hide).  To set the source address to translate into, click on the ... button and select the outside interface

Your rule table should look like this

Lets say we wanted to refine these rules abit more, and specify that only hosts from the internal network of 172.16.100.0/24 should be matched to have their addresses translated.  To accomplish this, we need to create a network object.  To allow for better organization, we should ideally create a network object group, which we can later add more network objects into.  We can do this from within the nat rule window.  So edit your rule again, and under the source address for the match section, click on the ... button again to draw up your selection.  Now you can click on the add drop down, and select network object group.

Lets call this group "INSIDE-HOSTS", with a description of "hosts inside the corporate network".  You cannot have spaces in the group name, but you may add spaces in the description.  Now from within this window, you can add your network object groups.  Click the radio button Create new Network Object member.  Set a name if desired, set the type to network, and set the IP address to 172.16.100.0 with a mask of 255.255.255.0.    You can also add in a description if desired. Click Add >> when you are finished, and then OK. Your window should look like this

Now, from your Browse Original Source Address window, you can select your INSIDE-HOSTS network object group, or just select the network object of VLAN100.  In the real world, this selection would depend on your network design.  We will select our newly created network object group of INSIDE-HOSTS.

Click ok, and now your NAT rule will apply to any network object that is a member of INSIDE-HOSTS.  In our configuration, that would be any host inside our VLAN 100 network of 172.16.100.0.

Configure ICMP Inspection

Now we just have one last component to configure.  Have you noticed that you are unable to ping the neighboring router's address (if you are following the topology) at 207.100.100.30, from your management workstation off the inside interface of the ASA?  In fact, any ICMP traffic crossing the ASA, and returning through it will fail.

By default, the ASA won't statefully inspect icmp traffic.  This means that any ping attempts crossing the firewall will fail, as there is no stateful inspection, the traffic cannot be returned.  For troubleshooting purposes, lets enable this.  Below the NAT Rules icon is Service Policy Rules.  It is within here that we can get ICMP inspection enabled.

Right click and edit the inspection default policy.  This policy is present on the default configuration of the ASA

Now browser over to default inspections.  You can see that ICMP is listed, by why isn't working?  The answer is within the Rule Actions tab-these are the actions (hence the name) that are applied to traffic that meets the inspection criteria.

Click on the rule actions tab, browse down until you see ICMP-you will see that it is unchecked.  Check the box next to ICMP, click ok, and apply the configuration.  Now try to ping again from the inside interface to the neighboring router.  Your ping should be successful this time.

That completes our ASA configuration for now, later we will return to configure the VPNs!

CCNA Security Review

CCNA Security: Implementation
In the next post, I'll be picking up where I left off with the ASA lab, but I want to list out what I'll primarily be focusing on in the next series of posts.  I'll still be reviewing the configuration for the lab, but focusing in on these key topics from the CCNA Security Syllabus:

Implement security on Cisco routers
Implement AAA
Implement IP ACLs
Implement secure network management
Implement VLANs and trunking
Implement spanning tree
Implement zone based firewall policy using CCP
Implement ASA
Implement NAT and PAT
Configure Cisco IOS IPS using CCP
Implement IOS IPSec site-site VPN with PSK auth
Implement SSL VPN using ASDM


We've performed the basic setup of the ASA, now we need to configure a few access control functions, and then configure NAT and PAT, and besides the VPN configurations, we'll have the ASA covered.

Moving on from there, I'll be reviewing configuring the datacenter, corp, and branch routers following the CCNA Security implementation topics-secured following the network foundation protection topics, locally hardened, and an example of ZBF configuration using CCP.  The datacenter edge router will have NAT/PAT configured via CCP.  The ISP router will be configured with an IP ACL to review on access lists.

The internal switches will be configured following what is expected of the exam blueprint- secure management, spanning tree protection, port security.  VLANs and trunks will of course be setup, this goes without saying considering the topology.

All devices will be configured for snmp logging, and a later date, this data will be fed to a network monitoring system.  For now, AAA local will be used until I have a tacacs server setup, but I will review the tacacs commands.

As a demonstration, I will configure IOS IPsec site to site with PSK between two of the routers, but will tear this down and replace it with a full mesh site to site tunnels between the routers and the ASA using digital certificates for authentication instead of PSK.

A SSL VPN will be configured for remote users using the ASDM

I don't have a router capable of running IOS IPS so I won't be able to demonstrate that implementation step.

That covers most if not all of the implementation topics listed on the exam blueprint as of today.

Lab part 1: Initial ASA Configuration

At the end of this post you can see the complete topology of what this lab series covers (I couldn't really find another more practical way of cramming everything in, I usually use GNS3 just to create a clean topology quickly).  In the first post of the lab, we are going to start with getting an ASA up and running so that ASDM can be used to connect to it.  This lab starts with a wiped ASA, and rather then following the CLI startup wizard, it will be configured manually.  I think this is the best way to learn as to what is taking place.

Lab Objectives

This lab assumes an ASA 5505 with no initial configuration.  These are the requirements for the configuration:

• Outside interface, assigned to VLAN 10, security level 0 with an IP of 207.100.100.1/27
• Inside interface, assigned to VLAN 100, security level 100, with an IP of 172.16.100.1/24
• Interface eth0/0 should be mapped to the outside 
• Interface eth0/1 should be reserved for a future DMZ config
• Interface eth0/2 should be assigned to the inside
• Host with an IP address of 172.16.100.10 should be able to use ASDM to connect to the ASA

ASA Setup

As you can see, we are starting from scratch with no configuration, and the ASA has prompted to pre-configure the firewall following the interactive prompts.  We'll say no and continue with the configuration.

Configure Credentials

Now moving to enable mode you'll notice it asks for a password.  By default, there is no password, so just press enter to continue.

The first thing we will do is add an enable password, and create an admin user for the ASA.  Note that the ASA uses the command enable password vs the traditional enable secret in IOS devices.  However if you check the configuration, you will see that the password is encrypted.  Use a password of your choice, and you can use the following commands:

ciscoasa(config)# enable password cisco

ciscoasa(config)# username admin password cisco privilege 15

Another thing that I noticed was interesting was the placement of the command privilege behind the configuration of the password.  Normally it seems you configure the privilege first and then the password.

Configure Interfaces

Now since the ASA 5505 model uses switchports for its 8 interfaces, we need to accomplish any IP address assignment by creating SVIs-switched virtual interfaces.  If you've ever setup a switch before and configured it with a management IP address-then you have created an SVI.  On an ASA 5505, we create VLANs, assign them IP addresses, configure the name and security level, and then move into the switchport configuration and assign them to the corresponding VLANs.

We will start by creating the SVIs for the outside and inside interfaces.  The two differences here between a switch SVI and a ASA SVI, is that we also need to define a name using the nameif command, and we need to define a security level using the security-level <100-0> command.  By default, an ASA will only allow traffic to flow from higher security level interfaces, down to lower security level interfaces.  Traffic from lower security levels (using the default rules-and this will be explained in detail in a later post), cannot access higher security level zones unless it was initiated from a higher security zone-this is the stateful, default behavior.  I use the following commands to setup my inside and outside interfaces:

ciscoasa# conf t
ciscoasa(config)# int vlan 10
ciscoasa(config)# nameif outside
ciscoasa(config-if)# security-level 0
ciscoasa(config-if)# ip address 207.100.100.1 255.255.255.224
ciscoasa(config-if)# no shut
ciscoasa(config-if)# exit
ciscoasa(config)# int vlan 100
ciscoasa(config-if)# nameif inside
ciscoasa(config-if)# security-level 100
ciscoasa(config-if)# ip address 172.16.100.1 255.255.255.0
ciscoasa(config-if)# no shut

ciscoasa(config-if)# exit

Now that we have our inside and outside interfaces, we need to assign the correct switchports to them.  This is done exactly like one would be used to when working with a switch.  Except that the switchport names are slightly different, they are "ethernet x/x", and by default, the switchports are shut down.  So you can use et for shorthand here.  These are the commands that I use now to assign my switchports to their SVI interfaces.

ciscoasa(config)# int et0/0
ciscoasa(config-if)# switchport access vlan 10
ciscoasa(config-if)# no shut
ciscoasa(config-if)# exit
ciscoasa(config)# int et0/2
ciscoasa(config-if)# switchport access vlan 100
ciscoasa(config-if)# no shut
ciscoasa(config-if)# exit

Configure Access to ASDM

If you check back in the list, you see that we need to configure the ASA so that it can be reached via ASDM.  To do so, we need to start the HTTPS server, and add the IP address for the management workstation to a special management access list.  By default, the ASA will deny access from any IP to its HTTPS server.  The commands used to do this are:

ciscoasa(config)# http server enable
ciscoasa(config)# http 172.16.100.10 255.255.255.255 inside

Now you might be thinking-wait, that says HTTP, not HTTPS.  Not to worry, the command will only allow the ASA to be reached via HTTPS.  For some reason that I do not know, the command is HTTP.
The second line allows a management machine to access the ASA at the inside interface.  Also, wildcards are not generally used in the configuration of the ASA, instead it is the normal subnet mask format.


You should now be able to access the ASA via the ASDM by opening a browser and typing in https://172.16.100.1 (or whichever IP you have picked for your inside address)  The certificate will be untrusted by the browser since it is a self signed cert.

 After you continue through you'll see the option to download the ASDM and install it on your local machine.  Alternatively, you can launch the ASDM using java webstart, and run it off the ASA's flash memory

  .  I will cover the ASDM in the next part of my lab.


At this point, we have met all of our required goals!