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.

WLC9800 NET::ERR_CERT_AUTHORITY_INVALID

 A continuación, os comento la solución a un problema que he tenido actualmente con una controladora Cisco WLC 9800 a la hora de validarse vía https después de haber cambiado los parámetros de la hora.  El tema es que una vez realizado el cambio horario e intentar hacer login de nuevo me he encontrado con el siguiente error.

NET::ERR_CERT_AUTHORITY_INVALID

Para corregir el problema se han de eliminar los certificados trustpoint que hay actualmente en la controladora. Para eliminarlos primero hemos de ejecutar el siguiente comando:

WLC#
WLC#show run | inc crypto
crypto pki server WLC_CA
crypto pki trustpoint TP-self-signed-3478691089
crypto pki trustpoint WLC_CA
crypto pki trustpoint WLC_WLC_TP
crypto pki certificate chain TP-self-signed-3478691089
crypto pki certificate chain WLC_CA

crypto pki certificate chain WLC_WLC_TP

WLC# 

Seguidamente los eliminamos:

No crypto pki server WLC_CA

No crypto pki trustpoint TP-self-signed-3478691089
No crypto pki trustpoint WLC_CA
No crypto pki trustpoint WLC_WLC_TP

Verificamos que todos los certificados se hayan eliminado     

WLC#sho run | inc crypto

WLC#

Seguidamente ejecutamos los siguientes comandos:

no ip http server
no ip http secure-server
ip http server
ip http secure-server
ip http authentication (local)

 

Tras ejecutarlos el certificado ya se ha generado de nuevo:

WLC#sho run | inc crypto
crypto pki trustpoint TP-self-signed-3478691089
crypto pki certificate chain TP-self-signed-3478691089

WLC#

Si volvemos a intentar hacer el login ya podemos saltarnos la alerta de que estamos trabajando con un certificado que no es de confianza y podemos hacer entrar a la controladora sin problemas.

Ver utilizanción de canal en redes Wifi con Wireshark

 

Cuando dos estaciones 802.11 están cercas una de otra y están en el mismo canal, entre ellas pueden oírse. Si además intentan transmitir al mismo tiempo, se produce una colisión y el paquete no llega correctamente a su destino. Para intentar evitar las colisiones en el mundo Wireless se creo un mecanismo denominado CCA (clear channel Assesment) cuyo objetivo es que cualquier estación ha de escuchar el medio y verificar que este esta libre antes de poder empezar a trasmitir. A medida que el numero de dispositivo aumenta la utilización del canal también lo hace y como consecuencia el rendimiento de la red empeora ya que los tiempos para trasmitir se han se han de repartir también.

El término “channel utilization” hace referencia pues a la cantidad de trasmisiones que una estación puede escuchar en un canal determinado, ya sean de su propia red o de las redes vecinas. Dicho de otra manera, vendría a ser un indicativo del uso del canal.

A continuación, os voy a mostrar como ver la ocupación de un canal a través de una captura de paquetes wifi analizado con wireshark.

Cuando un dispositivo es compatible con el protocolo 802.11 e y QBSS (QoS Enhanced Basic Service Set) es posible obtener la utilización del canal analizando los beacon frame. El valor ideal debería situarse por debajo del 40 %. Si la utilización supera el 80% el rendimiento de la red puede verse seriamente afectado.

Para empezar, vamos abrir una captura de paquetes con wireshark y vamos a analizar la trama número 435.

Es un beacon que publica un AP con el SSID Gryffindor

Si analizamos el campo QBSS podemos ver que hay un valor inicial que es un integro y a continuación wireshark nos muestra el porcentaje de utilización.

¿Como calcula Wireshark este porcentaje? Lo realiza cogiendo el valor del integro mostrado y dividiéndolo por 255, de esta forma podemos ver la utilización del canal de un AP determinado en un momento concreto. Pero como podemos aplicar un filtro para ver este valor de forma global. A continuación, vamos a aplicar un filtro para que nos muestre aquellos APs que desde su perspectiva detecten una utilización de canal por encima del 50%.  El valor a poner en el campo filtro es el siguiente:

wlan.qbss.cu >= 127

Con este filtro podemos que el SSID Vodafone5400 que actualmente emite en el canal 1, reporta constantemente una utilización del canal del 63%.

 

En la siguiente captura podemos ver algunos APs cuya utilización del canal están por encima del 70%.

Wireshark: seguimiento de paquetes en múltiples enlaces

 

En determinadas ocasiones podemos vernos obligados a hacer capturas de paquetes en dos puntos distintitos de la red. Una vez hecha la captura es necesario comparar los paquetes en ambos puntos para resolver ciertos problemas como pueden ser, ver si el paquete llega o no o si lo hace con tiempos de respuestas muy altos.

En la siguiente guía voy a mostrar cómo podemos identificar un paquete en ambos puntos de la captura asegurándonos que estamos trabajando en cada uno de los punto con el paquete correcto.

Para hacer la demo he montado la siguiente topología.

Las capturas de paquetes se van a tomar en el PC donde tenemos wireshark instalado y en el firewall a nivel del puerto donde está conectado el switch que da servicio a los equipos de la LAN.

Una vez hecho esto podemos probar de enviar vario pings . Los pings que he utilizado iban con destino a la ip 1.1.1.1.

Si analizamos las capturas recogidas en el PC y filtramos por la ip 1.1.1.1 tenemos los siguientes paquetes:

Si hacemos lo mismo en las capturas recogidas en el firewall podemos ver los siguientes paquetes:

Como observamos la identificación del paquete es diferente en ambas capturas y en la captura del cliente hay más paquetes debido a que quizás se empezó a capturar antes que en el Firewall.

 

Para poder identificar un paquete determinado en ambos puntos vamos a utilizar uno de los campos incluidos dentro de la cabecera del paquete IP, en concreto es el campo “Identification”

Este campo es un valor único que se añade en el paquete que nos serirá para seguir ese paquete determinado en cada una de las capturas.

Como podemos ver ya tenemos acotado uno de los paquetes con lo que podremos hacer los mismo con el resto de paquetes para poder compararlos.