Firewall Administration over the Network

Publish Date: August 3, 2015

Firewall Administration over the Network

In this section, we will discuss about  how to access the Cisco ASA for system management through Telnet, SSH, and HTTPS (using ASDM). We will also look into how to authenticate and authorize users and how to create login banners.

This procedure need to be completed through Console connection to ASA since you have not yet configured the management through network.

Allowing Telnet Access

The ASA allows Telnet connections to the ASA for management purposes. You cannot use Telnet to the lowest security interface unless you use Telnet inside an IPSec tunnel.

The ASA allows a maximum of 5 concurrent Telnet connections per context, if available, with a maximum of 100 connections divided between all contexts. To gain access to the ASA console using Telnet, enter the username and the login password set by the password command or log in by using the aaa authentication telnet console command.

To configure Telnet access to the ASA, follow these steps:

Step 1 To identify the IP addresses from which the ASA accepts connections, enter the following command for each address or subnet:

ciscoasa(config)# telnet 192.168.10.0 255.255.255.0 inside

Replace 192.168.10.0 255.255.255.0 inside with you own local subnet or particular management host address and interface name. If there is only one interface, you can configure Telnet to access that interface as long as the interface has a security level of 100.

Step 2 (Optional) To set the duration for how long a Telnet session can be idle before the ASA disconnects the session, enter the following command:

ciscoasa(config)# telnet timeout 15

Set the timeout from 1 to 1440 minutes. The default is 5 minutes. The default duration is too short in most cases and should be increased until all pre-production testing and troubleshooting has been completed.

Allowing SSH Access

The ASA allows SSH connections to the ASA for management purposes. The ASA allows a maximum of 5 concurrent SSH connections per context, if available, with a maximum of 100 connections divided between all contexts.

SSH is an application running on top of a reliable transport layer, such as TCP/IP, that provides strong authentication and encryption capabilities. The ASA supports the SSH remote shell functionality provided in SSH Versions 1 and 2 and supports DES and 3DES ciphers.

To gain access to the ASA console using SSH, at the SSH client prompt, enter the username and the login password set by the password command or log in by using the aaa authentication telnet console command.

To configure SSH access to the ASA, follow these steps:

Step 1 To generate an RSA key pair, which is required for SSH, enter the following command:

ciscoasa(config)# crypto key generate rsa modulus 1024

The modulus (in bits) is 512, 768, 1024, or 2048. The larger the key modulus size you specify, the longer it takes to generate an RSA. We recommend a value of 1024.

Step 2 To save the RSA keys to persistent Flash memory, enter the following command:

ciscoasa(config)# write memory

Step 3 To identify the IP addresses from which the ASA accepts connections, enter the following command for each address or subnet:

ciscoasa(config)# ssh 192.168.10.0 255.255.255.0 inside

Replace 192.168.10.0 255.255.255.0 inside with you own local subnet or particular management host address and interface name. The ASA accepts SSH connections from all interfaces, including the one with the lowest security level.

Step 4 (Optional) To set the duration for how long an SSH session can be idle before the ASA disconnects the session, enter the following command:

ciscoasa(config)# ssh timeout 15

Set the timeout from 1 to 60 minutes. The default is 5 minutes.

Step 5 (Optional) By default SSH allows both version 1 and version 2. To specify the version number enter the following command:

ciscoasa(config)# ssh version 2
Using an SSH Client

To gain access to the ASA console using SSH, at the SSH client enter the username asa and enter the login password set by the password command.

When starting an SSH session, a dot (.) displays on the ASA console before the SSH user authentication prompt appears, as follows:

hostname(config)# .

The display of the dot does not affect the functionality of SSH. The dot appears at the console when generating a server key or decrypting a message using private keys during SSH key exchange before user authentication occurs. These tasks can take up to two minutes or longer. The dot is a progress indicator that verifies that the ASA is busy and has not hung.

Allowing HTTPS Access for ASDM

To use ASDM, you need to enable the HTTPS server, and allow HTTPS connections to the ASA. All of these tasks are completed if you use the setup command. This section describes how to manually configure ASDM access and how to login to ASDM.

The ASA allows a maximum of 5 concurrent ASDM instances per context, if available, with a maximum of 32 ASDM instances between all contexts.

Enabling HTTPS Access

To configure ASDM access, follow these steps:

Step 1 To identify the IP addresses from which the ASA accepts HTTPS connections, enter the following command for each address or subnet:

hostname(config)# http 192.168.10.0 255.255.255.0 inside

Replace 192.168.10.0 255.255.255.0 inside with you own local subnet or particular management host address and interface name.

Step 2 To enable the HTTPS server, enter the following command:

hostname(config)# http server enable [port]

The port parameter is optional. By default, the port is 443. If you change the port number, be sure to include the new port in the ASDM access URL. For example, if you change it to port 444, enter:

https://10.1.1.1:444

Step 3 To specify the location of the ASDM image, enter the following command:

hostname(config)# asdm image disk0:/asdm-649.bin
Accessing ASDM from Your PC

From a supported web browser on the ASA network, enter the following URL:

https://192.168.10.1[:port]

Replace 192.168.10.1 with the IP address assigned to management interface of ASA. In transparent firewall mode, enter the management IP address.

Configuring Management Access Over a VPN Tunnel

If your VPN tunnel terminates on one interface, but you want to manage the ASA by accessing a different interface, you can identify that interface as a management-access interface. For example, if you enter the ASA from the outside interface, this feature lets you connect to the inside interface using ASDM, SSH, Telnet, or SNMP; or you can ping the inside interface when entering from the outside interface. Management access is available via the following VPN tunnel types: IPsec clients, IPsec LAN-to-LAN, and the AnyConnect SSL VPN client.

To specify an interface as a mangement-only interface, enter the following command:

hostname(config)# management access management_interface

where management_interface specifies the name of the management interface you want to access when entering the security appliance from another interface. You can define only one management-access interface.

Local Database User Profiles

The ASA supports a variety of AAA server types and a local database of usernames and passwords that is stored on the ASA. In this section we will discuss about local database user profiles.

User profiles contain  a username and a password, although the passwords are optional.

The username attributes command lets you enter the username mode. In this mode, you can add other information to a specific user profile. The information you can add includes VPN-related attributes, such as a VPN session timeout value.

If you are using AAA authentication on ASA and  the AAA authentication fails due to some reason like AAA server unreachable, the local database can act as a fallback method. This behavior is designed to help you prevent accidental lockout from the ASA.

The local database supports the following fallback functions:

  • Console and enable password authentication — When you use the aaa authentication console command, you can add the LOCAL keyword after the AAA server group tag. If the servers in the group all are unavailable, the ASA uses the local database to authenticate administrative access. This can also include enable password authentication.
  • Command authorization — When you use the aaa authorization command command, you can add the LOCAL keyword after the AAA server group tag. If the TACACS+ servers in the group all are unavailable, the local database is used to authorize commands based on privilege levels.
  • VPN authentication and authorization — VPN authentication and authorization are supported to enable remote access to the ASA if AAA servers that normally support these VPN services are unavailable. The authentication-server-group command, available in tunnel-group general attributes mode, lets you specify the LOCAL keyword when you are configuring attributes of a tunnel group. When VPN client of an administrator specifies a tunnel group configured to fallback to the local database, the VPN tunnel can be established even if the AAA server group is unavailable, provided that the local database is configured with the necessary attributes.
Configuring the Local Database

You can use the local database for CLI access authentication, privileged mode authentication, command authorization, network access authentication, and VPN authentication and authorization. You cannot use the local database for network access authorization. The local database does not support accounting.

For multiple context mode, you can configure usernames in the system execution space to provide individual logins using the login command; however, you cannot configure any aaa commands in the system execution space.

To define a user account in the local database, perform the following steps:

Step 1 To create the user account, enter the following command:

hostname(config)# username name {nopassword | password password [mschap]} [privilege priv_level]

where the username keyword is a string from 4 to 64 characters long.

The nopassword keyword creates a user account with no password.

The password argument is a string from 3 to 16 characters long.

The mschap keyword specifies that the password is e converted to unicode and hashed using MD4 after you enter it. Use this keyword if users are authenticated using MSCHAPv1 or MSCHAPv2.

The privilege argument sets the privilege level from 0 to 15. The default is 2. This privilege level is used with command authorization.

Step 2 (Optional) To enforce user-specific access levels for users who authenticate for management access, enter the following command:

hostname(config)# aaa authorization exec authentication-server

This command enables management authorization for local users and for any users authenticated by RADIUS, LDAP, and TACACS+. For a local user, configure the level of access using the service-type command as described in Step 4.

Step 3 (Optional) To configure username attributes, enter the following command:

hostname(config)# username username attributes

where the username argument is the username you created in Step 1.

Step 4 (Optional) If you configured management authorization in Step 2, enter the following command to configure the user level:

hostname(config-username)# service-type {admin | nas-prompt | remote-access}

where the admin keyword allows full access to any services specified by the aaa authentication console LOCAL commands. admin is the default.

The nas-prompt keyword allows access to the CLI when you configure the aaa authentication {telnet | ssh | serial} console LOCAL command, but denies ASDM configuration access if you configure the aaa authentication http console LOCAL command. ASDM monitoring access is allowed. If you configure enable authentication with the aaa authentication enable console LOCAL command, the user cannot access privileged EXEC mode using the enable command (or by using the login command).

The remote-access keyword denies management access. The user cannot use any services specified by the aaa authentication console LOCAL commands (excluding the serial keyword; serial access is allowed).

Step 5 (Optional) If you are using this username for VPN authentication, you can configure many VPN attributes for the user.

Configuring Access Hours

Associate the hours that this user is allowed to access the system by specifying the name of a configured time-range policy:

To remove the attribute from the running configuration, enter the no form of this command. This option allows inheritance of a time-range value from another group policy. To prevent inheriting a value, enter the vpn-access-hours none command. The default is unrestricted access.

hostname(config-username)# vpn-access-hours value {time-range | none} hostname(config-username)# vpn-access-hours value none hostname(config)# 

The following example shows how to associate the user named anyuser with a time-range policy called 824:

hostname(config)# username anyuser attributes hostname(config-username)# vpn-access-hours 824 hostname(config-username)# 

Configuring Maximum Simultaneous Logins

Specify the maximum number of simultaneous logins allowed for this user. The range is 0 through 2147483647. The default is 3 simultaneous logins. To remove the attribute from the running configuration, enter the no form of this command. Enter 0 to disable login and prevent user access.

hostname(config-username)# vpn-simultaneous-logins integer hostname(config-username)# no vpn-simultaneous-logins hostname(config-username)# 

Note:- While the maximum limit for the number of simultaneous logins is very large, allowing several could compromise security and affect performance.

The following example shows how to allow a maximum of 4 simultaneous logins for the user named anyuser:

hostname(config)# username anyuser attributes hostname(config-username)# vpn-simultaneous-logins 4 hostname(config-username)# 

Configuring the Idle Timeout

Specify the idle timeout period in minutes, or enter none to disable the idle timeout. If there is no communication activity on the connection in this period, the ASA terminates the connection.

The range is 1 through 35791394 minutes. The default is 30 minutes. To allow an unlimited timeout period, and thus prevent inheriting a timeout value, enter the vpn-idle-timeout command with the none keyword. To remove the attribute from the running configuration, enter the no form of this command.

hostname(config-username)# vpn-idle-timeout {minutes | none} hostname(config-username)# no vpn-idle-timeout hostname(config-username)# 

The following example shows how to set a VPN idle timeout of 15 minutes for the user named anyuser:

hostname(config)# username anyuser attributes hostname(config-username)# vpn-idle-timeout 30 hostname(config-username)# 

Configuring the Maximum Connect Time

Specify the maximum user connection time in minutes, or enter none to allow unlimited connection time and prevent inheriting a value for this attribute. At the end of this period of time, the ASA terminates the connection.

The range is 1 through 35791394 minutes. There is no default timeout. To allow an unlimited timeout period, and thus prevent inheriting a timeout value, enter the vpn-session-timeout command with the none keyword. To remove the attribute from the running configuration, enter the no form of this command.

hostname(config-username)# vpn-session-timeout {minutes | none} hostname(config-username)# no vpn-session-timeout hostname(config-username)# 

The following example shows how to set a VPN session timeout of 180 minutes for the user named anyuser:

hostname(config)# username anyuser attributes
hostname(config-username)# vpn-session-timeout 180
hostname(config-username)# 

Applying an ACL Filter

Specify the name of a previously-configured, user-specific ACL to use as a filter for VPN connections. To disallow an access list and prevent inheriting an access list from the group policy, enter the vpn-filter command with the none keyword. To remove the ACL, including a null value created by issuing the vpnfilter none command, enter the no form of this command. The no option allows inheritance of a value from the group policy. There are no default behaviors or values for this command.

You configure ACLs to permit or deny various types of traffic for this user. You then use the vpn-filter command to apply those ACLs.

hostname(config-username)# vpn-filter {value ACL_name | none}
hostname(config-username)# no vpn-filter
hostname(config-username)# 

Note:- Clientless SSL VPN does not use ACLs defined in the vpn-filter command.

The following example shows how to set a filter that invokes an access list named acl_vpn for the user named anyuser:

hostname(config)# username anyuser attributes hostname(config-username)# vpn-filter value acl_vpn hostname(config-username)# 

Specifying the IP Address and Netmask

Specify the IP address and netmask to assign to a particular user. To remove the IP address, enter the no form of this command.

hostname(config-username)# vpn-framed-ip-address {ip_address} hostname(config-username)# no vpn-framed-ip-address hostname(config-username)

The following example shows how to set an IP address of 192.168.10.100 for a user named anyuser:

hostname(config)# username anyuser attributes hostname(config-username)# vpn-framed-ip-address 192.168.10.100 hostname(config-username)

Specify the network mask to use with the IP address specified in the previous step. If you used the no vpn-framed-ip-address command, do not specify a network mask. To remove the subnet mask, enter the no form of this command. There is no default behavior or value.

hostname(config-username)# vpn-framed-ip-netmask {netmask} hostname(config-username)# no vpn-framed-ip-netmask hostname(config-username)

The following example shows how to set a subnet mask of 255.255.255.254 for a user named anyuser:

hostname(config)# username anyuser attributes hostname(config-username)# vpn-framed-ip-netmask 255.255.255.254 hostname(config-username)

Specifying the Tunnel Protocol

Specify the VPN tunnel types (IPSec or clientless SSL VPN) that this user can use. The default is taken from the default group policy, the default for which is IPSec. To remove the attribute from the running configuration, enter the no form of this command.

hostname(config-username)# vpn-tunnel-protocol {webvpn | IPSec} hostname(config-username)# no vpn-tunnel-protocol [webvpn | IPSec] hostname(config-username)

The parameter values for this command are as follows:

IPSec — Negotiates an IPSec tunnel between two peers (a remote access client or another secure gateway). Creates security associations that govern authentication, encryption, encapsulation, and key management.

webvpn — Provides clientless SSL VPN access to remote users via an HTTPS-enabled web browser, and does not require a client

Enter this command to configure one or more tunneling modes. You must configure at least one tunneling mode for users to connect over a VPN tunnel.

The following example shows how to configure clientless SSL VPN and IPSec tunneling modes for the user named anyuser:

hostname(config)# username anyuser attributes hostname(config-username)# vpn-tunnel-protocol webvpn hostname(config-username)# vpn-tunnel-protocol IPSec hostname(config-username)

Restricting Remote User Access

Configure the group-lock attribute with the value keyword to restrict remote users to access only through the specified, preexisting connection profile. Group-lock restricts users by checking whether the group configured in the VPN client is the same as the connection profile to which the user is assigned. If it is not, the ASA prevents the user from connecting. If you do not configure group-lock, the ASA authenticates users without regard to the assigned group.

To remove the group-lock attribute from the running configuration, enter the no form of this command. This option allows inheritance of a value from the group policy. To disable group-lock, and to prevent inheriting a group-lock value from a default or specified group policy, enter the group-lock command with the none keyword.

hostname(config-username)# group-lock {value tunnel-grp-name | none} hostname(config-username)# no group-lock hostname(config-username)


The following example shows how to set group lock for the user named anyuser:

hostname(config)# username anyuser attributes
hostname(config-username)# group-lock value tunnel-group-name hostname(config-username)

Enabling Password Storage for Software Client Users

Specify whether to let users store their login passwords on the client system. Password storage is disabled by default. Enable password storage only on systems that you know to be in secure sites. To disable password storage, enter the password-storage command with the disable keyword. To remove the password-storage attribute from the running configuration, enter the no form of this command. This enables inheritance of a value for password-storage from the group policy.

hostname(config-username)# password-storage {enable | disable} hostname(config-username)# no password-storage hostname(config-username)

This command has no bearing on interactive hardware client authentication or individual user authentication for hardware clients.

The following example shows how to enable password storage for the user named anyuser:

hostname(config)# username anyuser attributes
hostname(config-username)# password-storage enable
hostname(config-username)
Identifying AAA Server Groups and Servers

If you want to use an external AAA server for authentication, authorization, or accounting, you must first create at least one AAA server group per AAA protocol and add one or more servers to each group. You identify AAA server groups by name. Each server group is specific to one type of server: Kerberos, LDAP, NT, RADIUS, SDI, or TACACS+.

The ASA contacts the first server in the group. If that server is unavailable, the ASA contacts the next server in the group, if configured. If all servers in the group are unavailable, the ASA tries the local database if you configured it as a fallback method (management authentication and authorization only). If you do not have a fallback method, the ASA continues to try the AAA servers.

To illustrate further illustrate the distinction between no response and an authentication failure, consider this scenario:

You configure an LDAP server group with two Active Directory servers, Server 1 and Server 2, in that order. When the remote user logs in, the Adaptive Security Appliance attempts to authentication to Server 1.

If Server 1 responds with an authentication failure (such as user not found), the ASA does not attempt to authentication to Server 2.

If Server 1 does not respond within the timeout period (or the number of authentication attempts exceeds the configured maximum), the ASA tries Server 2.

If both servers in the group do not respond, and the ASA is configured to fallback to the local database, the ASA attempts to authenticate using the local database.

To create a server group and add AAA servers to it, follow these steps:

Step 1 For each AAA server group you need to create, follow these steps:

a. Identify the server group name and the protocol. To do so, enter the following command:

hostname(config)# aaa-server server_group protocol {kerberos | ldap | nt | radius | sdi | tacacs+}

For example, to use RADIUS to authenticate network access and TACACS+ to authenticate CLI access, you need to create at least two server groups, one for RADIUS servers and one for TACACS+ servers.

You can have up to 100 single-mode server groups or 4 multiple-mode server groups. Each server group can have up to 16 servers in single mode or up to 4 servers in multiple mode.

When you enter a aaa-server protocol command, you enter group mode.

b. Merge a downloadable ACL with the ACL received in the Cisco AV pair from a RADIUS packet by entering the following command:

hostname(config-aaa-server-group)# merge-dacl {before-avpair | after-avpair}

The default setting is no merge dacl, which specifies that downloadable ACLs will not be merged with Cisco AV pair ACLs. If both an AV pair and a downloadable ACL are received, the AV pair has priority and is used.

The before-avpair option specifies that the downloadable ACL entries should be placed before the Cisco AV pair entries.

The after-avpair option specifies that the downloadable ACL entries should be placed after the Cisco AV pair entries. This option applies only to VPN connections. For VPN users, ACLs can be in the form of Cisco AV pair ACLs, downloadable ACLs, and an ACL that is configured on the ASA. This option determines whether or not the downloadable ACL and the AV pair ACL are merged, and does not apply to any ACLs configured on the ASA.

c. If you want to specify the maximum number of requests sent to a AAA server in the group before trying the next server, enter the following command:

hostname(config-aaa-server-group)# max-failed-attempts number

The number can be between 1 and 5. The default is 3.

If you configured a fallback method using the local database (for management access only; and all the servers in the group fail to respond, then the group is considered to be unresponsive, and the fallback method is tried. The server group remains marked as unresponsive for a period of 10 minutes (by default) so that additional AAA requests within that period do not attempt to contact the server group, and the fallback method is used immediately. To change the unresponsive period from the default, see the reactivation-mode command in the following step.

If you do not have a fallback method, the ASA continues to retry the servers in the group.

d. If you want to specify the method (reactivation policy) by which failed servers in a group are reactivated, enter the following command:

hostname(config-aaa-server-group)# # reactivation-mode {depletion [deadtime minutes] | timed}

Where the depletion keyword reactivates failed servers only after all of the servers in the group are inactive.

The deadtime minutes argument specifies the amount of time in minutes, between 0 and 1440, that elapses between the disabling of the last server in the group and the subsequent re-enabling of all servers. The default is 10 minutes.

The timed keyword reactivates failed servers after 30 seconds of down time.

e. If you want to send accounting messages to all servers in the group (RADIUS or TACACS+ only), enter the following command:

hostname(config-aaa-server-group)# accounting-mode simultaneous

To restore the default of sending messages only to the active server, enter the accounting-mode single command.

Step 2 For each AAA server on your network, follow these steps:

a. Identify the server, including the AAA server group it belongs to. To do so, enter the following command:

hostname(config)# aaa-server server_group (interface_name) host server_ip

When you enter a aaa-server host command, you enter host mode.

b. As needed, use host mode commands to further configure the AAA server.

Back



Microsoft Certified | Cisco Certified