Seguridad

Muy genérico pero aquí voy a poner tips que nos facilitan la vida para implementar procedimientos que permiten aumentar nuestra seguridad

Host dinámicos

Introducción

Un host dinámico es una entrada FQDN con un componente dinámico en la asignación de su IP.

Es un mecanismo muy apropiado para poder añadir una capa extra de seguridad a los accesos a determinado sistemas y programas.

Un fallo común en la aplicación de políticas de acceso a dispositivos o sistemas protegidos mediante cortafuegos (firewall) es el añadido de IP tratadas como fijas que no lo son, o fijas que en un momento determinado cambian o deberían dejar de estar autorizadas.

Aplicaciones de un host dinámico

Son muchas y variadas siendo las más importantes para el escenario privado o empresarial del hosting las siguientes: Limitar el acceso a servidores o dispositivos vía SSH mediante host autorizado Limitar el acceso a páginas web o zonas de una página web via host autorizado

¿Cómo obtener y mantener un host dinámico?

Para tener un host dinámico necesitamos un sistema de DNS que nos permita mediante una aplicación actualizar regularmente (300 segundos +/-) los datos de nuestro host dinámico.

Hay algunos de pago y otros gratuitos pero yo me decanto por noip de DNS Services

Proceso de alta en Noip.com

El Alta como usuario es gratis, y nos permitirá hasta 3 hostnames de un único dominio.

Alta en NoIp

Durante el proceso deberemos escoger el nombre de host y el dominio del que derivará nuestro hostname dinámico.

Una vez aceptado, deberemos confirmar nuestra dirección de correo electrónico.

Acceso a noip.com

Importante: Noip no permite que tengas instaladas las Vue Developers Tools (todavía no entiendo por qué)

Deberemos completar por seguridad los datos personales y de uso. Descargamos el software para que podamos actualizar nuestro ordenador, tablet o móvil. Instalamos y configuramos

Configuración del software de noip

Instalación

Instalación NoIp Software

Primer acceso

En la primera apertura veremos que falta por indicar el host dinámico que vamos aplicar a esa instalación. Seleccionamos y listo.

Primer acceso

Configuración

Configuración

Funcionando

Funcionando no ip

Consulta su ayuda para ver opciones (arranque automático, etc)

Aviso

Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos. También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad. El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris

Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Limitación de acceso por host dinámico - Apache y Nginx

Introducción

Muchas veces necesitamos usar mecanismos de seguridad para el acceso a determinadas areas, más cuando nos encontramos con software que ya ha tenido más de una incidencia de seguridad o conocemos la baja calidad de su software como WHMCS.

Uno de los mejores mecanismos es la aplicación de seguridad mediante al acceso a la zona que queremos proteger, mediante el uso de Host dinámicos

Apache

Con apache usaremos .htaccess para cerrar todas las conexiones a la zona web que queremos proteger.

Requerimientos

Implementación

Require forward-dns mi.hostdinamico.tld

También si tenemos IP fija podemos usarla (aunque en nueysro tip anterior indico mi preferencia por los host dinámicos)

Require forward-dns 00.00.00.00 

Nginx

** pendiente de testing ** Nginx tiene otros mecanismos, y lo describe en HTTP rDNS

Requerimientos

server {
	resolver 127.0.0.1; # Si tienes activado dns localhost, sino pon tu resolver preferido
    
    rdns_allow mi\.hostname\.tld;
	
    location /path {
    	echo_exec $protegido
    }
    
    location
}

Compilación

En mi blog tengo una entrada sobre LEMP en la que hago compilación de modulos como este.

Para compilar ete modulo de forma dinámica:

$ cd ~/soft/
$ git clone git@github.com:flant/nginx-http-rdns.git
## $version ya estaba declarada en la compilacion sino, poner la que corresponda. Ten en cuenta que este post
## entiende que se esta siguiente el modelo del enalce de más arriba
$ cd ninx-$version/
$ /configure --with-compat --add-dynamic-module=../nginx-http-rdns
$ make
$ make modules
$ sudo mv objs/ngx_http_rdns_module.so /usr/lib/nginx/modules/

Añadir la carga del módulo a nginx en /etc/nginx/modules-enabled/51-mod-http_rdns.conf

load_module modules/ngx_http_rdns_module.so;

Configurar en los sitios que se requiera segun su configuración.

$sudo nginx -t # Para verificar que todo esta correcto

Aviso

Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos. También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad. El contenido el contenido se entrega, tal y como esta, sin que ello implique ningún obligación ni responsabilidad por parte de Castris

Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Llaves SSH en entornos *nix (linux, MacOS X, Windows WSL)

Introducción a las llaves SSH

El uso de llaves SSH es primordial para operaciones con servidores, ya sean aisladas o automatizadas. Añaden una capa extra de seguridad frente al uso de contraseñas y una versatilidad a las operaciones que se hace necesario tener nuestro par de llaves SSH.

Podemos tener nuestro par de llaves único (acosenjado por cuestiones de seguridad, ya que su revocación es más fácil) o por dispositivo.

Llaves OpenSssh (OpenSssh Keys)

Como norma general los servidores unix usan OpenSSh Server y por tanto sus llaves requieren que esten en este formato. Si usamos un entorno tipo unix (Linux, MacOS X, Windows WSL, FreeBsd) ese formato no supondra ningun problema. Si usamos Windows sin WSL, entonces seguramente usemos algun programa como Putty que tiene su formato cerrado, y el procedimiento requiere convertir sus llaves publicas a formato OpenSSH.

Puedes consultar nuestro manual Manual para conexión SSH con Putty

Generar un par de llaves

Vamos generar un par de llaves OpenSSH, sin contraseña, para operacioneas desatendidas y porque creemos que es suficiente el nivel de seguridad que no sofrece, sin necesidad de añadir la capa extra con la contraseña.

Tan sencillo como posicionarnos en nustro home, y ejecutar el comando, admitiendo todos los pasos por defecto.

Eso creara un par de llavez con el nombre id_rsa (privada) y ìd_rsa.pub (publica)

yamna@nox:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/yamna/.ssh/id_rsa): 
Created directory '/home/yamna/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again:
Your identification has been saved in /home/yamna/.ssh/id_rsa
Your public key has been saved in /home/yamna/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:20RVkgzXUBA9/V2tkoDejoim+L7zAtjvfxvva4CmQaA yamna@nox
The key's randomart image is:
+---[RSA 3072]----+
|         ..oBXo..|
|  .     . .oo.+ +|
| . .   . ... . o+|
|E   .   ... o . o|
|.. . . oSo.  .   |
|o . + + o+.      |
| o + +  o..      |
|. + o   .o.      |
| o+*o....++.     |
+----[SHA256]-----+

ssh-keygen

Parte pública

Si queremos acceder a un servidor remoto (root o usuario) deberemos añadir la llave publica a el fichero de autorizaciones del sistema remoto o bien facilitarselo al administrador para que el haga su trabajo.

No existe ningun problema en enviar esta llave (la pública) a alguien, incluso en modo texto. A fin de cuentas es la llave pública que no sirve nada más que para que otros la ulticen para autorizarnos a nosotros.

Parte privada

Esta es la parte que si tenemos que atender a su seguridad. La perdida de un dispositivo, que tenga esa llave, unido a que el hacker pueda analizar nuestro historico, le dará la oportunidad de acceder de forma inmediata a todos los servicios en los que tu par de llaves esten autorizadas. Asi pues, la más minima sospecha de intrusión, substracción, perdida de dispositivo, con ese par de llaves, conlleva a la revocación inmediata de las llaves y aviso a los administradores implicados. (como si perdieras la contraseña)

Aviso

Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos. También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad. El contenido el contenido se entrega, tal y como esta, sin que ello implique ningún obligación ni responsabilidad por parte de Castris

Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Deshabilitar 2FA en WHMCS para un administrador

Introducción

En muchos entornos de trabajo es posible que lidiemos con los problemas de perdida o ausencias técnicas de los administradores que estan obligados al uso de la verificación de contraseña 2FA o doble factor.

Además a veces es una labor muy dificil, la de formar al personal de las empresas, en sus obligaciones de seguridad, por lo que muchas veces, pierden o no tienen acceso (por qu eno lo descargaron, no lo guardaron,...) del o los, códigos de seguridad

Desactivación de la obligación de uso de 2FA para un administrador de WHMCS

# $ mysql # Podemos tener acceso automatizado o necesitar escribir las credenciales
# 
$ mysql -u user_whcms -p 
mysql > update whmcs_bd.tbladmins set authmodule='' where username='nombre_de_usuario_admin';
mysql > update whmcs_bd.tbladmins set authdata='' where username='nombre_de_usuario_admin';
Aviso

Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos. También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad. El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris

Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Error de acceso SSH con llaves ssh (Permission denied (publickey)) habiendo verificado que las llaves son correctas

Introducción

Desde OpenSSH 7.0 se deshabilito por defecto el intercambio de claves SSH-DSS. Esto puede producir un comportamiento de error, muy silencioso que es fácil de detectar y corregir.

Si tenemos una llave creada con el tipo dss y esta está autorizada en un sistema, o por error, no vimos que nos pasaban una llave con esa característica, para añadirla a un sistema, esta no funcionará en el sistema actualizado, y nos dará en primera instancia un error de Denegación por llave incorrecta.

Análisis

En el acceso general con esa llave sólo recibiremos un mensaje corto

root@server:~# ssh  user_remoto@servidor.remoto.tld -p 51514
user_remoto@servidor.remoto.tld: Permission denied (publickey).

Como siempre, debemos acostumbrarnos a analizar nuestros problemas con el aumento del sistemas de logs o de mensajes (debug)

Dejaremos el listado sólo en lo justo para ver el problema

root@server:~#  ssh  user_remoto@servidor.remoto.tld -p 51514 -vv
OpenSSH_8.2p1 Ubuntu-4ubuntu0.3, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
...
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ecdsa_sk
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Trying private key: /root/.ssh/id_ed25519_sk
debug1: Trying private key: /root/.ssh/id_xmss
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.

Importante que nos indique que ha buscado la llave y no le ha valido.

Revisando la llave vemos que tiene el tipo ssh-dss el cual no está aceptado por el servidor remoto.

También es importante ver el log del **servidor sshd** si es posible, y dependiendo del nivel de log que tenga podremos ver que nos indica que el tipo dss no está aceptado

Revisamos el valor de la llave y vemos en el incio, que tenemos una llave tipo DSS.

root@server:~# cat .ssh/id_dsa.pub 
ssh-dss AAAAB3N….

Opciones

Reconstrucción de la llave con formato rsa (Recomendado)

El tipo RSA es el más aconsejado. Si el sistema no te crea la llave por defecto con DSA o no se la crea al usuario que te está facilitando la llave, deberá forzar el comando de generación de sus llaves para que use el formato RSA.

root@server:~#  ssh-keygen -t rsa

Deberemos actualizar la llave en nuestro fichero de authorized_keys, y ya debería funcionar

Activación del algoritmo DSS en el servidor (No aconsejable)

Puede existir algún escenario, por prisas, situación específica, etc, que no nos permita de forma inmediata, el recrear la llave del servidor que quiere acceder, por lo que debemos reactivar el tipo de llave que tenemos.

Es imperativo, entender que esto es un atajo, muy común en los artículos de internet, que puede llevar a dejar nuestro sistema más inseguro, si luego no lo devolvemos a la normalidad.

Ese error, ocurre en el 90% de los casos, porque el administrador, va corriendo, y luego no vuelve atrás a corregir la situación.

Para ello debemos editar el fichero /etc/ssh/sshd_config añadiendo la línea siguiente:

PubkeyAcceptedKeyTypes=+ssh-dss

Centos 8

Requiere un paso adicional, relacionado con su System-wide Cryptographic Policies.

Primero deberíamos conocer el nivel actual (suele ser por defecto) para luego devolverlo a su estado original

$ update-crypto-policies --show
DEFAULT
Debemos, devolver en cuanto podamos, (nueva llave) nuestro sistema a la posición de seguridad inicial

Otros enlaces

Aviso

Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos. También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad. El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris

Si necesitas soporte profesional puedes contratar con Castris soporte profesional.