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