Hands reached: continue about ASA
Perhaps we will start with the basic settings for interfaces and routing, as well as the settings for connections for remote administration.
Configuring interfaces The
Cisco ASA is a hardware-based firewall with stateful inspection sessions. ASA can operate in two modes: routed (router mode, by default) and transparent (transparent firewall, when ASA works as a filtering bridge). We will get to know the work in the first mode and hereafter we will mean it everywhere, unless otherwise specified.
In routed mode, on each ASA interface, the IP address, mask, security level (security-level), interface name, and the interface must be forced to raise, since by default all interfaces are in the "disabled by administrator" state. (There are exceptions: sometimes ASAs come pre-configured. This is typical for the 5505 model. In this case, as a rule, the internal interface with the name inside is already configured as the most secure and raised, a DHCP server is running on it, a static address from the network 192.168.1.0 is set / 24, the external interface with the name outside is also raised and itself receives an address via DHCP and the address translation from the network behind the inside interface to the outside interface address is configured. It turns out such a plug-n-play :))
The “security level” parameter is a number from 0 to 100, which allows you to compare 2 interfaces and determine which of them is more “safe”. The parameter is used qualitatively, not quantitatively, i.e. only the more-less relationship is important. By default, traffic going "outside", i.e. from an interface with a higher level of security to an interface with a lower level of security, it is skipped, the session is remembered and only responses from these sessions are skipped. Traffic going "inside" is prohibited by default.
The parameter “interface name” (nameif) in the future allows you to use not the physical name of the interface in the settings, but its name, which can be selected as “speaking” (inside, outside, dmz, partner, etc.). In theory, according to cisco itself, the name is not case-sensitive, (not case sensitive), but in practice, a number of commands require case-sensitivity, which is rather inconvenient. A typical example: applying a crypto map to an interface requires an exact spelling of the interface name. The name of the interface is continued by pressing the TAB button, i.e. you can type the beginning of the name and continue with the tab to the end if the typed beginning uniquely identifies the interface.
This interface configuration is common to all ASA models except the ASA 5505. The 5505 has an integrated 8-port L2 / L3 switch. IP addresses in model 5505 are set on logical interfaces
The physical L2 interfaces themselves are mapped to VLANs.
Thus, firewalling occurs between logical interfaces vlan.
As a rule, the security level of interfaces is selected in such a way as to best match the logical topology of the network. The topology itself is a security zone and the rules of interaction between them. The classic scheme is the assignment of different security levels to different interfaces.
No one forbids making the security level on different interfaces the same, however, by default, traffic exchange between such interfaces is prohibited. Such traffic can be deliberately allowed by giving a command
However, it must be understood that between interfaces with the same level of security there is no firewalling, but only routing. Therefore, this approach is used for interfaces related to the same logical security zone (for example, 2 local area networks of users united by ASA)
Routing
Well, where would you go without it! Like any router (the ASA also has one, because it uses the routing table to transmit packets), the networks configured on the interfaces automatically fall into the routing table marked “Connected”, however, provided that the interface itself is located in up state. Packet routing between these networks is automatic.
Those networks that the ASA itself does not need to be described. This can be done manually using the command
Indicate the interface for which to look for next-hop, because The ASA itself does not do such a search (unlike a regular cisco router). I remind you that only one route gets to the destination network in the routing table, unlike classic routers, where up to 16 parallel paths can be used.
The default route is set in the same way.
If the ASA does not have a record in the routing table about the packet destination network, it discards the packet.
If the task arises of making a backup static route, which will work only when the main one disappears, then this is solved by indicating the so-called Administrative distance of the route. This is a number from 0 to 255 that indicates how good the route selection method is. For example, static routes are mapped by default to AD 1, EIGRP - 90, OSPF - 110, RIP - 120. You can explicitly specify AD for the fallback route more than the main AD. For instance:
But in this situation there is one important question: how to make the main route “disappear”? If the interface physically fell, everything is obvious - it will work out by itself, but if the interface is up and the provider is dead? This is a very common situation, given that the ASA has solid ethernet, which physically falls extremely rarely.
To solve this problem, SLA technology is used. It is highly developed on classic routers, and on ASA since version 7.2 they implemented only the simplest mechanism: the availability of a host via icmp protocol. To do this, create such a "pingovalka" (sla monitor)
Further, it must be started by specifying the start time (it is possible to start “now”) and the end of work (you can set the work to infinity)
But that is not all. It is necessary to create a “switch” (track) that will track the status of the “pingovalka”.
Do not ask why the pingovalka binding is done with the rtr keyword - this is a nonsense of inconsistency of settings on cisco routers. By the way, such a discrepancy has already been fixed on the routers themselves, but not yet on the ASA.
And now everything is ready to apply this design to static routing
Now, while the pingable host is accessible, track will be up (almost written in “up” :)) and the main route will be in the routing table, but as soon as the connection is lost, after a given number of lost packets (by default, packets are sent every 10 seconds and wait for the loss of three packets) track will be placed in the down state and the main route will disappear from the routing table, and packets will be sent over the alternate path.
I will give an example of a config of two default routes through different providers with checking the availability of the main provider:
Dynamic routing on the ASA is possible via the RIPv1,2, OSPF, EIGRP protocols. Configuring these protocols on the ASA is very similar to configuring cisco routers. For now, I will not touch on dynamic routing in these publications, although if I reach my hands and there is interest, I will write a separate chapter.
Remote control
It is clear that with the current development of data networks, it would be unreasonable not to introduce remote control of firewalls. Therefore, the ASA, like most cisco devices, provides several remote management methods.
The simplest and most insecure is telnet. To provide access to the ASA via telnet, you must explicitly specify which hosts and networks and on which interface access is allowed, and you must also specify the password for the telnet with the passwd command:
For security reasons, telnet operation on the most insecure (with the lowest level of security within this ASA) interface is blocked and telnet operation on this interface is possible only if it comes through an IPSec tunnel.
More secure command line access is provided by the ssh protocol. However, to provide ssh access, in addition to explicitly indicating which hosts can be accessed for management, you must also specify the RSA keys necessary to encrypt user data. By default, the pix user and the password specified by the passwd command (telnet password) are used for ssh connection.
As a rule, on the ASA starting from version 7.2, a domain name has already been set (domain.invalid) and default keys are generated, but at least this should be checked
The presence of at least some RSA keys already allows you to work on ssh. But you can additionally create non-default key pairs. To do this, you must explicitly specify the name of the key pair
To remove a key pair (or all pairs), use the command
Tip: after any actions with key pairs (create, delete), be sure to save. You can use the standard cisco commands for this.
or short version of the last command
ASA also provides an extremely popular configuration method using a web browser. This method is called ASDM (Adaptive Security Device Manager). The secure protocol https is used for access. Access control is configured very similar to ssh: you need to work out or make sure that there are default RSA keys and indicate where you can connect.
If you do not configure anything else, then access will be provided without specifying the user. If the password for privileged mode was specified
then when connecting, you must specify it as the password without specifying the user.
It is necessary to verify that the ASDM flash contains the ASDM file corresponding to the OS used.
When working with ASDM, java is used and the following is true: if you use OS version 7.X, then ASDM needs version 5.X and java 1.5. If OS 8.X is used, then ASDM needs version 6.X and java version 1.6. To the credit of the developers and the joy of the tuners, ASDM version 6 works unmatched better and faster than version 5.X. Whose merit is there: java or cisco or both - I do not know.
A reasonable question arises: if you want to use not the default access rules, but explicitly indicate where to get the user? Commands are used for this (console - keyword)
If only a local user database is used, then only LOCAL can be specified in the authentication rule (check that at least one user is created, otherwise you can block access to yourself), and if you want to use external databases accessible via TACACS +, RADIUS or LDAP, then such servers must be pre-configured
The local user base is set by the command
Access via ASDM is possible only on behalf of a user with privilege level 15 (maximum means that the user can be configured)
. Local users can also be assigned a number of attributes using the command
Finishing this part I will give a piece of a config. It has 2 interfaces configured (in this case it is gigabitethernet 0/0 and 0/1, however on different platforms it can be other physical interfaces), inside and outside, default route, remote access via ssh and https from everywhere is allowed, with This
authentication uses a local user database.
Using these settings, you allow packets to go from a directly connected network behind the inside interface to the outside. Outside, only answers will be received for sessions (tcp and udp), open from the inside, because I’ll remind you that by default the traffic going “inside” is completely prohibited. How to resolve it, we will talk in the next part.
Access Lists (to be continued)
Configuring interfaces The
Cisco ASA is a hardware-based firewall with stateful inspection sessions. ASA can operate in two modes: routed (router mode, by default) and transparent (transparent firewall, when ASA works as a filtering bridge). We will get to know the work in the first mode and hereafter we will mean it everywhere, unless otherwise specified.
In routed mode, on each ASA interface, the IP address, mask, security level (security-level), interface name, and the interface must be forced to raise, since by default all interfaces are in the "disabled by administrator" state. (There are exceptions: sometimes ASAs come pre-configured. This is typical for the 5505 model. In this case, as a rule, the internal interface with the name inside is already configured as the most secure and raised, a DHCP server is running on it, a static address from the network 192.168.1.0 is set / 24, the external interface with the name outside is also raised and itself receives an address via DHCP and the address translation from the network behind the inside interface to the outside interface address is configured. It turns out such a plug-n-play :))
int g0 / 0 ip address {address} {mask} security-level {number} nameif {name} no shutdown
The “security level” parameter is a number from 0 to 100, which allows you to compare 2 interfaces and determine which of them is more “safe”. The parameter is used qualitatively, not quantitatively, i.e. only the more-less relationship is important. By default, traffic going "outside", i.e. from an interface with a higher level of security to an interface with a lower level of security, it is skipped, the session is remembered and only responses from these sessions are skipped. Traffic going "inside" is prohibited by default.
The parameter “interface name” (nameif) in the future allows you to use not the physical name of the interface in the settings, but its name, which can be selected as “speaking” (inside, outside, dmz, partner, etc.). In theory, according to cisco itself, the name is not case-sensitive, (not case sensitive), but in practice, a number of commands require case-sensitivity, which is rather inconvenient. A typical example: applying a crypto map to an interface requires an exact spelling of the interface name. The name of the interface is continued by pressing the TAB button, i.e. you can type the beginning of the name and continue with the tab to the end if the typed beginning uniquely identifies the interface.
This interface configuration is common to all ASA models except the ASA 5505. The 5505 has an integrated 8-port L2 / L3 switch. IP addresses in model 5505 are set on logical interfaces
interface vlan {#} ip address {address} {mask} security-level {number} nameif {name} no shutdown
The physical L2 interfaces themselves are mapped to VLANs.
interface f0 / 0 switchport access vlan {#}
Thus, firewalling occurs between logical interfaces vlan.
As a rule, the security level of interfaces is selected in such a way as to best match the logical topology of the network. The topology itself is a security zone and the rules of interaction between them. The classic scheme is the assignment of different security levels to different interfaces.
No one forbids making the security level on different interfaces the same, however, by default, traffic exchange between such interfaces is prohibited. Such traffic can be deliberately allowed by giving a command
same-security-traffic permit inter-interface
However, it must be understood that between interfaces with the same level of security there is no firewalling, but only routing. Therefore, this approach is used for interfaces related to the same logical security zone (for example, 2 local area networks of users united by ASA)
Routing
Well, where would you go without it! Like any router (the ASA also has one, because it uses the routing table to transmit packets), the networks configured on the interfaces automatically fall into the routing table marked “Connected”, however, provided that the interface itself is located in up state. Packet routing between these networks is automatic.
Those networks that the ASA itself does not need to be described. This can be done manually using the command
route {interface} {network} {mask} {next-hop} [{administrative distance}] [track {#}]
Indicate the interface for which to look for next-hop, because The ASA itself does not do such a search (unlike a regular cisco router). I remind you that only one route gets to the destination network in the routing table, unlike classic routers, where up to 16 parallel paths can be used.
The default route is set in the same way.
route {interface} 0.0.0.0 0.0.0.0 {next-hop}
If the ASA does not have a record in the routing table about the packet destination network, it discards the packet.
If the task arises of making a backup static route, which will work only when the main one disappears, then this is solved by indicating the so-called Administrative distance of the route. This is a number from 0 to 255 that indicates how good the route selection method is. For example, static routes are mapped by default to AD 1, EIGRP - 90, OSPF - 110, RIP - 120. You can explicitly specify AD for the fallback route more than the main AD. For instance:
route outside 0.0.0.0 0.0.0.0 {next-hop} 1 route backup 0.0.0.0 0.0.0.0 {next-hop_backup} 210
But in this situation there is one important question: how to make the main route “disappear”? If the interface physically fell, everything is obvious - it will work out by itself, but if the interface is up and the provider is dead? This is a very common situation, given that the ASA has solid ethernet, which physically falls extremely rarely.
To solve this problem, SLA technology is used. It is highly developed on classic routers, and on ASA since version 7.2 they implemented only the simplest mechanism: the availability of a host via icmp protocol. To do this, create such a "pingovalka" (sla monitor)
sla monitor {#} type echo protocol ipIcmpEcho {ip address} interface {interface}
Further, it must be started by specifying the start time (it is possible to start “now”) and the end of work (you can set the work to infinity)
sla monitor schedule {#} start now life forever
But that is not all. It is necessary to create a “switch” (track) that will track the status of the “pingovalka”.
track {track #} rtr {sla #} reachability
Do not ask why the pingovalka binding is done with the rtr keyword - this is a nonsense of inconsistency of settings on cisco routers. By the way, such a discrepancy has already been fixed on the routers themselves, but not yet on the ASA.
And now everything is ready to apply this design to static routing
route outside 0 0 {next-hop_outside} track {#} route backup 0 0 {next-hop_backup} 210
Now, while the pingable host is accessible, track will be up (almost written in “up” :)) and the main route will be in the routing table, but as soon as the connection is lost, after a given number of lost packets (by default, packets are sent every 10 seconds and wait for the loss of three packets) track will be placed in the down state and the main route will disappear from the routing table, and packets will be sent over the alternate path.
I will give an example of a config of two default routes through different providers with checking the availability of the main provider:
sla monitor 1 type echo protocol ipIcmpEcho 1.1.1.1 interface outside sla monitor schedule 1 start now life forever track 11 rtr 1 reachability route outside 0 0 1.1.1.1 track 11 route backup 0 0 2.2.2.1 210
Dynamic routing on the ASA is possible via the RIPv1,2, OSPF, EIGRP protocols. Configuring these protocols on the ASA is very similar to configuring cisco routers. For now, I will not touch on dynamic routing in these publications, although if I reach my hands and there is interest, I will write a separate chapter.
Remote control
It is clear that with the current development of data networks, it would be unreasonable not to introduce remote control of firewalls. Therefore, the ASA, like most cisco devices, provides several remote management methods.
The simplest and most insecure is telnet. To provide access to the ASA via telnet, you must explicitly specify which hosts and networks and on which interface access is allowed, and you must also specify the password for the telnet with the passwd command:
telnet 192.168.1.128 255.255.255.128 inside telnet 192.168.1.254 255.255.255.255 inside passwd {password}
For security reasons, telnet operation on the most insecure (with the lowest level of security within this ASA) interface is blocked and telnet operation on this interface is possible only if it comes through an IPSec tunnel.
More secure command line access is provided by the ssh protocol. However, to provide ssh access, in addition to explicitly indicating which hosts can be accessed for management, you must also specify the RSA keys necessary to encrypt user data. By default, the pix user and the password specified by the passwd command (telnet password) are used for ssh connection.
! Set domain name domain name {name} ! ! It is advisable to specify a non-default host name hostname {name} ! ! After that, you can generate the keys crypto key generate rsa ! ! Allow ssh ssh 192.168.1.128 255.255.255.128 inside ssh 1.2.3.4 255.255.255.255 outside passwd {password}
As a rule, on the ASA starting from version 7.2, a domain name has already been set (domain.invalid) and default keys are generated, but at least this should be checked
show crypto key mypubkey rsa
The presence of at least some RSA keys already allows you to work on ssh. But you can additionally create non-default key pairs. To do this, you must explicitly specify the name of the key pair
crypto key generate rsa label {pair name}
To remove a key pair (or all pairs), use the command
crypto key zeroize rsa [label {pair name}]
Tip: after any actions with key pairs (create, delete), be sure to save. You can use the standard cisco commands for this.
copy running-config startup-config write memory
or short version of the last command
wr
ASA also provides an extremely popular configuration method using a web browser. This method is called ASDM (Adaptive Security Device Manager). The secure protocol https is used for access. Access control is configured very similar to ssh: you need to work out or make sure that there are default RSA keys and indicate where you can connect.
domain name {name} hostname {name} crypto key generate rsa ! We turn on the https server itself, it is often turned on by default. When turned on ! Generates a self-signed certificate. http server enable ! Allow https http 192.168.1.128 255.255.255.128 inside http 1.2.3.4 255.255.255.255 outside
If you do not configure anything else, then access will be provided without specifying the user. If the password for privileged mode was specified
enable password {password}
then when connecting, you must specify it as the password without specifying the user.
It is necessary to verify that the ASDM flash contains the ASDM file corresponding to the OS used.
dir flash: show flash
When working with ASDM, java is used and the following is true: if you use OS version 7.X, then ASDM needs version 5.X and java 1.5. If OS 8.X is used, then ASDM needs version 6.X and java version 1.6. To the credit of the developers and the joy of the tuners, ASDM version 6 works unmatched better and faster than version 5.X. Whose merit is there: java or cisco or both - I do not know.
A reasonable question arises: if you want to use not the default access rules, but explicitly indicate where to get the user? Commands are used for this (console - keyword)
aaa authentication telnet console {AAA server name} [LOCAL] aaa authentication ssh console {AAA server name} [LOCAL] aaa authentication http console {AAA server name} [LOCAL]
If only a local user database is used, then only LOCAL can be specified in the authentication rule (check that at least one user is created, otherwise you can block access to yourself), and if you want to use external databases accessible via TACACS +, RADIUS or LDAP, then such servers must be pre-configured
aaa-server {AAA server name} protocol {tacacs | radius | ldap} aaa-server {AAA server name} ({interface}) host {ip} key {key} ! and other commands specific to this type of server
The local user base is set by the command
user {user} password {password} [privilege #]
Access via ASDM is possible only on behalf of a user with privilege level 15 (maximum means that the user can be configured)
. Local users can also be assigned a number of attributes using the command
user {user} attributes ! various user attributes
Finishing this part I will give a piece of a config. It has 2 interfaces configured (in this case it is gigabitethernet 0/0 and 0/1, however on different platforms it can be other physical interfaces), inside and outside, default route, remote access via ssh and https from everywhere is allowed, with This
authentication uses a local user database.
hostname myAsa ! domain name anticisco.ru ! interface g0 / 0 nameif outside security-level 0 ip address 1.1.1.2 255.255.255.252 no shut ! int g0 / 1 nameif inside security-level 100 ip address 10.1.1.1 255.255.255.0 no shut ! ! on ASA record 0.0.0.0 can be reduced to 0 ! route outside 0 0 1.1.1.1 ! username admin password cisco privilege 15 ! ssh 0 0 inside ssh 0 0 outside ! http 0 0 inside http 0 0 outside ! aaa authentication ssh console LOCAL aaa authentication http console LOCAL
Using these settings, you allow packets to go from a directly connected network behind the inside interface to the outside. Outside, only answers will be received for sessions (tcp and udp), open from the inside, because I’ll remind you that by default the traffic going “inside” is completely prohibited. How to resolve it, we will talk in the next part.
Access Lists (to be continued)