Hands reached: we continue about ASA
Let's start with the basic interface settings and routing, as well as connection settings for remote administration
Interface Setup
The Cisco ASA is a stateful inspection hardware firewall. ASA can work in two modes: routed (router mode, by default) and transparent (transparent firewall, when ASA works as a bridge with filtering). We will get acquainted with the work in the first mode and further we will mean it everywhere, unless a different mode is explicitly indicated.
')
In routed mode, each ASA interface is configured with ip address, mask, security level, interface name, and the interface must be “raised”, since by default all interfaces are in the “disabled by administrator” state. (Exceptions are: sometimes ASAshki come pre-configured. This is typical for model 5505. In this case, as a rule, the internal interface called inside is already configured as the safest and raised, it has a DHCP server, a static address from the 192.168.1.0 network is set / 24, the external interface with the name outside is also raised and receives the address itself via DHCP and the translation of addresses from the network behind the inside interface to the outside interface address is configured. This turns out to be such a plug-n-play :))
The “security level” parameter is a number from 0 to 100 that allows you to compare 2 interfaces and determine which of them is more “secure”. The parameter is used qualitatively, not quantitatively, i.e. what matters is the more-less relationship. By default, traffic going outward, i.e. from an interface with a higher level of security to an interface with a lower level of security, is skipped, the session is remembered, and only responses to those sessions are skipped. The traffic going "inside" is by default prohibited.
The “interface name” parameter (nameif) allows you to use in the settings not the physical name of the interface, but its name, which can be selected as “speaking” (inside, outside, dmz, partner, etc.). In theory, according to cisco itself, the name does not depend on the register (not case sensitive), but in practice a number of commands require register compliance, which is rather inconvenient. A typical example: the use of a crypto map on an interface requires the exact spelling of the interface name. The interface name continues 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 dialed beginning uniquely identifies the interface.
This interface configuration is typical for all ASA models, except the ASA 5505. The 5505 model has an integrated 8-port L2 / L3 switch. IP addresses in model 5505 are set on logical interfaces
The L2 physical interfaces themselves are mapped to VLANs.
Thus, firewalling occurs between logical interfaces vlan.
As a rule, the interface security level is selected in such a way as to correspond to the logical network topology as much as possible. The topology itself is a security zone and the rules of interaction between them. The classic scheme is the assignment to different interfaces of different security levels.
Nobody forbids to make the security level on different interfaces the same, but by default the exchange of traffic between such interfaces is prohibited. Such traffic can be consciously resolved by issuing a command
However, it should be understood that between interfaces with the same level of security, firewalling does not occur, but only routing. Therefore, this approach is used for interfaces belonging to the same logical security zone (for example, 2 user local area networks, combined with ASA)
Routing
Well, where do without it! Like any router (the ASA is also, because it uses the routing table to transmit packets), the networks configured on the interfaces automatically enter the routing table with the note “connected”, though the interface itself is in up state. Packet routing between these networks is done automatically.
Those networks that the ASA itself does not know should be described. This can be done manually using the command
Specifies the interface for which to look next-hop, because ASA itself does not do such a search (unlike the regular router cisco). I remind you that in the routing table there is only one route to the destination network, as opposed to 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 an entry in the routing table of the destination network of the packet, it discards the packet.
If there is a task to make a backup static route that will work only when the main one disappears, this is solved by specifying the so-called Administrative distance of the route. This is a number from 0 to 255, which indicates how good the route selection method is. For example, static routes are mapped to AD 1 by default, EIGRP is 90, OSPF is 110, and RIP is 120. You can explicitly specify AD for the alternate route more than the main AD. For example:
But in this situation there is one important question: how to make the main route disappear? If the interface is physically dropped, everything is obvious - it will work, and if the interface is up, and the provider is dead? This is a very common situation, considering that on the ASA is 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 from version 7.2 they have implemented only the simplest mechanism: the availability of a certain host using the icmp protocol. To do this, create such a "pingovalka" (sla monitor)
Further, it is necessary to start it 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's not all. It is necessary to create a “switch” (track) that will track the state of the “pingalki”.
Do not ask why pinging is linked with the rtr keyword - these are pieces of inconsistency of settings on cisco routers. By the way, on the routers themselves, this inconsistency has already been repaired, but the ASA does not yet exist.
And now everything is ready to apply this construction to static routing
Now, while the pinged host is available, the track will be in a raised (almost wrote in a “raised” :) state and the main route will be in the routing table, but as soon as the connection is lost, after a specified number of lost packets (by default, packets are sent every 10 seconds and waiting for three packets to disappear) track will be transferred to the down state and the main route will disappear from the routing table, and packets will be sent along the alternate path.
I will give an example of the config of the two default routes through different providers with a check of the availability of the main provider:
Dynamic routing to ASA is possible using RIPv1,2, OSPF, EIGRP protocols. Configuring these protocols on the ASA is very similar to configuring the cisco routers. While I will not deal with dynamic routing in these publications, although if hands reach interest, I will write a separate chapter.
Remote control
It is clear that with the current development of data networks, it would be unwise to not introduce remote control of firewalls. Therefore, the ASA, like most cisco devices, provides several methods of remote control.
The simplest and most insecure is telnet. To provide access to the ASA via telnet, you must explicitly indicate which hosts and networks from which interface are allowed, and also set the telnet password using the passwd command:
For security reasons, telnet operation on the most insecure (with the lowest security level within this ASA) interface is blocked and telnet operation on this interface is possible only if it arrives through the IPSec tunnel.
More secure access to the command line is provided by the ssh protocol. However, in order to provide ssh access, in addition to explicitly specifying from which hosts you can log in to control, you must also specify the RSA keys required to encrypt user data. By default, the ssh user uses the user pix and the password specified by the passwd command (telnet password).
As a rule, since ASA version 7.2, the 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 clearly 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. For this you can use the standard commands cisco
or a short version of the last command
ASA also provides an extremely popular method of setting up using a web browser. This method is called ASDM (Adaptive Security Device Manager). For access the secure protocol https is used. Providing access is configured very similar to the ssh setting: you need to work out or make sure that the default RSA keys are present and specify where you can connect from.
If nothing else is configured, access will be provided without a user. If the password was specified for privileged mode
when connecting, it is necessary to specify it as a password, without specifying a user.
You need to verify that in the ASA flash there is an ASDM file corresponding to the OS you are using.
When working with ASDM, java is used and the following is true: if you are using 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 customizers, ASDM version 6 does not work better and faster than version 5.X. Whose merit is here: java or cisco or both - I do not know.
A reasonable question arises: what if you want to use not the default access rules, but explicitly indicate where to get the user from? To do this, use commands (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 need to use external databases accessible via TACACS +, RADIUS or LDAP protocols, then such servers need to be pre-configured
The local user base is set by the command
Access via ASDM is possible only on behalf of a user with a privilege level of 15 (maximum, means that the user can customize everything)
Also local users can set 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, but on different platforms it can be other physical interfaces), inside and outside, the default route, remote access via ssh and https is allowed from everywhere, with by this
authentication uses a local user database.
Using these settings, you allow the packets to go from the directly attached network behind the inside interface to the outside. Outside, only answers for sessions (tcp and udp) that are open from the inside will come, as I remind the default traffic going "inside" all prohibited. How to solve it let's talk in the next part.
Access Lists (continued)
Interface Setup
The Cisco ASA is a stateful inspection hardware firewall. ASA can work in two modes: routed (router mode, by default) and transparent (transparent firewall, when ASA works as a bridge with filtering). We will get acquainted with the work in the first mode and further we will mean it everywhere, unless a different mode is explicitly indicated.
')
In routed mode, each ASA interface is configured with ip address, mask, security level, interface name, and the interface must be “raised”, since by default all interfaces are in the “disabled by administrator” state. (Exceptions are: sometimes ASAshki come pre-configured. This is typical for model 5505. In this case, as a rule, the internal interface called inside is already configured as the safest and raised, it has a DHCP server, a static address from the 192.168.1.0 network is set / 24, the external interface with the name outside is also raised and receives the address itself via DHCP and the translation of addresses from the network behind the inside interface to the outside interface address is configured. This turns out to be 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 that allows you to compare 2 interfaces and determine which of them is more “secure”. The parameter is used qualitatively, not quantitatively, i.e. what matters is the more-less relationship. By default, traffic going outward, i.e. from an interface with a higher level of security to an interface with a lower level of security, is skipped, the session is remembered, and only responses to those sessions are skipped. The traffic going "inside" is by default prohibited.
The “interface name” parameter (nameif) allows you to use in the settings not the physical name of the interface, but its name, which can be selected as “speaking” (inside, outside, dmz, partner, etc.). In theory, according to cisco itself, the name does not depend on the register (not case sensitive), but in practice a number of commands require register compliance, which is rather inconvenient. A typical example: the use of a crypto map on an interface requires the exact spelling of the interface name. The interface name continues 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 dialed beginning uniquely identifies the interface.
This interface configuration is typical for all ASA models, except the ASA 5505. The 5505 model 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 L2 physical interfaces themselves are mapped to VLANs.
interface f0 / 0
switchport access vlan {#}
Thus, firewalling occurs between logical interfaces vlan.
As a rule, the interface security level is selected in such a way as to correspond to the logical network topology as much as possible. The topology itself is a security zone and the rules of interaction between them. The classic scheme is the assignment to different interfaces of different security levels.
Nobody forbids to make the security level on different interfaces the same, but by default the exchange of traffic between such interfaces is prohibited. Such traffic can be consciously resolved by issuing a command
same-security-traffic permit inter-interface
However, it should be understood that between interfaces with the same level of security, firewalling does not occur, but only routing. Therefore, this approach is used for interfaces belonging to the same logical security zone (for example, 2 user local area networks, combined with ASA)
Routing
Well, where do without it! Like any router (the ASA is also, because it uses the routing table to transmit packets), the networks configured on the interfaces automatically enter the routing table with the note “connected”, though the interface itself is in up state. Packet routing between these networks is done automatically.
Those networks that the ASA itself does not know should be described. This can be done manually using the command
route {interface} {network} {mask} {next-hop} [{administrative distance}] [track {#}]
Specifies the interface for which to look next-hop, because ASA itself does not do such a search (unlike the regular router cisco). I remind you that in the routing table there is only one route to the destination network, as opposed to 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 an entry in the routing table of the destination network of the packet, it discards the packet.
If there is a task to make a backup static route that will work only when the main one disappears, this is solved by specifying the so-called Administrative distance of the route. This is a number from 0 to 255, which indicates how good the route selection method is. For example, static routes are mapped to AD 1 by default, EIGRP is 90, OSPF is 110, and RIP is 120. You can explicitly specify AD for the alternate route more than the main AD. For example:
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 is physically dropped, everything is obvious - it will work, and if the interface is up, and the provider is dead? This is a very common situation, considering that on the ASA is 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 from version 7.2 they have implemented only the simplest mechanism: the availability of a certain host using the icmp protocol. To do this, create such a "pingovalka" (sla monitor)
sla monitor {#}
type echo protocol ipIcmpEcho {ip address} interface {interface}
Further, it is necessary to start it 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's not all. It is necessary to create a “switch” (track) that will track the state of the “pingalki”.
track {track #} rtr {sla #} reachability
Do not ask why pinging is linked with the rtr keyword - these are pieces of inconsistency of settings on cisco routers. By the way, on the routers themselves, this inconsistency has already been repaired, but the ASA does not yet exist.
And now everything is ready to apply this construction to static routing
route outside 0 0 {next-hop_outside} track {#}
route backup 0 0 {next-hop_backup} 210
Now, while the pinged host is available, the track will be in a raised (almost wrote in a “raised” :) state and the main route will be in the routing table, but as soon as the connection is lost, after a specified number of lost packets (by default, packets are sent every 10 seconds and waiting for three packets to disappear) track will be transferred to the down state and the main route will disappear from the routing table, and packets will be sent along the alternate path.
I will give an example of the config of the two default routes through different providers with a check of 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 1.1.1.1 track 11
route backup 0 0 2.2.2.1 210
Dynamic routing to ASA is possible using RIPv1,2, OSPF, EIGRP protocols. Configuring these protocols on the ASA is very similar to configuring the cisco routers. While I will not deal with dynamic routing in these publications, although if hands reach interest, I will write a separate chapter.
Remote control
It is clear that with the current development of data networks, it would be unwise to not introduce remote control of firewalls. Therefore, the ASA, like most cisco devices, provides several methods of remote control.
The simplest and most insecure is telnet. To provide access to the ASA via telnet, you must explicitly indicate which hosts and networks from which interface are allowed, and also set the telnet password using 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 security level within this ASA) interface is blocked and telnet operation on this interface is possible only if it arrives through the IPSec tunnel.
More secure access to the command line is provided by the ssh protocol. However, in order to provide ssh access, in addition to explicitly specifying from which hosts you can log in to control, you must also specify the RSA keys required to encrypt user data. By default, the ssh user uses the user pix and the password specified by the passwd command (telnet password).
! Set the domain name
domain name {name}
!
! It is advisable to specify a non-default host name.
hostname {name}
!
! After that, you can generate 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, since ASA version 7.2, the 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 clearly 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. For this you can use the standard commands cisco
copy running-config startup-config write memory
or a short version of the last command
wr
ASA also provides an extremely popular method of setting up using a web browser. This method is called ASDM (Adaptive Security Device Manager). For access the secure protocol https is used. Providing access is configured very similar to the ssh setting: you need to work out or make sure that the default RSA keys are present and specify where you can connect from.
domain name {name} hostname {name} crypto key generate rsa! We turn on the https server itself, it is often enabled 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 nothing else is configured, access will be provided without a user. If the password was specified for privileged mode
enable password {password}
when connecting, it is necessary to specify it as a password, without specifying a user.
You need to verify that in the ASA flash there is an ASDM file corresponding to the OS you are using.
dir flash: show flash
When working with ASDM, java is used and the following is true: if you are using 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 customizers, ASDM version 6 does not work better and faster than version 5.X. Whose merit is here: java or cisco or both - I do not know.
A reasonable question arises: what if you want to use not the default access rules, but explicitly indicate where to get the user from? To do this, use commands (console - keyword)
aaa authentication telnet console {server AAA name} [LOCAL]
aaa authentication ssh console {server AAA name} [LOCAL]
aaa authentication http console {server AAA 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 need to use external databases accessible via TACACS +, RADIUS or LDAP protocols, then such servers need to be pre-configured
aaa-server {server AAA name} protocol {tacacs | radius | ldap}
aaa-server {server AAA 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 a privilege level of 15 (maximum, means that the user can customize everything)
Also local users can set 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, but on different platforms it can be other physical interfaces), inside and outside, the default route, remote access via ssh and https is allowed from everywhere, with by 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 ! ! 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 the packets to go from the directly attached network behind the inside interface to the outside. Outside, only answers for sessions (tcp and udp) that are open from the inside will come, as I remind the default traffic going "inside" all prohibited. How to solve it let's talk in the next part.
Access Lists (continued)
Source: https://habr.com/ru/post/80414/
All Articles