Páginas

12 noviembre, 2015

Cambiar puerto de conexión de Escritorio remoto RDP

RDP (Remote Desktop Protocol) protocólo 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
Búscamos 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 decicmal, 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 redfirección de puerto se suelen definir por primer y último puerto externo y primer y último puerto interno e indicar la direccó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!

08 noviembre, 2015

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!

04 noviembre, 2015

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!

02 octubre, 2015

Descargar un website a un directorio local [HTTrack, Cyotek WebCopy y wget]

HTTrack es un software freeware, tanto para sistemas Windows como para Linux, que nos permitirá descargar un sitio Web por completo a un directorio local de nuestro equipo. Construye recursivamente todos los directorios, consiguiendo HTML, imágenes y otros archivos desde el servidor a tu equipo.

Figura 1: HTTrack descargando una website de ejemplo.

Una vez descargado todo el website, podremos navegador de forma local sin conexión a Internet o a ese sitio web, navegar entre todos los hipervínculos de dicha website.

Dependiendo el "tamaño" que pueda tener el sitio web a descargar el proceso tardará más o menos tiempo, aunque esto dependerá también del tipo de conexión a Internet que tengamos.
Para hacerse una idea unos 330MiB tardaríamos unas 4 horas en descargar.

Cyotek WebCopy se trata de otro software con el que poder descargar un sitio web. Similar a HTTrack. Admite URLs con esquema HTTPS, estableciendo campos de formulario o login si se trata de un portal con autenticación previa.

Figura 2: Cyotek WebCopy descarga de sitio web.

wget: Linux y Windows

Otra forma de poder descargar todo un website a nuestro equipo local es a través del uso de wget en sistemas Linux esta utilidad ya viene integrada por defecto.
wget [WEBSITE] -r -k -page-requisites
Figura 3: wget sobre Ubuntu.

Algunos modificadores útiles de wget:

-r o -recursive: indica que de forma recursiva profundice en el árbol de directorios del sitio remoto.
-k o -html-extension: convierte todas las extensiones de fichero a .html.
-page-requisites: descarga absolutamente todo lo que necesite cada página web (imágenes, CSS, etc…).
-no-clobber: evita re-descargar archivos que ya se hubieran descargado.
-convert-links: convierte los enlaces a fichero local, de modo que pueda navegar por todos los hipervínculos de forma local, offline.
-domains [Website]: no descargará ningún enlace o nada que se salga del dominio indicado.
-no-parent: no subirá a niveles superiores al dominio

Figura 4: wget sobre Windows.

Descargar wget para Windows: http://gnuwin32.sourceforge.net/packages/wget.htm

Después de descargarlo y ejecutarlo seguramente nos pedirá las siguientes librerías:
libssl32.dll y libeay32.dll: https://openvpn.net/release/openssl
libintl3.dll: http://gnuwin32.sourceforge.net/packages/libintl.htm
libiconv2.dll: http://gnuwin32.sourceforge.net/packages/libiconv.htm

Saludos!

23 septiembre, 2015

Diferencia entre las carpetas "Archivos de programa" y "System32" en arquitecturas x86 y x64

Aunque a estas alturas tecnológicas es algo tarde para explicar esto, creo que nunca viene de más dar un repaso y quizás aclarar determinados conceptos.

En una entrada anterior comentara como "listar aplicaciones y actualizaciones instaladas en Windows de forma remota". Había comentado la diferencia de las claves de registro que había entre OS de 32 bits (x86) y 64 bits (x64).

Simplemente detallaré un poco más las diferencias más considerables entre ambas arquitecturas entre directorios y algunas carpetas y como afecta esto a la compatibilidad de todo en sistemas Windows.

Saber que hay dos diferencias en cuanto a los nombres: 'WOW64' y 'x86'.

WOW64: viene de "Windows on Windows 64 bits" (algo como Windows de 32 bits en Windows de 64 bits). Es un emulador que permite a las aplicaciones basadas en Windows de 32 bits correr indistintamente en Windows de 64 bits. Se utiliza una capa de compatibilidad entre un programa de 32 bits y el sistema operativo de 64 bits.

x86: inicialmente es un nombre que viene de la arquitectura de procesadores Intel que usaba instrucciones de 32 bits. El término x86 hace referencia referirse a los procesadores de Intel que usaban instrucciones de 32 bits. Eran procesadores llamados 8086, 80186, 80286, 80386, etc, este último fue usado para referirse a procesadores de 32 bits.

Existen dos variantes diferentes de la carpeta "Archivos de programa" y la carpeta de "Sistema de Windows".

Windows de 64 bits tiene dos versiones diferentes de la carpeta program files y la carpeta de sistema de Windows. Una versión está orientada para archivos de 32 bits y la otra versión para archivos de 64 bits. Los nombres de estas carpetas y los bits a que coresponden, son de la siguiente manera:

C:\Windows\System32: Carpeta de sistema de Windows para archivos 64 bits.
C:\Windows\SysWOW64: Carpeta de sistema de Windows para archivos 32 bits.
C:\Archivos de programa: Carpeta para archivos de programa 64 bits.
C:\Archivos de programa (x86): Carpeta para archivos de programa 32 bits.
La carpeta SysWOW64 está dedicada únicamente para archivos de 32 bits
La carpeta System32 está únicamente destinada para archivos de 64 bits
Aquí seguramente veremos algo que nos puede resultar confuso, resulta que la carpeta System32 está dedicada para archivos 64 bits y la carpeta SysWOW64 está dedicada para archivos 32 bits. Esto puede verse un poco ilógico atendiendo a los nombres de las carpetas, pero hay una explicación para ello.
Tiene que ver con la compatibilidad. Muchos desarrolladores han codificado el nombre de la ruta de la carpeta de sistema en el código fuente de sus aplicaciones con el fin de preservar la compatibilidad, si la aplicación se convierte a código de 64 bits, la carpeta de sistema de 64 bits, aún se llamará System32.

¿Qué ocurre con las aplicaciones de 32 bits que tienen codificada la ruta de system y están corriendo en Windows de 64 bits? ¿Cómo pueden encontrar la nueva carpeta SysWOW64 sin cambios en el código del programa?.

La respuesta es que el emulador redirecciona las llamadas a la carpeta System32 a la carpeta SysWOW64 de manera transparente, aún si la carpeta ha sido codificada a la carpeta System32 (C:\Windows\System32), el emulador se asegurará que la carpeta SysWOW64 se use en su lugar. De modo que el mismo código fuente, que utiliza la carpeta System32, puede compilarse tanto en códigos de programas de 32 bits como de 64 bits sin cambio alguno.

Es muy importante que archivos binarios compilados en 32 bits o 64 bits se instalen en la carpeta correcta de system. De otra forma el programa que necesite determinado archivo no podrá cargarlo y probablemente no funcionará correctamente.

Si tenemos instalado un sistema Windows de 64 bits, tendremos instaladas dos carpetas para archivos de programa (Program Files):
Archivos de programa (x86) instala siempre un programa de 32 bits.
Archivos de programa instala siempre un programa de 64 bits.
En muchos casos el programa iniciará y funcionará pese a que coloques el programa en carpetas equivocadas, pero si el programa pide a Windows la ruta de archivos de programa y desea accesar los archivos instalados en la carpeta, se utilizará la carpeta errónea y el programa fallará en su función. De modo que para asegurarse de que todo funcionará como se espera, deberás siempre instalar las aplicaciones que corran a 64 bits o en 32 bits en sus carpetas correspondientes.

Por último señalar las diferencias de esto el registro de Windows. En el caso de aplicaciones tanto de 32 bits como de 64 bits, se ven reflejadas en el siguiente path del registro:

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
Y esto viene siendo la explicación de las diferencias entre arquitecturas de x64 y x86 en sistemas Windows.

Saludos!

18 septiembre, 2015

Exportar un controlador específico de impresora incluido en el DriverStore de Windows

Si queremos exportar un controlador específico de el cual ya está incluido en el repositorio nativo DriverStore de Windows.

¿Por qué razón lo haríamos esto?

Simplemente por que en la website oficial el fabricante en cuestión no publica el controlador necesario o específico del modelo para nuevos sistemas operativos, sino que lo hace con un controlador genérico.

Sin embargo, en algunos casos Windows lo incluye en sus repositorios oficiales. Como es el siguiente caso, donde Windows incluye el controlador HP LaserJet 4200/4300 PCL6.

Figura 1: Driver de HP Laserjet 4200/4300 PCL6 el cual queremos exportar.

Para poder ver la ruta, el controlador de inicialización (.ini) y sus otros ficheros dependientes del driver podemos hacer uso de prndrvr.vbs del que ya hablara en otro artículo http://www.zonasystem.com/2014/09/administrar-impresoras-de-windows.html

Por defecto ubicados en el path:
C:\Windows\System32\Printing_Admin_Scripts\es-ES
Abrimos una consola con privilegios de administrador y ejecutamos:
prndrvr.vbs -l |more
-l: Nos listará todos los controladores instalados en el equipo local.
|more: visualización por páginas de los resultados.

Figura 2: Controlador principal y lista de todos los archivos dependientes necesarios.

Podemos hacer exactamente lo mismo de forma gráfica. Para ello abrimos una MMC y agregamos el complemento de "Administración de impresión" para el equipo local, en el apartado de "Controladores" buscamos el driver de la impresora que nos interese, en sus propiedades veremos la ruta de acceso al controlador y el resto de ficheros independientes.

Figura 3: Método gráfico con el mismo resultado que prndrvr.vbs -l

La ruta por defecto del repositorio del conjunto de todos los drivers instalados en la máquina local es:
C:\Windows\System32\DriverStore\FileRepository
Dentro de este path buscamos la carpeta del controlador en cuestión, la cual obtenemos su nombre por lo realizado anteriormente.

Aquí tendremos dos opciones:

- Copiar el propio fichero del driver y sus depencias uno a uno siguiendo el listado mostrado anteriormente (ya sea que lo hicéramos en consola o de forma gráfica).

- Si vamos a reinstalar este driver en un equipo en el que tenga las depencias de dicho driver simplemente copiaremos el fichero de inicialización del propio driver (.inf). Ya que esté llamará a sus otros ficheros dependientes.

Saludos!

15 septiembre, 2015

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!

07 septiembre, 2015

Privacidad expuesta por medio del feed de Picasaweb

Este simple y pequeño tip nos permite ver fotos de perfiles públicos en picasaweb.google.com un servicio que Google suele ofrecer sincronización con la cuenta de Google global del usuario.

Servicios que usemos de Google y en el cual compartamos de algún modo imágenes a través de ellos podrán ser publicadas de forma pública en picasaweb: La galería de imágenes del teléfono, Blogger, Hangouts, etc.

Simplemente si accedemos a feed aleatorio como por ejemplo puede ser este.
http://picasaweb.google.com/data/feed/base/all?q=IMG0015+jpg+20150815
Veremos que podremos realizar búsquedas en base a esta muestra de feed, donde:
IMG0015: Serán las palabras que llevará por título la imagen en la búsqueda.
jpg: El tipo de imagen a mostrar.
20150825: Fecha en orden año/mes/día.

Palabras que contengan en sus títulos IMG o WA, lo mas seguro es que salgan fotos de gente que no sabe que tiene el picasa sincronizado con su cuenta de Google.

Finalmente clickando en algunas de las imágenes podremos acceder al perfil de dicho usuario y de ese modo ir navegando por sus álbumes, comprometiendo así su privacidad.

Esto no es un bug ni nada por el estilo, es un "fallo" del propio usuario. Bien es verdad que Google en ocasiones sincroniza sus servicios sin avisar o avisa al usuario final de un modo "transparente" pero será el usuario quien sea el responsable de estar pendiente de su privacidad y de revisar las configuraciones de los servicios de los que forma parte y así restringir determinados accesos de una forma pública a privada.

Revisar siempre la configuración de privacidades y permisos de cuentas en las que estáis registrados, a veces dedicar un mínimo de tiempo a estas tareas evitaremos este tipo de filtraciones públicas mal intencionadas y consiguiremos la privacidad de la persona.

Saludos!

26 agosto, 2015

Eliminar la caché de datos de equipos almacenada en conexiones RDP

Si hemos realizado conexiones por Terminal Services (escritorio remoto) veremos que estas guardan o quedan cacheadas en el panel de conexión por escritorio remoto.

La caché es guarda temporalmente los datos recientemente procesados de modo que la siguiente vez que nos queramos conectar a otro equipo lo tengamos más cómodo a la hora de introdurcir los datos necesarios.

Figura 1: Nombres de equipo en los que se tuvo alguna vez conexión RDP.

Si la conexión al equipo remoto se llega a establecer, el dato de nombre de equipo, dirección IP o DDNS que hubiésemos usado, quedará guardado para esa sesión de usuario en concreto.

Si queremos eliminar esta caché de datos, la podremos encontrar registrada en la siguiente ruta de registro:
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers

En Windows 10:

HKEY_USERS\<SID-USUARIO>\SOFTWARE\Microsoft\Terminal Server Client\Servers 

En formato de claves de registro están generados todos los nombres de equipo, IP o DDNS a los que nos hubiésemos conectado.

Simplemente tendríamos que eliminar todas las claves o la que queramos borrar el registro de conexión almacenada. Estas a parte del nombre del equipo de conexión también almacenan el nombreDeEquipo\UsuarioDeConexión en un valor de cadena llamado "UsernameHint".

Figura 2: Path del registro donde se almacen los datos de conexiones RDP.

También tendríamos que eliminar el valor de cadena correspondiente en la path de registro:
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default
Situado en la misma ruta pero en una clave más arriba, veremos la clave "Default".
Esta clave nos indica el orden de prioridad en el que se nos mostrorá la lista de conexiones al desplegar la barra de la ventana de "Conexión a Escritorio remoto".

Figura 3: Valores de cadena de orden de prioridad para conexiones Terminal Services.

Este orden son expresados por valores de cadena (REG_SZ) los cuales llevan nombres del tipo: MRU0, MRU1, MRU2, MRU3, etc. acompañados con el valor de datos del nombre de equipo, IP o DDNS a conectarse.

Si lo que queremos no es borrar el valor MRUX y lo que queremos es variar orden, bastará con renombrar los nombres MRUX, donde "X" inicia el número de orden de prioridad de mayor a menor.

Saludos!

24 agosto, 2015

Iniciar aplicaciones antes de la carga de perfiles de usuario

Si queremos iniciar una determinada aplicación en background antes de la carga de cualquier perfil de usuario, de modo que ya esté disponible cuando encendamos el equipo y nos apararezca la pantalla de bienvenida de Windows sin necesidad de iniciar sesión en la máquina local.

Simplemente tendremos que agregar en indicar la ruta del fichero binario .exe que lanza aplicación en la siguiente path del registro.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Una vez estemos en la clave Winlogon, a continuación buscamos el valor de cadena "Userinit" el cual tendremos que añadir el valor de ruta del fichero a ejecutar, por ejemplo: "C:\Program Files (x86)\CARPETA_APLICACIÓN\FICHERO.EXE".

Si queremos agregar más aplicaciones tendremos que separar las rutas por comas (,).

Figura 1: Winlogon, añadiendo aplicación en userinit.

El valor de cadena Userinit nos permite añadir aplicaciones u otros ficheros antes de la carga de perfiles de usuario de Windows.

Info. oficial de Microsoft: https://technet.microsoft.com/en-us/library/cc939862.aspx

Saludos!

14 agosto, 2015

¿Cómo se procesan las GPO en un dominio? (Objetivos de directiva de grupo)

Competencia entre contenedores.

Una GPO, como ya hemos visto anteriormente, puede ser contenida por equipos locales, sitios, dominios y unidades organizativas (en adelante OU). Como un usuario, por ejemplo, estará en un equipo local que a su vez se ubicará en un sitio, pertenecerá a un dominio y será miembro de una OU se ve claramente que se puede dar el caso de que en el equipo local se aplique una GPO, en el sitio otra, otra para el dominio y otra para la OU (e incluso para la OU hija, de tercer nivel, etc.). Se podría dar el caso, por tanto, de que las GPO contuvieran políticas que se contradijeran entre sí. Cuando se dan casos de estos, el sistema de GPO está implementado para asegurar que siempre se aplicarán las políticas, y para ello establece una forma de prioridad entre éstas por la cual, según dónde estén asignadas, unas prevalecen sobre otras atendiendo a una serie de reglas que a continuación, con la ayuda de dos figuras, describiremos.

Figura 1: Prioridades de las GPO.

En la figura 1 vemos, de forma resumida, cuál es la prioridad de las GPO. Las GPO de una OU prevalecen sobre las del dominio, que a su vez prevalecen sobre las de sitio, las cuales a su vez prevalecen sobre las del equipo local. Por prevalecer no se entiende que unas anulen a otras; las políticas se suman, sólo se anulan en caso de ser contradictorias entre ellas. Por ejemplo, si a nivel de dominio habilitamos la política de deshabilitación del panel de control y en la OU deshabilitamos esta política, y suponemos que ninguna otra de las políticas a nivel de dominio entra en contradicción con ninguna otra de las de la OU, el resultado que se aplicará a un objeto contenido dentro de la OU será la suma de ambas GPO, salvo que la política que se aplica respecto a la deshabilitación del panel de control será la de la OU, no la del dominio, y por tanto el panel de control será visible.

En la figura 2 vemos un diagrama de flujo que nos explica cómo son aplicadas las GPO; se puede apreciar el orden en que son leídas y como se actúa en caso de que se contradigan o no. Como se puede suponer, si hubiera una OU de tercer nivel, ésta prevalecería sobre la hija y obviamente una de cuarto nivel sobre la de tercer nivel y así sucesivamente:

Figura 2: Diagrama de flujo de aplicación de las GPO.

Más info en: http://freyes.svetlian.com/GPOS/GPOS.htm

Saludos!

08 julio, 2015

Registro de Windows desde línea de comandos y estructura de la jerarquía del registro (regedit)

Dejo una estupenda guía muy detalla y extensa de "© Fernando Reyes López" es ya de 2005, pero al tratarse de una guía que habla sobre el registro de Windows y su interacción en consola no varía prácticamente nada en su uso hasta la fecha actual.

Debido a que no es un guía mía y es muy extensa mejor dejo el enlace directo a la propia web del autor:
Guía detallada de la estructura jerárquica del registro de Windows (regedit).
Saludos!

30 marzo, 2015

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!

27 marzo, 2015

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.
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!

18 marzo, 2015

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!

22 febrero, 2015

Ver fotos de perfiles privados de Facebook

Esta entrada ya la había publicado hace tiempo pero por ciertos motivos tuve que eliminarla, hoy por otros motivos y petición de ciertos usuarios decidí reabrirla.

Realmente con este método no se visualizan las fotos o publicaciones de perfiles privados de Facebook, sino que es una forma de ver las fotos etiquetadas, que le gustaron, comentarios en fotos, etc. de dichos perfiles privados.

Esto tampoco se puede considerar un fallo de seguridad de Facebook, pero si a mi modo de ver una invasión de la privacidad de los usuarios que forman parte de esta red social.

Antes de nada comentar que, necesitamos estar registrados en la plataforma de Facebook.

Ahora simplemente buscamos el perfil del usuario:
https://www.facebook.com/nombreDelUsuario
Donde "nombreDelUsuario", es el nombre del perfil que nos interesa.

Ahora tendremos que conocer el ID que identifica a este usuario, este ID Facebook lo interpreta como una secuencia numérica que apunta al nombre de usuario.

Para poder saber que ID es el del usuario en cuestión tenemos dos opciones:

Sobre cualquier espacio en blanco de la página de Facebook del usuario en cuestión hacemos clic derecho > "Ver código fuente de la página".
Se nos abrirá una ventana en la que pulsaremos las teclas: Ctrl+F, para a continuación buscar "profile_id" (sin comillas) y pulsaremos la tecla Enter.

El primero que encontremos nos servirá, el cual se mostrará similar a lo siguiente:
"profile_id":0000000000000000
Donde la secuencia de "0" (ceros) es el número ID que identifica al nombre de usuario.

La otra opción de conocer este ID es haciendo uso de la propia web oficial de Facebook, en la que cuenta con un API para ello. (https://developers.facebook.com/docs/graph-api)

Entramos en la web: https://graph.facebook.com/nombreDelUsuario
En una vez pulsemos Enter, veremos algo como esto.
{
"id": "0000000000000000",
"first_name": "Nombre",
"gender": "Sexo",
"last_name": "Apellido",
"link": "https://www.facebook.com/nombreDelUsuario",
"locale": "Localidad",
"name": "Nombre del Perfil",
"username": "nombreDelUsuario"
}
Una vez ya sepamos cual es el ID que identifica a dicho usuario, copiaremos y colocaremos este ID en la siguiente URL:
https://www.facebook.com/search/0000000000000000
Donde la secuencia de "0" sería el ID en cuestión.

Por último tendremos que colocar después del ID el tipo de búsqueda que queramos hacer, estes son algunas referencias y los que yo en su día había encontrado.

/photos-tagged = Fotos etiquetadas
/photos-of = Fotos de...
/photos-by = Fotos por...
/photos-liked = Fotos a las que hizo Like
/photos-of/intersect = Más fotos
/photos-commented = Comentarios en fotos
/pages-liked = Páginas que le gusta
/groups = Grupos

Un ejemplo final sería:
https://www.facebook.com/search/IDdelUsuario/photos-tagged
Donde IDdelUsuario sería lógicamente la secuencia numérica respectiva y a continuación, en este caso, se mostrarían los resultados de las fotos en las que a ese usuario otros usuarios le etiquetaron o aparece etiquetado.

Esto no tiene gran misterio, ya que lo que se está haciendo es realizar una búsqueda interna de las bases de datos de Facebook hacía ese ID, ya que la referencia más habitual para las bases de datos es que sea un identificador unívoco "ID" y no un "nombreDeUsuario".

Dentro de esa búsqueda solo nos queda referenciar que tipo o hacia donde queremos buscar: fotos etiquetas, fotos de ..., comentarios en fotos, etc. Y que finalmente se muestren estos resultados.

Saludos!

Entradas Populares