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

       
    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)

    Also popular now: