Jugando con Cisco EEM (I)

Habitualmente, solemos monitorizar sucesos en routers (en este caso C1800) mediante traps snmp o agentes que procesan el log y tras evaluarlo, generan acciones. Cisco IOS Embedded Event Manager (EEM) nos da la posibilidad de definir acciones a eventos concretos generados en el sistema.

Por ejemplo, si usamos syslog para detectar accesos privilegiados a un router, tendríamos que tener un script que procese en tiempo real cada línea de log para buscar una cadena similar a «Privilege level set to 15 by«. Una vez detectada, un agente podría abrirnos una alerta en nuestro sistema de monitorización indicando del acceso privilegiado al router.

Una alternativa posible sería definirnos en EEM una entrada que recoja la información del susbsistema syslog y lance una acción al detectar un patrón concreto, en este caso el acceso privilegiado, por ejemplo enviar un trap SNMP o un correo electrónico de aviso.

Entraremos en detalle de EEM más adelante, no obstante, vamos a ver un ejemplo más práctico donde podríamos usar o no EEM. Por ejemplo, queremos disponer de un sistema automático para almacenar de forma periódica la configuración de nuestro router. Para abordar esta tarea, ahora mismo se me ocurren varias soluciones (quizás hay más que desconozco), por ejemplo:

  • Disponer de un script externo que obtiene la configuracion del sistema y la almacena en un fichero de forma periódica. Esto es bastante fácil de hacer, ya sea haciendo nosotros mismos el script, por ejemplo con expect o las librerias de Cisco de Perl, o con aplicaciones ya creadas como Rancid.
  • Usar el comando archive para guardar una copia de la configuración:
  • S2router(config)#archive                                                                                                 
    S2router(config-archive)# path flash:COPIA.txt                                                                                  
    S2router(config-archive)# time-period 1                                                                                         
    S2router(config-archive)# write-memory                                           
    S2router(config-archive)# exit              
    

    Una vez configurado, comienza a guardar copias cada minuto:

    S2router#show  archive                                                          
    
    There are currently 1 archive configurations saved.                             
    The next archive file will be named flash:COPIA.txt-1                           
     Archive #  Name                                                                
       0                                                                            
       1       flash:COPIA.txt-1                                                    
       2       flash:COPIA.txt-2                                                    
       3       flash:COPIA.txt-3                                                    
       4       flash:COPIA.txt-4                                
    
    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-    21169140  May 26 2010 18:20:18 +00:00  c1841-advsecurityk9-mz.12n              
        9  -rw-        5638  Dec 27 2013 15:58:54 +00:00  COPIA.txt-1                              
       10  -rw-        5638  Dec 27 2013 15:59:52 +00:00  COPIA.txt-2               
       11  -rw-        5615  Dec 27 2013 16:00:36 +00:00  COPIA.txt-3               
       12  -rw-        5615  Dec 27 2013 16:00:52 +00:00  COPIA.txt-4  
    
    
  • Disponer de una tarea periódica configurada en el router para volcar la configuración a un sitio remoto por ejemplo por TFTP o guardarla en flash (que es lo que vamos a hacer). Tenemos que tener en cuenta que cuando ejecutamos algunos comandos, el sistema nos solicita confirmación del mismo, por lo que para automatizar tareas y evitar esto, tendremos que usar el comando file prompt quiet, ya sea en modo de configuración global, o en cada tarea activándolo y desactivándolo. Para tareas periódicas, IOS dispone de un scheduler (kron) donde podríamos configurar lo siguiente:
    1. Creamos una policy-list de kron especificando las acciones a llevar a cabo:

        S2router(config)# kron policy-list copia                                         
        S2router(config-kron-policy)# cli copy running-config flash:copia.txt           
        S2router(config-kron-policy)# exit      
    

    2. Creamos una entrada en kron indicando la frecuencia de ejecución, por ejemplo cada minuto:

        S2router(config)# kron  occurrence  copia in 00:01 recurring                     
        S2router(config-kron-occurrence)#policy-list copia     
    

    3. Verificamos que la tarea esta en ejecución y cuando finaliza, tenemos nuestra copia almacenada en flash:

    S2router#show kron schedule                                                     
    Kron Occurrence Schedule                                                        
    copia inactive, will run again in 0 days 00:00:45  
    
    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-        5702  Dec 27 2013 10:21:18 +00:00  copia.txt        
    
    

Las situaciones vistas, implican que de forma periódica vamos almacenando las copias de seguridad, no obstante, en muchas ocasiones la configuración no cambia tanto como para requerir de la misma copia de seguridad todos los días, y menos si la copia se almacena en local, por lo que lo ideal sería disponer al menos de una copia cuando un administrador entra al sistema (aunque no realice ningún cambio). Es aquí donde podemos usar Cisco IOS EEM.

Cisco IOS Embedded Event Manager (EEM) es un sistema de Cisco IOS que permite recolectar datos de distintos subsistemas y llevar a cabo acciones, de forma que mediante la automonitorización reduce la necesidad de hacer polling al dispositivo y por lo tanto, podría reducir el ancho de banda usado por un NMS.

Su arquitectura es sencilla y consta de tres componentes:

  • Event detectors: recolectan información de los distintos subsistemas de IOS, como registros de syslog, comandos CLI, variables SNMP, registros Netflow, eventos de Routing, etc.
  • EEM Server: el sistema central que recibe la información, la procesa, y lanza una o varias acciones.
  • Policies: secuencias de comandos almacenados en memoria llamados applets o también scripts TCL definidos por el administrador.

Con EEM podemos generar copias periódicas por el vencimiento de timers o eventos de kron de forma similar a los vistos anteriormente, pero al darnos la potencia de poder detectar eventos y generar acciones concretas, podríamos hacer copias de seguridad únicamente cuando se detecte un acceso privilegiado al sistema. Vamos a verlo tanto con applets y acciones como con un script TCL.

Lo primero que debemos hacer es crear el applet:

S2router(config)# event manager applet ACCESOS  

A continuación, seleccionamos el patrón que buscamos dentro del susbistema syslog:

                           
S2router(config-applet)# event syslog pattern "Privilege level set to 15 by"    

Finalmente, indicamos las acciones a llevar a cabo cuando se detecta el patrón anterior. Estas serán por ejemplo registrar el acceso en el log (aparecerá en consola si lo tenemos configurado así) y realizar una copia de seguridad en flash:

S2router(config-applet)# action 1.0 cli syslog priority debugging msg "ACCESO PRIVILEGIADO"   
S2router(config-applet)# action 2.0 cli command "enable"                        
S2router(config-applet)# action 3.0 cli command "copy running-config flash:backup.txt"    
S2router(config-applet)# action 4.0 cli command "exit"   

Una vez creado, lo vemos registrado correctamente:

S2router# show  event manager policy registered                                  
No.  Class   Type    Event Type          Trap  Time Registered           Name   
1    applet  system  syslog              Off   Fri Dec 27 10:24:51 2013  ACCESOS
 pattern {Privilege level set to 15 by}                                         
 action 1.0 syslog priority debugging msg "ACCESO PRIVILEGIADO"                 
 action 2.0 cli command "enable"                                                
 action 3.0 cli command "copy running-config flash:backup.txt"                  
 action 4.0 cli command "exit"   

De forma que cuando accedemos por SSH, en la consola del sistema podríamos ver el mensaje anterior:

*Dec 27 10:27:31.643: %SYS-5-PRIV_AUTH_PASS: Privilege level set to 15 by jose )
*Dec 27 10:27:31.651: %HA_EM-7-LOG: ACCESOS: ACCESO PRIVILEGIADO                

Y comprobar que disponemos de la copia correcta almacenada en flash:

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:27:32 +00:00  backup.txt                
    9  -rw-        5702  Dec 27 2013 10:21:18 +00:00  copia.txt      

Con esto, ya disponemos de una copia de seguridad previa a los posibles cambios del administrador (lo mejor sería copiarla también a un sitio remoto). Lógicamente, si volvemos a entrar los cambios se perderán, pero podríamos disponer de variables de entorno definidas (show event manager environment) y guardar las copias con distintos nombres en base a la fecha de acceso. También podríamos enviar un correo electrónico o generar un trap SNMP para notificar del acceso.

En unos días la segunda parte con más opciones en EEM.

Firewalls transparentes

Como hemos visto infinidad de veces en libros o presentaciones de fabricantes, el firewall esta considerado como el elemento principal a la hora de llevar a cabo una correcta segmentación de redes y por lo tanto, habitualmente trabaja a nivel 3 proporcionando filtrado y enrutando entre ellas. Esta sería una arquitectura básica de red: el firewall segmentando una red corporativa en segmentos de DMZ, usuarios, servidores internos y WAN.

No obstante, y aunque nunca he tenido la necesidad de realizar una configuración así, muchos sistemas permiter trabajar a nivel 2 en modo transparente, manteniendo el direccionamiento de red dentro del segmento y siendo una configuración posible cuando se requiere un análisis o filtrado con el menor número de cambios posibles, por ejemplo, para no afectar a la red de servidores de producción. La arquitectura quedaría así:

[Read more…]

Firewalls Virtuales

Actualmente, lo habitual en una organización es disponer de un firewall/cluster y mediante el uso de vlans, ir creando nuevos segmentos dependiendo del crecimiento de la red, lógicamente siempre que el sistema a nivel de procesamiento no se vea afectado. No obstante, puede darse el caso de empresas que den servicio a múltiples clientes con el mismo firewall, de forma que se quiera diferenciar cada cliente de forma unívoca. Para ello, cada vez más aparecen en el mercado soluciones de firewalls virtuales y como casi siempre, el uso de una funcionalidad lleva asociada la licencia correspondiente.

Para este post, vamos a crear un firewall virtual en un dispositivo Cisco ASA 5550, no obstante, fabricantes como Fortinet disponen de soluciones similares.

Centrándonos en nuestro sistema, podemos crear múltiples firewalls virtuales llamados contextos, donde cada contexto es independiente del resto, y dispone de su propia política de seguridad, interfaces, usuarios o rutas, aunque hay otras funcionalidades que no vienen soportadas, como VPN o protocolos de enrutamiento dinámico (parece que en versiones actuales mejoran considerablemente estas limitaciones), no obstante, para nuestro caso, será suficiente.

Existen tres tipos de contexto:

  • system: el contexto raíz donde el administrador gestiona el resto de contextos del sistema, interfaces, recursos, etc.
  • admin: igual que cualquier otro contexto pero donde el administrador tiene permisos para acceder a otros contextos.
  • normal: una partición del firewall donde sólo se puede acceder a la información del propio contexto.

En nuestro ejemplo, partimos de un firewall sin configuración previa, si no lo fuera, deberíamos realizar una copia de seguridad previa. Una vez conectados al sistema, debemos asegurarnos de cuantos firewalls virtuales podemos crear con la licencia disponible:

ciscoasa# show version

Licensed features for this platform:                                                                                                    
Maximum Physical Interfaces  : Unlimited                                                                                                
Maximum VLANs                : 250                                                                                                      
Inside Hosts                 : Unlimited                                                                                                
Failover                     : Active/Active                                                                                            
VPN-DES                      : Enabled                                                                                                  
VPN-3DES-AES                 : Enabled                                                                                                  
Security Contexts            : 5                                                                                                        
GTP/GPRS                     : Disabled                                                                                                 
VPN Peers                    : 5000                                                                                                     
WebVPN Peers                 : 2                                                                                                        
Advanced Endpoint Assessment : Disabled           

En éste caso, podríamos tener 5 contextos. Aclarado esto, procedemos con la configuración:

1. Configurar el sistema en modo múltiple:

ciscoasa# show mode                                                             
Security context mode: single  

ciscoasa(config)# mode  multiple                                                
WARNING: This command will change the behavior of the device                    
WARNING: This command will initiate a Reboot                                    
Proceed with change mode? [confirm]                                             
Convert the system configuration? [confirm]   

Tras reiniciar, podemos comprobar que el sistema ya aparece configurado en modo múltiple y dispone de configuración específica para el contexto admin:

ciscoasa# show  mode                                                            
Security context mode: multiple     

ciscoasa# show run
…...
class default                                                                   
  limit-resource All 0                                                          
  limit-resource ASDM 5                                                         
  limit-resource SSH 5                                                          
  limit-resource Telnet 5      
admin-context admin                                                             
context admin                                                                   
  config-url disk0:/admin.cfg 

2. Crear interfaces virtuales y asociarles identificador de vlan. Ya que vamos a usar vlans para confgurar contextos, necesitamos definir trunks en los switches

ciscoasa(config)# mac-address auto                                                                                                                        
ciscoasa(config)# interface GigabitEthernet0/1.1                            
ciscoasa(config-subif)# vlan 100
ciscoasa(config-subif)# no shutdown 
ciscoasa(config-subif)# interface GigabitEthernet0/2.1
ciscoasa(config-subif)# no shutdown
ciscoasa(config-subif)# vlan 200
ciscoasa(config-subif)# interface GigabitEthernet0/3.1
ciscoasa(config-subif)# no shutdown
ciscoasa(config-subif)# vlan 300

3. Definir los contextos (el contexto admin ya existe):

ciscoasa(config)# context Cliente1                                              
Creating context 'Cliente1'... Done. (2)                                        
ciscoasa(config-ctx)# description Contexto1   

4. Asignar visibilidad sobre las interfaces a cada contexto e indicar el fichero de configuración del mismo:

ciscoasa(config-ctx)# allocate-interface GigabitEthernet0/1.1 inside            
ciscoasa(config-ctx)# allocate-interface GigabitEthernet0/2.1 outside           
ciscoasa(config-ctx)# allocate-interface GigabitEthernet0/3.1 dmz 
ciscoasa(config-ctx)# config-url disk0:/cliente1.cfg     

Una vez configurados los contextos, podemos cambiar a un contexto específico y configurarlo como si de un único firewall se tratara. Una vez nos situamos en el contexto, vemos que el prompt cambia:

ciscoasa# changeto context Cliente1                                     
ciscoasa/Cliente1# show running-config
...
interface inside                                                                
 no nameif                                                                      
 no security-level                                                              
 no ip address                                                                  
!                                                                               
interface outside                                                               
 no nameif                                                                      
 no security-level                                                              
 no ip address                                                                  
!                                                                               
interface dmz                                                                   
 no nameif                                                                      
 no security-level                                                              
 no ip address    

En este punto, podemos volver al contexto system para crear un nuevo contexto:

ciscoasa/Cliente1(config)# changeto system                                      
ciscoasa(config)# context Cliente2                                              
Creating context 'Cliente2'... Done. (3)                                                                                        
ciscoasa(config-ctx)# description Contexto2                                     
ciscoasa(config-ctx)# allocate-interface GigabitEthernet0/1.2 inside            
ciscoasa(config-ctx)# allocate-interface GigabitEthernet0/2.2 outside           
ciscoasa(config-ctx)# allocate-interface GigabitEthernet0/3.2 dmz    
  config-url disk0:/cliente2.cfg          

Una vez creado (no tiene asignadas vlans todavía), podemos ver los contextos definidos en el sistema:

ciscoasa(config)# show context                                                  
Context Name      Class      Interfaces           URL                           
*admin            default                         disk0:/admin.cfg              
 Cliente1         default    GigabitEthernet0/1.1, disk0:/cliente1.cfg          
                             GigabitEthernet0/2.1,                              
                             GigabitEthernet0/3.1                               
 Cliente2         default    GigabitEthernet0/1.2, disk0:/cliente2.cfg          
                             GigabitEthernet0/2.2,                              
                             GigabitEthernet0/3.2                               
                                                                                
Total active Security Contexts: 3    

Antes de entrar a configurar nuestro contexto, si nos fijamos en la salida del comando anterior, vemos que aparece una class definida por defecto. Esta opción es útil si queremos limitar los recursos de nuestros contextos, ya sea para evitar la saturación del sistema, o por que dispongamos de contratos gold/silver y en cada uno de ellos, limitemos los recursos contratados.

Tras esto, volvemos a configurar nuestro contexto de forma independiente:

                                
ciscoasa# changeto context Cliente1
ciscoasa/Cliente1(config)# hostname ASA1   
ciscoasa/Cliente1(config)# domain-name cliente1.com     
ciscoasa/Cliente1(config)# username admin password admin privilege 15                                                               
ciscoasa/Cliente1(config)# interface inside
ciscoasa/Cliente1(config-if)# nameif inside
ciscoasa/Cliente1(config-if)#  security-level 100
ciscoasa/Cliente1(config-if)#  ip address 172.18.0.200 255.255.255.0
ciscoasa/Cliente1(config-if)#  no shutdown
ciscoasa/Cliente1(config)# http server enable                                                    
ciscoasa/Cliente1(config)# crypto key generate rsa                              
ciscoasa/Cliente1(config)# show crypto key mypubkey  rsa                      
Key pair was generated at: 06:14:35 UTC Dec 17 2013                             
Key name:                                                      
 Usage: General Purpose Key                                                     
 Modulus Size (bits): 1024                                                      
 Key Data:                                                                      
                                                                                
  30819f30 0d06092a 864886f7 0d010101 05000381 8d003081 89028181 00d81874       
  dcca041b fbb5752c 5f5562f1 95422b42 e825e7b4 0b7b0aee 5cd90c04 e3302ddc       
  d9ee6c98 8664e8cd 2a3ad611 aa6b9d35 09cc81f3 48eccbe3 129d5483 17170a54       
  b1bef1ca b351ede5 86e3b26b 8f8619f9 b5d928c7 3b391861 8a1c72de 449e0fbc       
  b2acddee 3deaa0ff db55df25 4ba26f7b 6446972c e05e1839 52a09bad 45020301 0001 

ciscoasa/Cliente1(config)# http 172.18.0.150 255.255.255.255 inside             
ciscoasa/Cliente1(config)# ssh 172.18.0.150 255.255.255.255 inside                                                                      
ciscoasa/Cliente1(config)# wr mem

En este punto, ya podríamos acceder de forma remota al dispositivo y gestionarlo de forma independiente.

Desde el contexto admin, podemos ver la configuración de los contextos con el comando show running-config all context [name] y los recursos consumidos con show resource usage context [name]:

ciscoasa(config)#  show resource usage context Cliente1                                                                                 
Resource              Current         Peak      Limit        Denied Context                                                             
ASDM                        1            1          5             0 Cliente1                                                            
Conns                       2            9  unlimited             0 Cliente1                                                            
Hosts                       2            2  unlimited             0 Cliente1                                                            
Conns [rate]                1           11  unlimited             0 Cliente1    

También podemos guardar todos los cambios de los contextos:

ciscoasa(config)# wr mem all                                                                                                            
Building configuration...                                                                                                               
Saving context :           system : (000/003 Contexts saved)                                                                            
Cryptochecksum: 1eb2b9ed bf4f0170 628827cb cda1116d                                                                                     
                                                                                                                                        
1612 bytes copied in 3.300 secs (537 bytes/sec)                                                                                         
Saving context :            admin : (001/003 Contexts saved)                                                                            
Cryptochecksum: d367f98b 4f1280c6 2a3275f4 5e0df5eb                                                                                     
                                                                                                                                        
1313 bytes copied in 0.200 secs                                                                                                         
Saving context :         Cliente1 : (002/003 Contexts saved)                                                                            
Cryptochecksum: fc0590ec a8514229 3d126e92 4052d174                                                                                     
                                                                                                                                        
1572 bytes copied in 0.210 secs                                                                                                         
Saving context :         Cliente2 : (003/003 Contexts saved)                                                                            
Cryptochecksum: 81553ccc ebd17807 b63b1f4b ee30b125                                                                                     
                                                                                                                                        
1432 bytes copied in 0.200 secs                                                                                                         
[OK]              

Finalmente, podemos borrar contextos o volver a dejar el sistema en modo single:

ciscoasa(config)#  no context Cliente2                                                                                                  
WARNING: Removing context 'Cliente2'                                                                                                    
Proceed with removing the context? [confirm]                                                                                            
Removing context 'Cliente2' (3)... Done  


ciscoasa(config)# show  context                                                                                                         
Context Name      Class      Interfaces           URL                                                                                   
*admin            default                         disk0:/admin.cfg                                                                      
 Cliente1         default    GigabitEthernet0/1.1, disk0:/cliente1.cfg                                                                  
                             GigabitEthernet0/2.1,                                                                                      
                             GigabitEthernet0/3.1                                                                                       
                                                                                                                                        
Total active Security Contexts: 2            

Para restaurar el sistema, debemos recuperar la copia de seguridad previa si disponemos de ella, en otro caso, perderemos los cambios iniciales:

ciscoasa(config)# mode single                                                                                                           
WARNING: This command will change the behavior of the device                                                                            
WARNING: This command will initiate a Reboot                                                                                            
Proceed with change mode? [confirm]                                                                                                     
Security context mode: single    

Tras reiniciar, podremos borrar los ficheros generados anteriormente

                                                                                        
ciscoasa# delete disk0:/cliente1.cfg                                                                                                    
Delete filename [cliente1.cfg]?                                                                                                         
                                                                                                                                        
Delete disk0:/cliente1.cfg? [confirm]                                                                                                   
                                                                                                                                        
ciscoasa# delete disk0:/cliente2.cfg                                                                                                     
Delete filename [cliente2.cfg]?                                                                                                          
Delete disk0:/cliente2.cfg? [confirm]    

ciscoasa# delete disk0:/admin.cfg                                                                                                        
Delete filename [admin.cfg]?                                                                                                             
Delete disk0:/admin.cfg? [confirm]  

De esta forma, y salvado las limitaciones existentes, podríamos disponer de mútiples firewalls independientes para dar soporte a distintos clientes en una única plataforma.

Aplicación de AAA: Authentication, Authorization and Accounting (II)

Siguiendo con el post de ayer y tras ver las distintas funcionalidades que podemos configurar usando Radius como servidor AAA, podemos mejorar el sistema VPMS (Vlan Management Policy Server) visto en un post anterior, y poder autenticar los accesos a la red mediante el protocolo 802.1x, un estándar del IEEE para la autenticación de equipos conectados a una red mediante distintas tecnologías, de forma que se previene el acceso a la misma si la autenticación falla.

Para habilitar el protocolo 802.1x en nuestro dispositivo, primero debemos habilitar el servicio de forma global:


S2router(config)# dot1x system-auth-control

A continuación, activamos 802.1x en los puertos de acceso a red donde se conectan los usuarios. En nuestro caso simplemente una interfaz del router, pero seria extensible a un switch.


S2router(config)# interface fastethernet 0/1
S2router(config-if)# pae authenticator
S2router(config-if)# dot1x port-control auto

En este momento, el equipo conectado a dicho puerto perderá el acceso a red, posiblemente indicando un problema de autenticación.

El siguiente paso es configurar la autenticación 802.1x en el equipo cliente (en nuestro caso Windows XP), el cual, en estos momentos donde la autenticación ha fallado, podemos comprobar en el router que se encuentra en estado AUTHENTICATING ya que no se han proporcionado todavía las credenciales de acceso correctas:


S2router# show dot1x interface fastethernet0/1 details
PAE = AUTHENTICATOR
PortControl = AUTO
ReAuthentication = Enabled
ReAuthPeriod = 120 Seconds
ServerTimeout = 30 Seconds
SuppTimeout = 30 Seconds
QuietWhile = 120 Seconds
RateLimit = 0 Seconds
MaxReq = 2

Dot1x Client List
-------------------------------------
MAC Address State
-------------------------------------

0023.8bd7.c2b3 AUTHENTICATING

Para configurar el equipo cliente, dentro de la configuración de las propiedades de red, seleccionamos la pestaña Autenticación (debemos tener activado el servicio de autoconfiguración de redes cableadas), activando la autenticación 802.1x y seleccionando desafío MD5 como método de autenticación, ya que no disponemos de infraestructura PKI en nuestra configuración.

Tras activar esta opción, aparece una ventana de autenticación de acceso a red propia de Windows, donde indicamos el usuario y contraseña definidos en el servidor radius (juanito). No es necesario indicar dominio.

Una vez el sistema valida las credenciales, podemos ver el equipo autenticado:


S2router# show dot1x interface fastethernet0/1 details
PAE = AUTHENTICATOR
PortControl = AUTO
ReAuthentication = Disabled
ReAuthPeriod = 3600 Seconds
ServerTimeout = 30 Seconds
SuppTimeout = 30 Seconds
QuietWhile = 120 Seconds
RateLimit = 0 Seconds
MaxReq = 2

Dot1x Client List
-------------------------------------
MAC Address State
-------------------------------------

0023.8bd7.c2b3 AUTHENTICATED

Llegados a éste punto, el usuario final ya dispondría de acceso a la red con normalidad.

Esta solución es una medida de seguridad más a la hora de securizar nuestra red, y como siempre, debemos evaluar los pros y los contras de cada medida antes de ser implantada, tanto desde el punto de vista de seguridad, como desde el punto de vista de la transparencia de acceso del usuario, para que pueda realizar sus tareas diarias con normalidad.

Aplicación de AAA: Authentication, Authorization and Accounting

Recientemente, nuestro compañero Juan Manuel Sanz, ha publicado diversos artículos sobre el uso de servidores Radius como parte de una solución Wifi empresarial (ver I y II) Aparte de este uso, podemos usar Radius como servidor AAA (authentication, authorization and accounting) en nuestros dispositivos de red, como routers o switches, para el control de acceso a la misma. En este post, vamos a mostrar algunos ejemplos de uso de un servidor AAA.

El esquema de red que vamos a seguir es el siguiente:

En el esquema, podemos ver el router (Cisco 1800) como Autenticador, el servidor Freeradius como servidor de autenticación, y dos usuarios, un gestor de red que va a administrar el router por SSH y un usuario final del servicio.

Como pasos previos, vamos a configurar SSH como método de acceso al router y un usuario local del mismo (pepito):

router(config)# hostname  S2router                                                                                                                                    
S2router(config)# ip domain-name  s2grupo.es                                                                                                                          
S2router(config)# crypto key generate rsa 
## How many bits in the modulus [512]: 1024
S2router(config)# ip ssh time-out 60
S2router(config)# ip ssh authentication-retries 2
S2router(config)# aaa new-model
S2router(config)# line vty 0 4                                                                                                                                        
S2router(config-line)# transport input ssh    
S2router(config)# username pepito secret password    

Una vez configurado, podemos comprobar el acceso sin problemas al dispositivo:

PC$ ssh pepito@172.18.0.200
## Welcome ##
pepito@172.18.0.200's password: ******
S2router> 
 
S2router# show  ssh                                                                                                                                                   
Connection Version Mode Encryption  Hmac         State                 Username                                                                                      
0          2.0     IN   aes128-cbc  hmac-md5     Session started       pepito
0          2.0     OUT  aes128-cbc  hmac-md5     Session started       pepito                                                                                        
%No SSHv1 server connections running.     

Authentication

En nuestro primer punto, vamos a usar el servidor Radius (172.18.0.155) para autenticar los accesos por SSH para la gestión del router; para ello, usamos el usuario juanito definido previamente por Juan Manuel, en el fichero users de radius, no obstante, no usaremos certificados en nuestra configuración. Con el usuario ya definido, añadiremos un nuevo cliente al fichero clients.conf que se corresponderá con el router de nuestra infraestructura.

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

A continuación, nos conectamos al dispositivo de red (por ejemplo mediante el usuario pepito) e indicamos que la autenticación va a usar el servidor radius. Para ello, seguimos los siguientes pasos:

1. Definimos el servidor radius:

S2router(config)# radius-server host 172.18.0.155 auth-port 1812 acct-port  1813 
S2router(config)# radius-server deadtime 15                                      
S2router(config)# radius-server key password   

2. Configuramos el método de autenticación. Es importante configurar varios métodos de autenticación por si no esta disponible alguno de ellos, no perder el acceso al dispositivo. En este caso, el segundo método de autenticación es la base de datos local del propio equipo:

S2router(config)# aaa authentication login USUARIOS group radius local   

3. Probamos el acceso desde la propia consola del dispositivo:

S2router#test aaa group radius juanito password  legacy   
                                                                                                         
Attempting authentication test to server-group radius using radius                                                                                                   
User was successfully authenticated.     

4. Configuramos el acceso al dispositivo por SSH autenticando mediante radius:

S2router(config)# line vty 0 4                                                                                                                                    
S2router(config-line)# login authentication USUARIOS        

5. Probamos el acceso desde el exterior por SSH:

PC$ ssh juanito@172.18.0.200
## Welcome ##
juanito@172.18.0.200's password: ******
S2router> 

S2router# show  ssh                                                                                                                                                   
Connection Version Mode Encryption  Hmac         State                 Username                                                                                      
0          2.0     IN   aes128-cbc  hmac-md5     Session started       juanito                                                                                       
0          2.0     OUT  aes128-cbc  hmac-md5     Session started       juanito                                                                                       
%No SSHv1 server connections running.    

Como se puede apreciar, accedemos correctamente y podemos ver log de radius para confirmarlo:

rad_recv: Access-Request packet from host 172.18.0.200 port 1645, id=17, length=99
        User-Name = "juanito"
        Reply-Message = "Password: "
        User-Password = "password"
        NAS-Port = 194
        NAS-Port-Id = "tty194"
        NAS-Port-Type = Virtual
        Calling-Station-Id = "172.18.0.150"
        NAS-IP-Address = 172.18.0.200
# Executing section authorize from file /etc/freeradius/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] No '@' in User-Name = "juanito", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
[files] users: Matched entry juanito at line 205
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
++[pap] returns updated
Found Auth-Type = PAP
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group PAP {...}
[pap] login attempt with password "password"
[pap] Using clear text password "password"
[pap] User authenticated successfully
++[pap] returns ok
# Executing section post-auth from file /etc/freeradius/sites-enabled/default
+- entering group post-auth {...}
++[exec] returns noop
Sending Access-Accept of id 17 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 17 with timestamp +10
Ready to process requests.

En este punto, el usuario juanito accede sin problemas pero pepito no, ya que no dispone de usuario dado de alta en el servidor radius, no obstante, si detenemos el servidor radius, pepito accederá pero juanito no, ya que usaremos la base de datos local del dispositivo, por eso, es importante disponer de varios métodos de autenticación.

Habitualmente, el acceso a la gestión de los dispositivos suele basarse en usuarios locales debido a que no debería existir demasiadas personas que gestionen el dispositivo, no obstante, podríamos usar el mismo ejemplo para validar usuarios y grupos de acceso VPN.

Authorization

La siguiente funcionalidad sería, para usuarios autenticados, poder autorizar que acciones puede realizar, por ejemplo, que comandos tienen disponibles para ejecutar en el dispositivo. Para nuestro escenario inicial, el usuario juanito no dispone de privilegios de administración del dispositivo:

PC$ ssh juanito@172.18.0.200
## Welcome ##
juanito@172.18.0.200's password: ******
S2router> show running-config
           ^ 
% Invalid input detected at '^' marker.

No obstante podemos definir permisos para un nivel de privilegios concretos y luego indicarle al servidor radius que asocie a un usuario a dicho nivel.

Primero, definimos permisos para el nivel 3 de privilegios del sistema:

S2router(config)# privilege  exec  level  3 show running-config                                                                                                       
S2router(config)# privilege exec level 3 configure terminal                                                                                                           
S2router(config)# privilege configure all level 3 interface     

Con estos comandos, juanito, como operador de red, podría gestionar las interfaces de red y ver su configuración en el dispositivo. A continuación, definimos que el equipo use radius como sistema de autorización, al igual que hicimos en el apartado anterior:

S2router(config)# aaa authorization exec USUARIOS group radius local            

Finalmente, lo asociamos el servidor de autorización a la conexión remota al dispositivo:

S2router(config)# line vty 0 4
S2router(config-ine )# authorization exec USUARIOS   

Una vez configurado el dispositivo, modificamos la definición del usuario juanito indicando parámetros adicionales para su autorización para que disponga de privilegios de nivel 3:

juanito Cleartext-Password := "password"
        Service-Type = NAS-Prompt-User,
        Cisco-AVPair += "shell:priv-lvl=3",

De forma que la próxima vez que accede al dispositivo, ya se le aplicarán los nuevos permisos configurados:

PC$ ssh juanito@172.18.0.200
## Welcome ##
juanito@172.18.0.200's password: ******

S2router# show  privilege 
Current privilege level is 3

S2router# show running-config
Building configuration...
-----

Como podemos ver, el prompt de usuario ha cambiado con respecto al punto anterior.

Accounting

La última opción es la de accounting. Personalmente, de las tres funcionalidades que hemos visto, ésta es la que menos he usado. También hay que tener en cuenta que hay algunos comandos en los dispositivos Cisco que no funcionan con servidores radius (por ejemplo el accounting de commands), sino que sólo se pueden configurar usando un servidor AAA tacacs+.

Para este apartado, la configuración será similar a la configurada anteriormente: hay que definir radius dentro de la configuración de accounting. Para nuestro ejemplo, definimos algunas opciones de accounting de acceso remoto:

S2router(config)# aaa accounting send stop-record authentication failure 
S2router(config)# aaa accounting update periodic 1
S2router(config)# aaa accounting exec USUARIOS start-stop group radius
S2router(config)# aaa accounting network USUARIOS start-stop group radius

A continuación, aplicamos accounting para las conexiones remotas:

S2router(config)#line vty 0 4
S2router(config-line)# accounting exec USUARIOS

Ahora, al conectar al dispositivo, se registra un log de accesos, donde podemos ver información de los accesos remotos como el login de usuario, hora de conexión, dirección IP origen, etc.

PC# more /var/log/freeradius/radacct/172.18.0.200/detail-20131204 

Wed Dec  4 11:31:04 2013
        Acct-Session-Id = "00000048"
        User-Name = "juanito"
        Acct-Authentic = RADIUS
        Acct-Status-Type = Start
        NAS-Port = 194
        NAS-Port-Id = "tty194"
        NAS-Port-Type = Virtual
        Calling-Station-Id = "172.18.0.150"
        Service-Type = NAS-Prompt-User
        NAS-IP-Address = 172.18.0.200
        Acct-Delay-Time = 0
        Acct-Unique-Session-Id = "245d0d9d5afc1a35"
        Timestamp = 1386153064
        Request-Authenticator = Verified

Una solución de accounting sería útil por ejemplo, en un router con funcionalidades de gateway de voz, para llevar registro de llamadas y poder realizar una facturación posterior.

Analizando nuestra red (III)

¿Sabemos qué tráfico circula por nuestra red? Al hilo de los distintos posts (Analizando nuestra red, Analizando nuestra red II) de análisis de red que se han ido publicando en este blog hoy vamos a continuar en este tema centrándonos en el análisis del tráfico desde un punto de vista de rendimiento y clasificación del mismo.

Cuando monitorizamos una red, nos solemos centrar en dos puntos, la cantidad de tráfico que atraviesa la red, habitualmente mediante la activación del servicio SNMP y la consulta mediante polling del tráfico de las interfaces de red, mediante alguna herramienta que gráficamente muestre los resultados, como puede ser mrtg o Cacti, y la tipología de dicho tráfico.

Para poder monitorizar que tipo de tráfico circula por nuestra red existen distintas soluciones, aunque nos centraremos en el uso del protocolo netflow; A grandes rasgos, netflow es un protocolo de red desarrollado por Cisco para la monitorización y análisis de tráfico de red, el cual está presente en distintos fabricantes de dispositivos en la actualidad.

La arquitectura netflow esta constituida por tres elementos:

  • Netflow Exporter: el dispositivo de red, habitualmente un router o un switch de gama alta (hay que confirmar previamente que el servicio netflow está soportado), que captura los flujos de datos que circulan por él, enviando información sobre direcciones IP, puertos o protocolos usados.
  • Netflow collector: el elemento que recoge la información enviada por el dispositivo de red y la almacena.
  • Consola de análisis: el sistema a través del cual el gestor de red analiza la información almacenada por el colector.

Para este post hemos usado un Router Cisco 1800 como Netflow Exporter y un sistema GNU/Linux para la implementación del Netflow collector y la consola de análisis.

Una vez tenemos los equipos configurados a nivel de red y por lo tanto, existe conectividad entre ellos, configuramos el colector; para ello, instalamos las herramientas flow-tools en nuestro sistema y configuramos el servicio indicando en el fichero de configuración /etc/flow-tools/flow-capture.conf la información del dispositivo de red que nos enviará la información; por cada dispositivo añadiremos al fichero de configuración una entrada como la siguiente:

-w /var/netflow/flows/completed/router 0/172.18.0.200/9995 -S1

Indicando el directorio donde almacenaremos la información enviada ordenada por fecha (/var/netflow/flows/completed/router), los datos de red del dispositivo de la forma Dirección Local/Dirección Remota/Puerto, por lo que con el parámetro 0/172.18.0.200/9995, indicamos que recibimos información del dispositivo con dirección IP 172.18.0.200 a través del puerto 9995 de cualquiera de las direcciones IP del servidor y en intervalos de un minuto. Una vez arrancado el servicio, ya podemos recibir la información de dispositivo de red.

A continuación procedemos a configurar el servicio Netflow en el router (algunos de éstos comandos son opcionales):

# Indicamos el tiempo durante el cual flujo activo antes de expirar de la caché
Router(config)#ip flow-cache timeout active 1 

# Indicamos el número de entradas en la caché
Router(config)#ip flow-cache entries 20
# Interfaz que usaremos para conectar con el colector
Router(config)#ip flow-export source FastEthernet0/0
# Versión del protocolo
Router(config)#ip flow-export version 5
# Dirección IP y puerto de colector
Router(config)#ip flow-export destination 172.17.2.23 9995 

# Captura de flujos del aplicaciones más usadas
Router(config)#ip flow-top-talkers
# Maximo número de aplicaciones
Router(config-flow-top-talkers)# top 20
# Criterio de ordenación
Router(config-flow-top-talkers)# sort-by bytes
# Filtro de flujos
Router(config-flow-top-talkers)# match destination port min 0 max 65535 

# Interfaz que captura flujos
Router(config)#interface FastEthernet0/0
# Activamos netflow para el tráfico inbound
Router(config-if)# ip flow ingress
# Activamos netflow para el tráfico outbound
Router(config-if)# ip flow egress
# Activamos la cache netflow para el enrutamiento
Router(config-if)# ip route-cache flow

Llegados a este punto, el dispositivo está en disposición de capturar los flujos de tráfico:

Router#show ip flow export
Flow export v5 is enabled for main cache
Exporting flows to 172.17.2.23 (9995)
Exporting using source interface FastEthernet0/0
Version 5 flow records
168 flows exported in 74 udp datagrams
0 flows failed due to lack of export packet
0 export packets were sent up to process level
0 export packets were dropped due to no fib
0 export packets were dropped due to adjacency issues
0 export packets were dropped due to fragmentation failures
0 export packets were dropped due to encapsulation fixup failures
Router#show ip flow top-talkers
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Bytes
Fa0/0 172.17.2.23 Local 172.18.0.200 06 0016 A4B2 60K
Fa0/0 172.17.2.23 Local 172.18.0.200 06 A332 0017 2567
2 of 20 top talkers shown. 2 of 2 flows matched.

Router#show ip cache flow
IP packet size distribution (19470 total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .056 .606 .007 .005 .005 .004 .004 .004 .004 .298 .000 .000 .000 .000

512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 278544 bytes
2 active, 4094 inactive, 170 added
4303 ager polls, 0 flow alloc failures
Active flows timeout in 1 minutes
Inactive flows timeout in 15 seconds
IP Sub Flow Cache, 21640 bytes
2 active, 1022 inactive, 170 added, 170 added to flow
0 alloc failures, 0 force free
1 chunk, 1 chunk added
last clearing of statistics never
Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)
-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow
TCP-Telnet 7 0.0 99 41 0.2 29.0 6.0
TCP-other 44 0.0 155 314 2.0 40.5 5.9
UDP-other 76 0.0 154 74 3.4 0.5 15.5
ICMP 41 0.0 1 139 0.0 0.7 15.4
Total: 168 0.0 114 158 5.6 12.2 12.6

SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Fa0/0 172.17.2.23 Local 172.18.0.200 06 0016 A4B2 172
Fa0/0 172.17.2.23 Local 172.18.0.200 06 A332 0017 35

A continuación, como gestores de red y a través de la consola de análisis que proporciona flow-tools, ya somos capaces de mostrar la información enviada de una fecha concreta y almacenada en el colector.

Linux:/# flow-cat /var/netflow/flows/completed/test/2013/2013-05/2013-05-15/*
    | flow-print

srcIP          dstIP        prot   srcPort dstPort octets   packets
172.18.0.150   172.18.0.200  1     0       0       518880   360
172.17.0.87    172.18.0.200  6     22      15042   83196    282
172.18.0.150   172.18.0.200  6     55215   23      9560     239
172.17.2.23    172.18.0.200  17    44186   161     71       1
172.17.2.23    172.18.0.200  17    50078   161     71       1
172.17.2.23    172.18.0.200  17    40590   161     73       1
172.17.2.23    172.18.0.200  17    44599   161     73       1
172.17.2.23    172.18.0.200  17    59577   161     73       1

Lógicamente, con estos datos almacenados, es posible configurar una interfaz gráfica, como por ejemplo el plugin Flowview de Cacti, para recoger esta información almacenada y presentarla de forma más amigable para el gestor, pudiendo filtrar los flujos recibidos y crear gráficas por puertos o direcciones IP (pinchar en la imagen para ampliarla).

Para acabar, flow-tools nos permite crear filtros de captura para analizar los flujos recibidos en base a patrones. Si por ejemplo queremos obtener los flujos de tráfico SSH, podríamos crear en un fichero (/tmp/filter) un filtro como el siguiente:

filter-primitive SSH
type ip-port
permit 22

filter-definition FlujoSSH
match ip-destination-port SSH

Y aplicar el filtro a la información almacenada un día concreto:

Linux:/# flow-cat /var/netflow/flows/completed/test/2013/2013-05/2013-05-15/*
    | flow-nfilter -F FlujoSSH -f /tmp/filter | flow-print

srcIP         dstIP         prot    srcPort dstPort octets packets
172.18.0.150  172.18.0.200  6       34498   22      44     1
172.18.0.150  172.18.0.200  6       33169   22      44     1
172.18.0.150  172.18.0.200  6       63712   22      44     1
172.18.0.150  172.18.0.200  6       61025   22      44     1
172.18.0.150  172.18.0.200  6       43271   22      44     1
172.18.0.150  172.18.0.200  6       44450   22      44     1
172.18.0.150  172.18.0.200  6       33121   22      44     1
172.18.0.150  172.18.0.200  6       63119   22      44     1
172.18.0.150  172.18.0.200  6       37077   22      44     1
172.18.0.150  172.18.0.200  6       35145   22      44     1
172.18.0.150  172.18.0.200  6       59776   22      44     1
172.18.0.150  172.18.0.200  6       52694   22      44     1
172.18.0.150  172.18.0.200  6       44754   22      44     1

Con ésta funcionalidad y aunque hay aplicaciones dedicadas a ello, no sería complejo crear un agente que analizara periódicamente los flujos recibidos por el colector en busca de patrones sospechosos o cambios en el uso de la red, como por ejemplo un aumento del uso del protocolo telnet en la red con respecto a información anterior, generando una alerta en nuestro sistema de monitorización.

VLAN Management Policy Server

Habitualmente, cuando tenemos que llevar a cabo la segmentación lógica de una red mediante el uso de VLANs, procedemos a crear las redes necesarias ya sea de forma manual o automáticamente mediante protocolos tipo VTP (VLAN Trunking Protocol) de Cisco en nuestra red y tras esto, asignamos las distintas interfaces de los dispositivos a cada una de las VLANs definidas. Esto supone que, si mañana me cambio de sitio y cambio mi portátil de toma de red, deberé configurar la nueva toma de red para que pertenezca a la VLAN que necesito para llevar a cabo mi trabajo diario.

Una solución a este problema puede ser el uso junto al protocolo VTP, el servicio VMPS (VLAN Management Policy Server) de Cisco, el cual proporciona una primera aproximación a una solución de control de acceso a red tan ofrecida por los fabricantes en la actualidad. Entre otras funcionalidades, VMPS permite asociar dinámicamente equipos a VLANs basándonos en su dirección MAC (con el problema de seguridad que supone), de forma que mi portátil, en cualquier toma de red de la oficina al que lo conecte, siempre pertenecerá a la misma VLAN y podré trabajar con normalidad.

Cualquier switch Cisco de gama media soporta VMPS como cliente, no obstante, solo las gamas altas (superiores a la 4000), soportan el modo servidor. A pesar de esto, no es necesario disponer de uno de estos equipos para aplicar esta solución ya que existen multitud de herramientas tanto libres (algunas algo desactualizadas) como comerciales que nos proporcionan la funcionalidad de servidor VMPS que necesitamos. Dentro de todas ellas, se ha seleccionado vmpsd (http://sourceforge.net/projects/vmps/), un pequeño demonio para GNU/Linux que nos proporciona un servidor VMPS sin necesidad de instalar demasiado software, como un sistema de gestión de base de datos. Para proceder a configurar VMPS en nuestro switch (el elegido es un Cisco 2960), realizamos los siguientes pasos:

1) Configuramos VTP

Switch(config)#vtp  mode  server 
Switch(config)#vtp  domain s2

Switch#show  vtp  status 
          : running VTP2
Configuration Revision          : 1
Maximum VLANs supported locally : 255
Number of existing VLANs        : 14
VTP Operating Mode              : Server
VTP Domain Name                 : s2
VTP Pruning Mode                : Disabled
VTP V2 Mode                     : Enabled
VTP Traps Generation            : Disabled
MD5 digest                      : 0xC4 0xE8 0xDB 0x1A 0xF2 0x6B 0xC2 0x79 

2) Configuramos switch como cliente VMPS

Para llevar a cabo esta configuración, indicamos la dirección IP del servidor VPMS principal (podemos tener varios)

Switch(config)# vmps retry 3
Switch(config)# vmps reconfirm 1
Switch(config)# vmps server 172.18.0.150 primary
Switch#show  vmps 
VQP Client Status:
--------------------
VMPS VQP Version:   1
Reconfirm Interval: 1 min
Server Retry Count: 3
VMPS domain server: 172.18.0.150 (primary, current)
Reconfirmation status
---------------------
VMPS Action:         No Dynamic Port

3) Creamos las distintas vlans

Switch(config)#vlan 21
Switch(config-vlan)#name GESTION
Switch(config)#vlan 22
Switch(config-vlan)#name USUARIOS
Switch(config)#vlan 23
Switch(config-vlan)#name INVITADOS
Switch#show  vlan 
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
21   GESTION                          active    
22   USUARIOS                         active    
23   INVITADOS                        active   

4) Marcamos las interfaces que usan VMPS

Switch(config)#interface  range  fastEthernet 0/10-20 
Switch(config-if-range)# switchport mode access
Switch(config-if-range)# switchport access vlan dynamic

Switch#show  interface fastEthernet 0/10 switchport 
Name: Fa0/10
Switchport: Enabled
Administrative Mode: dynamic access  ******
Operational Mode: down
Administrative Trunking Encapsulation: dot1q
Negotiation of Trunking: Off
Access Mode VLAN: unassigned  *******
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none 
Administrative private-vlan mapping: none 
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk associations: none
Administrative private-vlan trunk mappings: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL

5) Configuramos el servidor VMPS (vlan.db)

vmps domain s2
vmps mode open
vmps fallback INVITADOS
vmps no-domain-req deny

vmps-mac-addrs
address 0023.8bd7.c2b3 vlan-name GESTION

En la configuración debemos tener en cuenta lo siguiente:

  • El dominio debe coincidir con el configurado en VTP.
  • La VLAN INVITADOS es usada para redireccionar las MACs que no estan autorizadas por la política debido a que configuramos el modo open, si usamos el modo secure, la interfaz quedaría deshabilitada.
  • Asignamos la dirección MAC de mi portatil a la VLAN de GESTION.

Una vez aquí, arrancamos el demonio y lanzamos una consulta de prueba (indicamos la dirección IP, el dominio VTP y la dirección MAC)

perl vqpcli.pl  -s 172.18.0.150 -v s2  -m 0023.8bd7.c2b3
Vlan: GESTION
MAC Address: 00238bd7c2b3 
Status: ALLOW

Como vemos, la dirección MAC esta autorizada y le asigna la VLAN GESTION.

Llegados a este punto, solo queda probar a conectarnos al switch (activamos el debug mediante el comando debug vqpc all) para realizar distintas pruebas:

Conectamos mi portátil una de las tomas definidas para usar VMPS (fa0/13)

*Mar  1 02:23:09.070: VQPC EVENT: -pm_port_vqp_start: port Fa0/13
*Mar  1 02:23:11.075: %LINK-3-UPDOWN: Interface FastEthernet0/13, changed state to up
*Mar  1 02:23:12.081: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/13, changed 
                      state to up
*Mar  1 02:23:13.986: VQPC LEARN: 
*Mar  1 02:23:13.986: VQPC LEARN: -learning mac 0023.8bd7.c2b3 on vlan 0, port Fa0/13
*Mar  1 02:23:13.986: VQPC LEARN: adding mac 0023.8bd7.c2b3 on vlan 0, port Fa0/13, type = 0x0021
*Mar  1 02:23:13.986: VQPC: allocating transID 0x00000471
*Mar  1 02:23:13.986: VQPC PAK: xmt transaction ID = 0x00000471
*Mar  1 02:23:13.986: VQPC PAK: sending query to VMPS
*Mar  1 02:23:13.986: VQPC PAK:  
*Mar  1 02:23:13.986: VQPC PAK: rcvd packet from VMPS
*Mar  1 02:23:13.994: VQPC PAK: transaction ID = 0x00000471
*Mar  1 02:23:13.994: VQPC: rcvd response, transID = 0x00000471
*Mar  1 02:23:13.994: VQPC PAK: VLAN name TLV, vlanName = GESTION
*Mar  1 02:23:13.994: VQPC PAK: Cookie TLV, cookie = 0023.8bd7.c2b3, length = 6
*Mar  1 02:23:13.994: VQPC EVENT: -set_hwidb_vlanid: port Fa0/13 to vlan 21, mac: 0023.8bd7.c2b3
*Mar  1 02:23:13.994: VQPC EVENT: saving 0023.8bd7.c2b3 from old vlan 0
*Mar  1 02:23:13.994: VQPC EVENT: changing Fa0/13 to vlan 21
*Mar  1 02:23:13.994: VQPC LEARN: adding mac 0023.8bd7.c2b3 on vlan 21, port Fa0/13, type = 0x0001
*Mar  1 02:23:13.994: VQPC LEARN: deleting mac 0023.8bd7.c2b3 on vlan 0, port Fa0/13
*Mar  1 02:23:13.994: VQPC LEARN: changing mac 0023.8bd7.c2b3 on vlan 21, port Fa0/13 to FORWARDING

Como vemos, asigna la dirección MAC la VLAN 21 (GESTION):

Switch#show  vlan 

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
21   GESTION                          active    Fa0/13
22   USUARIOS                         active   
23   INVITADOS                        active    

Switch#show  interface fastEthernet  0/13 switchport 
Name: Fa0/13
Switchport: Enabled
Administrative Mode: dynamic access
Operational Mode: dynamic access
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 21 (GESTION)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none 
Administrative private-vlan mapping: none 
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk associations: none
Administrative private-vlan trunk mappings: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled

Ahora la desconecamos y la conectamos a otra toma del switch( fa0/17)

*Mar  1 02:24:42.938: VQPC EVENT: -pm_port_vqp_start: port Fa0/17
*Mar  1 02:24:44.650: VQPC LEARN: 
*Mar  1 02:24:44.650: VQPC LEARN: -learning mac 0023.8bd7.c2b3 on vlan 0, port Fa0/17
*Mar  1 02:24:44.650: VQPC LEARN: adding mac 0023.8bd7.c2b3 on vlan 0, port Fa0/17, type = 0x0021
*Mar  1 02:24:44.650: VQPC: allocating transID 0x00000491
*Mar  1 02:24:44.650: VQPC PAK: xmt transaction ID = 0x00000491
*Mar  1 02:24:44.650: VQPC PAK: sending query to VMPS
*Mar  1 02:24:44.650: VQPC PAK:  
*Mar  1 02:24:44.650: VQPC PAK: rcvd packet from VMPS
*Mar  1 02:24:44.650: VQPC PAK: transaction ID = 0x00000491
*Mar  1 02:24:44.650: VQPC: rcvd response, transID = 0x00000491
*Mar  1 02:24:44.650: VQPC PAK: VLAN name TLV, vlanName = GESTION
*Mar  1 02:24:44.650: VQPC PAK: Cookie TLV, cookie = 0023.8bd7.c2b3, length = 6
*Mar  1 02:24:44.650: VQPC EVENT: -set_hwidb_vlanid: port Fa0/17 to vlan 21, mac: 0023.8bd7.c2b3
*Mar  1 02:24:44.650: VQPC EVENT: saving 0023.8bd7.c2b3 from old vlan 0
*Mar  1 02:24:44.650: VQPC EVENT: changing Fa0/17 to vlan 21
*Mar  1 02:24:44.658: VQPC LEARN: adding mac 0023.8bd7.c2b3 on vlan 21, port Fa0/17, type = 0x0001
*Mar  1 02:24:44.658: VQPC LEARN: deleting mac 0023.8bd7.c2b3 on vlan 0, port Fa0/17
*Mar  1 02:24:44.658: VQPC LEARN: changing mac 0023.8bd7.c2b3 on vlan 21, port Fa0/17 to FORWARDING
*Mar  1 02:24:44.943: %LINK-3-UPDOWN: Interface FastEthernet0/17, changed state to up
*Mar  1 02:24:45.950: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/17, 
                      changed state to up

Switch#sh mac-address-table | inc DYNAMIC
  21    0023.8bd7.c2b3    DYNAMIC     Fa0/17

Switch#show  vlan                                    

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
21   GESTION                          active    Fa0/13, Fa0/17
22   USUARIOS                         active   
23   INVITADOS                        active    

Vemos que la interfaz Fa0/13 todavía está asignada a la VLAN GESTION, por lo que conectamos otro equipo dicho puerto:

*Mar  1 00:03:35.016: VQPC EVENT: -pm_port_vqp_start: port Fa0/13
*Mar  1 00:03:36.887: VQPC LEARN: 
*Mar  1 00:03:36.887: VQPC LEARN: -learning mac 0005.1b00.3f81 on vlan 0, port Fa0/13
*Mar  1 00:03:36.887: VQPC LEARN: adding mac 0005.1b00.3f81 on vlan 0, port Fa0/13, type = 0x0021
*Mar  1 00:03:36.887: VQPC: allocating transID 0x00000061
*Mar  1 00:03:36.887: VQPC PAK: xmt transaction ID = 0x00000061
*Mar  1 00:03:36.887: VQPC PAK: sending query to VMPS
*Mar  1 00:03:36.887: VQPC PAK:  
*Mar  1 00:03:36.887: VQPC PAK: rcvd packet from VMPS
*Mar  1 00:03:36.887: VQPC PAK: transaction ID = 0x00000061
*Mar  1 00:03:36.887: VQPC: rcvd response, transID = 0x00000061
*Mar  1 00:03:36.887: VQPC PAK: VLAN name TLV, vlanName = INVITADOS
*Mar  1 00:03:36.887: VQPC PAK: Cookie TLV, cookie = 0005.1b00.3f81, length = 6
*Mar  1 00:03:36.887: VQPC EVENT: -set_hwidb_vlanid: port Fa0/13 to vlan 23, mac: 0005.1b00.3f81
*Mar  1 00:03:36.887: VQPC EVENT: saving 0005.1b00.3f81 from old vlan 0
*Mar  1 00:03:36.887: VQPC EVENT: changing Fa0/13 to vlan 23
*Mar  1 00:03:36.895: VQPC LEARN: adding mac 0005.1b00.3f81 on vlan 23, port Fa0/13, type = 0x0001
*Mar  1 00:03:36.895: VQPC LEARN: deleting mac 0005.1b00.3f81 on vlan 0, port Fa0/13
*Mar  1 00:03:36.895: VQPC LEARN: changing mac 0005.1b00.3f81 on vlan 23, port Fa0/13 to FORWARDING
*Mar  1 00:03:37.021: %LINK-3-UPDOWN: Interface FastEthernet0/13, changed state to up
*Mar  1 00:03:38.028: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/13, 
                      changed state to up

Puesto que la dirección MAC no está autorizada por la política definida, la asigna dinámicamente a la VLAN INVITADOS.

Switch#show  vlan 

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
21   GESTION                          active    Fa0/17
22   USUARIOS                         active    Fa0/24
23   INVITADOS                        active    Fa0/13

Si ahora cambiamos la política al modo secure y sin VLAN de fallback y conectamos el mismo equipo:

*Mar  1 00:12:57.019: VQPC LEARN: 
*Mar  1 00:12:57.019: VQPC LEARN: -learning mac 0005.1b00.3f81 on vlan 0, port Fa0/13
*Mar  1 00:12:57.019: VQPC LEARN: adding mac 0005.1b00.3f81 on vlan 0, port Fa0/13, type = 0x0021
*Mar  1 00:12:57.019: VQPC: allocating transID 0x00000151
*Mar  1 00:12:57.019: VQPC PAK: xmt transaction ID = 0x00000151
*Mar  1 00:12:57.019: VQPC PAK: sending query to VMPS
*Mar  1 00:12:57.019: VQPC PAK:  
*Mar  1 00:12:57.019: VQPC PAK: rcvd packet from VMPS
*Mar  1 00:12:57.019: VQPC PAK: transaction ID = 0x00000151
*Mar  1 00:12:57.019: VQPC: rcvd response, transID = 0x00000151
*Mar  1 00:12:57.019: %VQPCLIENT-2-SHUTDOWN: Interface Fa0/13 shutdown by VMPS
*Mar  1 00:12:57.019: %PM-4-ERR_DISABLE: vmps error detected on Fa0/13, putting Fa0/13 in 
                      err-disable state
*Mar  1 00:12:57.019: VQPC EVENT: -pm_port_vqp_stop: port Fa0/13
*Mar  1 00:12:57.019: VQPC EVENT: port Fa0/13, REMOVE dynamic access config
*Mar  1 00:12:57.019: VQPC EVENT: deleting all addresses on vlan 0,t Fa0/13
*Mar  1 00:12:57.019: VQPC EVENT: Deleted TCAM catch-all for port Fa0/13
*Mar  1 00:12:57.019: VQPC EVENT: -set_hwidb_vlanid: port Fa0/13 to vlan 0, mac: NULL
*Mar  1 00:12:57.019: VQPC EVENT: changing Fa0/13 to vlan 0
*Mar  1 00:12:58.026: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/13, 
                      changed state to down
*Mar  1 00:12:59.024: %LINK-3-UPDOWN: Interface FastEthernet0/13, changed state to down

Switch#show interfaces fas 0/13 status 

Port      Name     Status       Vlan        Duplex  Speed Type
Fa0/13             err-disabled unassigned  auto    auto 10/100BaseTX

Podemos comprobar como efectivamente ha desconectado la interfaz del switch y así aparece en las estadísticas del protocolo VMPS:

Switch#show  vmps statistics
VMPS Client Statistics
----------------------
VQP  Queries:               53
VQP  Responses:             20
VMPS Changes:               0
VQP  Shutdowns:             5
VQP  Denied:                0
VQP  Wrong Domain:          0
VQP  Wrong Version:         0
VQP  Insufficient Resource: 0

Como hemos podido ver, esta solución nos proporciona algo más de seguridad que la solución habitual, mejorando la mobilidad por nuestra red. No obstante, presenta otros problemas de seguridad que veremos en futuras entradas.

Cisco Modular Policy Framework (II)

En el anterior post dedicado a MPF vimos de forma sencilla cómo podemos inspeccionar tráfico a nivel de aplicación para su posterior filtrado; en el ejemplo vimos como se puede filtrar una consulta DNS dependiendo de la búsqueda realizada, no obstante, una gran funcionalidad que nos aporta MPF es la posibilidad de usar expresiones regulares, lo cual nos permite por ejemplo, implementar una firma para una vulnerabilidad reciente de la que todavía no existe parche publicado, y que todavía no tienen firma oficial nuestros sistemas IDS (como podría ser SNORT).

En este post, y dada la reciente entrada de Raúl vamos a usar MPF para, mediante una expresión regular, registrar y filtrar la reciente vulnerabilidad cgi-php.

Para llevar a cabo dicho filtrado, podríamos seguir los siguientes pasos:

1. Configuramos una expresión regular que nos permita detectar los patrones de tráfico interesantes, en este caso, los que identifican potenciales ataques contra la nueva vulnerabilidad:

ciscoasa(config)# regex php_cgi "\?\-[acndefhilmrBRFEHTsvwz]"

Podemos comprobar si una url hace match con la expresion regular mediante el comando test:

ciscoasa# test regex http://www.testpage.com/wordpress/?-s ?-[acndefhilmrBRFEHsvwz]
INFO: Regular expression match succeeded.

Nota: Tenemos que pulsar crtl+v para evitar que se interprete el simbolo ? en la consola del sistema.

2. Creamos un policy-map donde asociamos la expresión regular creada anteriormente y especificamos las acciones a llevar a cabo, en este caso, la filtramos y registramos el acceso:

ciscoasa(config)# policy-map type inspect http HTTP_PHP_CGI
ciscoasa(config-pmap)# match request args regex php_cgi
ciscoasa(config-pmap-c)# drop-connection log

3. Asociamos al policy-map existente la nueva inspección HTTP:

ciscoasa(config)# policy-map global_policy
ciscoasa(config-pmap)# class inspection_default
ciscoasa(config-pmap-c)# inspect http HTTP_PHP_CGI

Puesto que hemos modificado el policy-map creado por defecto, no sería necesario modificar o crear un nuevo service-policy.

Una vez tenemos la configuración finalizada, intentamos acceder a un recurso potencialmente vulnerable y comprobamos en el log que dicho acceso es filtrado correctamente por el sistema:

%ASA-4-415017: HTTP - matched request args regex php_cgi in policy-map HTTP_PHP_CGI,
  arguments matched - Dropping connection from outside:10.10.10.20/1185
  to dmz:172.18.0.150/80

Y en el debug podemos comprobar los pasos realizados durante la conexion HTTP y como es filtrada al hacer match con la expresión regular que inspecciona los argumentos de la petición:

sapi_inspect_http: ====== Opening New Connection D5534E50 =====

D5534E50:request:before deobfuscation httpState=sHTTP_START saveState=sHTTP_START
  matchState=0 data|GET /wordpress/?-s HTTP/1.1..Host: www.testpage.com..User-Agent:
  Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0..Accept:
  text/html,appl0

D5534E50:request:Deobfuscated 309 bytes

D5534E50:Number of outstanding requests=1

D5534E50:request:After deobfuscate httpState=sHTTP_FINAL  matchState=12 meth=2
    URI=/wordpress/
    Params=?-s HTTP/1.1..Host: www.testpage.com.User-Agent: Mozilla/5.0 (Windows NT
      5.1; rv:11.0) Gecko/20100101 Firefox/11.0.Accept: text
    Header=.Host: www.testpage.com.User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0)
      Gecko/20100101 Firefox/11.0.Accept: text/html,applica
    URI Len:12 ARG Len:12 HDR Len:295

D5534E50:request:Searching parameters

request: Check args - Match regex:20,

D5534E50:appfw_action:syslogID:6415017

D5534E50:request:>>>Silently drop & disconnect
PKT|GET /wordpress/?-s HTTP/1.1..Host: www.testpage.com..User-Agent: Mozilla/5.0
  (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0..Accept: text/html|
inspectHttp: ======== Closing Connection D5534E50 =======!!

Una alternativa a esta configuración para no tener que inspeccionar todas las conexiones HTTP sería asociar el service-policy a la interfaz que queremos inspeccionar, o una solución aún mejor sería asociar la interfaz y al MPF creado a una lista de acceso para inspeccionar el tráfico solo dirigido a servidores web, para ello llevaríamos a cabo los siguientes pasos:

1. Creamos una ACL para identificar el tráfico a inspeccionar:

ciscoasa(config)# access-list ServidoresWeb extended permit ip any  host 172.18.0.150

2. Creamos un nuevo class-map al que asociamos la access-list creada:

ciscoasa(config)# class-map CM-ServidoresWeb
ciscoasa(config-cmap)# match access-list ServidoresWeb

3. Creamos un policy-map y le asociamos el class-map creado y sobre él, aplicamos la inspección de tráfico:

ciscoasa(config)# policy-map PM-ServidoresWeb
ciscoasa(config-pmap)# class CM-ServidoresWeb
ciscoasa(config-pmap-c)# inspect http HTTP_PHP_CGI

4. Finalmente, aplicamos mediante un service-policy, el nuevo policy-map a la interfaz:

ciscoasa(config)# service-policy PM-ServidoresWeb interface outside

Como podemos ver, gracias a MPF podemos usar funcionalidades de IPS a nuestro firewall; esperamos poder preparar algún post más sobre MPF próximamente.

Cisco Modular Policy Framework (I)

(N.d.E. Entrada realizada por José Luis Villalón y Borja Merino)

Cisco Modular Policy Framework (MPF) es un conjunto de funcionalidades y reglas que nos proporciona Cisco para configurar de forma flexible sus firewalls, pudiendo realizar un filtrado más específico de las conexiones que atraviesan nuestra red.

Habitualmente, cuando configuramos un firewall, solemos centrarnos principalmente en las capas de red y transporte, filtrando únicamente por direcciones IP, puertos, o incluso flags, no obstante, no debemos olvidarnos de que esto no siempre es suficiente, por lo que debemos poder controlar también las capas superiores, pudiendo filtrar por parámetros concretos a nivel de aplicación.

Como ya vimos hace tiempo, Cisco ASA nos da la posibilidad de poder normalizar conexiones TCP, no obstante, es realmente MPF quien hace posible esta normalización, junto con otras funcionalidades avanzadas como comprobaciones a nivel de checksum de paquete, tcp windowing, filtrado de flags, gestión de ancho de banda, o incluso, la posibilidad de hacer un bypass del stateful inspection del sistema. No obstante, para este post usaremos el framework para llevar a cabo una inspeccionar tráfico a nivel de aplicación.

Recordando el post de Roberto sobre la identificación de accesos de logmein, podemos configurar nuestro ASA para filtrar determinados patrones de tráfico a nivel de aplicación; en nuestro caso y para mantener un ejemplo similar, bloquearemos las peticiones DNS a dominios de logmein.com, aunque también se podría inspeccionar el tráfico HTTP para evitar ciertas conexiones.

[Read more…]

¿Privacidad en las redes?

Recientemente he tenido la oportunidad de leer un artículo sobre privacidad en las comunicaciones móviles titulado Cellular Telephony and the Question of Privacy ($) donde entre otras cosas se plantea un sistema que garantice la privacidad del acceso a las redes móviles, separando la identidad del terminal de la identidad del usuario mediante un sistema PKI.

En el sistema propuesto, el terminal dispone de un modo de funcionamiento privado donde este envía una petición PER (Privacy Enabling Registration) a la red del operador; dicha petición consiste en un mensaje de certificación que valida al usuario y un valor aleatorio denominado RET (Random Equipment Tag), que se incluirá en los registros VLR (Visitor Location Register) y HLR (Home Location Register) del operador, los cuales permiten enrutar y mantener las llamadas, pero sin asociarlos a un usuario determinado (los siguientes mensajes de registro incluyen peticiones PET en lugar del número de télefono).

En España, la Ley de conservación de datos relativos a las comunicaciones electrónicas y a las redes públicas de comunicaciones (Ley 25/2007 de 18 de octubre) indica que los operadores de telefonía móvil con servicios prepago deberán registrar la identidad de los clientes que acceden a la red. Aparte de esta ley, cada vez es más habitual que la privacidad y el anonimato en la red se muestren como una problemática real, y ya comienzan a aparecer servicios de Internet integrados con sistemas de identificación como el DNI electrónico, como por ejemplo ha hecho Tuenti recientemente.

Sin entrar en detalles técnicos que seguro que hay muchos que se me escapan y a la vista de un entorno legislativo y político cada vez más preocupado por trazar y registrar todo tipo de comunicaciones, ¿piensan que un sistema así podría ser factible? Y desde otro punto de vista, ¿es necesario o deseable?