Personalmente lo utilzo con relativa frecuencia, generalmente con el cliente FileZilla, un cliente FTP multiplataforma de código abierto muy recomendable. Y siendo honestos, hasta la escritura de esta entrada, mi desconocimiento sobre los modos de conexión activo o pasivo era absoluto, algo que intuyo que le sucede a mucha gente, y ya se sabe que mal de muchos consuelo de tontos entrada en el blog.

FTP, FTPS y SFTP.

Recordemos que existen tres protocolos distintos a los que solemos referirnos cuando hablamos de FTP: FTP, FTPS y SFTP. Si tienes dudas sobre alguno de ellos puedes echarle un vistazo a la entrada FTP, FTPS y SFTP: diferencias, ventajas e inconvenientes.

Pues bien, los modos activo o pasivo solo aplican sobre los protocolos FTP y FTPS, en ningún caso sobre SFTP, pues es un protocolo que dista bastante de los dos anteriores.

Puerto de datos y puerto de control

Otro aspecto clave que debemos conoce para entender el funcionamiento del FTP es que trabaja sobre dos puertos distintos: el puerto de datos y el puerto de comandos o puerto de control.

Los nombres son bastante auto-explicativos, el puerto de datos se encarga de la transmisión de los ficheros y el puerto de control de las instrucciones entre ambos host. Se diseñó así para poder enviar comandos sin la necesidad de detener la transmisión de datos ni de encolarlos tras estos.

Si nos centramos en el servidor, tradicionalmente el puerto de control ha sido el 21 y el puerto de datos varía en función del modo, siendo el 20 para el modo activo, y un puerto aleatorio para el modo pasivo.

En el lado del cliente, en cambio, el puerto de control será un puerto aleatorio P superior a 1023, y el puerto de datos será P+1. Esto es así tanto en el modo activo, como en el pasivo.

Pero veamos cada uno de los modos en detalle para entenderlo mejor.

FTP activo

Es el modo predeterminado para las conexiones FTP, de hecho fue el primero en desarrollarse. En este modo el servidor utilizará el puerto 20 para la transferencia de datos, mientras que transmitirá los comandos utilizando el puerto 21. El cliente en cambio utilizará un puerto aleatorio P superior al 1023 para la transferencia de comandos, y un puerto P+1 para la transferencia de datos.

Secuencia de conexión del modo activo

La secuencia de conexión del modo activo es la siguiente:

1. El cliente FTP comienza la conexión dese un puerto de control aleatorio P con destino al puerto 21 del servidor. Como hemos mencionado el puerto P será superior a 1023.
2. El servidor responde desde el puerto de control.
3. El servidor inicia entonces la conexión del canal de datos: puerto 20 para el servidor y puerto P+1 para el cliente.
4. El cliente responde desde el puerto de datos estableciendo así la conexión.

Inconvenientes del modo activo

Históricamente el principal inconveniente de este modo ha radicado en que si no hay una directiva específica en los firewalls del lado del cliente, la conexión es propensa a ser bloqueada. Esto se debe a que, como hemos visto, existen dos conexiones independientes: una de salida en la que el cliente establece la conexión del canal de control y otra de entrada en la que el servidor hace lo propio con el de datos. Esta última conexión es iniciada por el servidor en el puerto previamente negociado, y en ocasiones es bloqueada por el firewall del cliente al ser identificada como un intento de conexión externa no autorizada.

Recordemos que este sistema se diseñó en los años 70, cuando la democratización de los sistemas informáticos y los problemas de seguridad eran completamente distintos a los que podemos encontrar hoy en día.

Sea como sea, en todos los años que llevo utilizando el protocolo FTP desde el rol de cliente, no recuerdo haber experimentado nunca problemas de este tipo, y habré conectado con varias decenas de servidores de muchos proveedores distintos. Entiendo que esto se deba a la sofisticación de los sistemas de red y de seguridad más modernos.

FTP pasivo

El modo de FTP pasivo surge como consecuencia de los problemas de conexión del modo activo. Este modo mantiene los dos canales (control y datos) pero en este caso es el cliente el encargado de establecer las dos conexiones.

El servidor sigue manteniendo el puerto 21 como puerto de comandos, el puerto de datos en cambio difiere del modo activo y pasa a ser un rango de puertos Q superior a 1023. Del lado del cliente seguimos manteniendo el puerto P superior a 1023 para control, y el puerto P+1 para datos.

Secuencia de conexión del modo pasivo

La secuencia de conexión del modo pasivo es la que sigue a continuación:

1. El cliente FTP comienza la conexión dese un puerto de control aleatorio P con destino al puerto 21 del servidor.
2. El servidor responde desde el puerto de control.
3. El cliente inicia la conexión del canal de datos dese el puerto P+1 hacia el puerto Q del servidor.
4. El servidor responde desde el puerto de datos estableciendo así la conexión.

Como ves, los pasos uno y dos son iguales que en el modo activo, y es en los pasos tres y cuatro dónde vemos como se invierten los roles y es el cliente el que inicia la conexión de datos.

Inconvenientes del modo pasivo del FTP

El principal inconveniente de habilitar el modo pasivo en un servidor FTP está asociado con el riesgo extra en materia de seguridad que conlleva la apertura de un rango de puertos extra con respecto al modo activo. Notemos que para que el modo pasivo funcione adecuadamente estos puertos deben ser abiertos tanto en el servidor como en el firewall.

Para minimizar este riesgo la estrategia pasa por definir un rango de puertos lo más pequeño posible en función del número de conexiones concurrentes que esperemos tener, pero ojo, porque un cliente no se corresponde con una única conexión, es muy probable que cada cliente abra múltiples conexiones concurrentes.

Resumen

Para cerrar esta entrada os dejo una tabla con el resumen de lo que hemos visto.

Créditos, referencias y artículos relacionados

• Imagen de portada por Michal Jarmoluk en Pixabay
• FTP, FTPS y SFTP: diferencias, ventajas e inconvenientes
• VSFTP instalar y configurar un servidor FTP en una Raspberry Pi con Ubuntu
• FTPS o cómo habilitar SSL en vsftp
• Usuarios virtuales en vsftp

Y uno de esos valores que a veces se quedan cortos es la cantidad de memoria máxima que un script desarrollado en PHP puede consumir, así que hoy veremos como aumentar ese límite.

Fatal error: Allowed memory size of 134217728 bytes exhausted

Alcanzar el límite máximo de memoria de nuestro servidor no es algo demasiado habitual. La configuración por defecto tiene un valor lo suficientemente amplio como para que podamos ejecutar la mayoría de las aplicaciones sin problema alguno. Pero en caso de alcanzarlo,el sistema devuelve el siguiente error:

Fatal error: Allowed memory size of 134217728 bytes exhausted

Con la salvedad de que el número de bytes puede variar en función de la configuración del servidor.

Medida de protección

Que PHP disponga de un límite máximo de consumo de memoria en la ejecución de cada script es una medida de protección, no olvidemos que la memoria en una máquina es un recurso finito. Así que antes de ampliar este parámetro, mi consejo es que nos aseguremos de que:

1. No es un bug en nuestro script el que crea la necesidad de ampliar la memoria.
2. Nuestro script está razonablemente optimizado.

Es decir, nada que no debamos hacer con cualquier otro script que no supere el límite máximo de memoria definido. Porque si recordáis una de las primeras lecciones que aprendemos (o al menos que deberíamos aprender) al comenzar a programar es que nuestro código debe cumplir tres requisitos fundamentales:

1. Estar libre de errores
2. Ser eficiente
3. Ser comprensible

Cómo aumentar el límite máximo de memoria para un script PHP

Por defecto, el límite máximo de memoria que un script PHP puede consumir es de 128Mb, algo más que razonable. Si ya tenemos claro que queremos aumentar este límite podemos hacerlo de dos formas.

Con la función init_set()

Con la función init_set() pasando el string memory_limit como primer parámetro y la cantidad de memoria deseada como segundo. Con este método, el nuevo limite afectará única y exclusivamente al script dónde lo estemos utilizando, es decir, sin afectar a la configuración general del servidor.

<?php

ini_set('memory_limit', '256M');

...

?>

En el archivo php.ini

En este caso, la principal diferencia con respecto al método anterior es que el nuevo límite afectará a todos los scripts PHP que se ejecuten en el servidor dónde apliquemos esta configuración. Para definir el nuevo límite, buscamos la directriz memory_limit, dentro de la sección Resources Limits, en el archivo php.ini y modificamos su valor.

;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;

...

; Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
memory_limit=256M

Y acto seguido reiniciamos el servidor Apache 2 para que los cambios surtan efecto.:

sudo service apache2 restart

La ubicación del archivo php.ini variará en función del sistema que estemos utilizando. En los sistemas Linux basados en Debian como Ubuntu la ubicación será /etc/php/X.X/apache2, donde X.X será la versión de PHP.

Comprobar límite máximo de memoria de un script PHP

Podemos comprobar el valor máximo de memoria que utiliza un script configurado en nuestro servidor en la sección Core de la salida de la función phpinfo():

O como acabamos de ver, accediendo al archivo de configuración php.ini:

Créditos, referencias y artículos relacionados

• Imagen de portada: Public Domain Pictures
• Aumentar el limite de tiempo máximo de ejecución de un script en PHP.
• Documentación de la función php init_set()
• Servidor Web en Raspberry PI y Ubuntu Mate
• Como configurar Virtual Hosts en Apache 2 y Ubuntu
• Habilitar módulos en Apache 2 sobre Ubuntu

Algunos de ellos pueden ser: la memoria consumida en la ejecución del script, el tamaño de los archivos subidos al servidor, el número de variables pasadas por get o por post, etc.

En esta estrada hablamos sobre el límite de tiempo de ejecución de un script.

Fatal error: Maximum execution time of 30 seconds exceeded

Este es el error que nos encontraremos si nuestro script sobrepasa el tiempo máximo de ejecución definido.

Encontrarnos con este error no es una situación excesivamente habitual y en muchos casos puede ser el resultado de un error de programación, como por ejemplo una rutina que nos haga entrar en un bucle infinito.

Pero también es posible alcanzar ese límite por las propias exigencias de nuestro software. En mi caso, me he encontrado con esta situación al desarrollar aplicaciones empresariales que procesan una gran cantidad de datos.

Medida de protección

Que PHP disponga de un límite máximo de tiempo de ejecución para los scripts es una medida de protección que puede librarnos de largas esperas e incluso de algún reinicio. La experiencia me dice que en algunas ocasiones un bucle infinito puede dejar un equipo completamente bloqueado.

Así que antes de ampliar el tiempo máximo de ejecución mi consejo es que nos aseguremos de que:

1. No es un bug en nuestro script el que crea la necesidad de ampliar este tiempo.
2. Nuestro script está razonablemente optimizado.

Es decir, nada que no debamos hacer con cualquier otro script que no supere el tiempo de ejecución máximo.

Cómo aumentar el límite el tiempo de ejecución de un script PHP

Por defecto, el tiempo máximo de ejecución de un script es de 30 segundos. Si ya tenemos claro que queremos aumentar este tiempo podemos hacerlo de varias formas.

Con la función set_time_limit()

Utilizaremos esta función al comienzo de nuestro script definiendo el tiempo máximo de ejecución en segundos. Por lo tanto, con este método el nuevo limite afectará única y exclusivamente al script dónde lo utilicemos.

<?php

set_time_limit(60);

...

?>

Debemos puntualizar que en caso de que estemos utilizando php en modo seguro esta función no tendrá ningún efecto.

Con la función init_set()

Este sistema funciona exactamente igual que set_time_limit(), con la única diferencia que utilizaremos la función init_set() pasando el string max_execution_time como primer parámetro.

<?php

ini_set('max_execution_time', 60);

...

?>

En el archivo php.ini

En este caso, la principal diferencia entre este método y los dos anteriores es que el nuevo límite afectará a todos los scripts PHP que se ejecuten en el servidor dónde apliquemos esta configuración. Para aplicarlo, buscamos la directriz max_execution_time, dentro de la sección Resources Limits, en el archivo php.ini y modificamos su valor.

;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;

; Maximum execution time of each script, in seconds
; http://php.net/max-execution-time
; Note: This directive is hardcoded to 0 for the CLI SAPI
max_execution_time = 60

Y acto seguido reiniciamos el servidor Apache 2 para que los cambios surtan efecto.:

sudo service apache2 restart

La ubicación del archivo php.ini variará en función del sistema que estemos utilizando. En los sistemas Linux basados en Debian como Ubuntu la ubicación será /etc/php/X.X/apache2, donde X.X será la versión de PHP.

En el archivo .htaccess

Esta es quizás la opción menos conocida de las que mostramos en esta entrada, pero es una de las más interesante en cuanto a que podemos conseguir que la nueva directriz aplique a todos los scripts cuando no tenemos acceso al archivo php.ini.

Para aplicar este sistema editaremos el archivo .htaccess que nos interese incluyendo las siguientes líneas:

<IfModule mod_php7.c>
php_value max_execution_time 60
</IfModule>

Si nuestro servidor utiliza una versión 5.X de PHP en lugar de una versión 7.X, solo habría que cambiar mod_php7.c por mod_php5.c.

Cómo comprobar el valor de tiempo máximo de ejecución

Podemos comprobar el valor de tiempo máximo de ejecución configurado en nuestro servidor en la sección Core de la salida de la función phpinfo():

O como acabamos de ver, accediendo al archivo de configuración php.ini:

Créditos, referencias y artículos relacionados

• Imagen de portada: Michael Jarmoluk
• Documentación de la función php set_time_limit()
• Documentación de la función php init_set()
• Servidor Web en Raspberry PI y Ubuntu Mate
• Como configurar Virtual Hosts en Apache 2 y Ubuntu
• Habilitar módulos en Apache 2 sobre Ubuntu

Así que puestos a escribir sobre habilitar módulos, y dado que es una tarea bastante habitual habitual cuando instalamos un nuevo servidor web, o incluso cuando instalamos algunos paquetes de software sobre un servidor web existente, decidí escribir esta entrada más generalista.

Y es que en la actualidad, en una instalación estándar de Apache 2 sobre Ubuntu 18 se instalan más de 100 módulos, de los cuales sólo hay activos algo más de una veintena.

Habilitar módulos

Lejos quedan los tiempos en los que para habilitar módulos de Apache teníamos que editar el archivo apache.conf, tarea que generalmente no consistía más que en descomentar alguna línea. Hoy basta con ejecutar el comando a2enmod y reiniciar el servidor:

sudo a2enmod modulo
sudo service apache2 restart

Pero descubramos que hay detrás de de este comando.

Los módulos disponibles por Apache 2 se encuentran dentro del directorio /etc/apache2/mods-available/. Lo que quiere decir que si el módulo que queremos habilitar no se encuentra ahí tendremos que copiarlo y asignarle los permisos adecuados.

Por otro lado, los módulos habilitados se encuentran en el directorio /etc/apache2/mods-enabled/. Pero en este caso en lugar de encontrar archivos, encontraremos enlaces simbólicos a los archivos situados en la carpeta /etc/apache2/mods-available/. Así que una alternativa al comando a2enmod es el comando ln:

sudo ln -s /etc/apache2/mods-available/modulo /etc/apache2/mods-enabled/modulo
sudo service apache2 restart

Deshabilitar módulos

Y para deshabilitar módulos la operación es muy similar, con la salvedad de que en lugar de utilizar el comando a2enmod utilizaremos el comando a2dismod:

sudo a2dismod modulo
sudo service apache2 restart

O simplemente eliminaremos el enlace simbólico:

sudo rm /etc/apache2/mods-enabled/modulo
sudo service apache2 restart

Comprobaciones y logs de errores

Podemos saber si un módulo se ha instalado correctamente revisando la salida de la función phpinfo() de php, en la sección apache2handler.

Y en caso de experimentar cualquier tipo de problema, el primer lugar dónde consultar qué está ocurriendo son los logs de error de Apache 2, en el archivo /var/log/apache2/error.log.

cat /var/log/apache2/error.log

Créditos, referencias y artículos relacionados

• Imagen de portada por Wichan Yodsawai.
• Servidor Web en Raspberry PI y Ubuntu Mate.
• Como configurar Virtual Hosts en Apache 2 y Ubuntu.
• Archivos y permisos de usuario en Apache 2 y Linux.

A pesar de que Cron tiene un funcionamiento bastante sencillo y está bien documentado en internet, no he querido dejar pasar la oportunidad de aportar mi granito de arena al tema, y aprovechando que estoy preparando una entrada que requiere de la ejecución programada de una tarea he escrito estas líneas.

Además, aunque es más que probable que si ya tienes cierta experiencia con sistemas operativos Linux esta entrada no te desvele nada nuevo (o si, quien sabe), seguro que a más de un lector con menos experiencia en este ámbito le resulta de interés.

Cron

Cron es un demonio concebido para ejecutar tareas previamente programadas de forma periódica.

Y por demonio entendemos un programa que se ejecuta en segundo plano, que carece de interface para interactuar con él y que por norma general se inicia en el arranque del sistema, es el equivalente en Linux de los servicios en Windows.

Y como cualquier demonio o servicio en Linux podemos arrancarlo, pararlo, reiniciarlo o comprobar su estado con el comando service:

sudo service cron start
sudo service cron stop
sudo service cron restart
sudo service cron status

Crontab

Crontab es el nombre que se le da a los archivos dónde definimos las tareas programadas y la frecuencia con la que se ejecutarán. El nombre de crontab proviene de las palabras cron table.

Existe un archivo crontab «principal» /etc/crontab, que será gestionado por el administrador del equipo, pero además cada usuario del sistema tiene el suyo propio archivo.

Estructura de ficheros crontab

Los ficheros crontab son simples ficheros de texto dónde especificaremos una tarea por línea, y la estructura de cada línea es la siguiente:

# ┌───────────── minutos
# |
# │ ┌───────────── horas
# | |
# │ │ ┌───────────── día del mes
# | | |
# │ │ │ ┌───────────── mes
# | | | |
# │ │ │ │ ┌───────────── día de la semana
# │ │ │ │ │
# │ │ │ │ │
  * * * * * comando

Como puedes apreciar, en cada línea hay cinco campos reservados a definir la periodicidad, y uno más para hacer lo propio con el comando a ejecutar, todos ellos separados por espacios. Todos los campos deben ser rellenados obligatoriamente. Los rangos de valores posibles para cada campo son:

• Campo minutos: 0 – 59
• Campo horas: 0 – 23
• Campo día del mes: 0 – 31
• Campo mes: 1 – 12
• Campo día de la semana: 0 – 6, dónde 0 es domingo y 6 sábado.

Caracteres especiales en crontab

Para definir la periodicidad de la tarea, podemos ayudarnos de algunos «modificadores» que nos permitirán ampliar enormemente las posibilidades:

Otro carácter imprescindible es la almohadilla (#), que lo utilizaremos al comienzo de una línea para indicar que es un comentario.

Ejemplos de tareas programadas

Para disipar cualquier duda que podamos tener con respecto de los ficheros crontab, lo más sencillo es que veamos algunos ejemplos:

# Diariamente a las 02:00 am, ejecutamos el script definido
* 2 * * * service /home/user/script.sh

# Cada lunes a las 02:00 am, reiniciamos Apache
* 2 * * 1 service apache2 restart

# Cada 5 minutos, monitoreamos el estado de nuestra web
*/5 * * * * /home/user/checkSiteStatus.sh

# Cada hora, limpiamos la cache
0 * * * * * /home/user/cleanCache.sh

# De lunes a viernes a las 14:00, enviamos un e-mail
0 14 * * 1-5 /home/user/mail.sh

# los días 5,15 y 25 del mes a las 00:00, enviamos un informe
0 0 5,15,25 * * /home/user/sendReport.sh

Como ves, este sistema es realmente sencillo y versátil, ofreciéndonos muchas opciones para programar la ejecución de nuestras tareas. Si aún así tienes dudas, puedes realizar tus pruebas en la web Crontab Guru, una herramienta on-line muy útil.

Administrar las tareas programadas en Cron

Ahora que ya tenemos claros los fundamentos, vamos a ver como realizar las tareas más habituales.

Agregar una nueva tarea

Ya hemos explicado que para programar una tarea debemos incluirla en el archivo crontab, y para ello utilizaremos nuestro editor preferido:

sudo vim /etc/crontab

Pero además del archivo principal de crontab, cada usuario tiene el suyo propio, de forma que podemos programar tareas sin ser administrador del equipo. Para editar este archivo utilizaremos la orden:

crontab -e

Y si tenemos los permisos necesarios, poder editar el archivo crontab de otros usuarios ayudándonos del modificador -u seguido del nombre de usuario:

crontab -e -u usuario

Así que ahora solo quedaría agregar las tareas que nos interesen siguiendo las indicaciones que ya hemos visto. Aprovecho para hacer referencia al artículo Comandos en Vim por si quéreis echarle un vistazo,

Ver las tareas programadas

En este punto podemos hacer uso de alguno de los múltiples comandos que nos ofrece Linux para visualizar archivos como puede ser el comando more:

more /etc/crontab

O en caso de querer ver el archivo crontab de un usuario lo haremos con la orden crontab -l, utilizando o no el modificador -u en función de nuestras necesidades:

crontab -l
crontab -u usuario -l

Resetear el archivo crontab

Esta opción bien podría haberla omitido por lo delicada, pero ahí la dejo:

crontab -r

Ojo que no pide confirmación.

Logs en Cron

Los logs de Cron se almacenan en el archivo /var/log/syslog, pero este archivo contiene otros logs además de los que nos interesan. Si queremos ver exclusivamente los losg de cron podemos lanzar el siguiente comando:

grep CRON /var/log/syslog

La información que recibiremos no es muy detallada, pero en caso de tener alguna duda es buen buen lugar para comenzar a investigar.

Créditos y referencias

• Imagen principal: jairojehuel
• man crontab en man7.org
• man cron en man7.org cron

Esta entrada continua el contenido iniciado en el artículo VSFTP instalar y configurar un servidor FTP en una Raspberry Pi con Ubuntu, desde dónde enlazamos más contenido relacionado con la insralación y la configuración de vsftp.

Usuarios virtuales vs usuarios de sistema

La configuración por defecto de vsftp nos permite autentificarnos con las credenciales de los usuarios que tengamos creados en el sistema, dándonos acceso a las mismas carpetas a las que estos tienen acceso. Pero además nos permite autentificarnos con usuarios virtuales creados especificamente para acceder por ftp a una determinada carpeta. Y lo mejor de todo es que estas dos opciones son totalmente compatible entre si, pudiendo elegir entre:

1. Habilitar solo el acceso de los usuarios del sistema (por defecto).
2. Habilitar solo el acceso de usuarios virtuales.
3. Habilitar el acceso de usuarios del sistema y usuarios virtuales.

/etc/vsftps.conf

Para no extendernos demasiado en esta entrada, a continuación veremos el resultado final del archivo /etc/vsftpd.conf. Si estás interesado en conocer los detalles de cada línea de configuración puede echarle un vistazo a la documentación oficial de vsftp en este enlace. Para facilitar la lectura hemos eliminado todas las líneas de comentarios originales del archivo:

# configuración excluyendo comentarios
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
secure_chroot_dir=/var/run/vsftpd/empty
user_sub_token=$USER
hide_ids=YES
listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
chroot_local_user=YES
allow_writeable_chroot=YES
hide_ids=YES

# Configuración específica de usuarios virtuales
user_config_dir=/etc/vsftpd/usersConf
guest_enable=YES
virtual_use_local_privs=YES
pam_service_name=vsftpd

Creación de usuarios virtuales

Una vez realizada la configuración de vsftp, lo siguiente que haremos será crear los usuarios virtuales. Para ello crearemos un directorio dónde alojar los ficheros de autentificación y acto seguido los propios ficheros, que en este ejemplo serán dos, uno por usuario. Por algún motivo que desconozco no he podido hacer funcionar la autentificación con PAM sin incluir la opción -d en la creación de los ficheros de autentificación, lo que nos limita a contraseñas con un máximo de 8 caracteres, una opción que lamentablemente reduce bastante la seguridad.

sudo mkdir /etc/vsftpd
sudo htpasswd -c -d /etc/vsftpd/ftpd.passwd ftpUser1
sudo htpasswd -d /etc/vsftpd/ftpd.passwd ftpUser2

El comando htpasswd nos solicitará que definamos la contraseña y que la confirmemos, y ojo que en el segundo usuario hemos omitido la opción -c, solo es necesario incluirla con el primer usuario, si la incluimos en el segundo o sucesivos truncaremos el fichero y por lo tanto únicamente dejaremos el último usuario que hemos creado.

Instalación y Configuración de PAM

Como adelantabamos en el punto anterior utilizaremos PAM (Pluggable Authentication Modules) para la autentificación de los usuarios, así que si no lo tenemos instalado deberemos hacerlo:

sudo apt-get update
sudo apt-get install libpam-pwdfilev

El archivo de configuración de PAM para el servicio vsftp por defecto se encuentra en /etc/pam.d/vsftp, notad que hicimos referencia a él en la configuración de vsftp mediante la directiva pam_service_name. Así que por seguridad realizaremos una copia de seguridad de este archivo y acto seguido lo editaremos de forma que quede así:

auth required pam_pwdfile.so pwdfile /etc/vsftpd/ftpd.passwd
account required pam_permit.so

Como ves, le estamos indicando que utilice el archivo que acabamos de crear con el comando htpasswd para autentificar a los usuarios virtuales.

Directorios de usuarios virtuales

El último paso que nos queda para tener nuestro servicio funcionando es definir cuales serán los directorios a los que tendrán acceso los usuarios. Para realizar esta configuración crearemos un archivo por cada usuario al que estemos concediendo acceso, y para mantenerlos organizados los almacenaremos dentro de un directorio que crearemos a tal efecto, al que ya hemos hecho referencia en /etc/vsftpd.conf mediante la directiva user_config_dir. El nombre de cada archivo debe ser idéntico al nombre de usuario al que hace referencia:

sudo mkdir /etc/vsftpd/usersConf
sudo vim /etc/vsftpd/usersConf/ftpUser1
sudo vim /etc/vsftpd/usersConf/ftpUser2

El contenido de cada archivo debe hacer referencia al directorio al que le estamos concediendo acceso de la siguiente manera:

local_root=/var/www/targetDir

Permisos de escritura

Un aspecto de gran importancia es configurar correctamente los permisos de escritura del directorio de cada usuario, en caso contrario nos encontraremos con un error cuando intentemos cargar cualquier archivo en nuestro servidor.

En nuestro caso, estamos concediendo acceso a una carpeta de un servidor web, así que daremos por hecho que los permisos están configurados tal y como explicamos en la entrada Archivos y permisos de usuario en Apache 2 y Linux.

sudo usermod -a -G www-data ftpd
sudo chown ftpd:www-data /var/www/users/ftpUser1

Comprobamos que todo funciona

Reiniciamos el servidor y comprobamos que todo funciona:

sudo service vsftpd restart

Recuerda que si tienes algún problemalor archivos de logs de vsftp están en /var/log/vsftp.log y los logs de autentificación /var/log/auth.log.

Lamentablemente, según mi experiencia, esa practica no está tan extendida en los servidores ftp, dónde a día de hoy todavía todavía existen un gran número de ellos que no implementan el protocolo FTPS, haciendo uso de conexiones sin encriptar y por lo tanto menos seguras. Una lástima teniendo en cuenta que no es algo complicado.

Hoy veremos cómo habilitar el protocolo FTPS en nuestro servidor vsftp, ampliando el contenido publicado en el artículo VSFTP instalar y configurar un servidor FTP en una Raspberry Pi con Ubuntu. Además, es muy probable que también te interese echarle un vistazo a la entrada FTP, FTPS y SFTP: diferencias, ventajas e inconvenientes, pues es una buena introducción si no estás familiarizado con estos protocolos.

Esta configuración está realizada sobre Ubuntu Mate 16.0.4.2 corriendo en una Raspberry PI, pero es perfectamente aplicable a otras distribuciones y versiones de Linux y otros hardwares.

Asumiremos que ya tenemos nuestro servidor vsftp funcionando y que tenemos OpenSSL instalado. Así que el primer paso será crear los certificados SSL pertinentes:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem

A continuación agregamos las siguientes líneas al final del archivo /etc/vsftpd.conf:

# Opciones para el certificado SSL
rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.pem
ssl_enable=YES

Ya solo nos queda reiniciar el servidor y comprobar que la configuración que hemos aplicado funciona correctamente.

sudo service vsftpd restart

Y con estos sencillos pasos hemos terminado, mejorando notablemente la seguridad de nuestro servidor FTP.

Esta entrada pertenece a la serie de artículos sobre cómo utilizar una Raspberry PI como herramienta de apoyo para el desarrollo web, y veremos como instalar y configurar vsftp en Ubuntu, crear usuarios virtuales y habilitar el acceso con el protocolo FTPS.

vsftp

Puestos a implementar una solución ftp el primer paso será elegir uno de las muchas posibilidades que existen en el mercado. Si ya hemos descartado el protocolo SFTP, y queremos un servidor FTP o FTPS que nos permita mantener la simplicidad pero ampliando la versatilidad, y que además esté disponible bajo licencia de software libre, vsftp (Very Secure FTP) es una buena opción.

Además otra de las ventajas de Vsftp es que su uso está muy extendido y es fácil resolver cualquier duda con alguna consulta en internet, y entre algunas de sus características podemos destacar:

• Usuarios virtuales
• Configuración avanzada por usuario
• Configuración por IP de origen
• Límites por IP de origen
• Limitación de ancho de banda
• Encriptación sobre SSL

Características más que suficientes para cubrir muchos de los casos que podemos necesitar.

Por otro lado, si leiste el articulo FTP, FTPS y SFTP: diferencias, ventajas e inconvenientes, es interesante destacar que es totalmente compatible tener habilitado el acceso SFTP y el acceso FTP y FTPS con Vsftp. Esto nos permitiría por ejemplo utilizar SFTP para los usuarios del sistema y FTPS para una lista de usuarios específicos con unas necesidades distintas.

Instalar vsftp

Como es habitual la instalación de cualquier programa incluido en los repositorios de una distro es algo muy sencillo.

sudo apt-get update
sudo apt-get install vsftpd

Tras la instalación de vsftp el servidor es perfectamente funcional con los usuarios del sistema

Configurar vsftp

La configuración de vsftp ofrece muchas posibilidades y se realiza en el archivo /etc/vsftpd.conf, puedes ver todas las opciones de configuración que tiene en este enlace.

En cuanto a las configuraciones que vamos a aplicar lo haremos en entradas separadas para facilitar la organización y la lectura y evitar que esto se convierta en un artículo demasiado largo y aburrido. A continuación tienes los enlaces:

• Creación y configuración de usuarios virtuales
• Habilitar el acceso por FTPS

Comprobamos que todo funciona

Después de aplicar cualquier configuración deberemos probar que funciona correctamente, para ello el primer paso será reiniciar el servidor para aplicar la nueva configuración y acto seguido conectarnos con nuestro cliente ftp favorito.

sudo service vsftpd restart

En caso de que tengamos algún tipo de problema podemos revisar los logs de vsftp en /var/log/vsftp.log y los logs de autentificación /var/log/auth.log. Ojo que podemos tener más de un archivo de log por servicio.

El uso del FTP suponía para mi una de esas situaciones, lo utilizo con relativa frecuencia pero nunca me había cuestionado cual era la diferencia entre FTPS y SFTP. Si bien sabía que ambos añadían una capa de encriptación con respecto al protocolo FTP,  desconocía por completo que era lo que les distinguía. Así que cuando configuraba una nueva conexión, seleccionaba la opciones que me permitía conectar sin darle mayor importancia.

El caso es que hace unas semanas instalé un servidor FTP en mi Raspberry. No es el primero que instalo, pero cuando lo he hecho siempre han estado destinados a ámbitos muy concretos, protegidos por una red local y su uso ha sido prácticamente unipersonal,  por lo que nunca me preocupé demasiado por los detalles más allá de que me permitieran conectar y hacer mi trabajo.

La diferencia fue que en esta ocasión quise profundizar un poco más, conocer exactamente la diferencia entre los distintos protocolos y aplicar configuraciones más complejas y eso es lo que os cuento en esta y otras entradas que vendrán.

FTP

FTP son siglas de File Transfer Protocol, es un protocolo que lleva con nosotros desde la década de los 70 y fue diseñado para la transferencia de archivos a través de la red con  una configuración de cliente-servidor.

Su principal defecto es que carece de capa alguna de seguridad, los datos viajan por la red en texto plano, sin encriptación, de modo que es muy sencillo interceptar no solo los archivos que se transmiten sino también los datos de autentificación. Por otro lado, esta ausencia de encriptación es la responsable de que sea el protocolo de transmisión más rápido de los que veremos en esta entrada, pues no existe consumo de recursos relacionados con la encriptación y el tamaño de los paquetes transmitidos es menor.

Por defecto hace uso del puerto 21 y es el precursor de los otros dos protocolos que vamos a ver en esta entrada.

FTPS

Las siglas FTPS provienen de FTP over SSL y no es más que el protocolo estándar FTP transmitido sobre una conexión segura. Inicialmente la conexión segura hacía referencia únicamente  SSL (Secure Sockets Layer), pero con el  paso del tiempo y la aparición del protocolo TLS (Transport Layer Security), también soporta este último. Este protocolo hace uso de dos canales diferentes: uno de control y otro de transferencia, y tiene dos variantes bien diferenciadas:

• FTP implicito sobre SSL. Recibe este nombre porque la conexión cifrada es implicita, es decir, ocurre desde un primer instante, sin necesidad de solicitarla, motivo por el cual además está desaconsejada (deprecated). Por defecto utiliza el puerto 990 para el canal de control y el 998 para el de datos, de forma que el puerto 21 permanece libre para poder ofrecer un servicio FTP estandar. En cualquier caso los dos canales viajan encriptados.
• FTP explicito sobre SSL o también conocido como FTPES. El cliente establece una conexión FTP estándar mediante el puerto 21 con el servidor y una vez conectado se solicita explícitamente la negociación SSL, de ahí el nombre. En función de la configuración del servidor, si el cliente no solicita la encriptación es posible que ocurran dos cosas: que se rechace la conexión o que se establezca una conexión FTP estándar (insegura). Esta variante permite decidir si queremos encriptar los canales de control y transferencia o si por el contrario solo queremos encriptar uno de ellos.

Un aspecto que puede resultar negativo de este protocolo es que por el hecho de utilizar más de un canal puede resultar problemático con algunas configuraciones en los firewalls, así que es posible que si tenemos un firewall en funcionamiento e implementamos un servidor FTPS nos veremos obligados a revisar su configuración.

STFP

SFTP o SSH File Transfer Protocol es un protocolo que «simula» el comportamiento del protocolo FTP pero que realmente poco o nada tiene que ver con él, no es una extensión o una mejora como puede ser FTPS, si no que fue desarrollado desde cero.

Tanto los datos de control como de transferencia se transmiten siempre encriptados y por un único canal, utilizando para ello el puerto 22 al igual que el protocolo SSH (Secure SHell) sobre el que está construido. Posiblemente por este motivo muchos servidores FTP implementan los protocolos FTP Y FTPS pero no SFTP. En su lugar podemos ver implementaciones  de servidores SFTP de la mano de los propios servidores de SSH, algunos ejemplos son OpenSSH o LSH.

SFTP ha sido el último protocolo en llegar y cabe destacar que su especificación nunca ha pasado de ser un borrador, es decir, no existe un documento RFC.

Conclusión

Es interesante conocer qué hay detrás de los distintos protocolos de transmisión de ficheros para poder decidir cual es el que mejor se adapta a las necesidades que tengamos en cada momento.

Mi recomendación dependerá del uso que le vayamos a dar, pero siempre que sea posible utilizaría un protocolo que implemente una capa de encriptación y no esté desaconsejado (deprecated), es decir: SFTP o FTPES.

¿Y tú qué opinas al respecto? ¿Qué protocolo prefieres y por qué? ¿Has tenido alguna mala experiencia por utilizar un FTP sin encriptación? Déjanos un comentario contándonos tu experiencia.

Créditos, referencias y artículos relacionados

• VSFTP instalar y configurar un servidor FTP en una Raspberry Pi con Ubuntu
• FTPS o cómo habilitar SSL en vsftp
• Usuarios virtuales en vsftp

Los ejemplos de este documento han sido probados tanto sobre Ubuntu Mate 16.0.4.2 y Apache 2.4.18 como sobre XUbuntu 18.04 con la versión 2.4.29 de Apache, aunque funcionarán sobre la mayoría de distribuciones Linux con la versión 2.4 de Apache.

Para el resto del artículo, asumiremos que la ip de la máquina dónde estamos configurando los host virtuales es 192.168.1.10.

¿Qué es un virtual host en Apache 2?

Virtual host es la herramienta que Apache pone a nuestra disposición para poder publicar más de una página web en un mismo servidor Apache, y que además,  nos permite mantener configuraciones diferentes para cada host virtual.

Al realizar una petición al servidor web, Apache puede identificar a que site (host virtual) queremos acceden en función de tres variables relacionadas con la solicitud realuzada al servidor:

1. La IP
2. El Host Name
3. El puerto

En este artículo distinguiremos los host virtuales por el puerto, pues es lo que utilizo habitualmente en mi entorno de desarrollo por una simple cuestión de comodidad.

Nociones de configuración

Toda la configuración de Apache 2 se encuentra bajo la carpeta /var/apache2. Los archivos de configuración para los virtual hosts se encuentran dentro de dos carpetas en particular:

1. /var/apache2/sites-available. En esta carpeta se encuentran todos los archivos de configuración de los hosts virtuales, cada host se corresponde con un archivo.
2. /var/apache2/sites-enabled. En esta carpeta se crearán enlaces simbólicos a los archivos de la carpeta sites-available para los host que queramos activar en cada momento.

Con la instalación de Apache, se creará por defecto, el archivo /etc/apache2/sites-available/000-default.conf y su correspondiente enlace simbólico en la carpeta sites-enabled que se encarga de configurar el host virtual por defecto al que accedemos tras instalar Apache.

Cómo crear un virtual host

Crear host virtuales es una tarea relativamente habitual, así que los señores desarrolladores de Apache nos lo han puesto bastante sencillo.

A continuación crearemos un host virtual para alojar un entorno de pruebas de este blog. Para entender mejor el proceso, a pesar de que es sencillo, lo dividiremos en cuatro pasos:

Paso 1: Creamos el directorio que alojará nuestra web

Lo primero será crear el directorio dónde alojaremos los archivos que posteriormente serviremos.

cd /var/www
sudo mkdir ahierro.es
cd ahierro.es
sudo mkdir public

La carpeta que serviremos será public, es buena idea guardarse un nivel de directorio para archivos relacionados con el proyecto que no deben ser accesibles desde una url en el navegador. Esto es bastante habitual en muchas aplicaciones y frameworks.

En este paso del proceso es importante dejar correctamente configurados los permisos de acceso a los archivos y carpetas de nuestro host virtual. Para ello os dejo un enlace al artículo Archivos y permisos de usuario en Apache 2 y Linux por si queréis echarle un vistazo.

Paso 2: Creamos el archivo de configuración del nuevo host virtual

Ahora crearemos el archivo de configuración en /etc/apache2/sites-available, lo más sencillo es hacerlo desde otro que ya exista. Es muy importante que lleve la extensión .conf o el comando a2ensite no funcionará más adelante:

cd /etc/apache2/sites-available
sudo cp 000-default.conf ahierro.es.conf

Lo editamos:

sudo vim ahierro.es.conf

Inicialmente tenemos algo así:

<VirtualHost *:80>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com

ServerAdmin webmaster@localhost
DocumentRoot /var/www/html

# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
</VirtualHost>

Y tras modificarlo debe quedar así:

<VirtualHost *:80>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com

ServerAdmin webmaster@localhost
DocumentRoot /var/www/ahierro.es/public

# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf

<Directory /var/www/ahierro.es/public>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>

</VirtualHost>

Como podemos ver en la línea 1 hemos cambiado :80 por :8085, con lo que estamos indicando que a este virtualhost accederemos mediante este puerto. Personalmente suelo comenzar con el puerto 8080, en este ejemplo he especificado el 8085 porque ya tengo otros cinco host virtuales.

En la línea 12 lo único que hemos hecho es actualizar la referencia al directorio raíz para asegurarnos que apunta al lugar adecuado.

Y por último hemos añadido una nueva sección a partir de la línea 30 con unas directrices básicas entre las que hemos habilitado el módulo mod_rewrite, necesario para la re-escritura de urls.

Paso 3: Abrimos el puerto adecuado en Apache

Por defecto Apache solo atiende solicitudes por el puerto 80. Para conseguir que también atienda las que llegan por el puerto 8085, que es el que hemos indicado en nuestro fichero de configuración del virtual host, debemos editar el archivo /etc/apache2/ports.conf.

sudo vim /etc/apache2/ports.conf

El contenido del fichero es algo así:

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf

Listen 80
Listen 8085

<IfModule ssl_module>
Listen 443
</IfModule>

<IfModule mod_gnutls>
Listen 443
</IfModule>

Vemos que la  línea 5 hace referencia al puerto 80, nosotros hemos añadido una línea más, la 6, indicándole que escuche también el puerto 8085.

Paso 4: Habilitamos el nuevo virtualhost

Si os habéis fijado hablamos de los directorios sites-available y sites-enabled, pero solo hemos trabajado con el primero. Para crear el enlace simbólico lo haremos con el comando a2ensite:

sudo a2ensite ahierro.es.conf

Y por si te lo estás preguntando, si, un ln o un cp servirían de igual manera. Y ahora que el enlace simbólico ya se encuentra en el directorio sites-enabled solo nos queda reiniciar apache:

sudo service apache2 restart

Paso 5: Comprobamos que todo funcione correctamente

Podemos comprobar que todo ha salido bien con dos sencillos pasos

1. Creamos un archivo index.html y lo guardamos en el directorio público del host virtual que acabamos de crear, en este caso /var/www/ahierro.es/public.
2. Accedemos a la ip del servidor seguida de dos puntos y el puerto: http://192.168.1.10:8085/index.html.

Si vemos el contenido del archivo index.html es que todo ha salido bien, en caso contrario deberemos buscar el problema en función del mensaje de error obtenido.

Conclusión

Una forma sencilla de organizar nuestros proyectos siempre que no sean demasiados.

Personalmente, en el virtual host por defecto (puerto 80),  creo un sencillo fichero con enlaces a todos los hosts virtuales y otros accesos directos que me interesa tener a mano como pueden ser phpmyadmin o phpinfo. Esto suele ahorrarme unos minutos preciados minutos cada día.

Y como siempre me gustaría saber tú opinión,  ¿utilizas los virtual host? ¿los identificas por puerto? ¿organizas tus proyectos de otra forma? Deja un comentario y aprendamos juntos.

Créditos, referencias y artículos relacionados

• Archivos y permisos de usuario en Apache 2 y Linux
• Ejecutar Linux en Windows 10 con WSL
• Servidor Web en Raspberry PI y Ubuntu Mate
• Clonar una web en un servidor local