Configurando un servidor de FTP seguro

El objetivo de esta página es documentar la puesta en servicio de un servidor de FTP seguro (SFTP) en una DMZ conectado con un recurso compartido de Windows donde se depositarán los documentos subidos, y con autenticación de los usuarios mediante certificado digital.

Invocamos ssh-keygen con los parámetros que queramos o sin ningún parámetro. En nuestro caso usaremos el parámetro -C para introducir un comentario en la clave pública del certificado que nos indique quién es el propietario. También usaremos el parámetro -t dsa porque queremos fabricar un certificado DSA en lugar de RSA, que es la opción predeterminada.

mysftp:~$ sudo ssh-keygen -t dsa -C usuario@aplicacion

A continuación se nos pide el nombre del fichero que contendrá la clave privada. La clave pública irá en un fichero con el mismo nombre y acabado en .pub.

Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa):

COntestamos con una ruta al almacén de certificados que vamos a usar para todos los clientes del servicio sftp: /altroot/almacen_certificados

Enter passphrase (empty for no passphrase):

Si tecleamos passphrase tendremos que escribir dicha frase cada vez que queramos usar el certificado. En nuestro caso no vamos a usar este sistema de protección adicional, por lo que tecleamos intro

Enter same passphrase again:

De nuevo tecleamos intro

Your identification has been saved in /altroot/almacen_certificados/id_dsa.
Your public key has been saved in /altroot/almacen_certificados/id_dsa.pub.
The key fingerprint is:
83:87:54:77:77:a8:9b:83:f7:64:ac:a6:ae:85:4d:9a usuario@aplicacion

Ya tenemos generados ambos certificados en el almacén.

SCPonly es un shell cuya única función es ejecutar cualquiera de las aplicaciones ssh del sistema y lo hace dentro de una jaula chroot. No dispone de intérprete de comandos, por lo que es el shell ideal para usar cuando queremos que el único servicio que un determinado usuario utilice sea el de FTP seguro.

El resultado de usar SCPonly es que cada usuario solo puede navegar por los directorios que configuremos dentro de su jaula (por ejemplo, el directorio que conectemos con el recurso compartido de Windows), pero no puede “pasear” por el sistema.

Si usamos sftp-server como shell no disponemos de esa privacidad, y el usuario puede pasearse por los directorios del sistema, lo cual viola la privacidad que pretendemos conseguir.

Hay un package en Ubuntu llamado scponly que es una versión que no viene configurada para meter a cada usuario en una jaula (chroot), por lo que para este proyecto no nos vale. En lugar de instalar el package scponly, lo bajamos de la web y lo compilamos para incluir el soporte chroot que no viene en el package.

Esto está explicado en esta misma web en el documento sobre scponlyc: scponlyc

Para más información sobre scponly: http://sublimation.org/scponly/wiki/index.php/FAQ

mysftp:~$ sudo tail -f /var/log/auth.log
Mar 29 09:20:21 mysftp sshd[4575]: Accepted publickey for jherrero from 80.65.41.7 port 1177 ssh2
Mar 29 09:20:21 mysftp sshd[4577]: (pam_unix) session opened for user jherrero by (uid=0)
Mar 29 09:20:21 mysftp sshd[4577]: subsystem request for sftp
Mar 29 09:20:21 mysftp scponly[4578]: running: /usr/lib/sftp-server (username: jherrero(1006), IP/port: 80.65.41.7 1177 22)

Instalamos smbfs para conectar con las unidades remotas

mysftp:~$ aptitude install smbfs

Probamos desde línea de comandos a ver si funciona:

mysftp:~$ smbmount //server/share /mnt -o username=jherrero,password=67yh45f
smbmnt must be installed suid root for direct user mounts
smbmnt failed: 1

En otros sistemas el mensaje es

Dado que el recurso se va a montar en /etc/fstab, no vamos a hacer que los usuarios puedan montar unidades smbfs, por lo que el mensaje “only root can do that” es lo que el usuario debe recibir si intenta montar unidades.

En caso de que necesitemos que los usuarios puedan montar unidades smbfs, debemos activar el permiso *suid root* al programa que se encarga de montar. Esto implica que sea quien sea el que ejecute el comando, éste se ejecutará con las credenciales del propietario del comando, y no con las credenciales del usuario que lo ejecuta. Esto puede tener consecuencias en la seguridad del sistema, por lo que solo ponga el bit de “suid root” cuando realmente lo necesite y en procesos totalmente confiables.

mysftp:~$ ls -l /usr/bin/smbmnt /usr/bin/smbumount
-rwxr-xr-x 1 root root 8832 2007-02-06 02:36 /usr/bin/smbmnt
-rwxr-xr-x 1 root root 6196 2007-02-06 02:36 /usr/bin/smbumount

mysftp:~$ sudo chmod u+s /usr/bin/smbmnt /usr/bin/smbumount
-rwsr-xr-x 1 root root 8832 2007-02-06 02:36 /usr/bin/smbmnt
-rwsr-xr-x 1 root root 6196 2007-02-06 02:36 /usr/bin/smbumount

Ahora ya podemos montar correntamente el recurso compartido Windows usando smbmount.

Un error frecuente es otorgar los permisos “suid root” al programa “smbmount”, ya que es el que nosotros invocamos al querer conectar unidades de red smbfs. Sin embargo, si hacermos esto lo que obtendremos es este bonito error:

libsmb based programs must *NOT* be setuid root.
7246: Connection to 194.140.134.7 failed
SMB connection failed

Si intentamos montar la unidad usando la sintaxis alternativa (con el comando mount) nos encontramos con este mensaje:

mysftp:~$ mount -t smbfs //server/share /mnt -o username=jherrero,password=67yh45f
mount: only root can do that

Esto es normal. El comando mount está reservado al usuario root, y es él el que debe de dar permisos a los usuarios para montar unidades concretas mediante definir esos montajes en el fichero /etc/fstab y ponerles la opcion user, indicando así que ese directorio remoto concreto puede ser montado por usuarios.

Para que se monten automáticamente

//server/share   /altroot/home/jherrero/windows   smbfs   codepage=cp850,iocharset=utf8,dmask=777,fmask=777,credentials=/altroot/wincredentials 0 0

Creamos el fichero de credenciales y solo autorizamos a root a leer o modificar su contenido

mysftp:~$ sudo cat > /altroot/wincredentials
username=jherrero
password=67yh45f
^C
mysftp:~$ sudo chmod 700 /altroot/wincredentials

Especificamos el dominio de la # red Microsoft al que nos vamos a conectar

Change this to the workgroup/NT-domain name your Samba server will part of
   workgroup = DOMINIO-PRUEBAS

$ sftp admin@mysftp
  _____  ______  _______  _____  
 / ____||  ____||__   __||  __ \
| (___  | |__      | |   | |__) |
 \___ \ |  __|     | |   |  ___/
 ____) || |        | |   | | 
|_____/ |_|        |_|   |_|  
                                    
WARNING - YOU ARE NOT WELCOME HERE

Este sistema solo puede ser usado con autorización de un administrador.
No espere privacidad aqui dentro: todas sus acciones serán monitorizadas
y registradas con el fin de asegurar la integridad de nuestros sistemas.
Si detectamos actividad no autorizada tales registros serán usados contra usted.
Su entrada a este sistema implica que está de acuerdo con estas normas.

mysftp:~$

Si se ha configurado el fichero /etc/resolv.conf para usar el servidor DNS interno de nuestra organización (porque los recursos compartidos de Windows se montan por nombre), y no queremos tener que mantener manualmente un fichero de hosts que nos quita flexibilidad si lo servidores cambian de IP, la opción mejor es definir un servidor DNS en la propia máquina que resuelva tanto los nombres de internet como los nombres internos de nuestra organización a sus direcciones privadas.

Esto se hace mediante definir en el servidor un zone forward de la zona privada a los servidores privados, y para el resto de direcciones usar las