miércoles, 30 de octubre de 2019

Deshabilitar TLS 1.0 y TLS 1.1 en NGINX



Cómo deshabilitar TLS 1.0 y TLS 1.1 en un servidor que esté ejecutando NGINX para servir contenido.



Transport Layer Security (TLS) es un protocolo de encriptación usado encima de la capa HTTP para generar conexiones HTTPS, es decir, conexiones seguras vía navegador web entre un cliente y un servidor (entre otros usos). TLS es el sucesor del protocolo SSL. A su vez, TLS ha ido evolucionando en diferentes versiones desde el año 1999 hasta la actualidad: TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3...

Compañías de la talla de Microsoft, Google o Mozilla han declarado que dejarán de ofrecer soporte para TLS 1.0 y TLS 1.1 en marzo de 2020, por lo que si tenemos un servidor web corriendo NGINX (tanto en modo servidor como en modo Reverse Proxy), sería recomendable deshabilitarlos, puesto que dejarán de ser un estándar. Las conexiones HTTPS se podrán seguir realizando con TLS 1.2 o superior.


Backup



Antes de deshabilitar TLS 1.0 y TLS 1.1 en una instalación de NGINX, deberíamos empezar por realizar un backup de la configuración actual de NGINX que se esté ejecutando en el servidor:

HOST# cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup


Configuración general



Para que NGINX solo negocie con TLS 1.2 o superior en todos los dominios que apuntan a él, debemos editar la directiva "server" general del servidor en el archivo /etc/nginx/nginx.conf y añadir (o modificar) la opción ssl_protocols para que quede tal que así:

server { listen 443 ssl http2; ... ssl_protocols TLSv1.2 TLSv1.3; }

Si ya disponemos de la directiva ssl_protocols, simplemente debemos eliminar los valores TLSv1 y TLSv1.1.


Configuración independiente de un dominio



Puede que se de el caso de que usemos NGINX como Reverse Proxy y queramos que un dominio determinado sea accesible con TLS 1.0, por ejemplo, porque se conectan a él máquinas que tienen un sistema operativo antiguo embedido y solo pueden negociar conexiones HTTPS con TLSv1.

Para este tipo de casos, podemos configurar la entrada de tipo "server" que agrupa la configuración del dominio en cuestión (por ejemplo, dominio.net) para que este dominio funcione con TLS 1.0 de forma independiente a la configuración general. Para ello, especificamos en el bloque server del dominio los ssl_protocols que queremos que acepte (TLSv1, TLSv1.1, TLSv1.2, etc.):

server { listen 443 ssl http2; server_name www.dominio.net dominio.net; ... ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; }


Aplicar cambios



Una vez configurados los protocolos, solo queda recargar la configuración de NGINX:

HOST# nginx -s reload

A partir de este momento, si realizamos un test de conexión HTTPS (con Qualys, nmap, etc.), observaremos que el servidor ya no negocia con TLS 1.0 ni TLS 1.1.
0

miércoles, 23 de octubre de 2019

Deshabilitar TLS 1.0 y TLS 1.1 en Apache



Cómo deshabilitar TLS 1.0 y TLS 1.1 en un servidor web Apache.

Microsoft, Google y Mozilla han declarado que dejarán de ofrecer soporte para TLS 1.0 y TLS 1.1 en marzo de 2020 en sus navegadores web (Edge, Chrome y Firefox, respectivamente).

Cuando accedemos a una web por HTTPS, cliente y servidor negocian la encriptación con un protocolo que ambos soporten (TLS 1.0, TLS 1.2, TLS 1.3, etc.). A partir de marzo de 2020, TLS 1.1 ya no será aceptado como protocolo válido por los navegadores web de las compañías mencionadas.

Aprovechando que los navegadores web actuales ya no podrán usar TLS 1.1 o inferior, podemos aprovechar para deshabilitar estos protocolos de encriptación HTTPS obsoletos e inseguros en nuestros servidores web. Por un lado ganaremos en seguridad; por otro lado perderemos en compatibilidad con ordenadores que usen navegadores antiguos (NOTA: nadie debería usar navegadores antiguos).

Apache, en su rama actual 2.4.x, soporta TLS 1.0 y TLS 1.1 por defecto.

Para deshabilitar estos protocolos, debemos editar el archivo ssl-global.conf:

HOST# vi /etc/apache2/ssl-global.conf

En este archivo, encontraremos la siguiente sección:

# SSL protocols # Supporting TLS only is adequate nowadays SSLProtocol all -SSLv2 -SSLv3

Por defecto, Apache ya no acepta encriptación SSL, solo TLS.


Opciones



Para dejar de aceptar TLS 1.0 y TLS 1.1 en Apache, deberemos cambiar la directiva SSLProtocol all. Al modificarla, podemos usar uno de estos dos métodos, segun si queremos aceptar o rechazar cipher suites en nuestro servidor web.

Método 1

Con el método 1, indicamos al servidor web qué protocolos no acepta. Es decir, el servidor aceptará todos aquellos cipher suites que no estén en la lista.

Para quitar protocolos de encriptación, debemos usar el signo "-" precediendo el nombre del protocolo:

SSLProtocol all -SSLv2 -SSLv3 -TLSv1.0 -TLSv1.1


Método 2

Con el método 2 indicamos solo aquellos cipher suites que sí acepta el servidor.

Para permitir solo ciertos protocolos, los indicamos explícitamente:

SSLProtocol all TLSv1.2 TLSv1.3


Conclusión



Personalmente, prefiero el método 1, ya que de este modo, podemos ir especificando los protocolos que van quedando obsoletos a medida que vayan quedando obsoletos. Bajo mi punto de vista, es más fácil estar al día sobre qué protocolos se "deprecan" que sobre qué protocolos se lanzan.
3

miércoles, 16 de octubre de 2019

Averiguar versión de VMWare ESXi de un host



Cómo averiguar la versión y el build number de VMWare ESX/ESXi que está corriendo un host.



Puede que no recordemos qué versión de VMWare ESXi se está ejecutando sobre un host y necesitemos averiguarlo para ver si cierta versión de un sistema operativo está soportada en esa versión. O puede que simplemente queramos saber la versión para mantenerla en nuestra documentación interna.

Para averiguar la versión de VMWare que se ejecuta en un host determinado, existen dos formas:

- Vía SSH
- Vía vSphere


SSH



Para ver la versión de VMWare que se está ejecutando en un host por SSH, deberemos conectarnos al host vía SSH y ejecutar el siguiente comando:

[root@esxigs:~] vmware -v VMware ESXi 6.0.0 build-6921384

El resultado es la versión y build number de ESXi que está corriendo en el host.


vSphere



Para ver la versión de VMWare mediante vSphere Web Client, deberemos conectarnos al apartado web del vSphere y seguir los siguientes pasos:

1. Ir a Home.
2. Clicar Hosts and Clusters.
3. Abrir el datacenter.
4. Expandir el cluster.
5. Clicar sobre el host.
6. Clicar sobre Summary.
7. En el apartado "Configuration" se encuentra el campo "ESX/ESXi Version":




Fuentes:

https://kb.vmware.com/s/article/1022196
0

miércoles, 9 de octubre de 2019

Conectarse como root a instancia Linux en AWS



Cómo conectarse directamente como root a una instancia EC2 Linux en AWS.



Al crear una instancia Linux en AWS, Amazon nos obliga a iniciar una conexión por SSH a una instancia EC2 Linux en AWS usando un usuario no privilegiado predefinido por ellos, como ec2-user o ubuntu. Si tratamos de iniciar una sesión SSH como root, nos encontraremos con el siguiente mensaje:

Using username "root". Authenticating with public key "imported-openssh-key" Please login as the user "ec2-user" rather than the user "root".

Para permitir el login del usuario root vía SSH, cambiamos al usuario root:

HOST# sudo su

Nos situamos en la home de root:

HOST# cd /root/.ssh

Y buscamos el fichero authorized_keys, el cual contendrá algo parecido a:

HOST# cat authorized_keys no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user \"ec2-user\" rather than the user \"root\".';echo;sleep 10" ssh-rsa AAAAB3NzaC1yc2EAAAADA+K4WkbVwemgociUzbzVtBb5SJZHbV1uqKNBH8mS82o6ffjhUGljbUjTj5EStJVMqnxFZpi7+RukgH55lwtKeIASZxjyiHEKq+0xg3iyRno2masFCgiwZD18znPnUFtX0Js8vM0+QOOsb7EE+w8nLuk+m4Jxze+eTjjErRSrTkpQejeJ3OkfGce3GLJLCwA2KsUMMLEsAvyTL6qn9ppk+VaO1fNeQtrr0OYSBKo3 KEY_NAME

Para permitir el login de root por SSH, tenemos que borrar el "command" con algún editor tipo vi:

command="echo 'Please login as the user \"ec2-user\" rather than the user \"root\".';echo;sleep 10"

A continuación, debemos editar el fichero de configuración de SSH (/etc/ssh/sshd_config) y modificar la política PermitRootLogin, la cual viene desactivada por defecto en AWS (PermitRootLogin No).

Si queremos acceder solamente con clave pública/privada:

PermitRootLogin wihtout-password

Si queremos acceder con password:

PermitRootLogin Yes

Una vez modificada la política, recargamos la configuración del servicio SSH para que lea los cambios:

HOST# systemctl reload sshd

Hecho esto, ya podremos conectarnos a la instancia EC2 Linux por SSH con el usuario root.
0

miércoles, 2 de octubre de 2019

Linux: espacio ocupado no concuerda con archivos



Cómo liberar espacio bloqueado en disco en un sistema Linux.



El sistema de monitorización que uso para ver si las máquinas virtuales tienen el disco lleno, la CPU al 100%, etc. me envió un correo diciendo que el directorio raíz de un sistema Linux estaba prácticamente lleno. Me conecté a la máquina afectada y lo comprobé:

root@host:/# df -h S.ficheros      Size   Used   Avail   Use%   Montado en /dev/sda1        38G    30G    5,9G    84%   / tmpfs           7,9G      0    7,9G     0%   /lib/init/rw udev            7,9G   100K    7,9G     1%   /dev tmpfs           7,9G      0    7,9G     0%   /dev/shm

Al ejecutar el comando df vi que había 30 GB usados de un total de 38 GB aprovisionados en /dev/sda1. En cambio, al mirar qué carpeta estaba ocupando más espacio en disco mediante du, no vi ningún directorio donde se concentrara esa ocupación. Tampoco el total de GB ocupados cuadraban con los mostrados por df. Como vemos, no había más de 3 GB usados en total:

root@host:/# du -hs * | sort -h 0      dead.letter 0      initrd.img 0      proc 0      sys 0      vmlinuz 4,0K   lib64 4,0K   mnt 4,0K   opt 4,0K   selinux 8,0K   backup 8,0K   srv 12K    media 16K    lost+found 52K    tmp 100K   dev 3,6M   lib32 4,5M   sbin 5,8M   bin 6,6M   etc 16M    boot 22M    root 49M    home 115M   lib 1,0G   usr 1,8G   var

Lo que podía estar ocurriendo es que algún proceso estuviese usando un archivo que hubiese sido eliminado y como el buffer no se podía vaciar porque no existía el archivo hacia el que el proceso quería escribir, se mantuviera esa información en el limbo hasta que ese proceso mueriera, aumentando así el tamaño del buffer hasta ocupar esos 30 GB mencionados anteriormente.

Podemos ver qué procesos usan archivos que han sido borrados mediante:

root@host:/# lsof | grep deleted

En el resultado, vi que el programa apache2 estaba tratando de escribir en los archivos /var/log/apache2/error.log y /var/log/apache2/other_vhosts_access.log, los cuales habían sido eliminados:

apache2 ... /var/log/apache2/error.log (deleted) apache2 ... /var/log/apache2/other_vhosts_access.log (deleted)

Como el causante era Apache, tras reiniciar Apache se liberó el espacio ocupado en /dev/sda1:

root@host:/# df -h S.ficheros      Size   Used   Avail   Use%   Montado en /dev/sda1        38G   4,7G    32G     14%   / tmpfs           7,9G      0    7,9G     0%   /lib/init/rw udev            7,9G   100K    7,9G     1%   /dev tmpfs           7,9G      0    7,9G     0%   /dev/shm

¡Misterio resuelto!


Fuentes:

https://serverfault.com/questions/315181/df-says-disk-is-full-but-it-is-not
0