miércoles, 23 de septiembre de 2020

Qué es y cómo apuntarse a Windows Insider



¿Qué es Windows Insider? ¿Cómo enrolar un ordenador al programa?



Windows Insider es una iniciativa de Microsoft destinada a los usuarios de Windows que permite a quien esté apuntado en ella probar versiones preliminares (o nuevas características) del sistema operativo Windows antes de que estas sean lanzadas al gran público. A cambio, Microsoft pide a los Insiders sus opiniones respecto a las nuevas funcionalidades de cara a mejorar el producto.

Este programa fue anunciado el 30 de septiembre de 2014 junto con Windows 10. A finales de ese mismo año, alrededor de 1,5 millones de personas ya se habían instalado la primera preview de la siguiente build de Windows 10 y ya estaban flighting.


Flighting



Flighting es un término inventado por el departamento de marketing de Microsoft usado para denominar el proceso de ejecutar las compilaciones de Windows 10 Insider Preview. Este proceso incluye:

• Configurar nuestro dispositivo en uno de los canales de Windows Insider.
• Instalar las actualizaciones preview (de vista previa) de ese canal.
• Ejecutar y probar esas compilaciones previas.


Canales



Microsoft divide el programa Insider en 5 canales, donde 2 de ellos son sólo para uso interno, es decir, solo visibles por sus empleados.

El primer canal se llama Canary, y es donde los desarrolladores de Microsoft proponen y prueban por primera vez nuevas funciones para Windows.

Una vez creada una nuva función, esta llega al canal Dev y se libera al público para que de su feedback.

Una vez testeadas en el canal Dev, las actualizaciones vuelven a un canal interno, el canal Microsoft, donde además de los desarrolladores, el resto de empleados de Microsoft pueden también probarlas.

Una vez pulidas por los programadores tras el feedback recibido desde Dev, las actualizaciones pasan del canal Microsoft al canal Beta, volviendo a ser públicas.

En última instancia, las actualizaciones llegan al canal "Release Preview", donde los Insiders reciben las próximas actualizaciones acumulativas unos días antes de su lanzamiento oficial, para acabar de pulir incompatibilidades o problemas derivados de hardware poco común.

No hace falta decir que al canal Dev llegan muchas más actualizaciones que al canal Beta, pero cuando las actualizaciones llegan al canal Beta, estas ya han sido pulidas y funcionan mejor que cuando llegaron a Dev. Por último, las Release Preview apenas recibirán builds, aunque días antes de que se lance una gran actualización se envían allí para que puedan ser probadas anticipadamente por los Insiders.


Ventajas y desventajas



La ventaja principal de este programa es la posibilidad de ser una de las primeras personas en probar cada nueva función de Windows. Otra ventaja de Insider es que siendo miembro del programa tienes Windows gratis, pues una vez que inscritos en el programa podemos descargarnos la ISO de la última build disponible de Windows dntro del programa.

En el otro lado se encuentra la inestabilidad que puede padecer un PC al usar versiones no finales de un producto, con culegues ocasionales y problemas varios.


Cómo apuntarse a Windows Insider



Para apuntarse a Windows Insider, hace falta un ordenador con Windows 10.

Ir a Inicio, botón derecho y clic en configuración:


Una vez allí, ir a Actualización y seguridad y luego a Programa Windows Insider:


A continuación, clicar el botón "Comenzar" y acto seguido, vincular una cuenta:


Nos registramos en el programa Windows Insider y aceptamos las condiciones de uso:


Y por último, elegimos el canal que queramos probar.


A partir de este momento, ya recibiremos las actualizaciones lanzadas desde el canal seleccionado.


Fuentes:

https://insider.windows.com/es-es/
0

miércoles, 16 de septiembre de 2020

Rutas estáticas persistentes en SLES



Cómo crear (y eliminar) rutas estáticas persistentes en un SUSE Linux Enterprise Server.



Si añadimos una ruta estática a un SUSE Linux Enterprise Server con el comando ip route add y reiniciamos la máquina después, comprobaremos que las rutas añadidas de esta manera se pierden tras un reinicio, es decir, son temporales.

Para añadir rutas estáticas persistentes a un SLES, es decir, rutas que se mantengan en el sistema operativo tras reiniciar la máquina, deberemos editar dos archivos: /etc/sysconfig/network/routes y /etc/sysconfig/network/ifroute-* y añadirlas en uno de ellos.


Archivos



La tabla de rutas persistentes de un SUSE Linux Enterprise Server se encuentra en el archivo:

/etc/sysconfig/network/routes

Adicionalmente, se pueden añadir rutas a un adpatador específico editando un archivo del tipo:

/etc/sysconfig/network/ifroute-*

Es decir, si tenemos un adaptador llamado eth0 configurado en el archivo ifcfg-eth0, podemos crear rutas estáticas que afecten solamente a este adaptador editando el archivo:

/etc/sysconfig/network/ifroute-eth0


Añadir ruta estática



Las entradas en los archivos de configuración de enrutamiento pueden seguir uno de estos 3 patrones:

DESTINO GATEWAY MÁSCARA INTERFAZ
DESTINO GATEWAY PREFIJO INTERFAZ
DESTINO/PREFIJO GATEWAY INTERFAZ

Para omitir el GATEWAY, MÁSCARA o PREFIJO escribir - (guión).

El destino siempre se escribe en la primera columna. Este puede ser tanto un host como una red, así como un FQDN que la máquina sepa resolver (por ejemplo, host.dominio.com).

La segunda columna contiene el gateway (desde donde se enviará el tráfico al destino).
La palabra clave default, por su parte, indica que la ruta usa la puerta de enlace predeterminada.

La tercera columna está obsoleta; solía contener la máscara de red IPv4 del destino, del tipo máscara (por ejemplo 255.255.255.0) o prefijo (/24). Hoy en día se usa una combinación de host o red con su prefijo directamente en la primera columna. Por ejemplo, 192.168.0.0/16 para IPv4 o fc00::/ 7 para IPv6.

Por último, la cuarta columna nos indica la interfaz a usar.


Mostrar rutas



Hay dos formas de visualizar las rutas estáticas persistentes de un sistema: por comando o por archivo.

Podemos usar el comando ip route show para ver las rutas estáticas configuradas en un sistema:

HOST# ip route show default via 192.168.4.1 dev eth0 192.168.4.0/24 dev eth0 proto kernel scope link src 192.168.4.2 192.168.7.0/24 dev eth1 proto kernel scope link src 192.168.7.2

(Recordar que el comando ip route sustituye el antiguo comando netstat -nr).

De otro modo, podemos mirar el contenido de uno de los archivos mencionados anteriormente:

HOST# cat /etc/sysconfig/network/routes 192.168.4.0 192.168.4.1 255.255.255.0 eth0 192.168.7.0 192.168.7.1 255.255.255.0 eth1

Sea cual sea el método elegido, deberíamos ver las mismas rutas.


Eliminar ruta estática



Para eliminar alguna ruta, basta simplemente con borrarla del archivo en cuestión.


Fuentes:

https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-network.html#sec-network-man...
https://www.novell.com/documentation/suse91/suselinux-adminguide/html/ch14s05.html
0

miércoles, 9 de septiembre de 2020

Especificar IP de origen desde proxy NGINX



Cómo enviar peticiones desde una IP de origen concreta en un proxy inverso NGINX.



Puede que tengamos un servidor web que solo acepte conexiones de un determinado rango IP y que tengamos un NGINX por delante actuando de reverse proxy que no disponga de una IP de ese rango o que sí disponga de ella, pero no la use a la hora de enviar tráfico a dicho servidor, por lo que los paquetes no lleguen desde el NGINX al servidor final.

Para solucionar este problema, podemos asignar una IP secundaria a nuestro NGINX y especificar que para ese servidor, usaremos esa IP secundaria como origen a la hora de enviarle tráfico.

Para especificar desde qué IP se envía tráfico hacia un servidor web final, podemos usar la directiva proxy_bind antes de proxy_pass en el bloque location dentro del bloque server de un dominio:

server { server_name dominio1.com; ... location /app1/ { proxy_bind 127.0.0.1; proxy_pass http://example.com/app1/; } } server { server_name dominio2.com; ... location /app2/ { proxy_bind 127.0.0.2; proxy_pass http://example.com/app2/; } }

La dirección IP también se puede especificar con una variable, p.e $server_addr.

Primero declaramos la variable y su valor:

set $server_addr "127.0.0.1";

A partir de aquí, ya la podemos usar dentro de la directiva proxy_bind de cuantos dominios queramos:

server { server_name dominio3.com; ... location /app3/ { proxy_bind $server_addr; proxy_pass http://example.com/app3/; } } server { server_name dominio4.com; ... location /app4/ { proxy_bind $server_addr; proxy_pass http://example.com/app4/; } } ...

De esta forma, podemos usar dicha variable en varios dominios y si algún día cambiamos la IP desde la que se origina el tráfico, no hará falta ir línea por línea cambiando su valor sino que podremos cambiarla una sola vez en la declaración de la variable.


Fuentes:

https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/
0

miércoles, 2 de septiembre de 2020

Acceder a Google Drive desde el escritorio



Cómo acceder a Google Drive desde nuestro explorador de Windows, Mac o Linux.



Google Drive es un servicio de alojamiento de archivos en la nube creado por Google en 2012. Este servicio nos permite disponer de hasta 15 GB por cuenta para guardar fotos, documentos, copias de seguridad, etc. alojados en servidores de Google sin gasto alguno.

Para disfrutar de Google Drive, deberemos usar una cuenta de gmail o vincular una cuenta de correo electrónico existente con Google. Una vez hecho esto, ya podremos usar Google Drive desde el navegador web y/o desde la aplicación de escritorio.

Para acceder a Google Drive desde el escritorio de nuestro ordenador como si de una carpeta más del sistema se tratara, deberemos descargar "Backp and Sync" (Copia de seguridad y sincronización) desde:

https://www.google.com/intl/es-419_ALL/drive/download/backup-and-sync/

Al inicio de la instalación, el programa nos pide iniciar sesión a nuestra cuenta Google:



Luego debemos elegir si queremos maneter sincronizadas las carpetas de fotos, vídeos y documentos de nuestro sistema operativo o si queremos mantener Google Drive como una carpeta independiente:



A continuación, y muy importante, debemos marcar "sincronizar mi unidad con este ordenador". Si no lo marcamos, no veremos los cambios que hagamos en nuestro PC en el Drive ni viceversa.



Una vez hecho esto, ya podremos acceder a nuestros archivos contenidos en el Drive como si de una carpeta más del ordenador se tratase:



Solo recordar que el límite de espacio del plan gratuito para este servicio es 15 GB.
0

miércoles, 26 de agosto de 2020

Incrementar tamaño de / en EC2 Linux



Cómo incrementar el tamaño de la partición raíz ( / ) de un EC2 Linux en Amazon Web Services.



Si tenemos una instancia Linux en AWS, puede pasarnos que nos quedemos sin espacio en el disco principal de la máquina y no tengamos más remedio que ampliar el número de GB del disco.

Antes de ampliar la partición raíz, debemos averiguar en qué disco está situada la partición:

ip-10-250-4-103:/home/ec2-user # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 18M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda1 99G 60G 35G 64% / tmpfs 799M 0 799M 0% /run/user/1000

Listamos los discos del sistema con el comando lsblk y encontramos el disco xvda:

ip-10-250-4-103:/home/ec2-user # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 100G 0 disk └─xvda1 202:1 0 100G 0 part /

Ahora ampliamos el espacio del disco xvda desde la consola de AWS.

Volvemos a lanzar el comando lsblk y vemos como xvda ha subido de tamaño:

ip-10-250-4-103:/home/ec2-user # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 250G 0 disk └─xvda1 202:1 0 100G 0 part /

Llegados a este punto, tenemos un disco ampliado, pero la partición raíz sigue igual:

ip-10-250-4-103:/home/ec2-user # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 18M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda1 99G 60G 35G 64% / tmpfs 799M 0 799M 0% /run/user/1000

Ampliamos la partición /dev/xvda1:

ip-10-250-4-103:/home/ec2-user # sudo growpart /dev/xvda 1 CHANGED: partition=1 start=2048 old: size=209713119 end=209715167 new: size=524285919,end=524287967

Comprobamos que haya cogido el nuevo espacio asignado:

ip-10-250-4-103:/home/ec2-user # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 250G 0 disk └─xvda1 202:1 0 250G 0 part /


EXT4



Si el disco está particionado con EXT4, usamos resize2fs para acabar de ampliar la partición raíz:

ip-10-250-4-103:/home/ec2-user # sudo resize2fs /dev/xvda1 resize2fs 1.42.11 (09-Jul-2014) Filesystem at /dev/xvda1 is mounted on /; on-line resizing required old_desc_blocks = 7, new_desc_blocks = 16 The filesystem on /dev/xvda1 is now 65535739 blocks long.

Vemos como la partición raíz ya ve el nuevo espacio en disco:

ip-10-250-4-103:/home/ec2-user # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 18M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda1 246G 60G 177G 26% / tmpfs 799M 0 799M 0% /run/user/1000


XFS



Si ampliamos una partición no EXT4 usando el comando resize2fs veremos el siguiente error en pantalla:

ip-10-250-4-94:/home/ec2-user # sudo resize2fs /dev/xvda2 resize2fs 1.43.8 (1-Jan-2018) resize2fs: Bad magic number in super-block while trying to open /dev/xvda2 Couldn't find valid filesystem superblock.

Buscamos el tipo de partición del sistema operativo:

ip-10-250-4-94:/home/ec2-user # df -Th Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 3.9G 0 3.9G 0% /dev tmpfs tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs tmpfs 3.9G 375M 3.6G 10% /run tmpfs tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda2 xfs 100G 58G 42G 58% / /dev/xvda1 xfs 297M 90M 208M 31% /boot tmpfs tmpfs 797M 0 797M 0% /run/user/1000

Vemos que es XFS. Usamos xfs_growfs para ampliar nuestra partición raíz:

ip-10-250-4-94:/home/ec2-user # sudo xfs_growfs -d / meta-data=/dev/xvda2 isize=512 agcount=42, agsize=636096 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=0 spinodes=0 rmapbt=0 = reflink=0 data = bsize=4096 blocks=26137339, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 data blocks changed from 26137339 to 65458939

Ahora ya vemos el nuevo espacio en la partición raíz:

ip-10-250-4-94:/home/ec2-user # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 375M 3.6G 10% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda2 250G 58G 192G 24% / /dev/xvda1 297M 90M 208M 31% /boot tmpfs 797M 0 797M 0% /run/user/1000


Fuentes:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html
0

miércoles, 19 de agosto de 2020

Qué es un bind mount y cómo crearlo en Linux



¿Qué es un bind mount? ¿Qué diferencia hay entre un bind mount y un enlace simbólico?



Los montajes "bind" (bind mounts) de Linux permiten montar una ruta del sistema de archivos en otra ubicación, es decir, hacen que dos rutas vayan al mismo directorio. Se suelen usar para restringir el acceso de usuarios específicos a ciertas rutas de un servidor.

Por ejemplo, si queremos que un usuario sólo pueda acceder a una ruta específica vía SFTP y esta muestre archivos contenidos en otra parte del sistema, podemos usar un bind mount, lo cual le permitirá al usuario ver los archivos de esa ruta a la que no tendría acceso de otra forma.


Configurar bind mount



Para crear un bind mount, debemos usar la siguiente sintaxis:

HOST# mount --bind /ruta/original/ /nueva/ruta

Tambien podemos usar esta otra sintaxis:

HOST# mount -o bind /ruta/original/ /nueva/ruta

Una vez hecho esto, cada vez que nos dirijamos a /nueva/ruta, veremos los archivos situados en /ruta/original, como si hubieramos accedido a /ruta/original.


Montaje persistente



Cuando reiniciemos la máquina, los bind mount se perderán. Para hacerlos persistentes (perdurables después de reinicios), deberemos editar el archivo /etc/fstab del sistema y decirle a este que los monte:

/ruta/original /nueva/ruta none bind,nobootwait 0 0

Agregar nobootwait a la sección de opciones de la configuración de fstab garantiza que el sistema se inicie incluso si el directorio original se ha eliminado del sistema.


Diferencias entre bind mount y enlaces simbólicos



Un enlace simbólico es un inodo que apunta a un determinado objeto del sistema de archivos. Por otro lado, si se monta un directorio con un bind mount, se crea un segundo punto de montaje para un directorio ya existente dentro del sistema de archivos.

Si un enlace simbólico se podría ver como una redirección, un bind mount se podría ver como otra puerta de enlace a los datos de un directorio ya existente.

Varios programas pueden distinguir entre enlaces simbólicos y directorios o archivos reales. Pocos pueden distinguir entre un directorio o archivo y el que está montado en él (bind mount). Un software de backup, por ejemplo, creará dos copias de cada archivo ubicado en un directorio doblemente montado mediante bind mount, ya que tratará a ambos directorios como rutas independientes.

En un chroot, por su parte, si el objetivo del enlace está fuera del chroot, el enlace simbólico quedará muerto. El bind mount, en cambio, funcionará y permitirá que se acceda a los datos ubicados fuera del chroot. Además, los enlaces simbólicos sobreviven a un reinicio mientras que los mount bind no lo hacen a menos que se edite /etc/fstab para hacerlos persistentes.

Por último, los bind mount permiten un acceso más rápido a su destino que los enlaces simbólicos.


Fuentes:

https://support.rackspace.com/how-to/bind-mounts-in-linux/
https://serverfault.com/questions/613179/how-do-i-do-mount-bind-in-etc-fstab
https://unix.stackexchange.com/questions/53456/what-is-the-difference-between-nobootwait...
0

miércoles, 12 de agosto de 2020

Enviar e-mail usando telnet



Cómo conectarnos a un servidor SMTP y enviar un e-mail usando telnet, paso a paso.



Podemos probar la conectividad o el funcionamiento de un servidor SMTP mediante el uso de telnet, tanto desde Windows como desde Linux. Para ello, deberemos conectarnos al servidor SMTP y ejecutar una serie de instrucciones que nos servirán para poder enviar un e-mail de prueba.

Veamos los pasos uno a uno.

Para conectarnos al servidor SMTP de turno, normalmente deberemos conectarnos al puerto 25:

telnet smtp.dominio.com 25

El siguiente paso es saludar al servidor. Para ello debemos escribir HELO smtp.dominio.com, reemplazando smtp.dominio.com por el nombre del servidor.

HELO smtp.dominio.com 250 smtp.dominio.com Hello smtp.dominio.com ([1.2.3.4]), pleased to meet you

Si aparece un mensaje de error, probar con EHLO en lugar de HELO.

A continuación, debemos especificar el remitente (quien envía el mail) con el comando:

MAIL FROM: remitente@dominio.com

MAIL FROM: remitente@dominio.com 250 remitente@dominio.com... Sender OK

Ahora toca especificar el destinatario escribiendo:

RCPT TO: destinatario@dominio.com

RCPT TO: destinatario@dominio.com 250 destinatario@dominio.com... Recipient OK

Para redactar el cuerpo del mensaje, debemos empezar ejecutando el comando DATA:

DATA 354 Enter message, end with "." on a line by itself

En la siguiente línea, escribir "SUBJECT: " y el asunto del mail:

SUBJECT: prueba

Tras pulsar enter, ya podemos escribir el mensaje. Cuando acabemos, habrá que pulsar enter de nuevo.

Para terminar, escribir . y presionar Enter. En este punto, deberá aparecer un mensaje confirmando si el correo se aceptó o se agregó a la cola. Este mensaje varía según el servidor.

SUBJECT: prueba probando . 250 Message accepted for delivery

Todo seguido sería:

telnet smtp.dominio.com 25 Trying smtp.dominio.com... Connected to smtp.dominio.com. Escape character is '^]'. 220 smtp.dominio.com ESMTP Service (IBM Domino Release 9.0.1FP3 H HELO smtp.dominio.com 250 smtp.dominio.com Hello smtp.dominio.com ([1.2.3.4]), pleased to meet you MAIL FROM: remitente@dominio.com 250 remitente@dominio.com... Sender OK RCPT TO: destinatario@dominio.com 250 destinatario@dominio.com... Recipient OK DATA 354 Enter message, end with "." on a line by itself SUBJECT: prueba probando . 250 Message accepted for delivery Connection closed by foreign host.

Una vez aceptado el mensaje, puede que el servidor cierre la conexión automáticamente o que tengamos que cerrarla manualmente con el comando quit.
0

miércoles, 5 de agosto de 2020

Ver qué dominio valida un certificado SSL



Ver qué dominios asegura un certificado SSL con extensión .crt o .pem.



Si nos descargamos un certificado de una autoridad certificadora como por ejemplo GoDaddy, obtendremos un archivo con un nombre parecido a:

3d8b2wfe3454e.crt

Este archivo es la parte privada de un certificado SSL, el cual es usado para securizar las conexiones HTTPS de un dominio determinado.

Si acumulamos varios archivos de este tipo sin renombrarlos, puede que en un momento dado no sepamos a qué dominio hace referencia un determinado archivo .crt. Para averiguar a qué dominio hace referencia un archivo concreto, podemos usar la utilidad openssl del siguiente modo:

openssl x509 -text -in archivo.crt

Donde archivo.crt es el nombre del archivo a verificar.

El resultado de este comando producirá un output similar a este:

HOST# openssl x509 -text -in archivo.crt Certificate: Data: Version: 3 (0x2) Serial Number: ac:42:57:06:12:67:98:e7 Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate Authority - G2 Validity Not Before: Mar 27 10:27:18 2019 GMT Not After : Mar 27 10:27:18 2021 GMT Subject: OU = Domain Control Validated, CN = dominio.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: ...

Nos debemos fijar en la línea que dice:

Subject: OU = Domain Control Validated, CN = dominio.com

Donde "CN =" muestra el dominio para el cual es válido el certificado.

También podemos buscar el apartado siguiente:

... X509v3 Subject Alternative Name: DNS:dominio.com, DNS:www.dominio.com ...

En el apartado "X509v3 Subject Alternative Name" se nos muestra también el dominio al que hace referencia el archivo. Concatenando un grep, podemos ir directos al dominio:

HOST# openssl x509 -text -in archivo.crt | grep DNS DNS:dominio.com, DNS:www.dominio.com

En definitiva, usando openssl y filtrando por "DNS" o por "Domain Control Validated" veremos rápidamente el dominio que valida un archivo .crt (la parte privada de un certificado SSL).


Fuentes:

https://security.stackexchange.com/questions/134245/how-to-verify-which-for-domains-if-any-is...
0

miércoles, 29 de julio de 2020

Obtener nombres propios dados los 'user logon names' o samAccountName en Active Directory



Cómo obtener el nombre de una persona teniendo su nombre de usuario de Active Directory.



Si tenemos el nombre de usuario de varias personas y queremos saber rápidamente cual es el nombre completo de cada una de ellas, podemos usar un pequeño script de PowerShell.

A continuación, muestro un par de scripts que nos permiten recuperar el nombre completo dado un nombre de usuario sobre un directorio activo corriendo en Windows Server 2016 o superior.

Imaginemos que tenemos una lista de usuarios llamada users.txt con nombres de usuario, por ejemplo, jgarcia, jtorres, mvarela, etc. uno en cada línea. Para extraer sus nombres completos de Active Directory podemos usar el siguiente script:

$List = Get-Content ".\users.txt"
ForEach ($User in $List) {
Get-ADUser -Filter "SamAccountName -eq '$User'" | Select-Object samaccountname, name
} 

El output del script será:

PS C:\Temp> C:\Temp\script.ps1 samaccountname name -------------- ---- jgarcia Juan Garcia jtorres Javier Torres mvarela Marta Varela agutierrez Álvaro Gutiérrez mperez Martín Pérez

De esta forma veremos el output en la terminal, pero ¿qué ocurre si queremos exportar el resultado a un archivo, como por ejemplo, un csv?

Con el siguiente script podemos escribir los nombres propios y los user logon name en un csv:

$aResults = @()
$List = Get-Content ".\users.txt"
ForEach($Item in $List){
$Item = $Item.Trim()
$User = Get-ADUser -Filter "SamAccountName -eq '$Item'" | Select-Object samaccountname, name
$hItemDetails = New-Object -TypeName psobject -Property @{
FullName = $Item
UserName = $User.SamAccountName
}
#Add data to array
$aResults += $hItemDetails
}
$aResults | Export-CSV ".\Results.csv"

Podemos modificar el script para escribir solo los nombres propios en el archivo, si así lo necesitamos, quitando el parámetro SamAccountName del selector Select-Object.


Fuentes:

https://docs.microsoft.com/en-us/powershell/module/addsadministration/get-aduser?view=win10-ps

miércoles, 22 de julio de 2020

Tipos de red móvil



¿Qué significa que una conexión de red móvil sea H, H+, 3G, 4G o 5G?



En la parte superior de la pantalla de un teléfono móvil aparece, además de la hora y el nivel de batería, una sigla que nos indica la velocidad de conexión de la que dispone ese dispositivo en esa ubicación.


Esta sigla puede ser G, E, 3G, H, 4G... Cada una hace referencia a un tipo de conexión y velocidad.
Vamos a ver las diferencias entre cada una de ellas, ordenadas de más lenta a más rápida.

G

La letra G representa una conexión GPRS, es decir, la calidad de conexión más baja que puede usar un teléfono móvil. Su velocidad de navegación oscila entre los 56 y los 144 KB/s.

E

La conexión EDGE es una versión mejorada del GPRS la cual permite usar algunas aplicaciones livianas como WhatsApp o Telegram. Su velocidad es de 384 KB/s.

3G

3G es una red de tercera generación. Fue creada para transmitir voz y datos y su velocidad oscila entre los 384 KB/s y 2 MB/s, por lo que permite navegar por internet sin problemas.

H

La letra H representa la conexión HDSPA o 3.5G. Esta conexión llega a 14 MB/s de bajada y entre 386 KB/s y 5.76 MB/s de subida.

H+

Esta conexión equivale a 3.8 G, con una velocidad constante de descarga de 84 MB/s y una velocidad de subida de 22 MB/s.

4G o LTE

4G es la red de cuarta generación. Su velocidad ronda los 100 MB/s de descarga y los 50 MB/s de subida, aunque en zonas urbanas estos números pueden ser mayores.

4G+

4G+ es la etapa intermedia entre 4G y 5G. La velocidad de esta conexión es el doble o triple que el 4G convencional, según la zona.

5G

El 5G es la quinta generación de red móvil. Permite una velocidad de descarga de hasta 10 GB/s.


Fuentes:

https://www.xataka.com.mx/movistar4glte/h-h-lte-que-significan-estos-simbolos-en-la-pantalla-de...
https://larepublica.pe/tecnologia/2020/07/18/smartphone-que-significan-las-letras-e-h-h-3g-4g...
0

miércoles, 15 de julio de 2020

Backups de volúmenes de AWS desde CLI



Cómo crear backups de volúmenes EBS de instancias EC2 de AWS desde CLI.



Si usamos AWS, puede resultar interesante crear bakups / snapshots / copias de seguridad del disco principal de una instancia EC2 mediante CLI desde un Linux o Windows que tengan el AWS CLI instalado.

Para crear un snapshot del volumen de una instancia desde CLI, es interesante parar primero la instancia para evitar que se escriban datos al disco mientras se realiza la copia.

Para parar una instancia EC2 desde CLI, buscamos primero la ID de la instancia usando su tag "Name" (en este caso, busco la instance ID de una instancia llamada Test1):

[ec2-user@ip-10-5-0-143 ~]$ aws ec2 describe-instances --filters 'Name=tag:Name,Values=Test1' --query 'Reservations[0].Instances[0].InstanceId' "i-04aebf98625bacce4"

Hemos obtenido el instance ID "i-04aebf98625bacce4".

Ahora buscamos el volume ID del disco EBS de la instancia Test1:

[ec2-user@ip-10-5-0-143 ~]$ aws ec2 describe-instances --filter 'Name=tag:Name,Values=Test1' --query 'Reservations[0].Instances[0].BlockDeviceMappings[0].Ebs.{VolumeId:VolumeId}' { "VolumeId": "vol-0b2efa7e024e758e5" }

Paramos la instancia:

[ec2-user@ip-10-5-0-143 ~]$ aws ec2 stop-instances --instance-ids i-04aebf98625bacce4 { "StoppingInstances": [ { "InstanceId": "i-04aebf98625bacce4", "CurrentState": { "Code": 64, "Name": "stopping" }, "PreviousState": { "Code": 16, "Name": "running" } } ] }

Miramos si ya está apagada la instancia:

[ec2-user@ip-10-5-0-143 ~]$ aws ec2 wait instance-stopped --instance-id i-04aebf98625bacce4

Creamos un snapshot del volumen:

[ec2-user@ip-10-5-0-143 ~]$ aws ec2 create-snapshot --volume-id vol-0b2efa7e024e758e5 { "Description": "", "Tags": [], "Encrypted": false, "VolumeId": "vol-0b2efa7e024e758e5", "State": "pending", "VolumeSize": 8, "StartTime": "2020-06-17T10:45:11.000Z", "Progress": "", "OwnerId": "077455710323", "SnapshotId": "snap-0f2af28035ea778e5" }

Miramos si ya ha acabado el proceso:

[ec2-user@ip-10-5-0-143 ~]$ aws ec2 wait snapshot-completed --snapshot-id snap-0f2af28035ea778e5

Ya podemos iniciar la instancia:

[ec2-user@ip-10-5-0-143 ~]$ aws ec2 start-instances --instance-ids i-04aebf98625bacce4 { "StartingInstances": [ { "InstanceId": "i-04aebf98625bacce4", "CurrentState": { "Code": 0, "Name": "pending" }, "PreviousState": { "Code": 80, "Name": "stopped" } } ] }

Por último, podemos mirar qué snapshots hay del volumen de esta instancia en nuestra cuenta:

[ec2-user@ip-10-5-0-143 ~]$ aws ec2 describe-snapshots --filters "Name=volume-id,Values=vol-0b2efa7e024e758e5" { "Snapshots": [ { "Description": "", "Encrypted": false, "VolumeId": "vol-0b2efa7e024e758e5", "State": "completed", "VolumeSize": 8, "StartTime": "2020-07-15T10:50:02.036Z", "Progress": "100%", "OwnerId": "077455710323", "SnapshotId": "snap-0c9062daba8a9f4f7" } ] }

Vemos que tenemos un snapshot del volumen de la instancia con fecha de hoy. Misión cumplida.


Fuentes:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
0

miércoles, 8 de julio de 2020

Arrancar YaST2 en modo gráfico vía X11



Cómo acceder al YaST2 de un SLES en modo gráfico desde Windows.



Alguien me pidió acceso al entorno gráfico de un SUSE Linux Enterprise Server para instalar cierto software mediante YaST2. El servidor en cuestión no tenía entorno gráfico instalado y el usuario no quería usar YaST2 en modo texto, así que la única alternativa para arrancar YaST2 en modo gráfico era usar X11 Forwarding vía SSH conectado desde un Windows.


Windows



En Windows, suelo usar PuTTy para realizar conexiones SSH hacia servidores Linux. En él, podemos permitir X11 Forwarding en su correspondiente apartado:



Además, debemos instalar algún gestor de ventanas X en Windows como, por ejemplo, Xming.


SUSE



Para poder hacer X11 Forwarding desde un host remoto corriendo SUSE - es decir, para poder visualizar las ventanas de las aplicaciones gráficas de una máquina remota con SUSE desde nuestro PC - primero debemos editar el archivo de configuración de SSH del host remoto:

root@host:~ # vi /etc/ssh/sshd_config

Y configurar el parámetro X11 Forwarding en yes:

X11Forwarding yes

Una vez configurado, reiniciamos el daemon de ssh para aplicar los cambios:

root@host:~ # service sshd restart

Ahora vamos a permitir a la cuenta root ejecutar aplicaciones mediante X11 Forwarding. Para ello, vamos a copiar una cookie de Xorg de un usuario cualquiera hacia root para usarla desde root.

Para permitir a root realizar X11 Forwarding, primero abrimos una shell como un usuario "no root":

root@host:~ # su - usuario

Ahora miramos el valor de la variable DISPLAY:

usuario@host:~> echo $DISPLAY localhost:10.0

Volvemos a root y exportamos el display hallado anteriormente hacia una variable de entorno temporal:

root@host:~ # export DISPLAY=localhost:10

Copiamos la "Xorg authorization cookie" del usuario elegido hacia el home de la cuenta root:

root@host:~ # cp /home/usuario/.Xauthority ~

Activamos las conexiones remotas:

root@host:~ # xhost +local: non-network local connections being added to access control list

Probamos que el X11 Forwarding funcione ejecutando una instancia de algún programa con GUI, como por ejemplo xclock (debemos instalarlo previamente con "zypper in xclock"):

root@host:~ # xclock

Si todo ha ido bien, deberíamos ver algo así en Windows:



Si podemos ver una ventana con xclock, ya podemos ejecutar YaST2 en modo gráfico como root:

root@host:~ # yast2


Fuentes:

https://www.suse.com/c/running-graphical-programs-remotely-root/
0

martes, 30 de junio de 2020

Permitir conexiones UDP a través de NGINX



Permitir tráfico por un puerto UDP a través de un reverse proxy NGINX.



NGINX usado como reverse proxy permite configurar conexiones TCP más allá de HTTP y HTTPS usando políticas stream; permite, por ejemplo, abrir el puerto 25 (TCP) de la máquina donde corre NGINX y redirigirilo hacia el puerto 25 de nuestro servidor de correo.

Aparte de redirigir puertos TCP, NGINX también permite redirigir tráfico de puertos UDP hacia un servidor final usando el mismo recurso que se usa para la pila TCP, es decir, stream. Recordemos que UDP (User Datagram Protocol) es el protocolo usado por aplicaciones no transaccionales como DNS, SNMP, syslog, RADIUS, etc. las cuales podemos pasar a través de NGINX sin ningún problema.

Para poder redigir puertos UDP a través de NGINX necesitamos que este esté compilado con el flag --with-stream (o disponer de NGINX Plus, el cual ya está compilado con este módulo).

Además de compilar NGINX con --with-stream, debemos incluir esta línea en nginx.conf y reiniciar nginx:

load_module lib64/nginx/modules/ngx_stream_module.so;

Esto activa el módulo stream en NGINX.

Una vez hecho esto, ya podemos aceptar peticiones hacia puertos UDP.

Por ejemplo, si queremos mandar tráfico hacia dos servidores DNS ubicados tras un proxy inverso NGINX, debemos crear un bloque stream y usar una configuración tipo:

stream { upstream dns_servers { server 192.168.1.1:53; server 192.168.1.2:53; } server { listen 53 udp; # enviamos el tráfico del puerto 53 UDP hacia el grupo "dns_servers" proxy_pass dns_servers; } }

En el código anterior, vemos un bloque "server" dentro de stream. En él, NGINX acepta peticiones hacia su puerto 53 UDP, que a su vez, se envían al grupo de servidores llamado "dns_servers".

Al mismo tiempo, vemos que el grupo "dns_servers" está formado por 2 servidores "finales" (los servidores DNS) a los cuales se envía tráfico destinado a su puerto 53 (en el bloque upstream no hace falta indicar TCP o UDP). De este modo, el tráfico UDP se enviará a ambos servidores por round robin.

A partir de este momento, al enviar tráfico hacia el puerto 53 UDP de la IP de NGINX, este se enviará por detrás mediante round robin (balanceo equitativo) hacia los servidores finales que hayamos designado, en este caso, a dos servidores DNS.


Fuentes:

https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/#upstream
0

jueves, 25 de junio de 2020

Ver fecha de caducidad de un certificado SSL



Ver la fecha de caducidad de un certificado SSL desde una URL o desde archivos .crt o .pem.



Los certificados SSL caducan y, por tanto, hay que ir renovándolos, ya sea un certificado generado con Let's Encrypt o un certificado comprado a una autoridad certificadora como GoDaddy.

Para renovar los certificados, antes debemos saber qué día caducan. Según si tenemos acceso a los archivos que forman el certificado o no, podemos usar un método u otro para verificar la fecha de caducidad de un certificado SSL asociado a un dominio.


Ver fecha de expiración de un archivo



Para ver la fecha de expiración de un archivo que contenga la clave pública de un certificado, ya sea este crt o pem, podemos usar la utilidad openssl, tanto en Windows como en Linux.

Desde una terminal Linux, podemos ejecutar:

HOST# openssl x509 -enddate -noout -in dominio.com.crt notAfter=Dec 5 11:21:26 2020 GMT

Desde un cmd o PowerShell en Windows, podemos usar:

C:\Users\usuario>openssl x509 -enddate -noout -in dominio.com.crt notAfter=Dec 5 11:21:26 2020 GMT

Si tenemos el certificado contenido en un archivo .p12, debemos convertirlo antes a .pem y luego ejecutar los comandos mencionados anteriormente.


Ver fecha de expiración de una URL



Para ver la fecha de expiración del certificado SSL de un dominio, podemos conectarnos al servidor web donde apunta ese dominio y consultar dicha información usando la utilidad openssl (tanto si es un dominio propio como un dominio ajeno).

Para realizar la consulta, podemos usar este pequeño script hecho en bash:

SITE_URL="dominio.com"
SITE_SSL_PORT="443"

openssl s_client -connect ${SITE_URL}:${SITE_SSL_PORT} \
  -servername ${SITE_URL} 2> /dev/null |  openssl x509 -noout  -dates

Con esta información ya podemos calcular si debemos renovar o no el certificado para ese dominio.
0

miércoles, 17 de junio de 2020

Windows: The system administrator has set policies to prevent this installation



Cómo solucionar este error para poder instalar software en una máquina con Windows.



Tenía que instalar un programa en un Windows Server 2019 corriendo en AWS, por lo que me he bajado su instalador (un archivo .msi) y, al ejecutarlo, me ha aparecido el siguiente error:



The system administrator has set policies to prevent this installation.

Para solucionar este error, he hecho lo siguiente:

Acceder al servidor como administrador.

Clicar Inicio > Ejecutar > gpedit.msc

Una vez en el "Local Group Policy Editor":

1. Ir a Computer Configuration > Administrative Templates > Windows Components > Windows Installer
2. Editar la política "Turn off Windows Installer".
3. En "Turn off Windows Installer" clicar "Enabled".
4. En Options > Disable Windows Installer –> Seleccionar "Never"





Clicar Apply y OK.

Aun en el "Local group policy editor":

1. Expandir Windows Settings > Security Settings > Software Restriction Policies.
2. Clic derecho en "Software Restriction Policies" y clicar "New Software Restriction Policies".
3. Clic derecho en "Enforcement" y clicar "Properties".
4. En Enforcement buscar la opción "Apply software restriction policies to the following users".
5. Seleccionar "All users except local administrators".





Clicar OK.

Cerrar el "Local group policy editor".

Ejecutar cmd como administrador y lanzar el siguiente comando para aplicar la política:

gpupdate /force

A partir de aquí, ya he podido instalar el programa.
0

miércoles, 10 de junio de 2020

SSH sin password entre 2 servidores



Cómo conectarnos desde un servidor Linux origen hacia un servidor Linux destino sin password.



Si necesitamos que un servidor Linux se conecte a otro (o a otro dispositivo con SSH) de forma automática - siguiendo un script, por ejemplo - y no queremos que el servidor destino nos pida password en cada conexión, podemos evitarlo usando un par de claves pública/privada, donde dejamos la parte privada de la clave en el servidor origen e insertamos la parte pública en el servidor destino.

El paquete SSH tiene comandos específicos built-in para facilitarnos esta tarea: ssh-keygen y ssh-copy-id.


En origen



Para crear el par de claves usaremos el comando ssh-keygen en el servidor origen:

HOST# ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: SHA256:56AtFXvBmudpHBDlOfatLM4PSTioipo8gMjdUC4jULZ root@HOST The key's randomart image is: +---[RSA 2048]----+ | .. ... | | .. . + . | | E. o o B | | . + . . B + . | |+ + = . S = . . | |+. o . B X + . | |. + + O o | |.+ . . + o | |=.o.. o.. | +----[SHA256]-----+

Esto nos generará dos archivos en la home del usuario:

- id_rsa: parte privada de la clave.
- id_rsa.pub: parte pública de la clave.

Ahora, copiamos la parte pública de la clave hacia el servidor destino con el comando ssh-copy-id.

En esta primera conexión, se nos pedirá el password del usuario ya que establecemos una conexión SSH inicial para copiar la clave publica:

HOST# ssh-copy-id usuario@destino /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub" /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys Password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'usuario@destino'" and check to make sure that only the key(s) you wanted were added.

A partir de este momento, si ejecutamos ssh usuario@destino en origen, podremos conectar a la máquina destino sin tener que introducir el password del usuario con el que nos conectamos:

HOST# ssh usuario@destino Last login: Mon Jun 8 18:19:54 2020 from origen usuario@destino:~> exit logout Connection to destino closed.

Recordar que no se nos pedirá password al conectarnos desde el usuario X en origen hasta el usuario Y en destino. Si queremos conectarnos desde otro usuario en origen o hacia otro usuario en destino, deberemos volver a generar el par de claves con el usuario que queramos usar en origen y copiar la clave pública hacia la carpeta home del usuario al que nos queremos conectar en destino.

Si no queremos usar un password en la primera conexión, podemos copiar la clave pública manualmente al servidor de destino en vez de usar ssh-copy-id.


En destino (método manual)



Para copiar la clave pública de forma manual:

1. Creamos una carpeta llamada ".ssh" en la carpeta "home" del usuario.
(la carpeta home la podemos sacar de /etc/passwd).
2. Hacemos un chmod a 700 de la carpeta ".ssh".
3. Creamos un archivo llamado "authorized_keys" dentro de la carpeta ".ssh".
4. Hacemos un chmod 600 del archivo "authorized_keys".
5. Copiamos en su interior el contenido de la clave pública (id_rsa.pub) del servidor origen.
0

martes, 2 de junio de 2020

Cambiar tipo de instancia de un servidor en AWS



Cambiar tipo de instancia (CPU y RAM) de una instancia / servidor / máquina virtual de AWS.



Puede que una máquina que tenemos alojada en AWS se nos haya quedado escasa de recursos respecto al momento de su creación. No hay problema, podemos cambiar su tipo de instancia - por ejemplo, de t2.large a t2.xlarge - en cualquier momento (parando la máquina, eso sí).

Para cambiar el tipo de instancia:

Paso 1

Ir a la consola de Amazon e ir a EC2.

Paso 2

Ir a Instances (Instancias).

Paso 3

Seleccionar la instancia a parar y pararla. Para pararla, ir al menú Actions (Acciones) > Instance State (Estado de la instancia) y clicar Stop (Detener).

Paso 4

Con la instancia aún seleccionada, ir a Actions > Instance Settings > Change Instance Type.

NOTA: esta acción estará deshabilitada si el estado de la instancia no es stopped.

Paso 5

En el cuadro de diálogo Change Instance Type (Cambiar tipo de instancia):

En Instance Type (Tipo de instancia), seleccionar el tipo de instancia que se desea asignar.

Si el tipo de instancia deseado no aparece en la lista, significa que el tipo de máquina no es compatible con la configuración de la instancia (por ejemplo, determinados tipos de instancia solo están disponibles para Linux y no aparecen en la lista si estamos reconfigurando una instancia Windows).

Clicar Apply (Aplicar) para pasar a la nueva configuración.

Paso 6

Para iniciar la instancia detenida, seleccionar la instancia y elegir Actions > Instance State > Start.

En el cuadro de diálogo de confirmación, elegir Yes, Start (Sí, iniciar).

Pasados unos minutos, el estado de la instancia debería cambiar a running y los checks deberían estar en OK. Cuando esto ocurra, la instancia ya estará levantada con el nuevo tipo.


Fuentes:

https://docs.aws.amazon.com/es_es/AWSEC2/latest/UserGuide/ec2-instance-resize.html
0