Filezilla y agentes SFTP con servidores modernos tipo AWS EC2

 

NOTA DE SEGURIDAD EN EL SERVIDOR.

Usualmente los usuario desarrolladores de fronend usan Filezilla con su configuración por defecto, dado que es muy conocido para los servidores del tipo Wordpress , el problema es que este  agente SFTP (file transfer bajo ssh) usa los protocolos  basados en diffie-hellman y politicas de seguridad basadas en ssh-rsa,ssh-dss  que comprometen la seguridad del  sistema , creando vulnerabilidades y bajo rendimiento del sistema.

Aquí dejo un archivo /etc/ssh/sshd-config funcional para poder usar filezilla en servidores con protecciones que no implementan estos protocolos y alguna configuraciones basicas que habilitan a Filezilla en servidores de alta seguridad.

Se recomienda enormemente cambiar/configurar a  Filezila a otros protocolos como Curve , +ssh-rsa,ssh-dsspor entre otros que son  mas eficientes y ofrece  mayor seguridad, si es posible en sus usuarios antes de pensar en relajar sus sistema.

En este archivo las entradas para institucional, empre0,empre1,empre2 hace referesncia a la configuración hipotética de usuarios que despliegan sus desarrollos en el servidor por ejemplo apache o nginx, cambie su directorio del contenedor /usr/share/nginx según su conveniencia

$ sudo emacs /etc/ssh/sshd-config

------------------------------------------------------------------------------------------------------------

#       $OpenBSD: sshd_config,v 1.104 2024/07/20 13:16:21 dtucker Exp $

# This is the sshd server system-wide configuration file.  See

# sshd_config(5) for more information.

HostKey /etc/ssh/ssh_host_rsa_key

HostKey /etc/ssh/ssh_host_dsa_key

HostKeyAlgorithms +ssh-rsa,ssh-dss

PubkeyAcceptedKeyTypes +ssh-rsa,ssh-dss

KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha\

1,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256

PubkeyAuthentication yes

AuthorizedKeysFile      .ssh/authorized_keys

#AuthorizedPrincipalsFile none

PasswordAuthentication yes

PermitEmptyPasswords no

Subsystem       sftp    /usr/libexec/openssh/sftp-server

HostkeyAlgorithms +ssh-dss

PubkeyAcceptedKeyTypes +ssh-dss

AuthorizedKeysCommand /opt/aws/bin/eic_run_authorized_keys %u %f

AuthorizedKeysCommandUser ec2-instance-connect

Ciphers aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc

Match User institucional

    ChrootDirectory /usr/share/nginx/institucional

    ForceCommand internal-sftp

    AllowTcpForwarding no

    X11Forwarding no

Match User empre0

    ChrootDirectory /usr/share/nginx/empre0

    ForceCommand internal-sftp

    AllowTcpForwarding no

    X11Forwarding no

Match User empre1

    ChrootDirectory /usr/share/nginx/empre1

    ForceCommand internal-sftp

    AllowTcpForwarding no

    X11Forwarding no

Match User empre2

    ChrootDirectory /usr/share/nginx/empre2

    ForceCommand internal-sftp

    AllowTcpForwarding no

    X11Forwarding no

-------------------------------------------------------------------------------------------------------------------

Es necesario hacer un par de paso de configuración para garantizar que esta configuración funcione

ya que usa contraseñas externas a los servidores es necesario configurarlas  adecuadamente.

1. Verifique que los siguientes archivos existen , sino crearlos.

$ ls -l /etc/ssh/ssh_host_rsa_key

$ ls -l /etc/ssh/ssh_host_dsa_key

*Nota verifique si en el cliente local existe el archivo /ssh./host-knows con acceso para el servidor,

si lo tiene , eliminar la entrada asignada al servidor que se pretende tener acceso, para evitar que se bloquee el acceso al servidor desde esa terminal.

Crear las claves necesarias para permitir acceso a Filezilla.

$ sudo ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ''

$ sudo ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ''

dar los permisos necesarios a estas claves.

$ sudo chmod 600 /etc/ssh/ssh_host_rsa_key

$ sudo chmod 600 /etc/ssh/ssh_host_dsa_key

$ sudo chown root:root /etc/ssh/ssh_host_rsa_key

$ sudo chown root:root /etc/ssh/ssh_host_dsa_key

iniciar el servidor sshd de seguridad.

sudo service sshd restart

verificar el estado del sertvicio

$ sudo service sshd status

Use esta informacion con precaución, no se recomienda para servidores de producción.

Se recomienda leer el siguiente texto y buscar mas información de sus sistemas antes de

hacer cualquier cambio en el servidor.

Las prácticas de seguridad y las políticas de criptografía evolucionan con el tiempo para adaptarse a nuevas amenazas y vulnerabilidades descubiertas. Aquí tienes una explicación de por qué algunos protocolos y políticas, como Diffie-Hellman y las claves basadas en ssh-rsa y ssh-dss, pueden no ser recomendados o soportados en los servidores de seguridad modernos:

1. Diffie-Hellman (DH)

Debilidades:

• Tamaño de clave fijo: Algunos parámetros DH, especialmente aquellos con tamaños de clave pequeños, son vulnerables a ataques de fuerza bruta.
• Intercambio de claves sin autenticación: El protocolo DH por sí mismo no autentica las partes comunicantes, lo que lo hace susceptible a ataques man-in-the-middle (MitM) si no se combina con otros mecanismos de autenticación.

Alternativas modernas:

• Elliptic-Curve Diffie-Hellman (ECDH): Proporciona mayor seguridad con tamaños de clave más pequeños y es más eficiente en términos de procesamiento.

2. SSH-RSA

Debilidades:

• Debilidad en SHA-1: La firma ssh-rsa usa el algoritmo de hash SHA-1, que ha demostrado ser vulnerable a ataques de colisión.
• Preferencia por algoritmos más seguros: Los algoritmos modernos como rsa-sha2-256 y rsa-sha2-512 usan SHA-2, que es más seguro que SHA-1.

Alternativas modernas:

• ED25519: Un algoritmo de clave pública basado en curvas elípticas que es más seguro y eficiente.
• RSA con SHA-2: Utilizar rsa-sha2-256 o rsa-sha2-512 para firmas RSA en lugar de ssh-rsa.

3. SSH-DSS (DSA)

Debilidades:

• Tamaño de clave fijo y pequeño: DSA tradicionalmente usa un tamaño de clave fijo de 1024 bits, que no es considerado seguro hoy en día.
• Requerimientos específicos: DSA tiene requisitos específicos sobre el tamaño de la clave y otros parámetros, lo que limita su flexibilidad y seguridad.

Alternativas modernas:

• ED25519: Proporciona seguridad mejorada con claves más pequeñas.
• RSA y ECDSA: Ofrecen mayor seguridad y flexibilidad con tamaños de clave más grandes y algoritmos modernos.

Recomendaciones

Para mantener altos niveles de seguridad en servidores SSH y otros sistemas criptográficos, se recomienda:

1. Actualizar algoritmos y claves:

   • Utilizar claves RSA de al menos 2048 bits, preferentemente 3072 o 4096 bits.
   • Emplear algoritmos modernos como ED25519 y ECDSA.

2. Políticas de seguridad actualizadas:

   • Deshabilitar algoritmos antiguos y débiles como ssh-dss y ssh-rsa.
   • Implementar políticas que requieran el uso de algoritmos seguros y tamaños de clave adecuados.

3. Mantener el software actualizado:

   • Asegurarse de que tanto el software del servidor como el cliente SSH estén actualizados para soportar las últimas prácticas y recomendaciones de seguridad.

Implementar estas prácticas ayuda a proteger la comunicación y los datos contra las amenazas más recientes y conocidas.