Archivo de la etiqueta: switch

Avisando con Syslog…

Posted on por
Anuncios

Saber si algo anómalo ocurre en nuestra de red resulta de vital importancia para llevar a cabo una correcta administración de nuestra infraestructura. Estas anomalías pueden venir dadas por una gran cantidad de causas pero por citar algunas podríamos hablar de fallo  de una fuente de alimentación para equipos con redundancia eléctrica, reseteo imprevisto de un dispositivo, intentos de accesos fallidos, etc. etc. etc.

Para tener conocimiento de ello, los equipos de red pueden tener disponible el protocolo Syslog para que, en caso de producirse algún suceso digno de ser notificado, envíen un mensaje de registro a una estación central donde los procese una aplicación y podamos visualizarlo. Existen una gran variedad de herramientas bajo los acrónimos SIEM, SIM y SEM. Alguna de ellas pueden ser Kiwi Syslog Server o algunas con una gran variedad de otras funcionalidades entre las que se encuentran las del registro de estos mensajes como puede ser Cisco Prime Lan Management Solution (LMS).

Pues bien, entre una de mis tareas en mi actual cliente estaba la de configurar esta herramienta para que enviase por correo electrónico las alarmas que el conjunto de administradores creímos más relevantes. Para ello en primer lugar configuramos los equipos para habilitar este protocolo mediante los siguientes comandos

Router(config)#logging on 

Habilitamos syslog a nivel global del equipo

Router(config)#logging 192.168.10.53

Indicamos la IP del host donde se enviarán los mensajes.

Router(config)#logging trap x

Indicamos el nivel a un valor determinado entre 0 y 7. La tabla que figura a continuación establece los niveles configurables. Hay que tener en cuenta según el número que indicamos llevará implícito también los números superiores. Esto es, si elegimos el número 5, recibiremos también los mensajes del nivel 6  y 7.

0 Emergencia: el sistema está inutilizable
1 Alerta: se debe actuar inmediatamente
2 Crítico: condiciones críticas
3 Error: condiciones de error
4 Peligro: condiciones de peligro
5 Aviso: normal, pero condiciones notables
6 Información: mensajes informativos
7 Depuración: mensajes de bajo nivel

Por último: 

Router(config)#service timestamps log datetime

El mensaje llevará consigo una marca horaria.

Una vez configurada la aplicación Cisco Prime LMS con un servidor de correo, cuenta de usuario, dirección de envío, etc. estaría listo para recibir correos con el siguiente contenido:

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 10 23:17:53 switch-0001.dominiopruebas.net 2013 Feb 10

23:17:52 GMT +01:00 %SYS-2-PS_FAIL: Power supply 2 failed 

En este caso el mensaje nos dice que la fuente de alimentación (PS, Power Supply) número 2 del switch con nombre switch-001, ha fallado. El mensaje ha sucedido a las 23:17:52 y la aplicación ha mandado el correo a las 23:17:53, un segundo más tarde.  Cabe destacar que se trataba de un switch Cisco 6509-E que poseen dos fuentes de alimentación redundantes, vamos que no estamos hablando de un 2960…

Suponiendo  que a la mañana siguiente nos damos cuenta de ello y la cambiamos por otra nueva, recibiremos el siguiente:

Syslog message generated from device switch-0001: Feb 11 08:15:22 switch-0001.dominiopruebas.net 2013 Feb 11 08:15:21 GMT +01:00 %SYS-2-PS_OK: Power supply 2 okay

Como os habréis podido imaginar los datos horarios son falsos, en realidad lo que hice fue apagarla para ver si lo que había configurado iba bien.

Pero como mi mente es algo inquieta, pensé en lugar de simular una un fallo de hardware fuese víctima de un ataque, por ejemplo de un CAM overflow. Hay más información aqui.

Así que preparé mi Backtrack, configuré el switch  igual que otro cualquiera, lo conecté a la red y venga.

Eché mano de la aplicación macof. Macof lo que hace básicamente es generar tramas con direcciones MAC de origen aleatorias de tal manera que por cada trama que entre en el switch la incluirá en la tabla CAM. Al ser todas distintas la tabla CAM se irá llenando, hasta que al final se sature, porque obviamente la memoria tiene un límite. ¿Y qué pasa cuando eso ocurre? Pues que el switch podría comportarse como un hub. Aparte de ello, también lancé un ataque con THC Hydra similar a lque explico en mis entradas Mejorando acceso por SSH (Parte I) y Mejorando acceso por SSH (Parte II)

Vamos que entre el llenado de la memoria más la carga en la CPU… iba bien servido. Así que lo dejé. Pues bien al cabo de un par de minutos empecé a recibir los siguientes correos:

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001:: Feb 11 16:46:51 switch-0001.dominiopruebas.net 20: Feb 11 15:46:51: %PLATFORM-1-CRASHED: System previously crashed with the following message:

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 21: Feb 11 15:46:51: %PLATFORM-1-CRASHED: Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 12.2(50)SE5, RELEASE SOFTWARE (fc1)

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 22: Feb 11 15:46:51: %PLATFORM-1-CRASHED: Technical Support: http://www.cisco.com/techsupport

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 23: Feb 11 15:46:51: %PLATFORM-1-CRASHED: Copyright (c) 1986-2010 by Cisco Systems, Inc.

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 24: Feb 11 15:46:51: %PLATFORM-1-CRASHED: Compiled Tue 28-Sep-10 13:44 by prod_rel_team 

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 25: Feb 11 15:46:51: %PLATFORM-1-CRASHED:  

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 26: Feb 11 15:46:51: %PLATFORM-1-CRASHED: Debug Exception (Could be NULL pointer dereference) Exception (0x2000)!

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 28: Feb 11 15:46:51: %PLATFORM-1-CRASHED: SRR0 = 0x010469F0  SRR1 = 0x00029230  SRR2 = 0x006548A4  SRR3 = 0x00021000

Resultan claras las palabras %PLATFORM-1-CRASHED: Luego el equipo se reinició y como el ataque continuaba pues vuelta a empezar, y a los dos minutos ¡catapum!, otra vez reinicio y así hasta parar.

Como vemos resultan muy útiles estos protocolos. La verdad que la herramienta de Cisco que pongo como ejemplo es una maravilla, como maravilla es lo que cuesta su licencia. La verdad que para la red que administramos es muy necesaria y el gasto se justifica, no tanto en otros entornos más pequeños. En cualquier caso lo que pretendo hacer ver es los mecanismos de los que podemos disponer para estar avisados en el caso de que algo raro suceda.

Espero haya sido interesante.

Un saludo, seguiremos informando

Mejorando acceso por SSH (Parte II)

Posted on por
Anuncios

Vamos entonces con la segunda parte de Mejorando SSH. Como decía, si bien SSH en sí mismo nos da unas garantías de seguridad podemos realizar algunas configuraciones adicionales para afinarlo un poquito más. Pero… ¿con qué objetivo? A esto vamos hoy.

Uno de los ataques o pruebas de Pentest que podemos sufrir o hacer, es mediante aplicaciones que lancen sucesivos intentos de conexión proporcionando usuarios y contraseñas generadas u obtenidas previamente, para tratar de ganar acceso al equipo en cuestión.

Un ejemplo de este software es THC-Hydra, que como ellos lo definen es un “A very fast network logon cracker which support many diferent services” y que viene incluido dentro de la distribución Backtrack. Entre todos los protocolos que soporta no podía falta SSH.

A continuación veremos qué ocurre si lanzamos un ataque de esta índole a un equipo, en concreto el utilizado para hacer este post, con el fin de saber la respuesta de éste. Como digo bien fruto de un intento de acceso ilegítimo o prueba de Pentest.

Abriremos nuestra máquina con Backtrack y ejecutaremos THC-Hydra pero en su versión gráfica que resulta más amigable. Iremos pues a Backtrack -> Privilege Escalation -> Password Attacks -> Online Attacks -> hydra-gtk

Ahora deberemos configurar la herramienta acorde a nuestras preferencias, es decir:

Seleccionamos el objetivo, 192.168.10.10. Nosotros ya lo sabemos, no obstante, podremos aprovecharnos de otros protocolos mal configurados como CDP, STP, etc. o lanzando un NMAP, ver por nombres de equipo cuál puede ser más distinto que el resto, o bien por los primeros 24 bits de la MAC que identifican al fabricante.

Indicamos los ficheros que contienen tanto el nombre de los usuarios como las contraseñas.

Indicamos la contraseña de “enable” para dispositivos Cisco, en mi caso he puesto “labtest,test,admin”:

 

Y finalmente daría a “Start”:

Si a nuestro equipo no le hubiéramos configurado los siguientes parámetros del post anterior:

ip ssh time-out 15

ip ssh authentication-retries 2

ip ssh source-interface Vlan10

ip ssh logging events

ip ssh version 2

¿Qué pasaría?

Que Hydra comenzará a tratar de conectarse al equipo abriendo conexiones en SSH. Esto implicará un aumento en la carga de CPU ya que deberá repetirse el proceso de establecimiento de conexión de TCP, negociado y cálculo de claves antes de realizar el envío de credenciale (usuario y contraseña), lo cual requiere una carga computacional. Si eso se repite constantemente…. Pues para ver lo que pasa ejecutaremos:

LAB_TEST#show processes cpu history 

Y obtendremos la siguiente gráfica:

Como podemos apreciar la CPU se sube de “vueltas” con esta acción alcanzando porcentajes del 99%. Lógicamente esto puede desembocar en problemas con las comunicaciones con los equipos finales, los usuarios estarían diciendo “Esto va un poco lento”, “La red no funciona”, “le cuesta abrir mucho este archivo”, etc. etc. etc. El problema es que salvo que tengamos otros protocolos, alertas, etc. configurados en el equipo, o monitorizando su actividad no nos enteraríamos ya que no tenemos registro de los intentos de conexión que está queriendo hacer Hydra.  De ahí que si logueamos las conexiones de SSH con:

LAB_TEST(config)#ip ssh logging events 

Y entonces, va a ser un no parar de mensajes en consola, pero por lo menos nos enteramos de la que nos está cayendo…

 

Además, ¡Ya tenemos las IP desde dónde nos están mandando los intentos de conexión!

Otro ejemplo claro sería el comando:

LAB_TEST(config)#ip ssh time-out 15

De esta manera si alguien abriese sucesivas conexiones a nuestro equipo y no introducimos el usuario, el switch se mantendrá esperando 120 segundos. ¿Para qué tanto tiempo? Limitémoslo a 15 que es más que suficiente.

En el caso de la versión, si no especificamos la 2 un usuario podría conectarse en la versión 1 configurando el cliente SSH para ese efecto y  dado que SSHv1 presenta una vulnerabilidad… Pues vamos a intentar no utilizar un protocolo vulnerable, ¿no? De todos modos os dejo la forma en la que podríamos hacerlo.

Y la consiguiente captura…

Pero si configuramos:

 LAB_TEST(config)#ip ssh version 2

Pues nos sale:

Y nuevamente la captura:

Bueno creo que ya ha quedado demostrado lo importante que a pesar de utilizar protocolos que ofrecen garantías de seguridad, cómo debemos ir más allá y “pulir” parámetros mejorar el acceso a nuestros equipos y si algo anómalo pasase pues darnos cuenta de ello. También hay que decir que las opciones expuestas no son las únicas, pero el ejemplo lo que querido hacer sobre un switch normalito cuyo uso tendrá más alcance que uno de la serie 6500 por ejemplo. 

No debemos olvidar que el acceso SSH se realiza por la línea VTY y ésta también tiene otras opciones que reforzarán a las que acabamos de explicar. Entre otras, limitar el número de conexiones concurrentes; reducir el time-out de conexión; aplicar una ACL para que las conexiones se realicen desde equipos concretos como los de los administradores de red; etc, etc.

Espero que hay gustado, os dejo hasta la próxima…

Seguiremos informando.

Seguridad en puerto

Posted on por
Anuncios

Dentro de las redes de datos podemos establecer dos grandes diferencias en lo que a comunicaciones se refiere. Las que se producen dentro de una red y las que no. Es decir, si un equipo se comunica con otro dentro de su mismo espacio de direccionamiento  (por ejemplo, la IP 192.168.1.10/24 con la 192.168.1.20/24), o bien si se comunica con otro de una red diferente, (la IP 192.168.1.10/24 con la 10.0.0.10/24).

Cuando un equipo se quiere comunicar con otro de su misma red los equipos que se emplean actualmente son los Switches, aunque también podemos encontrar Hubs o Puentes, pero ya están en desuso. Nos referimos en este caso a switches en su sentido tradicional, no switches multicapa. Las comunicaciones a este nivel se producen considerando las direcciones MAC de los equipos finales, o lo que es lo mismo se realizan a nivel de Capa de Enlace, la número 2 del Modelo OSI. Si bien se necesita la IP del equipo de destino, lo que se considera es la dirección MAC, no la de Capa de Red.

Para entender su funcionamiento pondremos un ejemplo con dos equipos llamados “origen” y “destino”. Para ello el equipo “origen” deberá conocer la IP del de “destino”, y al darse cuenta que está dentro de su misma red obtener la MAC del de “destino”. Para ello echará mano del protocolo ARP. El protocolo ARP permite conocer la dirección MAC de un equipo a partir de una IP conocida. Por tanto, si “origen” no la tiene almacenada en su caché ARP  deberá realizar un ARP request. Es decir, preguntará a toda su red sobre cuál es la MAC del equipo con IP XXX.XXX.XXX.XXX. En este caso la dirección MAC de destino será ff:ff:ff:ff:ff:ff, un broadcast de capa 2. Todos los equipos la recibirán y la procesarán pero sólo el que tenga la IP por la cuál se pregunta contestará con un ARP Reply, diciendo “–La MAC de la IP XXX.XXX.XXX.XXX es XX:XX:XX:XX:XX:XX. Conocida por “origen” tanto la IP y MAC de «destino», se producirá la comunicación. Si por el motivo que sea no se conocen algunos de estos campos, la misma no se produce.

Así pues, un Switch, a diferencia, de los Hubs introduce un nivel de “inteligencia”. Un switch contiene una tabla, denominada CAM (Content-Addresseable Memory), en la cual se incluyen las direcciones MAC de cada uno de los equipos conectados a los distintos puertos del switch. Para realizar las tareas de conmutación, acudirá a ella para saber por cuál de ellos deberá enviar el tráfico en función de la MAC de destino. Esta asignación de direcciones MAC podrá hacerse de forma dinámica o manual. La forma manual implica que el administrador asigne a cada puerto del switch la MAC del equipo conectado; mientras que la forma dinámica se basa en que por cada trama que ingrese por cada boca del switch, éste mirará la MAC de origen y la incluirá en la CAM. Pasado cierto tiempo, si no se recibe tráfico se borrará dicho registro. Así, a la hora de efectuar la comunicación, los switches se fijarán en la MAC de destino, consultarán dicha tabla para saber por qué puerto deben enviarla y la “despacharán”.

De lo anterior se desprende que, en un modo de aprendizaje dinámico (siendo el modo por defecto y más extendido) toda trama que contenga una MAC distinta, será almacenada en CAM. Y ¿qué pasaría si generásemos constantemente tramas con MAC de origen aleatorias? Pues que el tamaño de la CAM iría en aumento ocupando cada vez más memoria y por tanto consumiendo recursos. Este ataque es lo que se denomina MAC Flooding pudiéndose  llevar a cabo con aplicaciones como macof (incluída en Backtrack) o Loki aunque este último tiene otros muchos usos, de lo más interesantes y  de los que espero hablar en futuros post.

En este caso no será destacar el desbordamiento del buffer del switch, que también, sino que además deberemos considerar otros aspectos aparte de éste.

Una intrusión como norma general se producirá sin que nosotros nos demos cuenta. Es decir el atacante será lo más sigiloso posible para evitar ser detectado y poder llevar a cabo aquello que tenga en mente sin que nadie se entere. Sin embargo, este no es el único vector. Otra de la políticas que podremos emplear es montar un follón y escondernos entre la multitud para que sea mucho más difícil que nos encuentren.

Imaginaros que comenzamos a generar 10000 MACs y el administrador consulta la tabla MAC del switch, ¿cuál de esas 10000 es la del atacante? Vale nos han pillado, pero ¿desde qué MAC se está enviando ese tráfico? Encima si el atacante cambia su MAC, por ejemplo con macchanger.

Pongamos algún ejemplo. Para hacerlo sencillo, a continuación os dejo una captura de la interfaz de la herramienta Loki con la que generaré un total de 10 MACs de forma aleatoria.

Y bien, si ahora consultamos la tabla CAM para la interfaz a la que estoy conectado:

Imaginaros si ahora me da por poner en lugar de 10, 1000000, pues eso… el listado es un “poquito” más largo…

Para mitigar este ataque, algunos switches permiten establecer un máximo de direcciones MAC a almacenar en la tabla CAM por cada puerto. Si este número se sobrepasa, se podrá tomar una decisión desde mandar un trap de SNMP hasta “apagar” el puerto. En los switches Cisco esta configuración se denomina port-security. En el ejemplo siguiente se configurará la interfaz FastEthernet 0/1 en modo “acceso” (es decir para conectar equipos finales), se habilitará la característica port-security,  se aprenderán de forma dinámica un máximo de 10 direcciones MAC, y en caso de sobrepasar este número el puerto se deshabilitará.

Si por ejemplo ahora generamos 11 MAC’s nos aparecerá en consola:

Si consultamos el estado del puerto veremos que :

Tiene lógica. ¿Para qué voy a dejar al switch que aprenda indiscriminadamente direcciones MAC cuando en realidad tengo 1 o 2 equipos conectados a ese puerto? Le puedo dejar que aprenda, por ejemplo 5 como máximo, y si se sobrepasa que se apague el puerto. De igual manera que quitamos servicios en un servidor, lo mismo podremos hacer con las funcionalidades de nuestros equipos. Mejor que un usuario proteste porque no puede navegar o consultar tal o cual archivo antes que nos la líen. No debemos olvidarnos que una cadena es tan fuerte como el más débil de sus eslabones.

En fin, a tener cuidado.

Seguiremos informando….