Skip to content

Acceso remoto

Cuando estamos en la consola de Virtualbox estamos conectados como si estuviéramos conectados al equipo servidor con un ratón y un teclado. Esto no suele ocurrir salvo un fallo grave. si esto ocurre deberemos entrar en el Datacenter y acceder al rack de servidores.

Tareas de configuración

  • Instalación del servidor ssh
  • No permitir acceso root
  • Cambiar puerto defecto
  • ¿Meter sudo?
  • Generar contraseñas seguras
  • Acceso con clave pública
  • fail2ban en modo paranoia

Instalación del servidor ssh

El acceso remoto a nuestro servidor sera a través de SSH. En la instalación no instalamos ningún componente así que lo haremos ahora. NOTA: Si lo instalaste salta al siguiente paso.

Utilizaremos los repositorios de Ubuntu para instalar el servidor y el comando apt.

apt install openssh-server

Tras ejecutar este comando podremos ir a nuestro cliente y acceder con ssh

Desde cliente:
$ ssh nombreusuario@172.X.X.X

El protocolo ssh es un protocolo cifrado que utiliza claves pública-privada para iniciar la comunicación. En esta configuración no tenemos ninguna entidad certificador que diga que nuestro server es quien dice ser, así que la primera vez que nos conectamos debemos aceptar su identificación.

$ ssh nombreusuario@172.X.X.X
The authenticity of host '192.168.X.X (192.168.X.X)' can not be established.
ECDSA key fingerprint is SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
Are you sure you want to continue connecting (yes/no)?

Cambiar puerto defecto

Como todos los servicios el servidor ssh tiene sus ficheros de configuración, vamos a comenzar a configurar este servicio para cambiar el puerto.

Fichero de configuración: /etc/ssh/sshd_config

Formato: 

# Comentario
Clave Valor
Clave Valor
Clave Valor

Revisa el fichero mirando los distintos parámetros.

Modifica el puerto por defecto en el fichero al puerto 24500 ¿Qué ocurre si ahora te intentas conectar?

Para que los cambios tengan efecto hay que reiniciar el servicio service ssh restart o service ssh reload

No permitir acceso root

A día de hoy el acceso remoto para root no está permitido. La cuenta de usuario root es una cuenta que está en todas las máquinas GNU/Linux. Si alguien quiere realizar un ataque por fuerza bruta ya tendría información de una cuenta.

Comprueba que no puedes accceder con el comando ssh root@172.X.X.X

¿Meter sudo?

Al habilitar el comando sudo para el usuario administrador se permite que un usuario pueda ejecutar acciones de administrador. Por defecto en Ubuntu viene configurado.

Podemos elegir no habilitar sudo y que para hacer acciones de administrador el usuario se tenga que convertir en root.

su -

Si lo hacemos así ese usuario deberá ser root y conocer la password de root. Depende de cómo se administre el servidor puede ser una buena opción.

Logs de acceso

Todos los servicios tienen un log de acceso en el que podemos mirar qué ocurre. En el caso de los accesos remotos pordemos ver el contenido del fichero /var/log/auth.log

tail -20 /var/log/auth.log

PAM Pluggable Authentication Modules

En los sistemas GNU/Linux existe un servicio para centralizar los accesos. Se denomina PAM https://es.wikipedia.org/wiki/Pluggable_Authentication_Modules

Podemos hacer que el servidor ssh se integre con este sistema de autentificación o que trabaje solo sin integrarse con el servicio. Mira en el fichero de configuración UsePAM

Tareas

Con la integración con PAM activada realiza las siguientes acciones.

  • Login con usuario válido
  • 3 login con password erróneo
  • 3 login con usuario que no existe
  • Login con root

Desactiva la integración con PAM y realiza las mismas acciones.

Ahora busca en los logs e identifica cada uno de estos sucesos.

La diferencia con PAM y sin PAM en este caso es mínima. Solo cambia el proceso que escribe en los logs

Generar contraseñas seguras

Podemos utilizar los comandos que vienen con OpenSSL para generar secuencias de caracteres aleatorias.

openssl rand -base64 32

Para esa práctica vamos a utilizar contraseñas que sean fáciles de recordar y no usaremos contraseñas fuertes pero en todos los entornos de producción las contraseñas deben ser fuertes.

CUIDADO CON LAS CONTRASEÑAS EN PRODUCCIÓN

Acceso con clave pública

A día de hoy es muy común acceder con clave pública y clave privada, tanto a servidores remotos como en procesos automatizados.

El fichero que representa la clave privada es equivalente a una contraseña con lo que debe ser bien custodiado. Estos ficheros también se pueden proteger con contraseña.

Explicación de cifrados:

  • Cifrado de un solo sentido
  • Cifrado simétrico
    • Qué es
    • ventajas-inconvenientes
  • Cifrado asimétrico
    • Qué es
    • ventajas-inconvenientes
  • Infraestructura clave pública privada
  • Firma digital

Regla de oro: Nunca dejes tu clave privada en otro sitio.

Tareas

Genera en tu cliente una clave pública:

$ ssh-keygen

Se generan dos ficheros: 

.ssh/id_rsa
.ssh/id_rsa.pub

Para que el servidor pueda autentificar a tu usuario debe tener tu clave XXX en sus claves autorizadas... ¿Qué clave tenemos que copiar la pública o la privada?

Acceso en servidor

Copia tu clave ¿XXX? en el final del fichero ~/.ssh/authorized_keys del servidor dentro de tu espacio de usuairo. OJO: Si queires acceder desde varios puesto con distintas claves no machaques el contenido cada vez que añadas una.

Tarea 1

Comprueba que puedes acceder sin la necesidad de meter usuario y contraseña.

Tarea 2

Es importante saber realizar estas tareas desde un equipo Windows y un equipo Mac. Es común que los desarrolladores web suban a los controles de versiones la información utilizando claves públicas-privadas.

Busca en Internet un tutorial para realizar esta acción y comprueba que puedes acceder a tu servidor sin necesidad de contraseña.

Tarea 3

Analicemos el proceso de verificación automático y expedición de certificados que hace Let's Encrypt https://letsencrypt.org/docs/

fail2ban

Cuando un servidor en tiene acceso a internet es común que sufra ataques, muchos de ellos de forma automatizada. Los programas y bots que hay ejecutándose no se cansan de probar combinaciones.

Tareas

Vamos a simular un ataque con fuerza bruta:

  • Crea un usuario con nombre "fuerzabruta" y con password "123qwe".
    • Como root adduser
  • Instala desde tu cliente hydra
  • Crea un fichero con varias contraseñas:
  • Realiza un ataque con hydra a tu server:
    • hydra -l <user> -P <fichero> <ip> -t 2 ssh
    • Sustituye las partes entre <> por los valores apropiados
  • Verifica en los logs del sistema dónde y cuando ha ocurrido este ataque

Fail2ban: instalación y configuración

Fail2ban está disponible dentro de los repositorios de Ubuntu.

apt install fail2ban

Configuración

Fail2ban se organiza en jaulas, la estructura de los ficheros de configuración la podemos encontrar aquí:

root@villablancaweb:/etc/fail2ban# tree -L 1
.
├── action.d
├── fail2ban.conf
├── fail2ban.d
├── filter.d
├── jail.conf
├── jail.d
├── jail.local <- ESTE FICHERO LO TENEMOS QUE CREAR
├── paths-arch.conf
├── paths-common.conf
├── paths-debian.conf
└── paths-opensuse.conf

Crea la copia del fichero jail.conf como jail.local y analiza qué tipo de fichero es.

Dentro de este fichero tenemos una configuración general y una específica de las jaulas. Vamos a poner que la jaula sshd busque intentos en los logs de un día y si tiene 3 fallidos te eche 1 semana.

[sshd]

port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

bantime  = 604800 #  ; 1 week
findtime = 86400 #   ; 1 day
maxretry = 5

Por defecto las jaulas están desactivadas, tras la configuración general del jail.local, se cargan todos los ficheros bajo jail.d/*. Si muestras el contenido del único fichero verás que sshd se carga ahí.

Reinicia el servicio para activarlo.

service fail2ban restart

Verifica que no tienes errores en la configuración

service fail2ban status

Lo normal es que verifique los logs y vea todos los intentos de conexión que hemos realizado y nos bloquee.

NOTA: Ten en cuenta que hemos cambiado el puerto de ssh... quizá tengamos que cambiar algo en el fail2ban también

Chuleta Fail2Ban

Conéctate al servidor de forma local (En Virtualbox) y con los siguientes comando lista las IPs bloqueadas y desbloquea la tuya.

// Get Fail2Ban status and list all jails
fail2ban-client status

// List all IPs in a specific jail
fail2ban-client status <JAIL-NAME>

// Unban a specific IP from a jail
fail2ban-client set <JAIL-NAME> unbanip <IP-ADDRESS>

// Ban a specific IP in a jail
fail2ban-client set <JAIL-NAME> banip <IP-ADDRESS>

Para ver en iptables

Mostrar el listado de tablas:

iptables -L

Elementos extra

Existen varios detalles complejos que autentificación que se han tratado en clase aunque no son esenciales.

PasswordAuthentication y ChallengeResponseAuthentication

Información sobre el tema https://superuser.com/a/374234

Especificaciones de intercambio de mensajes:

Están relacionados con la forma en la que se puede introducir la contraseña cuando el servidor la pide.

Analizar comentarios del servidor ssh

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication yes

A día de hoy en el caso de requerir un acceso remoto desatendido se utilizan claves públicas y claves privadas. Nunca se almacena las contraseñas en claro, ni viajan en claro por la red.

Acceso remoto desatendido, usar siempre clave pública-privada