Archivo de la etiqueta: Cisco

Mejorando acceso por SSH (Parte I)

Posted on por
Anuncios

Bueno, aquí estamos otra vez. En esta ocasión vamos a meternos con el protocolo SSH. SSH son las iniciales del protocolo Secure SHel, utilizado ampliamente para conectarse a un host u otros equipos y poder administrarlos mediante una consola. Todo el tráfico que se intercambie entre el servidor (el equipo al que nos conectamos) y el cliente (equipo desde el cual nos vamos a conectar) irá cifrado, incluso las credenciales utilizadas para loguearnos. A diferencia de Telnet en el que el tráfico viaja en texto claro, SSH nos ofrece unas garantías de seguridad importantes.

Aunque los equipos de red también pueden ser administrados vía Web o incluso por medio SNMP, SSH está ampliamente extendido. Su implementación es sencilla, basta con configurar unos parámetros y ya podremos conectarnos. Sin embargo en esta ocasión vamos a ir un poco más allá y vamos a ver cómo podemos afinar un poco más  este protocolo, y mejorar el acceso nuestros dispositivos de red. Obviamente esta no es la única media, se podrían hacer otras muchas más configuraciones a nivel de equipo, con otros protocolos, otros parámetros, pero este no es este el caso. Hoy nos centraremos en SSH.

Al lío, las pruebas las he realizado con un switch de acceso del fabricante, para variar, Cisco. Será uno de la serie 2960 en concreto un WS-C2960-24TC-L con una IOS c2960-lanbasek9-mz.122-50.SE5.bin

Para configurar SSH bastaría con asignar un nombre al equipo, un dominio, y generar las claves para SSH. Mejor que describirlo os paso un ejemplo:

Switch#conf t

Switch(config)#hostname LAB_TEST

LAB_TEST(config)#ip domain-name LABTEST.lcl

LAB_TEST(config)#crypto key generate rsa

The name for the keys will be: LAB_TEST.LABTEST.lcl

Choose the size of the key modulus in the range of 360 to 2048 for your

General Purpose Keys. Choosing a key modulus greater than 512 may take  a few minutes.

How many bits in the modulus [512]: 1024

% Generating 1024 bit RSA keys, keys will be non-exportable…[OK]

*Mar  1 00:02:01.139: %SSH-5-ENABLED: SSH 1.99 has been enabled

Con lo anterior ya tendríamos configurado la parte de SSH pero aún nos queda algunos pasos más, como son:

Creación de una cuenta de usuario y contraseña local; y otra contraseña para el acceso a los permisos de la configuración del dispositivo:

LAB_TEST(config)#username labtest secret labtest

LAB_TEST(config)#enable secret labtest

Luego, configuraremos el acceso remoto siendo el protocolo entrante SSH. Se nos pedirá un login mediante usuario y contraseña almacenado en local. EL usuario y contraseña es el que hemos configurado en el paso anterior, usuario labtest y contraseña labtest

LAB_TEST(config)#line vty 0 4

LAB_TEST(config-line)#transport input ssh

LAB_TEST(config-line)#login local

LAB_TEST(config-line)#exit

También, aprovecharemos para permitir acceso a la línea de consola de la misma manera que en el paso anterior en lo que credenciales se refiere. Obviamente como entramos por consola, conectado directamente al equipo no le indicamos el protocolo de entrada.

LAB_TEST(config)#line console 0

LAB_TEST(config-line)#login local

LAB_TEST(config-line)#exit

Deshabilitamos la VLAN 1.

LAB_TEST(config)#interface vlan 1

LAB_TEST(config-if)#shutdown

LAB_TEST(config-if)#exit

Creamos una VLANnueva , en este caso la 10 y le asignamos un nombre.

LAB_TEST(config)#vlan 10

LAB_TEST(config-vlan)#name LAB_TEST

LAB_TEST(config-vlan)#exit

Para accede remotamente al equipo creamos una interfaz virtual, la levantamos y le asignamos una IP, en este caso la 192.168.10.10. Al switch también le tenemos que indicar una puerta de enlace que será la 192.168.10.1 para acceso desde otra red.

LAB_TEST(config)#interface vlan 10

LAB_TEST(config-if)#ip address 192.168.10.10 255.255.255.0

LAB_TEST(config-if)#no shutdown

LAB_TEST(config-if)#exit

LAB_TEST(config)#ip default-gateway 192.168.1

Configuramos el resto de puertos como puertos de acceso y los asignamos a la VLAN 10. La velocidad y el dúplex lo dejamos por defecto, es decir auto-auto.

LAB_TEST(config)#interface range fastEthernet 0/1 – 24

LAB_TEST(config-if-range)#switchport mode access

LAB_TEST(config-if-range)#switchport access vlan 10

LAB_TEST(config-if-range)#exit 

Para hacer las pruebas, he configurado un servidor DHCP en el switch para que asigne IPs al PC físico que he pinchado a uno de los puertos configurados en el punto anterior, más algún parámetro más como el Gateway, nombre de dominio un servidor DNS, etc. Luego le indico que excluya las 20 primeras IPs de aquellas que pueda asignar según peticiones DHCP. Estaba muy vago para andar configurando IPs estáticas, 😉

LAB_TEST(config)#ip dhcp pool LABTEST

LAB_TEST(dhcp-config)#network 192.168.10.0 255.255.255.0

LAB_TEST(dhcp-config)#default-router 192.168.10.1

LAB_TEST(dhcp-config)#domain-name LABTEST.lcl

LAB_TEST(dhcp-config)#dns-server 192.168.10.10

LAB_TEST(dhcp-config)#exit

LAB_TEST(config)#ip dhcp excluded-address 192.168.10.1 192.168.10.20 

Y por supuesto guardamos la configuración.

LAB_TEST(config)#do wr

Building configuration…

[OK]

LAB_TEST(config)#

Bueno con todo esto ya podríamos decir que nos podemos conectar con un cliente SSH, como puede ser Putty a la IP 192.168.10.10.

Luego nos logueamos con labtest como “usuario”, “contraseña” y “enable”, y “pá dentro”

Si entramos en modo de configuración global y entramos en el menú de ssh, veremos que nos aparecen distintas opciones:

LAB_TEST(config)#ip ssh ?

authentication-retries                Specify number of authentication retries

dscp                                                    IP DSCP value for SSH traffic

logging                                              Configure logging for SSH

precedence                                    IP Precedence value for SSH traffic

source-interface                           Specify interface for source address in SSH connections

time-out                                           Specify SSH time-out interval

version                                              Specify protocol version supported

Pues configuremos entonces:

LAB_TEST(config)#ip ssh authentication-retries 2 

Con este comando lo utilizaremos para la cantidad de intentos que se nos permitirá meter la contraseña de forma incorrecta. Con el parámetro 2, permitiremos 3 intentos, 0=1 intentos, 1=2 intentos y 2=3 intentos.

LAB_TEST(config)#ip ssh logging events

Con este otro registraremos los eventos relacionados, apareciéndonos en la consola.

LAB_TEST(config)#ip ssh source-interface vlan 10

Este parámetro no va a ser tanto para las conexiones entrante sino las salientes. Es decir, podremos realizar conexiones ssh contra otros equipos. En ese caso con este comando, le indicaremos qué dirección IP de origen queremos utilizar. En este caso le decimos que la misma que la que tenga la VLAN 10, o sea la 192.168.10.10.

LAB_TEST(config)#ip ssh time-out 15

Con este otro le decimos que el tiempo de espera para que un usuario introduzca la contraseña será de 15 segundos. OJO, una vez logueado estará sometido al tiempo que hayamos configurado para la interfaz virtual con el comando “exec-timeout” 

LAB_TEST(config)#ip ssh version 2 

Finalmente especificamos la version ssh a utilizar, en este caso la 2.

Pero ¿porqué afinar si ya con lo que hemos hecho al principio ya teneos un acceso seguro?

Bueno pues la respuesta la dejamos para el siguiente post, ¿si? A lo dicho, un saludo y…

Seguiremos informando.

Aegurando el enrutamiento Parte III

Posted on por
Anuncios

Bueno ya estamos aquí con la tercera entrega, con algo de retraso pero llega. Como ya hemos visto el enrutamiento es fundamental en entornos corporativos pero también la correcta configuración del mismo. Vista la manera en la que nos pueden comprometer nuestras tablas de rutas y provocar un funcionamiento distinto al original, veremos la manera en la que podemos evitarlo.

Para empezar vamos a aplicar una idea fundamental, “Si algo no es estrictamente necesario para el funcionamiento, lo deshabilitamos”. De igual manera que la gente de sistemas deshabilita servicios, cierra puertos, etc. vamos a aplicarnos el cuento, y hacer lo mismo con el enrutamiento. Si éste se produce entre los switches de Core, en nuestro ejemplo CORE_OF_01, CORE_OF_02, CORE_SRV_01 y CORE_SRV_02; ¿para qué mandar actualizaciones hacia los switches de acceso como OF_01 si éstos no llevan a cabo enrutamiento? ¿Por qué mandar anuncios hacia ellos? El enrutamiento, hemos visto que se produce entre los de Core, con lo que no deberían propagarse más allá de ellos ya que no es necesario.  Por tanto, accedemos a la configuración del protocolo en cuestión y deshabilitaremos dichos anuncios.

core-of-01#conf t

core-of-01(config)#router ospf 1

core-of-01(config-router)#passive-interface vlan 10 

Con el commando passive-interface lo que vamos a conseguir es que se no se envíen actualizaciones del protocolo con lo que en nuestro caso la aplicación “Loki” no podrá capturarlas y por lo tanto nuestro atacante obtener la información sobre nuestras redes y posterior posible inyección de rutas. En esta ocasión la hemos aplicado a una interfaz virtual.

Otra opción es habilitar la autenticación entre interfaces que participan en el enrutamiento. Esto es, emplear un secreto compartido entre ellas, necesario para procesar el paquete con la información recibida. Podremos elegir entre una autenticación simple, en la que el secreto compartido va implícito en texto plano dentro de dicho paquete o bien emplear algún algoritmo que en lugar de éste enviará un hash que deberá ser recalculado en destino, y si coincide con el enviado, se procesará.

En nuestro caso emplearemos esta segunda opción siendo el algoritmo MD5. Para ello en primer lugar habilitaremos la autenticación en el protocolo para las áreas que deseemos. En nuestro caso el área 1:

core-of-01#conf t

core-of-01(config)#router ospf 1

core-of-01(config-router)#area 1 authentication message-digest

El siguiente paso será habilitar la autenticación para las interfaces implicadas en el enrutamiento. Como hemos dicho con anterioridad estamos empleando interfaces virtuales con lo que:

core-of-01(config)#interface vlan 20

core-of-01(config-if)#ip ospf message-digest-key 1 md5 edorta 

De aquí queda por decir que el “1” hace referencia al identificador de la contraseña; MD5 al tipo de algoritmo de hashing, y “edorta” la contraseña en sí. Obviamente la contraseña debe ser la misma que en nuestro router vecino.

Parece sencillo pero habrá quien no lo implemente y luego vengan los disgustos. Son pocas líneas, pero necesarios para proteger nuestra red, a los usuarios y sobre todo la información que viaje por ella y que éstos utilizan.

Un saludo y 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….