Averiguar si un puerto está abierto en Windows

Escrito por Blai el 26.5.21

Cómo saber si un puerto está abierto en Windows.



Frecuentemente me encuentro con que tengo que comprobar si un puerto está abierto en Linux, pero no ha sido hasta hoy que he tenido que comprobar si un puerto estaba abierto en un Windows Server.

Tras investigar un poco y barajar varias opciones (PowerShell, cmd, programas externos) he optado por hacer las comprobaciones mediante cmd.

Servidor

Para comprobar si un puerto está escuchando en Windows mediante cmd, podemos usar el comando netstat y concatenar el resultado hacia findstr del siguiente modo:

C:\Users\Administrator>netstat -a | findstr "8443"

Si tras ejecutar el comando no vemos ningún resultado, significa que el puerto en cuestión (en este caso el puerto que estamos comprobando es el 8443) no está escuchando en la máquina.

Si tras ejecutar el comando vemos LISTENING en el resultado, significa que el puerto está escuchando:

C:\Users\Administrator>netstat -a | findstr "9443" TCP 0.0.0.0:9443 TEST103:0 LISTENING TCP 10.252.3.121:9443 ip-10-252-3-58:42264 TIME_WAIT TCP 10.252.3.121:9443 ip-10-252-3-58:42270 TIME_WAIT

Cliente

Si queremos averiguar desde nuestro ordenador si el puerto 443 - por ejemplo - de un servidor remoto está abierto, podemos hacerlo mediante el comando telnet:

C:\Users\Administrator>telnet 10.1.2.3 443

Si la pantalla de cmd se queda en negro o si aparece un banner con la versión de algún servicio como FTP o SSH, significa que el puerto está abierto y escuchando en el servidor remoto.

Leer más »

Instalar VMWare Tools en CentOS 6 "legacy"

Escrito por Blai el 19.5.21

Cómo instalar VMWare Tools en CentOS 6.



El otro día fui a instalar VMWare Tools en un CentOS 6 y me encontré con el siguiente mensaje:

[root@wgbcncentreon ~]# yum install open-vm-tools -y Complementos cargados:fastestmirror Configurando el proceso de actualización Determining fastest mirrors YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. Invalid release/repo/arch combination/ removing mirrorlist with no valid mirrors: /var/cache/yum/x86_64/6/base/mirrorlist.txt Error: Cannot find a valid baseurl for repo: base

Esto ocurre porque CentOS 6 es un sistema operativo "legacy" y los repositorios principales estám desactivados. Si queremos instalar cualquier paquete en un CentOS 6 - como VMWare Tools - deberemos instalar primero el repositorio EPEL (Extra Packages for Enterprise Linux) en él:

[root@centos66 ~]# rpm --import http://ftp.riken.jp/Linux/fedora/epel/RPM-GPG-KEY-EPEL-6 [root@centos66 ~]# rpm -ivh https://archives.fedoraproject.org/pub/archive/epel/6/x86_64/epel-release-6-8.noarch.rpm

Acto seguido instalamos las VMWare tools:

[root@centos66 ~]# yum install open-vm-tools -y Loaded plugins: fastestmirror Setting up Install Process Loading mirror speeds from cached hostfile * base: centos.ipserverone.com * epel: kartolo.sby.datautama.net.id * extras: centos.ipserverone.com * updates: centos.ipserverone.com Resolving Dependencies --> Running transaction check ---> Package open-vm-tools.x86_64 0:9.4.6-1.el6 will be installed --> Processing Dependency: libicuuc.so.42()(64bit) for package: open-vm-tools-9.4.6-1.el6.x86_64 --> Processing Dependency: libicui18n.so.42()(64bit) for package: open-vm-tools-9.4.6-1.el6.x86_64 --> Processing Dependency: libicudata.so.42()(64bit) for package: open-vm-tools-9.4.6-1.el6.x86_64 --> Processing Dependency: libdnet.so.1()(64bit) for package: open-vm-tools-9.4.6-1.el6.x86_64 --> Running transaction check ---> Package libdnet.x86_64 0:1.12-6.el6 will be installed ---> Package libicu.x86_64 0:4.2.1-9.1.el6_2 will be installed --> Finished Dependency Resolution Dependencies Resolved ======================================================================================= Package Arch Version Repository Size ======================================================================================= Installing: open-vm-tools x86_64 9.4.6-1.el6 epel 402 k Installing for dependencies: libdnet x86_64 1.12-6.el6 epel 28 k libicu x86_64 4.2.1-9.1.el6_2 base 4.9 M Transaction Summary ======================================================================================= Install 3 Package(s) Total download size: 5.3 M Installed size: 20 M Downloading Packages: (1/3): libdnet-1.12-6.el6.x86_64.rpm | 28 kB 00:00 http://centos.ipserverone.com/centos/6.6/os/x86_64/Packages/libicu-4.2.1-9.1.el6_2.x86_64.rpm: [Errno 12] Timeout on http://centos.ipserverone.com/centos/6.6/os/x86_64/Packages/libicu-4.2.1-9.1.el6_2.x86_64.rpm: (28, 'Operation too slow. Less than 1 bytes/sec transfered the last 30 seconds') Trying other mirror. (2/3): libicu-4.2.1-9.1.el6_2.x86_64.rpm | 4.9 MB 01:21 (3/3): open-vm-tools-9.4.6-1.el6.x86_64.rpm | 402 kB 00:04 --------------------------------------------------------------------------------------- Total 44 kB/s | 5.3 MB 02:04 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Warning: RPMDB altered outside of yum. Installing : libdnet-1.12-6.el6.x86_64 1/3 Installing : libicu-4.2.1-9.1.el6_2.x86_64 2/3 Installing : open-vm-tools-9.4.6-1.el6.x86_64 3/3 Verifying : libicu-4.2.1-9.1.el6_2.x86_64 1/3 Verifying : open-vm-tools-9.4.6-1.el6.x86_64 2/3 Verifying : libdnet-1.12-6.el6.x86_64 3/3 Installed: open-vm-tools.x86_64 0:9.4.6-1.el6 Dependency Installed: libdnet.x86_64 0:1.12-6.el6 libicu.x86_64 0:4.2.1-9.1.el6_2 Complete!

Por último iniciamos el servicio vmtoolsd:

[root@centos66 ~]# service vmtoolsd start

Tras esto, ya tenemos la última versión de VMWare Tools para CentOS 6 en funcionamiento.

Leer más »

NTLM sobre NGINX reverse proxy

Escrito por Blai el 12.5.21

Cómo autenticar un usuario con NTLM a través de NGINX.



Si tenemos un aplicativo web corriendo sobre un Microsoft IIS que requiera usuario y contraseña en un pop up para acceder a una determinada parte de la web, probablemente se use el protocolo NTLM.

NTLM (sucesor de NT LAN Manager) recoge un nombre de dominio, un nombre de usuario y una contraseña y usa cifrado para autenticar a un usuario sin enviar la contraseña del usuario a través de la conexión. En su lugar, el sistema que solicita la autenticación debe realizar un cálculo que demuestre que tiene acceso a las credenciales NTLM protegidas.

La autenticación NTLM implica por tanto tres actores: un cliente, un servidor y un controlador de dominio que realice los cálculos de autenticación en nombre del servidor.

Para saber si un Windows Server usa autenticación NTLM o no, podemos echar un ojo a los headers que envía el servidor y ver si está presente el siguiente header:

WWW-Authenticate: NTLM

Si el header está presente, pasamos el dominio de la web a través de NGINX y enviamos las peticiones hacia el Windows Server, no nos funcionará la autenticación de usuarios.

NTLM no funcionará porque los paquetes TCP no se reenvían exactamente como los recibió el proxy inverso. Por este motivo, muchos servidores 'proxy inverso' no funcionan con la autenticación NTLM ya que reenvían las solicitudes HTTP correctamente pero no los paquetes TCP.

Para solucionar el problema, me temo que debemos adquirir una licencia de NGINX Plus y usar el módulo NTLM, solo disponible en la versión de pago.

Para permitir autenticación NTLM a través de NGINX deberemos usar el siguiente código:

upstream http_backend { server 192.168.1.1:443; ntlm; } server { ... location /http/ { proxy_pass https://http_backend; proxy_http_version 1.1; proxy_set_header Connection ""; } }

Lo que hace este código es mandar las peticiones TCP enviadas a /http/ a un upstream y servir una conexión distinta para cada usuario. Huelga decir que con la orden "ntlm" (solo disponible en NGINX Plus) especificamos que se está usando NTLM en la autenticación de los usuarios.

Importante: para que la autenticación NTLM funcione correctamente, es necesario que la directiva proxy_http_version sea "1.1" y el campo de encabezado "Conexión" sea borrado.


Fuentes:

https://docs.microsoft.com/es-es/windows/win32/secauthn/microsoft-ntlm
https://nginx.org/en/docs/http/ngx_http_upstream_module.html#ntlm

Leer más »

Eliminar kernels viejos en SUSE Linux

Escrito por Blai el 5.5.21

Cómo eliminar un kernel viejo de un SUSE Linux para liberar espacio.



Hoy he actualizado un SUSE Linux Enterprise Server y el sistema me ha devuelto un error indicando que faltaba espacio en disco para instalar un nuevo kernel:

... (182/184) Installing: kernel-default-5.3.18-59.19.1.x86_64 ......................................................................[error] Installation of kernel-default-5.3.18-59.19.1.x86_64 failed: Error: Subprocess failed. Error: RPM failed: installing package kernel-default-5.3.18-59.19.1.x86_64 needs 76MB on the /boot filesystem

Para hacer espacio, tenía dos opciones:

- Borrar archivos no usados.
- Añadir espacio en disco a la máquina virtual.

He optado por la primera y he eliminado el kernel antiguo:

HOST # zypper purge-kernels Reading installed packages... Preparing to purge obsolete kernels... Configuration: latest,latest-1,running Running kernel release: 4.12.14-150.32-default Running kernel arch: x86_64 Resolving package dependencies... The following package is going to be REMOVED: kernel-default-4.12.14-150.22.1 1 package to remove. After the operation, 218.7 MiB will be freed. Continue? [y/n/v/...? shows all options] (y):

Tras eliminar el kernel viejo, el nuevo kernel se ha instalado sin problemas:

HOST # zypper up Refreshing service 'Basesystem_Module_x86_64'. Refreshing service 'Containers_Module_x86_64'. Refreshing service 'Desktop_Applications_Module_x86_64'. Refreshing service 'Development_Tools_Module_x86_64'. Refreshing service 'Legacy_Module_x86_64'. Refreshing service 'Public_Cloud_Module_x86_64'. Refreshing service 'Python_2_Module_x86_64'. Refreshing service 'SUSE_Cloud_Application_Platform_Tools_Module_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Server_x86_64'. Refreshing service 'Server_Applications_Module_x86_64'. Loading repository data... Reading installed packages... The following NEW package is going to be installed: kernel-default-5.3.18-59.19.1 The following package requires a system reboot: kernel-default-5.3.18-59.19.1 1 new package to install. Overall download size: 64.2 MiB. Already cached: 0 B. After the operation, additional 148.4 MiB will be used. Note: System reboot required. Continue? [y/n/v/...? shows all options] (y): y Retrieving package kernel-default-5.3.18-59.19.1.x86_64 (1/1), 64.2 MiB (148.4 MiB unpacked) Retrieving: kernel-default-5.3.18-59.19.1.x86_64.rpm ......[done (11.7 MiB/s)] Checking for file conflicts: ...........................................[done] (1/1) Installing: kernel-default-5.3.18-59.19.1.x86_64 .................[done]

Tras esto, el nuevo kernel ha quedado instalado.

Leer más »