Instalar características RSAT en Windows 10 cuando WSUS bloquea su descarga

A partir de las últimas versiones de Windows 10 las RSAT (Remote Desktop Services Tools) ya no se descargan e instalan como un paquete de actualizaciones de Microsoft. Sino que se incorporan como características avanzadas independientes que podemos descargar/instalar directamente desde el nuevo panel de configuración del sistema.

En el caso de que estemos trabajando en una máquina Windows 10 bajo un entorno de actualizaciones controladas por WSUS (Windows Server Update Services) es muy probable que el propio servidor WSUS esté bloqueando la descarga de las características RSAT.

Comprobar si las actualizaciones están controladas por WSUS

Para comprobar que el equipo está controlado por un servidor WSUS podemos comprobar la siguiente rama del registro.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

Si vemos que los valores "WUServer" y "WUStatusServer" existen y apuntan a una dirección, normalmente HTTP puerto 8530 o HTTPS puerto 8531 con un nombre DNS interno significará que nuestro equipo recibe actualizaciones controladas directamente de un servidor WSUS.

¿Cómo instalar RSAT bajo un entorno controlado por WSUS?

Para poder instalar RSAT desde las características avanzadas del nuevo panel de control, abrimos un regedit en un contexto privilegiado como administradores, siguiendo la rama anterior, localizamos la siguiente rama.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

La clave "AU" nos indica la sección de "Actualización automáticas de Windows Update". Aquí vemos el siguiente valor "UseWUServer" y lo establecemos a un valor 0.

• 1 = Obtiene actualizaciones de un servidor WSUS.
• 0 = Obtiene actualizaciones de Microsoft Update.

Abrimos una consola PowerShell como administrador y reiniciamos el servicio wuauserv "Windows Update Agent Service".

Restart-Service wuauserv

Ahora ya podemos añadir las características RSAT que queremos, una vez instaladas ya podemos habilitar de nuevo a través del registro la obtención de actualizaciones a través de WSUS.

Figura 1: Instalar características RSAT deshabilitando WSUS. 

Saludos!

Ejecutar WMIC en equipos remotos de la red local (Windows Management Instrumentation)

Si nos surgen problemas para la ejecución sentencias WMIC en máquinas o nodos remotos, mostraré los errores más comunes y como solucionarlos.

Un error puede ser que no esté habilitado las llamadas a procedimientos remotos (RPC).

Error:
Descripción = El servidor RPC no está disponible.

Figura 1: Error - "El servidor RPC no está disponible" (wmic).

Otro error común podría ser la falta de permisos para ejecutar WMIC en nodos remotos.

Error:
Descripción = Acceso denegado.

Figura 2: Error - "Acceso denegado" (wmic).

Comprobar que el servicio "Instrumental de administración de Windows" (Winmgmt) está habilitado en el tipo de inicio automático y esté en ejecución.

Figura 3: Servicios winmgmt (wmic) en Windows.

Habilitar la regla por aplicaciones permitidas del firewal (WFAS) de Windows para permitir comunicaciones y llamadas RPC de WMI. Dependiendo cada caso si se trata de una red privada o de dominio.

Figura 4: Reglas del WFAS (Windows Firewall Advanced Security) permitir la comunicación para WMI.

Verificar que el uso compartido de archivos e impresoras esté activado para el tipo de red según sea el caso. Por defecto en una red de dominio esta característica suele estar activada por defecto cuando un equipo cliente se uno al dominio.

Figura 5: Activar el uso de recurso compartido de archivos e impresoras.

Comprobar que en la consola del equipo remoto haya permisos suficientes para el usuario que ejecutará wmic.

Esto se puede modificar en la consola de Microsoft "wmimgmt.msc", en la pestaña de seguridad, se modifican los permisos para permitir la "Llamada remota habilita" y "Ejecutar métodos".

Figura 6: Permisos de seguridad al Control WMI.

Por último, y algo fundamental según las pruebas que he realizado, es que independientemente de si el equipo cliente remoto en el que se quiere ejecutar WMI forme parte de una red de dominio o una red privada. Será necesario crear un valor en el registro de Windows "LocalAccountTokenFilterPolicy" algo ya comentado en este artículo.

Desde mi punto de vista esto no es aconsejable a métodos de seguridad, no es para nada una buena práctica, pero si se trata de casos puntuales en los que se necesita realizar una serie de acciones remotas simplemente, por seguridad aconsejo volver a eliminar este valor del registro.

Para poder ejecutar este valor en el registro podemos hacerlo ejecutando una CMD en el equipo remoto a través de PsExec (PsTools de Sysinternals). En este artículo se detalla como hacerlo.

El valor LocalAccountTokenFilterPolicy se trata básicamente de "deshabilitar" el UAC (User Account Control) para la ejecución de acciones remotas.

Para añadir el valor LocalAccountTokenFilterPolicy a través de una CMD:

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

Para posteriormente eliminar el valor LocalAccountTokenFilterPolicy a través de una CMD:

reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /f

En el siguiente ejemplo se puede ver como se ejecuta WMIC remotamente desde un equipo local a un equipo remoto usando "wmic /node", especificando la dirección IP local o el hostname del equipo remoto y un usuario/password con privilegios administrativos en la máquina remota.

wmic /node:ip_hostname /user:usuario /password:password bios get serialnumber

Figura 7: Ejecución remota de "wmic /node".

Saludos!

Ejecutar una CMD en un equipo remoto con psexec

Esto es algo que suelo utilizar en muchos casos cuando los servicios para administraciones remotas que necesito en ese momento no están habilitados en el equipo remoto.

O bien me conecto con este tip para ejecutar una CMD en el equipo remoto y habilitar los servicios que sean necesarios para posteriormente administrar el equipo remoto de forma más cómoda a través del registro remoto (regedit) o los snap-ins MSC (administrador de dispositivos, impresoras, firewall, servicios, etc.) de administración remota añadidos a través de una MMC (Microsoft Management Console).

Como levantamos una CMD con privilegios administrativos ya sea de un administrador local o de dominio podemos ejecutar acciones remotas mediante la consola, "netsh" para la administración de redes o Firewall, "sc" para servicios, "reg" para la manipulación de entradas del registro, "wmic" instrumental de administración de Windows, etc. Aunque como comentaba anteriormente es más cómodo invocar las propias consolas de administración remotas MSC de Microsoft.

Para esto será necesario descargar psexec, parte de la colección de herramientas de Sysinternals de Microsoft.

Haciendo uso de PsExec ejecutamos lo siguiente en una CMD con privilegios de nuestro equipo local.

psexec \\EquipoRemoto -u UserAdmin -p Password cmd.exe

• EquipoRemoto: nombre o IP del equipo remoto al que nos queremos conectar.
• UserAdmin: usuario con privilegios de administrador local o de dominio sobre la máquina remota.
• Password: Passoword del usuario establecido anteriormente.
• Seguidamente indicamos la aplicación a ejecutar de forma remota, en este caso sería una CMD remota, por lo tanto "cmd.exe" o indicar la ruta absoluta para este binario o el que sea. "C:\Windows\System32\cmd.exe"
• Con el parámetro psexec /i indicamos una interacción GUI con ventana del equipo remoto. "C:\Windows\regedit.exe", etc.

Podemos usar el parámetro -h para ejecutar el token de elevación si en el sistema remoto tiene habilitado el UAC. Y el parámetro -s cmd.exe para ejecutar el proceso remoto en la cuenta del sistema.

En la siguiente captura se puede ver un ejemplo y una comprobación consultando las IPs y un whoami de como realmente estamos estamos dentro del equipo remoto.

Figura 1: Ejecución de una CMD en un equipo remoto con psexec.

En el caso de que obtengamos un error de acceso denegado, comparto el siguiente artículo como referencia para realizar la configuración previa WinRM.

• https://www.zonasystem.com/2019/01/ejecutar-wmic-en-equipos-remotos-de-la-red-local-windows-management-instrumentation.html.

Saludos!

Administrar los permisos de un servicio de Windows sobre un objeto

Definimos objeto a un fichero, carpeta, unidad, etc. Todo aquello en lo que se puedan administrar permisos NTFS en el caso de Windows.

Con los permisos NTFS de Windows podemos gestionar las DACL (Discretionary Access Control List) son lista de control de acceso discrecional en las que se pueden controlar quien es el propietario de un objeto y especifica quién tiene permiso y quién no para acceder a dicho objeto.

Sabemos que se pueden conceder DACL a usuarios locales del sistema, de un dominio, equipos o grupos de usuairos sobre uno o varios objetos (ficheros, carpetas o unidades).

¿Se pueden administrar estos permisos a objetos para un servicio de Windows o de terceros?

Si. Se pueden asignar uno o varios servicios a uno o varios objetos de Windows y establecer permisos sobre ellos. Lo que pasa que no se puede hacer una forma gráfica amigable ni de manera trivial como pasa con los usuarios.

Para conceder permisos a un objeto es necesario conocer el SID (Security Identifier) del usuario, equipo, grupo, etc. Que se va asignar a ese objeto. Por ejemplo en el caso de Windows, buscando el nombre de un usuario y asignándolo a un objeto sería suficiente para administrar las DACL de ese usuario sobre un objeto. De forma subyacente el sistema está reconociendo un SID asociado a ese usuario.

Los SID de los usuarios locales de un equipo se registran en la siguiente rama del registro de Windows.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProfileList

Hay otras formas de conocer los SID de usuarios locales así como también usuarios de dominio y equipos. Para conocer estos SID podemos usar WMIC (Windows Management Instrumentation Command-line).

Para listar todos los usuarios locales filtrando por nombre de usuario y SID.

wmic useraccount get name,sid

Igual que lo anterior pero filtrando un nombre de usuario en concreto.

wmic useraccount where (name='USUARIO') get name,sid

Lo mismo pero para usuarios que pertenezcan a un dominio.

wmic useraccount where (name='USUARIO' and domain='DOMINIO') get name,sid

Con PsGetSid (de Sysinternals) para listar los SID de usuarios locales de equipos remotos y el propio SID de la máquina locales y otras remotas. Para ejecutar cualquier herramienta PsTools de forma remota tendremos que conocer las credenciales de un administrador local o de dominio en la máquina remota.

Comentado todo lo anterior vamos a ver como podemos agregar un servicio a un objeto y gestionar sus permisos.

Lo primero que tenemos que averiguar es el nombre asignado a un servicio. Ya sea de Windows o de una aplicación de terceros la forma de conocerlo sería la misma.

En este caso de ejemplo usaré el servicio de Dropbox para Windows. Abrimos una consola de servicios (services.msc) y buscamos el servicio que queremos utilizar. Cuando abrimos el servicio vemos el apartado "Nombre del servicio" será ese el que usaremos.

Figura 1: Nombre del servicio Dropbox para Windows (DbxSvc).

Para conocer su SID asignado por Windows a un servicio usaremos la herramienta de comandos de Windows SC (Service Controller).

sc showsid DbxSvc

Figura 2: Conocer el SID asignado a un servicio de Windows con SC.

Ahora solo quedaría asociar ese SID a un objeto. De forma gráfica perosnalmente no encontré forma de hacerlo, pero si por la herramienta de comandos de Windows ICACLS. Con la que podemos mostrar y gestionar las listas de control de acceso discrecional (DACL) de un objeto.
En este caso agregaremos a la carpeta llamada "test" (que será el objeto) el servicio de Dropbox mediante el SID obtenido anteriormente.

icacls c:\test /grant *S-1-5-80-315955965-2752282644-3851734118-3415690430-1520210413:(f)

Figura 3: Agregando un servicio a un objeto con ICACLS

Ahora vemos como el servicio DbxSvc ya está integrado en el objeto y podremos manipular los permisos de forma gráfica. 

Figura 4: Administrando de forma gráfica los permisos de un servicio agregado a un objeto.

Saludos!

Cambiar puerto de conexión de Escritorio remoto RDP

RDP (Remote Desktop Protocol) protocolo desarrollado por Microsoft para el proceso de conexiones por escritorio remoto (Terminal Services) a otras máquinas ya sea en LAN o WAN.

Este protocolo trabaja bajo el puerto por defecto 3389 TCP y UDP. Por regla general cuando abrimos una ventana de conexiones de escritorio remoto (mstsc.exe) en el campo en el que indicamos el nombre de equipo o dirección IP (local o externa) y no especificamos nada más, este establece la conexión RDP por defecto por el puerto 3389 TCP.

Si queremos llegar a cambiar este puerto por defecto tendríamos que hacer principalmente dos configuraciones manuales, las cuales serían cambiar un valor del registro de Windows y permitir en el Firewall de Windows las conexiones entrantes por el nuevo puerto establecido.

Pero para verificar todo empecemos por el principio comprobando las configuraciones para permitir conexiones remotas.

En propiedades del sistema > Acceso remoto verificamos que tengamos marcado "Permitir las conexiones remotas a este equipo" y que por seguridad tengamos marcado el checkbox de permitir autenticación a nivel de red (NTLM).

Comprobamos que los usuarios permitidos para establecer este tipo de conexiones está permitido o simplemente seleccionamos aquellos usuarios que queramos permitir conexión remota al equipo y que estos tengas una password con la que poder autenticarse sobre NTLM, estos usuarios no tienen por que ser administradores.

Figura 1: Configuración de escritorio remoto en sysdm.cpl.

Comprobamos que el servicio RDCS (Remote Desktop Connection Service) está iniciado. Será el encargado de gestionar a nivel de sistema la conexión remota.

Figura 2: Servicio RDCS iniciado.

Comprobamos que el propio servicio de Terminal Services (TermService) está iniciado. Será el encargado de permitir la conexión.

Figura 3: Servicio TermService iniciado.

Por último comprobamos el WFAS (Windows Firewall Advanced System) y vemos que una vez que habilitamos opción de permitir conexiones y que el servicio está iniciado, este ya incluye estas tres reglas por defecto en el Firewall, vemos que por defecto usan tanto el protocolo TCP como UDL para el puerto de conexión 3389.

Estas reglas a priori no se pueden modificar ya que vienen definidas por por el sistema.

Figura 4: Reglas por defecto para RDP por conexión del puerto 3389.

Llegamos a la parte que realmente hace título a este artículo, como cambiar el puerto por defecto 3389 a otro puerto que deseemos.

Abrimos un registro de Windows y nos vamos al siguiente path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Buscamos el valor DWORD "PortNumber", lo abrimos e introducimos el valor en hexadecimal correspondiente al valor decimal que queramos dar al nuevo puerto. Aunque cambiemos a base decimal, tendremos que guardar el valor DWORD como hexadecimal.

En este caso modifiqué el puerto por defecto 3389 por el 60500 (en hexadecimal: ec54).

Figura 5: Cambiando el puerto de conexión por defecto de escritorio remoto.

Una vez lo cambiemos tendremos que permitir la entrada del nuevo puerto modificado. Esto lo haremos en modo avanzado del Firewall y agregando nuevas reglas de entrada de conexión tanto para protocolo TCP como para UDP para el mismo puerto. De modo que quede como puerto específico el puerto modificado, en mi caso, continuando el ejemplo el puerto 60500.

Figura 6: Agregamos el nuevo puerto de entrada en el Firewall.

Para usar esta conexión de forma local en nuestra red interna sería suficiente, pero si queremos hacerlo a través de una conexión de otra red, tendremos usar un DNS dinámico (DDNS).

Con nuestro DDNS ya configurado, tendremos que acceder al router que tengamos y en la sección NAT (NAT Forwarding) para la redirección de puertos, tendremos que abrir tanto para protocolos TCP y UDP el nuevo puerto establecido, continuando el ejemplo anterior, serían el 60500.

La redirección de puerto se suelen definir por primer y último puerto externo y primer y último puerto interno e indicar la dirección IP local a la que va redireccionada los puertos.

De modo que por ejemplo, si lo preferimos podemos indicar a nuestro router que abra el puerto externo 55555 y que después nos redirija al puerto interno de nuestro equipo 60500.

Figura 7: NAT Forwarding en router.

La visualización del router que se muestra en las capturas anteriores es solo un ejemplo de mi router SOHO ya que la interfaz gráfica de cada router suele ser distinta de uno a otro.

Para comprobar que el puerto está realmente abierto entre el router y el firewall de nuestro equipo local y queremos saber si es accesible desde otra red externa, lo comprobamos con algún escaneador de puertos online.

Figura 8: Escaneando el puerto 60500 en estado: abierto.

Para conectarnos usando RDP por un puerto específico establecido, simplemente introducimos la dirección IP interna/externa o DDNS seguido de : (dos puntos) y el número de puerto en cuestión.

Figura 9: Conexión por escritorio remoto con un puerto específico.

Por último podemos ver el resultado de este ejemplo en la siguiente captura. Observando que el puerto de conexión es el 60500 y el cliente lo estableció con uno aleatorio (65445). Con netstat podemos ver el PID y el servicio establecido para la conexión TermService.

Figura 10: Ejemplo de conexión establecida cliente/servidor con puerto RDP modificado.

Conclusiones

Para cambiar el puerto de Terminal Service simplemente nos bastaría con cambiar la clave de registro correspondiente (figura 5) y a continuación abrir ese determinado puerto para TCP/UDP en la configuración avanzada del Firewall de Windows (figura 6).

Saludos!

Interfaz web en uTorrent para administración remota

uTorrent dispone de una función para poder activar una interfaz web para su gestión y su posible administración remota.

En las preferencias avanzadas de uTorrent activamos la función de Interfaz web.

En ella configuramos un usuario y una password para poder acceder vía web. Establecemos un puerto de escucha local, en mi caso 9090. Sería habitual el 8080 pero actualmente este lo tengo reservado para otro cometido. La cuestión sería asignar un puerto que no estuviese predefinido en otro protocolo y que estuviese "siempre libre" o reservado para este fin. Y finalmente definimos un path para una carpeta de descarga.

Figura 1: Configurar de interfaz web en uTorrent, usuario, passw y puerto.

Quedaría pensar que sería necesario abrir el puerto asignado para la interfaz web de uTorrent en WFAS (firewall avanzado) de Windows. Pero no será necesario especificar explícitamente ningún puerto. Ya que cuando instalamos uTorrent de forma automática este crea una regla de entrada la cual necesariamente usa para establecer conexiones para las descargas de torrents.

Esta regla usa una tecnología conocida como "Edge Traversal" que permite que un equipo acepte paquetes entrantes no solicitados que han pasado a través de un dispositivo de borde, como un NAT router o firewall, por lo que este establece la conexión con cualquier puerto de entrada/salida solicitado.

Figura 2: Edge Traversal en regla por defecto de uTorrent.

Vemos que en esta regla Edge Traversal usa TCP para todos los puertos de conexión.

Figura 3: TCP para todos los puertos en Edge Traversal.

Para acceder en nuestra red interna esta configuración sería suficiente ya que poniendo el nombre de equipo o IP del host seguido del puerto en especificado 9090 y /gui en la barra de direcciones de un navegador, accederíamos a la interfaz web de uTorrent para su gestión.

Pero si queremos acceder desde otras redes externas, es decir, desde el exterior de nuestra red a la interfaz web de uTorrent podríamos hacerlo usando una configuración DDNS.

Primeramente abrimos el puerto específico en el router de nuestra red, en la sección de redirección de puertos (NAT Forwarding).

En mi caso he asignado como puerto de entrada externo el 50900 que a su vez redirige a mi IP interna local y al puerto especificado 9090 en la preferencias de uTorrent.

Figura 4: NAT Forwarding para acceso remoto en interfaz web uTorrent.

Desde un equipo de otra red, abrimos un navegador e introducimos en la barra de tareas: DDNS:50900/gui

Nos pedirá user/passw, introducimos la que habríamos puesto en las preferencias de configuración de interfaz web en uTorrent.

Figura 5: Acceso remoto por DDNS a la interfaz web de uTorrent.

Para poder gestionar uTorrent por interfaz web ya sea en red local o por acceso externo, uTorrent debe estar iniciado/ejecutándose en el host local.

Saludos!

Configurar DDNS para accesos remotos (NoIP) en Windows o Linux

Hoy en día existe gran información en internet sobre como crear un DDNS (Dynamic Domain Name System), pero simplemente como apunte personal y con motivo de entradas posteriores que iré publicando, escribiré esta entrada para tenerla como referencia.

En una red convencional disponemos de un rango de IPs internos (LAN) los cuales hacen NAT para salir a otras redes externas hacia Internet, NAT traduce las peticiones de todas las direcciones IPs internas en una única dirección IP externa/pública la cual es proporcionada por nuestro ISP.

Esta dirección IP pública cada vez que solemos reiniciar el router y esperamos el TTL suficiente para que expire la concesión de esa misma dirección IP o sencillamente nuestro ISP la "cambia" por otro dirección perdemos la pista de ella, ya que normalmente los usuarios domésticos no disponen de un dirección IP estática por parte de su ISP, en ese caso habría que negociar una posible dirección IP estática para uso doméstico y tendríamos que pagar un plus a mayores por este servicio.

Por esa razón para acceder de una red externa a nuestra red personal, deberíamos saber en todo momento que dirección IP pública que tenemos asignada en ese momento por nuestro ISP. Por lo que DDNS nos permite asociar una dirección IP pública a un nombre de dominio el cual podamos recordar y el cual se esté enviando de forma periódica solicitudes de renovación por un posible cambio de dirección IP en el que el servicio que escojamos nos mantenga actualizada la redirección del nombre de dominio a la dirección IP pública que tengamos asignada en ese momento.

Existen diversas web que ofrecen este tipo de servicio con un simple registro de cuenta en el sitio web en cuestión.

Algunos sitios son gratuitos y otros de pago, muchos de los sitios gratuitos que ofrecen los servicios DDNS son gratuitos durante un periordo de tiempo y después habría que ir renovándolo, lo que supondría cambiar el nombre de dominio paulatinamente.

Comentar antes de nada que simplemente bastaría con darse de alta en el proveedor de servicio que ofrezca DDNS, creando una nueva cuenta de usuario, este ya detecta la IP pública actual y cuando añadimos un host DDNS este servicio ya redirecciona el nombre de host a la IP pública de forma automática, (en ocasiones dependiendo el tipo de dominio puede tardar más o menos en actualizar la información).

Pero en el caso de un posible cambio de IP pública por parte de nuestro ISP habría que notificar al servicio que nos ofreció DDNS que hay una renovación de dirección IP, para mantener esta actualización de dirección IP tendremos dos formas de hacerlo.

[1] - Configurando nuestra cuenta DDNS en nuestro router y tipificando el servicio oportuno.
[2] - Configurando un cliente del propio servicio con nuestra cuenta DDNS en el sistema.

En mi caso y para ilustrar esto con un ejemplo me basaré en los servicios DDNS que ofrece noip.com.

En primer lugar nos registramos en el web de noip.com, elegimos que queremos crear nuestro hostname más tarde y en un principio elegimos un servicio gratuito DDNS. En el que nos pedirá un user y password vinculado a una dirección e-mail.

 Figura 1: Registro gratuito en noip.com

Una vez nos registramos confirmamos la activación de cuenta y accedemos al Cpanel de nuestra cuenta noip.

Añadiremos un nuevo host por lo que nos dirigimos a la sección: Host/Redirects > Add host > y creamos un nuevo hostname podremos escoger entre múltiples tipos de dominios. Dejaremos el el tipo de host en DDNS Host (A).

En este punto y en el caso de noip, de manera opcional nos deja elegir si queremos pasar a un servicio de pago en el que durante un año tendremos diversas ventajas que no tendremos con un servicio gratuito.

 Figura 2: Añadiendo un hostname DDNS en noip.

Con esto ya tendríamos configurado una cuenta con un hostname DDNS en noip. El cual apuntaría a la dirección IP pública actual. Si queremos que esta información se actualice con el paso del tiempo, por si nuestro ISP nos asigna otra dirección IP pública distinta.

Configuración de una cuenta DDNS en el router

[1] - Si es posible y nuestro router personal (SOHO) nos lo permite, configuramos la cuenta DDNS que creamos anteriormente.

Tendremos que mirar no solo de si nuestro router nos permite configurar un DDNS, sino si el servivio DDNS es de la mismo proveedor en la que creamos la cuenta (DynDNS, NoIP, TZO, etc.) hay routers neutros que disponen de la mayoría de proveedores, pero no todos son así.

En el panel de configuración del router buscamos la sección de DDNS en la que tendremos que introducir el hostname creado seguido del tipo de servicio, en este caso podemos establecer el proveedor No-IP, el ciclo de actualización sería "Cambio de IP" y por último, user y password de la cuenta creada. La interfaz de cada router suele variar de unos modelos a otros, pero la idea sigue siendo la misma.

Figura 3: Configuración de cuenta DDNS en router SOHO.

[2] - En el caso de que no dispongamos de esta opción en nuestro router o sencillamente nuestro router no disponga del servicio del proveedor en el que nos habíamos registrado (en este caso No-IP) y solo dispongamos de DynDNS. Entonces, tendremos que instalar el cliente DUC de noip en nuestro equipo local anfitrión este mantendrá la IP pública actualizada y sincornizada con nuestra cuenta noip de modo que nuestro hostname DDNS siempre nos redirija a la IP actual en todo momento existosamente.

DUC está disponible para sistemas Windows/Linux/MacOS.

Instalación y configuración de DUC (noip) en Windows

Descargamos el cliente de la web oficial llamado DUC (Dynamic DNS Update Client), simplemente lo descargamos lo instalamos e introducimos nuestras credenciales de cuenta.Veremos que tendremos el cliente corriendo en nuestro sistema, si lo deseamos podremos establecer una password de acceso para las configuraciones del cliente.

Figura 4: DUC inicializado y corriendo en el sistema.

En los servicios de Windows podemos comprobar que el servicio de noip-DUC está iniciado en background en el sistema (ducservice.exe).

Figura 5: Servicio de DUC iniciado en el sistema.

Cada vez que encendemos nuestro equipo tendremos que ejecutar de forma manual DUC si queremos que el servicio esté iniciado en el sistema.

Si queremos que el servicio de la cliente DUC se inicie de forma automática en el sistema, tendremos que activar los checkbox de inicio automático en el arranque del sistema. Startup para el servicio y para la propia aplicación cliente DUC.

 

Figura 6: Habilitar inicio automático del servicio/cliente DUC en el arranque del sistema.

Instalación y configuración de DUC (noip) en Linux (Ubuntu)

Abrimos una terminal con permisos de superusuario (sudo su). Descargamos el siguiente paquete:

wget http://www.no-ip.com/client/linux/noip-duc-linux.tar.gz

Descomprimimos el paquete.

tar xzf noip-duc-linux.tar.gz

Entramos en el directorio.

cd no-ip-2.1.9

Instalamos.

sudo make

Si tenemos probelmas para instalar make será necesario instalar el compilador gcc.

sudo apt-get install gcc

Instalamos con make.

sudo make install

Configuramos noip, en el que tendremos que introducir la cuenta creada en noip y seleccionar el DDNS.

/usr/local/bin/noip2 -C

En mi caso dispongo de varios DDNS, por lo que tuve que seleccionar solo uno de ellos.

Figura 7: Asisten de configuración por terminal de una cuenta noip en Linux.

Iniciamos la el cliente noip.

sudo /usr/local/bin/noip2

Figura 8: Script de llamada de inicio para noip2.

Si queremos que noip2 se carga de forma automática en el arranque del sistema.

Creamos un fichero.

sudo nano /etc/init.d/noip2

En este fichero agregamos la siguiente instrucción.

#! /bin/sh
sudo /usr/local/bin/noip2

Figura 9: noip2 corriendo en el sistema.

Le damos permisos de ejecución al fichero.

sudo chmod +x /etc/init.d/noip2

Agregamos la entrada al fichero de inicio.

sudo update-rc.d noip2 defaults

Ayuda de parámetros NoIP:

/usr/local/bin/noip2: Arranca el cliente noip
/usr/local/bin/noip2 -C: Configura el cliente noip
/usr/local/bin/noip2 -S: Visualiza el Estado del Cliente
/usr/local/bin/noip2 -D pid: Cambia el estado de depuracion del cliente pid
/usr/local/bin/noip2 -K pid: Finaliza el cliente pid

Más información sobre la instalación del cliente DUC de NoIP en su web oficial:
En Windows: http://www.noip.com/support/knowledgebase/installing-the-windows-4-x-dynamic-update-client-duc
En Linux: http://www.noip.com/support/knowledgebase/installing-the-linux-dynamic-update-client

Saludos!

PsKill: Finalizar procesos en equipos remotos

Hace un tiempo comentara el uso de las PSTools: http://www.zonasystem.com/2014/03/pstools-suite-de-herramientas-para-la.html una suite de herramientas para la administración remota de una misma red de trabajo.

En esta ocasión haremos uso de pslist, pskill y psexec, las cuales nos servirán para listar procesos remotos y después finalizarlos (matarlos). Esto nos puede resultar útil en un entorno empresarial en el que remotamente queramos hacer pruebas con algún que otro software y queramos "reiniciar" el proceso.

Teniendo descargadas las PSTools, abrimos una consola en Windows y usamos pslist para listar los procesos del equipo remoto:

pslist -t \\[EquipoRemoto/IP]

-t: Lista los procesos en forma de árbol (jerarquía).
[EquipoRemoto/IP]: Es el nombre FQDN del equipo remoto o la direción IP local.

Una vez tenemos localizado el nombre del proceso remoto a finalizar o mejor aún, el PID (Process identifier).

Con pskill podremos finalizar o matar dicho proceso remoto. Manteniéndose en la misma cmd escribimos:

pskill -t \\[EquipoRemoto/IP] -u [NombreEquipo\UsuarioPrivilegiado] -p [Password] [NombreProceso/PID]

-t: Finaliza el proceso y sus dependencias.
-u: Indicar el nombre de equipo y un usuario administrador con privilegios.
-p: Contraseña del usuario administrador privilegiado.

 [NombreProceso/PID]: Nombre del proceso o PID a finalizar.

Si lo necesitáramos podríamos iniciar de nuevo el proceso que cerramos, de modo que hiceramos como un "reinicio" del software en cuestión al que afecta dicho proceso.

Simplemente con psexec para ejecutar comandos y lo que queramos en un equipo remoto, escribimos en la misma consola:

psexec \\[EquipoRemoto/IP] -u [NombreEquipo\UsuarioPrivilegiado] -p [Password] [FullPathPrograma\fichero.exe]

[FullPathPrograma\fichero.exe]: Sería la ruta del fichero binario ejecutable. (por ejemplo: C:\Program Files (x86)\Mozilla Firefox\firefox.exe)

Con esto finalizaremos el proceso y sus dependencias en el equipo remoto al que hagamos referencia y lo volveremos a iniciar en caso de que sea necesario.

Saludos!

Desinstalar Internet Explorer desde CMD de forma remota

Aunque existe una forma gráfica para desinstalar el navegador Internet Explorer:
Inicio > Panel de control > Programas y características > Activar o desactivar las características de Windows.

Figura 1: Desinstalar IE de forma gráfica

Microsoft nos ilustra de como hacerlo por comandos en una CMD. Lo cual esto a nivel local pues puede resultar curioso, simplemente saber que hay una forma de hacerlo por consola. Pero a nivel corporativo esto puede resultar útil para desinstalar alguna versión, en ocasiones posterior de IE, que por motivos de las Windows Update se pudiesen actualizar en determinados equipos de nuestra red corporativa.

Para hacerlo de forma local simplemente ejecutando una CMD con privilegios de administrador, escribir el siguiente código y reiniciar el equipo, llegaría para desinstalar IE por consola.

Para hacerlo de forma remota a otro equipo de la red, simplemente ejecutamos una CMD remota con PsExec con privilegios de administrador local de la máquina remota en cuestión, como ya expliqué en otros artículos.

Y seguidamente escribimos el código para su desinstalación:

FORFILES /P %WINDIR%\servicing\Packages /M Microsoft-Windows-InternetExplorer-*9.*.mum /c "cmd /c echo Uninstalling package @fname && start /w pkgmgr /up:@fname /quiet /norestart

En este caso el IE a desinstalar es la versión 9 (InternetExplorer-*9.*).

Si queremos desinstalar otra versión por ejemplo: IE_10 o IE_11. Simplemente se tendrá que modificar el 9 por la versión en cuestión.

Saludos!

Listar aplicaciones y actualizaciones instaladas en Windows de forma remota

En ocasiones nos interesa saber que aplicaciones están instaladas remotamente una máquina de nuestra red, simplemente tener una lista aplicaciones para saber, entre otras cosas, si están usando software no permitido en el entorno corporativo.

Aunque ya expliqué en otras ocasiones formas similares de hacer esto, esta es otra más que me parece interesante.

• http://www.zonasystem.com/2014/08/desinstalar-software-local-o-remoto.html
• http://www.zonasystem.com/2015/03/desinstalarinstalar-actualizaciones.html

Para poder listar el aplicaciones y actualizaciones instaladas de forma remota.
Podremos hacerlo de dos formas, por CMD o registro remoto.

Hay que tener en cuenta una cuestión, antes de nada deberemos saber si el software remoto instalado que queremos listar es para arquitecturas de OS x86 o x64. Ya que las claves del registro de Windows varian en función a esto.

Para arquitecturas x86 (32bits):

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall  

Para arquitecturas x64 (64bits):

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall

En el siguiente ejemplo voy a usar valores de clave de registro para sistemas operativos de x64.

[1º Opción] - Si el equipo REMOTO tiene el servicio de Windows (services.msc) HABILITADO el "Registro remoto".
Simplemente abrimos en nuestro equipo un regedit > Archivo > Conectar a registro de red... > después especificamos el nombre del equipo remoto y tendremos acceso al árbol de claves de su registro en el cual podemos ir a la rama en cuestión para mirar las aplicaciones instaladas.

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall

[2º Opción] - La otra opción es ejecutar con PsExec de la suite de PsTools, una CMD remota y realizar los siguientes pasos en comandos.

Abrimos una consola CMD de Windows y hacemos uso del comando reg.
Ejecutando la siguiente consulta:

reg query HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall /S | find "DisplayName"

En la que se consultamos la clave en la que se hace referencia y se filtra por el valor "DisplayName", que contiene el nombre de la aplicación en cuestión.

Aconsejo exportar dicha lista a un documento de texto para visualizarlo de forma más clara y con más razón si tenemos numerosas aplicaciones instaladas en nuestro equipo.

Ejecutamos lo mismo pero realizando una exportación a un fichero txt.

reg query HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall /S | find "DisplayName" >> fichero.txt

De este modo se nos exportará toda la lista de software y actualizaciones a "fichero.txt". Aclaro que, si hacemos esto sin especificar una ruta en cuestión, este fichero se nos creará en el directorio actual donde estemos trabajando en la CMD abierta en esa instancia.

Saludos!

Desinstalar/instalar actualizaciones remotamente de Windows Update

Si en nuestra organización corporativa necesitamos desinstalar, de forma remota a otro equipo de la red, ciertas actualizaciones (KB: Knowledge Base) de Windows proporcionadas por las Windows Update. Podemos hacerlo primeramente con psexec, pequeña utilidad incorporada en las PsTools (suite de herramientas de gestión remota que comentara ya en este blog) y a continuación usando una herramienta nativa de Windows el "Instalador Independiente de Windows Update" (Windows Update Standalone Installer) WUSA.

WUSA es una herramienta en modo de comandos, por lo que necesitaríamos ejecutar en el equipo remoto una CMD de manera subyacente. Para que, en este caso, esta desinstalación sea transparente al usuario final.

Haciendo uso de PsExec (como ya dije, incluido en la suite de PsTools). Ejecutamos esto en una consola CMD de nuestro equipo local con privilegios.

psexec \\EquipoRemoto -u UserAdmin -p Password cmd.exe

Donde: EquipoRemoto es el nombre o IP del equipo remoto al que nos queremos conectar, UserAdmin sería un usuario con privilegios de administrador y Password es la contraseña del usuario UserAdmin, acto seguido indicamos la aplicación a ejecutar de forma remota, que para este caso usaremos cmd.exe.

Una vez tengamos acceso al equipo remoto de la organización a través de esa instancia por CMD. Simplemente tenemos que saber el número que identifica a la KB a desinstalar.
Si no estamos seguros de si el equipo remoto la tiene o no instalada dicha actualización, sencillamente con el comando SYSTEMINFO.

Entre otras informaciones podremos ver las actualizaciones instaladas en el equipo listadas, en las que se muestra el ID de la KB.

Figura 1: Listado de actualizaciones instaladas en el equipo, con el comando Systeminfo.

De este modo sabremos si la actualización que queremos desinstalar ya está instalada en el equipo remoto.

Para la desinstalar la actualización, escribimos en la CMD remota:

wusa /uninstall /kb:IDactualizacion

Donde: IDactualizacion sería el número ID de la KB a identificar para su desinstalación.

En el siguiente ejemplo la actualización a desinstalar sería la "kb:2981653"

Figura 2: Desinstalando actualización con wusa.

Espero que esto pueda ser de utilidad para aquellos que deseen desintalar actualizaciones de forma remota y subyacente al usuario final, en equipos de un mismo workspace.

Instalar actualizaciones en remoto

Añado que: WUSA es, como ya dije, el instalador independiente de Windows Update, es decir; que no solo vale para desinstalar actualizaciones sino que también podríamos instalarlas.

Para más información el caso de instalar alguna actualización en remoto y de que forma hacerla, consultar la ayuda con:

 wusa /?

Saludos!