Usar PowerShell para comprobar si un puerto responde a una conexión.

Tenéis que disculparme por desaparecer un par de meses, pero se me ha juntado una sobrecarga de trabajo con intentar acabar un curso de informática forense. La buena noticia es que ahora os podré contar más cosas sobre más temas, que de algo sirve estudiar xDDD.

La última vez que os escribí por aquí os contaba cómo podíamos comprobar que un servidor de correo respondía en un puerto concreto. Hoy vamos a ver cómo podemos comprobar de forma muy sencilla desde PowerShell si un puerto está respondiendo.

El comando tnc, abreviatura de Test-NetworkConnection, nos permite comprobar si un puerto responde. Requiere dos parámetros dicho comando, el primero es obligatorio y sería la IP o el nombre del host, el segundo es opcional y sería el puerto concreto que queremos comprobar (precedido del parámetro -port). La sintaxis básica sería:

tnc eldominiooip.com -port ElPuertoQueSea

Si no especificamos puerto simplemente sabremos si dicha IP o nombre de red tiene conexión, si lo especificamos sabremos además si el puerto está abierto o a la escucha. Esta mañana tenía que comprobar si un servidor web respondía en el puerto 8080, así que mandé el siguiente comando:

tnc dominio.ejemplo.com -port 8080

La respuesta que obtuve fue que la conexión TCP había fallado. Tras llamar al cliente confirmamos que le habían cambiado el router y no habían abierto el puerto. En este ejemplo fue el puerto 8080 de un servidor web, pero también podéis probar cualquier otro puerto, ya sea para un servicio web, ftp, smtp, etc.

Comprobar manualmente si un servidor de correo responde en un puerto concreto

Esta mañana tenía que ver por qué un cliente no podía enviar correos desde el software que le proporciona mi empresa, el cliente insistía en que había configurado bien su cuenta pero la aplicación devolvía un error en la capa de transporte… así que algo no estaba bien. Me pareció raro que el puerto del SMTP fuese el 25 porque su proveedor de correo normalmente usa el puerto 465 y autenticación SSL. ¿Podía comprobar esto? Pues sí, abrí una consola y probé:

telnet mail.direcciondemicliente.com 25

Y la respuesta que obtuve es que el servidor no conectaba, así que luego probé a usar openssl para comprobar si respondía en el puerto 465:

openssl s_client -connect mail.direcciondemicliente.com:465

Y ahí ya recibí un mensaje que empezaba por 220 y me decía que el servidor estaba ready for the chachachá. Cambié la configuración de los puertos en su correo y todo fue como la seda.

Así que si queréis comprobar si un servidor de correo responde podéis usar Telnet como en el primer ejemplo (telnet dirección puerto) en el caso de que la conexión no esté cifrada, mientras que con openssl podéis hacer la misma comprobación en servidores que usen validación SSL. ¿Y si usan TLS? Pues con openssl también pero con más parámetros, tal que así:

openssl s_client -starttls smtp -connect mail.direcciondemicliente.com:587

Powershell: obtener la temperatura de la placa base en grados celsius.

¿Se puede obtener la temperatura de la placa base en Windows sin necesidad de apps externas y sin tener que entrar al a BIOS? Se puede con PowerShell.

Lo primero que tenemos que hacer es ejecutar PowerShell con permisos de administrador. Luego si ejecutamos este comando podríamos obtener un array con un par de lecturas de la temperatura de nuestra placa base en ese momento:

$(Get-WmiObject MSAcpi_ThermalZoneTemperature -Namespace "root/wmi").CurrentTemperature

Pero claro, esto no nos da la temperatura en grados celsius, ni siquiera en kelvin realmente. Si queremos ver esos datos tenemos que operar: si dividimos ese valor entre 10 obtendremos la temperatura en grados kelvin, después para convertir de kelvin a celsius habría que restar 273.15 grados. Estas operaciones podemos meterlas directamente en el comando que ejecutamos para no tener que andar haciendo cálculos manuales. Ojo, porque el objeto al que llamamos nos devuelve un array, para poder operar yo voy a acceder al primer elemento de la respuesta y forzar la conversión a entero para poder trabajar sin problema. Nos quedaría tal que así:

[int]($(Get-WmiObject MSAcpi_ThermalZoneTemperature -Namespace "root/wmi").CurrentTemperature[0])/10-273.15

Voy a recalcar que esta temperatura es la de la placa base y no la del procesador, que generalmente suele ser más alta.

Ciberseguridad: consejos a la hora de usar conexiones con el protocolo RDP

El protocolo de acceso a escritorio remoto (en adelante RDP) ha formado parte de Windows desde hace años, apareciendo originalmente para Windows XP. Cuando nos conectamos por RDP tenemos un equipo que hace de servidor, al que nos conectaremos, y el resto de equipos serán clientes. Aunque es una forma muy cómoda de trabajar también hay que señalar que con el paso de los años se ha quedado bastante obsoleto en términos de seguridad: carece de encriptación y es muy sensible a los ataques por fuerza bruta. Cuando durante el confinamiento de marzo-mayo de 2020 muchas empresas se lanzaron a teletrabajar sin un plan claro, dada la urgencia, se abusó de estas conexiones y muchas sufrieron problemas de seguridad (recuerdo haber leído un artículo en Twitter allá sobre el 18 de marzo donde ya se remarcaba la cantidad de escritorios remotos vulnerables que se podían localizar en España). Los delincuentes intentar servirse de conexións RDP vulnerables para instalar ransomware, spyware o practicar el cryptojacking.

Fotografía genérica de un app de seguridad.
Photo by Pixabay on Pexels.com

¿Cómo podemos usar RDP de forma segura?

Vamos a plantear varios puntos. El primero ¿necesitamos conexión vía RDP para trabajar? En muchos casos es más seguro implementar soluciones de trabajo a través de portales en la nube, claro que también requiere de una inversión en desarrollo (que se verá compensada en el largo plazo por la mejora en productividad y en seguridad).

En caso de que realmente necesitemos esta conexión vamos con el siguiente punto ¿Está nuestro software actualizado? Este es un punto recurrente en todas las entradas sobre ciberseguridad, pero es importante recordar que un equipo desactualizado suele ser más vulnerable ante cualquier tipo de ataque. No olvides descargar siempre las actualizaciones de seguridad del sistema operativo.

Los ataques más comunes contra los escritorios remotos son ataques de fuerza bruta y en muchos casos se sirven de un diccionario de usuarios y contraseñas, por lo que es recomendable no utilizar nombres genéricos para los usuarios (tipo Admin, Administrador, Administrator, etc.) dificultando así el trabajo del atacante, además de complementarlo con una política de contraseñas robustas. A día de hoy depender solo de la contraseña puede no ser suficiente, por lo que sería recomendable utilizar alguna solución para realizar una autenticación de dos factores, ya sea a través de datos biométricos, de una clave generada al momento que se envíe al usuario o del uso de un dispositivo externo para la validación. Otra buena política es bloquear el acceso de un usuario a través de este protocolo tras un número determinado de intentos fallidos de conexión. También es importante definir bien los permisos de los usuarios para limitar qué pueden y qué no pueden hacer según el trabajo que vayan a desempeñar. Un último consejo es no dejar «usuarios zombies«, cuántos más usuarios tenga el servidor más posibilidades tendrá el atacante de intentar entrar, por lo que si un usuario deja de utilizarse lo mejor será eliminarlo del sistema.

Una de las mejores soluciones que tenemos para hacer más robusta nuestra seguridad en los accesos a un servidor por RDP es utilizar una VPN: por un lado nos dará un cifrado para nuestras comunicaciones, cosa de la que carece el protocolo RDP, y por otro podremos limitar el acceso al servidor y permitirlo solo a través de dicha VPN, lo que reduce enormemente las posibilidades de un ataque. Lo ideal es conectarse a través de una VPN, pero si por lo que sea no disponéis de una entonces al menos no utilicéis el puerto por defecto, el 3389, para la conexión. Cambiando este puerto se logra reducir un poco el número de ataques automatizados, aunque no es una solución ideal pues el atacante podría simplemente buscar los puertos a la escucha. También se puede implementar un filtrado por IP en el cortafuegos, pero es algo que solo recomendaría para empresas que cuenten con una IP fija, para el teletrabajo no acaba de ser una solución práctica pues la mayoría de conexiones domésticas utilizan direcciones IP dinámicas.

Cifrar la tarjeta SD en nuestro teléfono

Cuando ayer hablaba de apps de ciberseguridad para Android comentaba entre otras buenas prácticas de seguridad la idea de cifrar la tarjeta SD del dispositivo. Me habéis preguntado cómo se hace esto y por qué habría que hacerlo.

El por qué es simple: si alguien te roba tu teléfono puede que no sea capaz de desbloquearlo si lo has protegido con un patrón, datos biométricos, código pin, etc. pero si saca la tarjeta SD y la mete en otro dispositivo entonces podrá ver todo lo que hay en ella. ¿Ventajas de cifrarla? Mayor seguridad, si te roban el teléfono esos datos están protegidos, acceder a ellos es muy difícil, puede que no imposible pero sí muy complicado ¿Contras? Dos: una pequeña pérdida de rendimiento cuando accedas a la tarjeta que será más o menos significativa según la potencia del teléfono y, sobre todo, que una vez cifrada si se te estropea el teléfono no voy a decir que sea imposible recuperar esos datos, pero estás en la misma situación que el atacante: es complicado.

¿Cómo se cifra una tarjeta SD en Android?

Bueno, como siempre con Android dependemos mucho del fabricante y de la versión del sistema operativo. Como algo genérico diré que esa opción siempre va a estar en los ajustes del teléfono, donde deberemos buscar los que sean relativos a seguridad y dentro de los mismos deberíamos encontrar alguna referencia a la tarjeta SD.

Por ejemplo, en mi actual teléfono Samsung con Android 11 habría que ir a los Ajustes, allí a Datos Biométricos y Seguridad y dentro de ese menú ya aparece una opción que es Cifrar Tarjeta SD. Esto no era exactamente igual en mi anterior teléfono, un Huawei con Android 10, en el que para cifrar la tarjeta SD habría que ir a Ajustes, allí pulsar en Seguridad, dentro de ese menú ir a Ajustes adicionales, después apretar sobre Cifrado y credenciales y finalmente Cifrar tarjeta de memoria. Como véis esta opcion estará en el apartado de seguridad del teléfono, pero según el fabricante estará más accesibe o menos. En todo caso, seguramente en la web del fabricante del teléfono tendréis un manual de instrucciones de vuestro dispositivo en el que vendrán detalladas las instrucciones concretas para hacerlo en ese modelo.

Obtener nuestra IP externa desde el terminal de Linux usando el comando dig

Bueno, si ya vimos ayer cómo obtener nuestra IP externa desde el PowerShell de Windows y anteriormente desde Linux con cURL y con wget, hoy vamos a ver unha tercera forma de hacer esto desde Linux: con el comando dig (acrónimo de Domain Information Groper).

Para este ejemplo nos serviremos del servicio de OpenDNS, aunque también podría hacersce con otros como el de Google, Cloudflare o el de Ipify que usamos ayer. Básicamente tendríamos que usar este comando:

dig +short myip.opendns.com @resolver1.opendns.com

¿Y si queremos usarlo en un script? Pues basta con meter la respuesta que capturamos en una variable:

miDirIp="$(dig +short myip.opendns.com @resolver1.opendns.com)"

Conocer nuestra IP externa desde línea de comandos en Windows, usando PowerShell

En el pasado vimos cómo podíamos descubrir nuestra IP externa desde línea de comandos en Linux, sirviéndonos tanto de cURL como del comando wget. Como ahora ya todos sabéis que soy un apaniaguado del Tito Bill vamos a ver cómo hacerlo con el PowerShell de Microsoft.

Como siempre, cuando se trata de la IP externa, tenemos que recurrir a un servicio web externo. Hay un buen montón de opciones para esto, pero por comodidad (comodidad para mí, porque ya tengo las pruebas hechas con ese) recurriremos a https://api.ipify.org

En PowerShell podemos usar el cmdlt Invoke-WebRequest para lanzar peticiones http y https a una web y recoger su respuesta. Si llamamos al api que os ponía arriba obtendremos nuestra IP.

Invoke-WebRequest -uri "https://api.ipify.org/"

¿Y ya está? Pues no, porque eso nos devolverá como texto plano además de la IP el status de la respuesta y las cabeceras, por lo que aunque podemos leer la IP sería incómodo trabajar con ella. Pero por suerte el cmdlt nos permite filtrar y obtener solo el valor que nos interesa. Tal que así:

(Invoke-WebRequest -uri "https://api.ipify.org").content

De esa forma sí que obtendríamos solo la línea con el valor de la IP, ya que accedemos únicamente al contenido de la respuesta, al valor de content. Si quisiéramos meter el valor de la IP en una variable para trabajar con un script podríamos hacerlo tal que así:

$miDirIP = (Invoke-WebRequest -uri "https://api.ipify.org/").Content

Linux: matar procesos usando Kill, Pkill y Killall

Linux nos da tres opciones para matar procesos desde el terminal: kill, pkill y killall.

Antes de ver los tres comandos es importante recordad un punto: un usuario normal solo puede matar sus procesos, no los procesos del sistema o los de otro usuario. Un usuario root en cambio sí puede matar cualquier proceso, tanto del sistema como de otro. Realmente, a pesar de sus nombres, estos tres comandos no están pensados exclusivamente para matar procesos, sino que les pueden enviar todo tipo de señales, aunque sí es cierto que matar procesos es el comportamiento por defecto.

El comando kill nos permite matar un proceso identificándolo por su número identificador (PID), la sintaxis básica es kill -señal PID. El valor de la señal varía entre 64 posibilidades, siendo las que permiten matar procesos estas tres: SIGHUP (que se abrevia también con el valor numerico 1), SIGKILL(que se abrevia con el valor numérico 9) o SIGTERM(que se abrevia con el valor numérico 15). Si no ponemos ningún valor el tomado por defecto será 15, que es el más seguro pues no permite que se mate un proceso que esté en ejecución sino que espera a que termine y lo mata en ese momento, mientras que el valor 9 sería el más inseguro y contundente, mata al proceso incluso aunque esté ocupado. En el ejemplo siguiente veremos como matar un proceso que, por ejemplo, tenga el id 2015, primero con el valor por defecto y luego con la opción -9 o SIGKILL (las dos últimas sería la misma instrucción pero con distinta sintaxis):

kill 2015
kill -SIGKILL 2015
kill -9 2015

También podemos matar varios procesos en la misma instrucción. Imaginemos que queremos matar los procesos 2015, 2022 y 3049, solo tenemos que listarlos tras la instrucción kill separados por un espacio:

kill 2015 2022 3049

Si no queremos estar listando los procesos para poder ver sus PID podemos también matar un proceso por su nombre. Eso lo puedes hacer con el comando killall, que lo que hará será matar todos los procesos que coincidan con el nombre del comando. Imagina que quieres matar el proceso de mysql en tu servidor Linux, de esta forma lo harías, pero ojo porque si tienes varias instancias las mataría todas. Las señales para killall son distintas de las de kill, puedes listarlas ejecutando killall -l aunque coincide que el valor -9 también es el que podemos usar para matar el proceso de forma forzosa.

killall -9 mysql

Finalmente nos queda pkill, un comando que fue creado originalmente para el sistema operativo Solaris y cuyo funcionamiento es similar al de killall, la diferencia es que en este caso no necesitamos saber todo el nombre del proceso pues podemos usar exprexiones regulares para definir qué proceso queremos parar. Igual que en el ejemplo anterior veamos cómo terminaríamos el proceso de mysql, con el parámetro -e para que la consola nos informe de que lo ha eliminado.

pkill -e mysql

Crear un certificado autofirmado con OpenSSL

Ya habíamos hablado anteriormente de OpenSSL, vamos a ver hoy cómo podríamos generar un certificado autofirmado. Vamos a generarlo con cifrado SHA512 y con clave RSA de 4096 bits, que se llamarán micerautofirm.key y micert.pem (el nombre lo podeís poner vosotros).

openssl req -x509 -sha512 -nodes -newkey rsa: 4096 -keyout micerautofirm.key -out micert.pem

Este certificado autofirmado tiene validez por un mes. Si queréis uno para más tiempo podéis utilizar el parámetro -days y pasarle un entero con el número de días. Por ejemplo, para un año:

openssl req -x509 -sha512 -nodes -days 365 -newkey rsa: 4096 -keyout micerautofirm.key -out micert.pem

Script de PowerShell para enviar un correo con Gmail

Un compañero necesitaba un script de PowerShell que enviase un correo con un texto concreto desde su dirección de email a otra dirección fija, pero no lograba que funcionase correctamente utilizando su cuenta de Gmail. En su día por aquí, ya hace años, hablamos sobre cómo enviar correos desde una cuenta de Gmail usando PHPMailer, así que durante la hora de comer le he echado una mano y he hecho algo sirviéndome del cmdlet Send-MailMessage:

$username   = 'tucorreo@gmail.com'
$password   = 'tupassword'
$secstr     = New-Object -TypeName System.Security.SecureString
$password.ToCharArray() | ForEach-Object {$secstr.AppendChar($_)}

$brocolharum = @{
    from       = "tucorreo@gmail.com"
    to         = "correoquerecibe@gmail.com"
    subject    = "Danger Danger, high voltage!"
    smtpserver = "smtp.gmail.com"
    port       = "587"
    body       = "Si te estás leyendo esto me debes un capuccino con licor de avellana"
    credential = New-Object -typename System.Management.Automation.PSCredential -argumentlist $username, $secstr
    usessl     = $true
    verbose    = $true
    DeliveryNotificationOption = "OnFailure"
}

Send-MailMessage @brocolharum

Se trata de un ejemplo muy básico, después podéis adaptarlo a vuestras necesidades.