Tienda Wifi

Tienda Wifi
CiudadWireless es la tienda Wifi recomendada por elhacker.NET

Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Opciones y parámetros del archivo configuración SSH


Si accedemos a nuestro servidor mediante SSH a través de Internet, deberíamos de preocuparnos por asegurar el servidor, ya que los intentos de acceso no autorizado a los servidores SSH son muy frecuentes. Veamos a continuación algunos parámetros que podemos modificar o añadir para que nuestro servidor SSH esté más seguro.



Cambiar puerto por defecto

La seguridad mediante ocultación no es la solución, pero evitarás ataques automatizados. Además de usar un cortafuegos, una buena manera de proteger aún más nuestra máquina contra posibles intrusiones externas es cambiar los puertos por defecto de los distintos servicios que estemos usando.  En el fichero de configuración /etc/ssh/sshd_config podemos modificar el puerto del servidor SSH, 

Si lo hacemos, hemos de tener en cuenta que a partir de entonces, cuando queramos acceder al servicio del servidor SSH, lo indicaremos con -p puerto, del siguiente modo:

ssh -p 3426 el-brujo@ns2.elhacker.net


Asegurar el servidor SSH


Lo primero que tenemos que hacer es entrar en el archivo de configuración para realizar los cambios:

sudo nano /etc/ssh/sshd_config

Veremos una gran cantidad de opciones de configuración en él. Una de las primeras que encontraremos es la que indica el puerto de acceso al servidor, que por defecto es el 22. Si lo cambiamos (poniendo, por ejemplo, el puerto 3426), dificultaremos mucho el trabajo a quien intente acceder a nuestra máquina:

Port 3426

Algo importante que debemos comprobar es la directiva de seguridad que permite o deniega el acceso a root, el superusuario o administrador de los sistemas UNIX/Linux. Muchos de los ataques que se realizan, especialmente contra servidores, se concentran en particular sobre este usuario con la esperanza de que tenga una contraseña débil, algo que (desgraciadamente) sucede con demasiada frecuencia.

Por defecto, la directiva que controla el acceso de root se encuentra así:

PermitRootLogin prohibit-password

Esto significa que se prohíben todos los métodos de autentificación interactivos, permitiendo sólo la autentificación mediante Publickey, Hostbased y GSSAPI. Sin embargo, es mucho más seguro no permitir el acceso del administrador del sistema de ninguna de las maneras. Por eso, lo que haremos será impedir la entrada a root de todas las formas posibles, sean cuales sean, lo que conseguiremos cambiando así esta línea:

PermitRootLogin no

Otra opción que podemos modificar es la que indica la cantidad de minutos que la pantalla de login estará disponible para que el usuario se identifique. Pasado ese tiempo, si no nos hemos identificado, la conexión se cerrará:

LoginGraceTime 1m

Prestaremos atención asimismo a las dos siguientes directivas de seguridad:

MaxAuthTries 3
MaxSessions 4

Sirven para dificultar los ataques de fuerza bruta. La primera indica el número máximo de errores permitidos al hacer login. Si sobrepasamos ese número, se nos mostrará un mensaje de error y habrá que volver a empezar de nuevo. La segunda directiva se refiere al número máximo de conexiones simultáneas por IP que permite el servidor.

También nos aseguraremos de que se exija el uso de una contraseña de acceso y que no acepte contraseñas vacías o en blanco:

PasswordAuthentication yes
PermitEmptyPasswords no

Si hay varios usuarios en el sistema, podemos añadir también al final del fichero de configuración una directiva para que sólo los usuarios especificados tengan acceso al mismo:

AllowUsers pi elhackernet

O, si se prefiere, usar en su lugar esta otra para permitir el acceso a todos menos a los que se indican expresamente en ella:

DenyUsers luisp manu root

Guardamos los cambios y comprobamos que la configuración del fichero es correcta, para lo cual hay que escribir este comando:

sudo sshd -t

Si no aparece ningún mensaje de error, es que todo está bien. Es importante comprobar que el archivo de configuración es correcto porque si no, cuando reiniciemos el servicio (o la propia Raspberry), el servidor SSH no arrancará y no podremos conectarnos.

Una vez que nos hemos asegurado de que todo está en orden, necesitamos reiniciar el servicio para que los cambios surtan efecto:

sudo service ssh restart

Periódicamente es aconsejable mirar el fichero /var/log/auth.log para comprobar si ha habido algún intento de entrada ilegal. Si los hubiese, el siguiente comando nos ayudará a encontrarlos:

sudo cat /var/log/auth.log | grep 'invalid user\|Failed'

Y este otro contará cuántas líneas con intentos de intrusión aparecen:

sudo cat /var/log/auth.log | grep 'invalid user\|Failed' | wc -l

Para finalizar, añadiremos un par de notas importantes:

  1. 1.) Las contraseñas de usuario que usemos deben de ser "fuertes", es decir, tener cierta extensión (8 caracteres o más) y estar compuestas por una combinación de letras (mayúsculas y minúsculas), números y signos de puntuación. Además, la palabra resultante no debe tener sentido, de manera que no aparezca en ningún diccionario.
  2. 2.) También podemos conectarnos empleando autentificación mediante clave pública, lo que nos ahorra el tener que memorizar la contraseña y además resulta más seguro.

Existen otras configuraciones recomendadas para evitar las conexiones no deseadas al servidor SSH:

  • LoginGraceTime: Establece el tiempo necesario para introducir la contraseña, evitando que el atacante tenga que “pensar mucho”.
  • MaxAuthTries: Número de intentos permitidos al introducir la contraseña antes de ser desconectados.
  • MaxStartups: Número de logins simultáneos desde una IP, para evitar que se pueda utilizar la fuerza bruta con varias sesiones a la vez.
  • AllowUsers: crear una lista blanca de usuario. Este parámetro permite configurar los usuarios que podrán conectarse. Una medida muy restrictiva pero a la vez muy segura ya que bloqueará todas las conexiones de los usuarios que no estén en el listado. Los usuarios que esten aquí podrán conectarse, y el resto no.
  • DenyUsers: Parecido al anterior, pero ahora se crea una lista negra. Los usuarios que esten aquí no podrán conectarse, y el resto sí.
  • AllowGroups/DenyUsers: Exactamente igual a lo anterior, pero en lugar de crear una lista blanca/negra de usuarios, es de grupos de usuarios.

Por ejemplo, un archivo de configuración de sshd_config sería el siguiente:

Port 22445
PermitRootLogin no
LoginGraceTime 30
MaxAuthTries 3
MaxStartups 3
AllowUsers elhackernet
DenyUsers pi

Desactivar re-envio de tráfico (pueden utilizar ssh para redireccionar tráfico)

AllowTCPForwarding No

Después de los cambios, se deberá reiniciar el servicio sshd utilizando (reiniciar para que los cambios surtan efecto)

$ sudo systemctl restart ssh

 

Fail2ban

Quienes deseen ir un paso más allá en la seguridad de sus servidores, pueden instalar el servicio Fail2ban, que vigila los intentos de acceso a los servidores que tengamos instalados y banea (bloquea) aquellas IPs que hayan hecho un intento ilegal de entrar en el sistema mediante fuerza bruta:

sudo apt install fail2ban

Accedemos al fichero de configuración:

sudo nano /etc/fail2ban/jail.conf

En la sección [DEFAULT] encontramos varias líneas relativas a la configuración genérica del servicio. Las fundamentales son: ignoreip (IPs que no deseemos que se baneen, que corresponden a localhost [127.0.0.1/8 ::1], y además añadiremos todas las IPs de nuestra red local [192.168.1.0/24]); bantime (tiempo de bloqueo); findtime (tiempo durante el que se espera hasta alcanzar el número máximo de intentos de acceso fallidos [maxretry] de un cliente) y maxretry (número de intentos de login fallidos para que se active el bloqueo).

[DEFAULT]

#
# MISCELLANEOUS OPTIONS
#

# "ignoreip" can be a list of IP address, CIDR masks or DNS hosts...
ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24
bantime = 10m
findtime = 5m
maxretry = 3
. . . . . .

En el ejemplo anterior, el servicio se ha configurado de tal forma que, si durante un plazo de 5 minutos (findtime), un cliente (dirección IP) realiza 3 intentos fallidos de acceso (maxretry), su IP será bloqueada durante 10 minutos (bantime). Hasta que no transcurra dicho tiempo, no se le permitirá volver a hacer un nuevo intento de conexión.

Más abajo, en el apartado JAILS es donde se activa cada uno de los servicios que tengamos instalados. Así, en [sshd] activaremos la seguridad del servidor SSH contra ataques de fuerza bruta. Cada servicio se activa poniendo enabled = true al comienzo de su sección. La opción mode la podemos dejar como viene por defecto (normal). En port dejamos ssh si estamos usando el puerto por defecto (22) o bien pondremos el número de puerto por el que hayamos decidido cambiarlo. Si lo deseamos, es posible poner un bantime y un maxretry específicos para cada servicio. Las demás opciones las dejamos como están.

#
# JAILS
#

#
# SSH servers
#

[sshd]
# To use more aggressive sshd modes...
enabled = true
mode = normal
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
. . . . . .

Acabada la configuración, sólo tenemos que reiniciar el servicio:

sudo service fail2ban restart

Comprobaciones Fail2Ban

Desde este momento podremos realizar diversas comprobaciones, como conocer su estado:

sudo /etc/init.d/fail2ban status

Ver los servicos que tenemos activos:

sudo fail2ban-client status

O el estado actual de un servicio concreto (ssh en este caso), que nos mostrará si tiene alguna IP baneada en este momento:

sudo fail2ban-client status sshd

Se puede echar un vistazo al fichero de log para comprobar si ha habido intentos de acceso no autorizados:

sudo cat /var/log/fail2ban.log

Una forma más rápida de hacerlo es pedir que se nos muestren las IPs bloqueadas y en qué servicio han ocurrido:

sudo cat /var/log/fail2ban.log | grep "Ban"

También se puede bloquear una IP manualmente para un servicio concreto:

sudo fail2ban-client set apache-auth banip 192.168.1.27

O desbloquearla:

sudo fail2ban-client set apache-auth unbanip 192.168.1.27


Recibir un correo de alerta al bloquear una IP

Podemos hacer que Fail2ban nos envíe un correo cuando detecte un intento de intrusión y bloquee una determinada IP, informándonos de este hecho. Para lograrlo, lo primero que hemos de hacer es seguir los pasos para instalar un sistema de envío de correos desde la terminal.

Luego volvemos al fichero de configuración de Fail2ban:

sudo nano /etc/fail2ban/jail.conf

Dentro de él, en la sección # ACTIONS, localizamos y configuramos los siguientes parámetros:

destemail = Dirección de email para recibir los avisos sender = pi@raspberrypi [email usado en ciertas acciones] mta = mail [Servidor de correo que usaremos] action = %(action_mw)s [Está al final de la sección]

En la primera línea hemos de escribir la dirección de email en la que deseamos recibir los avisos, mientras que en las demás pondremos únicamente lo que aparece en color rojo.

Hecho lo anterior, guardamos los cambios realizados en el fichero y reiniciamos el servicio:

sudo service fail2ban restart

Comprobamos su estado para asegurarnos de que todo funciona correctamente:

sudo /etc/init.d/fail2ban status
  1. 1.- Si el servicio está activado [Active: active (running)], es que todo ha ido bien.
  2. 2.- Si, por el contrario, aparece un mensaje de error, comprobamos que no hemos cometido níngún fallo al configurar los datos del correo que introdujimos más arriba. Una vez hecha la comprobación, ejecutamos lo siguiente:
    sudo service fail2ban stop
    sudo service fail2ban start
  3. Y observamos de nuevo que el servicio esté activado:
    sudo /etc/init.d/fail2ban status

A partir de este momento, cada vez que haya un intento de acceso no autorizado y se bloquee la IP correspondiente, se nos enviará un aviso a la dirección de correo que hemos indicado, incluyendo información sobre la IP y el ISP desde los que se ha intentado acceder ilegalmente a nuestra máquina. Como medida de seguridad extra, también nos avisará (con un email por cada servicio que tengamos activado) cada vez que se detenga Fail2ban por algún motivo, incluyendo la desconexión o reinicio de la Raspberry.

Opciones y parámetros del archivo SSH Config (ssh_config)

¿Qué es el archivo SSH Config (ssh_config) para OpenSSH?

OpenSSH posee 2 archivos de configuración. Uno llamado ssh_config para la configuración del paquete cliente y otro llamado sshd_config para el paquete servidor, ambos ubicados en la ruta o directorio siguiente: /etc/ssh.

Por lo tanto, al trabajar en el archivo de configuración «SSH Config» (ssh_config) asumimos que, estaremos trabajando sobre un ordenador que funcionará como una estación de trabajo del tipo cliente, es decir, que realizará conexiones SSH hacia uno o más equipos Servidores con SSH.


Listado de opciones y parámetros existentes

A continuación estas son algunas de las opciones o parámetros existentes dentro del archivo de configuración «SSH Config» (ssh_config), muchas de las cuales pueden ser usadas dentro de una orden de comando del tipo «ssh -o option …».

Host / Match

Esta opción o parámetro indica dentro del archivo de configuración SSH cliente (ssh_config) que se restringen las siguientes declaraciones (hasta la siguiente opción o parámetro Host o Match indicados), para que sean solo para aquellos hosts que coincidan con uno de los patrones dados después de la palabra clave.

Es decir, que esta opción actúa como un divisor de sección dentro del archivo, al igual que la opción Match. Por lo tanto, ambas pueden repetirse varias veces en el archivo de configuración. Y sus valores, pueden ser una lista de patrones, que determinan cuáles son las opciones subsiguientes a aplicar a las conexiones realizadas a los hosts en cuestión.

El valor * significa “todos los hosts”, mientras que en Match el valor «all» hace lo mismo. Y, si se proporciona más de un patrón, deben estar separados por espacios en blanco. Una entrada de patrón se puede negar prefijándola con un signo de exclamación (‘!’), para que, dichas coincidencias negadas sean útiles al proporcionar excepciones para las coincidencias con comodines.

AddressFamily

Permite especificar que tipo (familia) de direcciones usar al conectarse. Los argumentos válidos son: any (predeterminado), inet (usar solo IPv4) o inet6 (usar solo IPv6).

BatchMode

Permite desactivar en la interacción del usuario, las solicitudes de contraseña y las solicitudes de confirmación de la clave del host, si se establece el argumento o valor «yes». Esta opción es útil en secuencias de comandos y otros trabajos por lotes donde no hay ningún usuario presente para interactuar con SSH. El argumento debe ser «yes» o «no», donde «no» es el valor predeterminado.

ExitOnForwardFailure

Este parámetro permite especificar si SSH debe terminar la conexión, si no puede configurar todos los reenvíos de puertos dinámicos, de túnel, locales y remotos solicitados.

ForwardAgent

Este parámetro permite especificar si la conexión con el agente de autenticación (si lo hay) se reenviará a la máquina remota. El argumento puede ser «yes», ya que, «no», es el valor predeterminado, además, el reenvío de agentes debe habilitarse con precaución. Puesto que, los usuarios con la capacidad de eludir los permisos de archivo en el host remoto pueden acceder al agente local a través de la conexión reenviada.

ForwardX11

Aquí se permite específica si las conexiones X11 se redirigirán automáticamente a través del canal seguro y el conjunto DISPLAY. El argumento puede ser «yes», ya que, «no», es el valor predeterminado.

ForwardX11Trusted

Aquí se establece en sí, cuáles serán los clientes X11 remotos que tendrán acceso total a la pantalla X11 original. Es decir, Si esta opción se establece en «yes», los clientes X11 remotos tendrán acceso total a la pantalla X11 original. Mientras que, si se establece en no (valor predeterminado), los clientes X11 remotos se considerarán no confiables y se evitará que roben o manipulen datos pertenecientes a clientes X11 confiables.

HashKnownHosts

Se utiliza para indicarle a SSH que debe aplicar hash a los nombres y direcciones de host cuando se agregan a ~/.ssh/known_hosts. De manera tal, de que estos nombres cifrados pueden ser utilizados normalmente por ssh y sshd, pero sin revelar información de identificación, en caso de que se divulgue el contenido del archivo.

GSSAPIAutentication

Se utiliza para especificar dentro de SSH, si se permite la autenticación de usuarios basada en GSSAPI. GSSAPI se usa normalmente para la autenticación Kerberos, por ejemplo, con Active Directory.

SendEnv

Sirve para especificar qué variables del entorno local deben enviarse al servidor. Para hacer funcionar esto de forma correcta, el servidor también debe admitirlo, además de estar configurado para aceptar estas variables de entorno. Las variables se especifican por nombre, que puede contener caracteres comodín. Además, varias de las variables de entorno pueden estar separadas por espacios en blanco o distribuidas en varias directivas de este tipo (SendEnv). 

Fuentes:

https://blog.elhacker.net/2021/01/seguridad-en-ssh-uso-de-llaves-privadas-yautenticacion-multifactor-2fa--con-google-authenticator.html

https://blog.elhacker.net/2021/01/securizar-una-raspberry-pi-seguridad-basica-red-ssh-internet.html

https://blog.desdelinux.net/aprendiendo-ssh-opciones-parametros-ssh-config/


0 comentarios :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.