Error al acceder por SSH desde Linux a equipos Cisco

 Recientemente me he encontrado con un problema al intentar accer por SSH desde la consola de Linux a dispositivos Cisco. Cuando intentaba hacer login recibía el siguiente error a la hora de establecer el algoritmo de encriptación.

Para corregir el problema he tenido que editar el fichero ~/ssh/config y añadir las siguientes lineas:

Host 10.5.18.98

    KexAlgorithms +diffie-hellman-group1-sha1

Aún y así me seguía dando el siguiente error:

Para corregir este error se ha de introducir las siguientes líneas:

HostKeyAlgorithms ssh-rsa

PubkeyAcceptedKeyTypes ssh-rsa 

Finalmente ya nos deja finalizar el proceso de conexión.

PIP error: externally-managed-environment

 Recientemente he instalado la última actualización  de Kali con dist-upgrade. Esta maquina la uso también para iniciarme en sripts de python. Después de realizar la actualización me encontrado que al intentar ejecutar el el commando pip para instalar algún módulo el sistema me devuelve el siguiente mensaje:

error: externally-managed-environment

Dado que mi nivel de inglés no son muy buenos y los de linux tampoco no me habia fijado que la respuesta esta en el mismo mensaje. Para poder instalar los módulos hay que ejecutar el comando con el argumento que se detalla al final del mensaje --break-system-packages como el ejemplo a continuación

pip install meraki --break-system-packages

ISE no muestra IP de clientes autenticados por MAB

 Recientemente me he encontrado con un problema en el que ISE no mostraba las IP de los dispositivos autenticados por MAB en el Live Log.

Los dispositivos se conectan a un C3560. Al ejecutar el show ip dhcp binding  se puede observar que el equipo tiene información de las peticiones DHCP pero no las está enviado a ISE.

Los dispositivos de red usan el atributo 8 de RADIUS (framed-IP-address) en las peticiones de acceso para pasar la información de la IP al Servidor de accesos a la red (NAS) o sea nuestro ISE. 

Para que ISE sea capaz de recibir esa información se ha de añadir el siguiente comando en la configuración global de ISE

radius-server attribute 8 include-in-access-req  

Una ver añadido el comando la ip aparecía ya correctamente en los logs

Comandos interesantes Windows y Linux

A continuación iré poniendo toda una serie de comandos que considero interesantes a nivel de administración de redes. Esta post será dinámico y se ira ampliando a medida que va encontrando comandos o enlaces a utlididades interesantes.

Ver dominio asociado a una IP

Para empezar miraremos como ver una el dominio asociado a una ip. En windows es lo podemos hacer con el comando ping -a.

C:\Users\josepi>ping -a 8.8.8.8

Haciendo ping a dns.google [8.8.8.8] con 32 bytes de datos:

Respuesta desde 8.8.8.8: bytes=32 tiempo=14ms TTL=117

Respuesta desde 8.8.8.8: bytes=32 tiempo=13ms TTL=117

Respuesta desde 8.8.8.8: bytes=32 tiempo=13ms TTL=117

Respuesta desde 8.8.8.8: bytes=32 tiempo=14ms TTL=117

Estadísticas de ping para 8.8.8.8:

    Paquetes: enviados = 4, recibidos = 4, perdidos = 0

    (0% perdidos),

Tiempos aproximados de ida y vuelta en milisegundos:

    Mínimo = 13ms, Máximo = 14ms, Media = 13ms

Como podemos ver el nombre que resuelve es dns.google

Si hacemos el proceso inverso mediante el comando nslookup podemos ver que ademas de la ip 8.8.8.8, también está asociada a ese nombre la ip 8.8.4.4

C:\Users\josepi>nslookup

Servidor predeterminado:  dns.google

Address:  8.8.8.8

> dns.google

Servidor:  dns.google

Address:  8.8.8.8

Respuesta no autoritativa:

Nombre:  dns.google

Addresses:  2001:4860:4860::8844

          2001:4860:4860::8888

          8.8.8.8

          8.8.4.4

Para jeecutar la misma operación en linux lo podemos hacer con el comando dig -x ip_address

rock64@rock64:~$ dig -x 8.8.8.8

; <<>> DiG 9.11.3-1ubuntu1.18-Ubuntu <<>> -x 8.8.8.8

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31384

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 65494

;; QUESTION SECTION:

;8.8.8.8.in-addr.arpa.          IN      PTR

;; ANSWER SECTION:

8.8.8.8.in-addr.arpa.   21283   IN      PTR     dns.google.

;; Query time: 16 msec

;; SERVER: 127.0.0.53#53(127.0.0.53)

;; WHEN: Tue Oct 18 10:42:33 CEST 2022

;; MSG SIZE  rcvd: 73

rock64@rock64:~$

Atajos en wireshark

 La mayoría de veces a la hora de revisar problemas en la red a través de la captura de paquetes necesitamos aplicar filtros para reducir la cantidad de información que wireshark muestra en pantalla. Esta operación se realiza mediante el uso de "Display Filters". Si queremos filtrar y definir que wireshark solo muestre paquetes en los que intervenga una ip en concreta podríamos crear un Display filter de la siguiente manera ip.addr == 192.168.50.44. Mediante este filtro la información mostrada se reduciría y nos facilita el proceso de análisis.

Pero podemos encontrarnos que en determinadas situaciones no nos acordemos o no sepamos la estructura del filtro que queremos aplicar. En estas situaciones podemos hacer uso del botón derecho del rato para aplicar los filtro. Supongamos que queremos aplicar un filtro para ver todos el trafico DNS. Para ello necesitaríamos encontrar una conexión con el puerto UDP 53 , abriríamos los detalles del paquete y buscaríamos el punto donde aparece el puerto destino y con el botón derecho podríamos aplicar el filtro.

Con esto ya tendríamos aplicado el filtro.

Si queremos también es posible observar como es la estructura del filtro en la esquina inferior de wireshark seleccionando el campo que nos interesa.

Montar Servidor de Syslogs (muy rápido)

Recientemente he tenido la necesidad de visualizar las conexión que se están realizando en un firewall y filtrar aquellas que se están permitiendo y aquellas que se están denegando. 

Hay equipos que esta funcionalidad la tienen integrada de forma nativa y es fácil de realizar un análisis, pero hay otros que no la tienen y hacer un seguimiento de las conexiones resulta más difícil. En estos casos una herramienta que ayuda a tener un listado de la conexiones es un servidor de syslogs.  Mediante este servicio podemos configurar los equipos de red para que envíen un registro de conexiones al servidor de logs y ya podemos las analizar conforme se están realizando junto con otra información complementaria que nos puede ser de utilidad en un futuro para analizar problemas de red.

El servidor de log permite a su vez tener un histórico más largo que los que pueden almacenar los dispositivos finales ya que la capacidad de almacenamiento puede ser superior.

El primer servidor que he probado se basa en linux y se llama rsyslog. Por defecto viene instalado en las distribuciones ubuntu y se puede usar incluso en una Raspberry. En caso de no estar instalado se puede realizar mediante el siguiente comando:

sudo apt install rsyslog

Seguidamente hemos de habilitar el fichero de configuración con nuestro editor favorito y quitar el simbolo de comentario al inicio de las siguientes líneas:

sudo nano /etc/rsyslog.conf

Acto seguido solo queda reiniciar los servicios mediante los siguientes comandos:

sudo service rsyslog restart

sudo systemctl restart rsyslog

Para ver si el servicio se ha reiniciado correctamente podemos ejecutar el comando

sudo service status rsyslog 

El comando debería devolvernos un mensaje como este:

Para terminar de verificar que se encuentra operativo podemos ejecutar el comando 

netstat -plan | grep udp

Podremos ver que hay una conexión a la escucha en el puerto 514

Acto seguido podemos configurar el dispositivo final para enviar los logs al servidor, en mi caso el equipo es un Meraki y la configuración se realiza desde el dashboard desde el Menú Network Wide--> General 

Los logs se almacenan en la carpeta /var/logs/syslog

La otra aplicación para poder recibir los en Windows es el programa tftpd64.

Únicamente hemo de verificar el checkbox del syslog server está seleccionado.

En caso de no estarlo se activa y se reinicia la aplicacion y ya está listo para recibir logs.

Configración Root Guard

 En esta entrada explicaré en qué consiste uno de los fallos de seguridad a nivel de capa 2 que consisten en tomar el rol de root bridge de la red. Para ponernos en situación y comprender las consecuencias de este ataque primero hemos de hablar de Spanning Tree (STP). STP es un mecanismo utilizado para evitar que se formen bucle en la red cuando hay redundancia de enlaces hacia los equipos.  Sin profundizar mucho en el funcionamiento, este procedimiento se lleva a cabo bloqueando el tráfico en uno de los puertos que dan la redundancia de forma que, la información que sale por un puerto (que contine el listado de mac que conoce el equipo) no vuelva a entrar de nuevo por el otro puerto y se forme el bucle.

Normalmente se escoge el switch central de la red para que haga de root bridge, suele ser el equipo donde se concentran todas los enlaces remotos y el que es más propenso a tener menos cambios topológicos. Normalmente suele ser el switch Core o de distribución de la red. La elección de este se realiza mediante intercambio de BPDUs y se toma en cuenta la información contenida en campo Priority ID y la MAC Address. Por defecto todos los switches Cisco vienen configurados con un priority ID de 32768, por lo que cuando dos equipos se montan con la configuración de fábrica el equipo que tomará el role de Root bridge es el que tenga la dirección MAC más baja.

En la siguiente topología he añadido tres equipos con la configuración de fábrica. Como se puede ver al ejecutar sho spannig-tree los tres tienen las misma prioridad por los que a la hora de decidir quién será el root sale como ganador el Switch-1 que el el que tiene la dirección mac más baja.

En este punto si conectamos otro switch con una prioridad más baja, este podría coger el rol de

y provocaría cambios en la topología, provocando posiblemente algún corte en la comunicación

al recalcular de nuevo el STP y provocando que el tráfico no fluya como inicialmente habíamos previsto. En nuestro caso le he asignado al Switc-3 una prioridad de 4096 para forzar que se convierta en root. En las capturas podemos que el root bridge a cambiado al Switch-3 y que el puerto que estaba bloqueado en este último ha pasado a estar en el switch-2 puerto Gi0/0.

Para prevenir este comportamiento y evitar que algún equipo no controlado tome el rol de root podemos hacer uso del la funcion root guad configurado este comando en aquello puerto que están configurado en modo trunk y conectados a algún switch.

Switch-1(config)#int gigabitEthernet 0/0

Switch-1(config-if)#spanning-tree guard root

Switch-1(config)#int gigabitEthernet 0/1

Switch-1(config-if)#spanning-tree guard root

Tras aplicar los comandos podemos ver como el equipo bloquea las peticiones del Switch-3 para hacerse root y el vuelve a hacerse el principal de la red.

Como recomendación general siempre es recomendable cambiar la prioridad por defecto de root en aquello switches que queramos que ejecuten esta función.