Y es que a veces encontraremos que nuestra aplicación tiene unos requisitos mínimos que el servidor no cumple. Pongamos por ejemplo que queremos instalar prestashop que tiene ciertos requisitos mínimos y que por algún motivo nuestro hosting no satisface.

Cómo configurar variables de PHP desde .htaccess

Hay varias formas de actuar sobre estas variables, pero tal y como reza el título de esta entrada hoy vamos a hacerlo con el archivo .htaccess, y para ello utilizaremos la orden php_value. Su sintaxis es muy sencilla:

php_value + variable_php + valor.

Un ejemplo podría ser que necesitamos que la variable memory_limit esté configurada en 64M y el servidor la tiene configurada en 32M, o quizás el max_input_vars está configurado en 500 y nuestros requisitos mínimos son 1.000. Para ello incluiríamos las siguientes líneas en el archivo .htaccess:

php_value memory_limit 64M
php_value max_input_vars 1000

O supongamos que queremos mostrar los errores de PHP de nuestra aplicación. Podemos hacerlo desde el archivo .htaccess:

php_value error_reporting 7
php_flag display_errors On

Dónde colocar las líneas dentro del archivo .htaccess

Personalmente me gusta colocar este tipo de sentencias al comienzo del archivo .htaccess, justo detrás de los comentarios:

# Comentarios habituales en archivos .htaccess

# variables php
php_value error_reporting 7
php_flag display_errors On

<IfModule mod_rewrite.c>
<IfModule mod_env.c>
SetEnv HTTP_MOD_REWRITE On
</IfModule>

RewriteEngine on
...

Créditos, referencias y artículos relacionados

• Aumentar el límite de memoria de un script en PHP
• Aumentar el limite de tiempo máximo de ejecución de un script en PHP
• 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

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

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.

Avahi

La mala noticia es que para lograr acceder por nombre a máquinas Linux en una red local con garantías la mejor solución es disponer de un servidor DNS (Bind es la opción Open Source más extendida), y en esta entrada no hablaremos sobre servidores DNS.

En esta entrada utilizaremos Avahi, una implementación gratuita de Zero-Configuration Networking que permite difundir y descubrir servicios y equipos en una red local. Quizás a alguno le resulte más familiar si citamos a Bonjour, que es la implementación propietaria que tiene Apple de esta tecnología.

Y en función de nuestras necesidades es posible que Avahi nos sirva o no (lógico). El principal motivo es que no basta con instalarlo en la máquina a la que queremos acceder por nombre (llamémosla máquina Destino), sino que cada equipo que quiera acceder por nombre a la máquina Destino debe poder trabajar con la tecnología Zero-Configuration Networking para interpretar la información publicada por nuestra máquina Destino.

Máquinas Destino y Clientes

Pongámonos en situación, de un lado tenemos una máquina corriendo Ubuntu, en mi caso es una Raspberry Pi corriendo la versión 16.0.4.2 de Ubuntu Mate. El hostname de esta máquina es «maquina1», su ip 192.168.1.15 y para agilizar la lectura, como ya hemos dicho, la llamaremos máquina «Destino». En esta máquina hemos instalado un servidor web y queremos acceder a ella mediante hostname.

Del otro lado tenemos una serie de equipos con distintos SSOO que son los que quieren consumir el servicio web accediendo por nombre. A estas máquinas las llamaremos «Clientes» y vamos a suponer que tenemos:

1. Cliente Linux, corriendo Ubuntu 18.
2. Cliente Windows, corriendo Windows 10.
3. Cliente Android, corriendo Android Oreo 8.1.

Lo siento por los amantes de Apple pero no tengo ningún dispositivo de la manzanita para probar, aún así si eres uno de ellos sigue leyendo porque estoy convencido que te será de utilidad.

Instalar y configurar Avahi

Comenzaremos realizando las instalaciones necesarias en la máquina Destino. En función de vuestra distro es posible que todos o algunos de estos paquetes ya estén instalados.

sudo apt-get update
sudo apt-get install avahi-daemon
sudo apt-get install avahi-utils
sudo apt-get install libnss-mdns

Y acto seguido editaremos la configuración de Avahi. Es buena idea que antes de editar cualquier archivo de configuración guardéis una copia que os ayude a volver al punto inicial si fuera necesario, aunque vamos a tocar muy poca configuración.

suco cp /ect/avahi/avahi-daemon.conf /etc/avahi/avahi-daemon.conf.bck
sudo vim /etc/avahi/avahi-daemon.conf

En el archivo de configuración nos centraremos primero en el nombre de la máquina y el dominio. Mi recomendación es que mantengáis la configuración por defecto, es decir ser coherentes y que el host-name coincida con el de la propia máquina y que el dominio sea «local». De esta forma accederemos a la máquina con maquina1.local.

[server]
host-name=maquina1
domain-name=local

Nos aseguraremos también de que las siguientes opciones se encuentren como mostramos:

[publish]
disable-publishing=no
disable-user-service-publishing=no
publish-addresses=yes

Reiniciamos el servicio y lo agregamos al arranque de nuestra máquina:

sudo service avahi-daemon restart
sudo update-rc.d avahi-daemon defaults

Y con esto hemos terminado con la máquina Destino.

Maquinas Clientes

Como ya mencionamos cada máquina cliente debe ser capaz de trabajar con la tecnología Zero-Configuration Networking para poder alcanzar la máquina Destino por nombre, así que veamos caso a caso.

Desde Linux

En cada equipo con sistema operativo Linux con el que queramos acceder por nombre a la máquina Destino deberemos instalar Avahi. Así que no tenemos más que repetir las instrucciones definidas en el apartado «Instalar y Configurar Avahi».

Desde Windows

Por defecto Windows no nos dejará acceder por hostname y por ahora no existe implementación de Avahi para este sistema operativo. En su defecto podemos instalar el programa «Servicios de impresión Bonjour para Windows», de Apple, que aunque está pensado para otro uso nos permitirá cubrir nuestra necesidad y alcanzar la máquina Destino por nombre.

Desde Android

Lamentablemente no he encontrado ninguna aplicación o demonio para Android que permita que cualquier aplicación que corra en este sistema operativo sea capaz de acceder por nombre a nuestra máquina Destino, una lástima. Si conoces alguna solución para ello estaría muy agradecido de que la compartas en un comentario.

IOS y MacOSX

Como he dicho no tengo ningún dispositivo de Apple para realizar pruebas, pero conociendo que tienen su propia implementación de de Zero-Configuration Networking (Bonjour), me atrevería a decir que podremos acceder por nombre a nuestra máquina Destino sin necesidad de instalar ningún software adicional.

Comprobar el funcionamiento

Aunque es de primero de pre-escolar (creo que ahora lo llaman infantil), me gusta comprobar las cosas, y la forma más sencilla de hacerlo es utilizar el comando ping. Si lo hemos conseguido obtendremos algo así:

ping raspi.local
PING raspi.local (192.168..15) 56(84) bytes of data.
64 bytes from 192.168.1.15 (192.168.1.15): icmp_seq=1 ttl=64 time=6.68 ms
64 bytes from 192.168.1.15 (192.168.1.15): icmp_seq=2 ttl=64 time=4.61 ms

Y si algo no funciona como esperamos obtendremos algo así:

ping maquina1.local
ping: maquina1.local: Nombre o servicio desconocido

Y como dijimos que en la máquina Destino teníamos un servidor web, al escribir maquina1.local en la barra de direcciones del navegador, obviamente, accederemos al contenido publicado.

Conclusión

Con Avahi podemos acceder por nombre a máquinas con sistema operativo Linux en nuestra red local. Su mayor limitación es que nos veremos obligado a que tanto la máquina a la que queremos acceder, como las máquinas con las que queremos acceder deben tener instalada una implementación de Zero-Configuration Networking.

Así que si bien resuelve ciertas situaciones y necesidades, si pensamos en una red de varias decenas de equipos con distintos sistemas operativos existen otras alternativas más escalables.

Como siempre me gustaría saber cómo cual es tu experiencia, ¿has usado Avahi? ¿accedes por ip? ¿utilizas otra tecnología u otros programas? Deja un comentario y danos tu opinión.

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

Esta entrada forma parte de la serie Raspberry Pi como herramienta de apoyo al desarrollo web, y está pensada para un servidor de uso personal. De cualquier manera, el contenido de esta guía es perfectamente aplicable a cualquier distribución de Linux basada en Ubuntu y a Raspbian.

Esta documento también puede utilizarse para la configuración de un servidor de una pequeña organización, en cuyo caso sería necesario tener en cuenta algunas consideraciones:

1. Una Rasperri Pi no es el hardware más adecuado. Debería instalarse sobre un hardware fiable y acordemente dimensionado a las necesidades del uso que se le dará.
2. Además del contenido de este artículo, deberían realizarse una serie de configuraciones extra enfocadas en la seguridad que no entran en el ámbito ni el alcance de este documento.
3. Este artículo esta pensado para la instalación y configuración de un servidor web en una red local, en caso de que el servidor sea accesible directamente desde internet, el punto anterior cobra mayor importancia, además de requerir algunos ajustes más.

Una vez que todos tenemos claro el ámbito y el alcance, vamos al lío.

Instalamos Apache 2

Este paso será muy sencillo, actualizamos los repositorios e instalamos Apache 2:

sudo apt-get update
sudo apt-get install apache2

Si todo ha ido bien ya podremos acceder al al servidor web desde cualquier pc conectado a la red local con tan solo introducir la ip en el navegador.

Para el resto de la entrada asumiremos que nuestra Raspberry está configurada con la IP estática 192.168.1.10.

Así que si introducimos en el navegador la dirección http://192.168.1.10  veremos la página por defecto de Apache 2:

Un aspecto muy importante en la configuración de Apache es asignar los permisos adecuados a la carpeta del servidor. Podemos pasar sin hacerlo pero más pronto que tarde nos encontraremos con problemas relacionados con permisos.

Comenzaremos asegurándonos de que /var/www/html pertenezca al grupo www-data y que tiene los permisos adecuados:

sudo chgrp www-data /var/www/html
sudo chmod 775 /var/www/html
sudo chmod g+s /var/www/html

Agregamos nuestro usuario al grupo www-data:

sudo usermod -a -G www-data usuario

Y por último nos aseguramos de ser los propietarios del directorio

sudo chown usuario /var/www/html

Con esto hemos concluido la instalación de Apache.

Instalamos PHP

Instalamos PHP:

sudo apt-get install php7.0

Es posible que en función de la distribución que utilicemos en lugar del paquete php7.0 encontremos otra versión. Podemos comprobarlo fácilmente con la siguiente orden:

sudo apt-cache search php

Y si por cualquier motivo necesitamos una versión específica de php, deberemos incluir el repositorio ondrej/php como hacemos a continuación:

sudo add-apt-repository -y ppa:ondrej/php
sudo apt-get update

En este caso he incluido la opción -y porque al intentar agregar el repositorio me mostraba un warning relacionado con la codificación de caracteres de los repositorios.

Acto seguido instalar la versión de php que necesitemos, en mi caso voy a instalar la versión 7.3:

sudo apt-get install php7.3

Tras reiniciar Apache ya habremos acabado:

sudo service apache2 restart

Para comprobar que php está correctamente instalado crearemos el archivo  /var/www/html/phpinfo.php con el siguiente contenido:

<?php php phpinfo(); ?>

Si todo es correcto al acceder a http://192.168.1.10/phpinfo.php veremos algo así:

Instalamos y configuramos MariaDB

Una vez que php está instalado, continuamos con la base de datos:

sudo apt-get install mariadb-server

Durante el proceso de instalación deberemos responder responder a algunas preguntas que sin complicación alguna.

El primer paso tras la instalación será configurar MariaDB para que podamos acceder remotamente, pues por defecto solo acepta conexiones desde el propio host:

sudo vim /etc/mysql/mariadb.conf.d/50-server.cnf

Esfe archivo puede cambiar en función de tu distribución y de la versión de MariaDB. En ocasiones puedes encontrarlo en /etc/mysql/my.cnf, en /etc/mysql/mysql.conf.d/mysqld.cnf, etc.

Localizamos la siguiente línea:

bind-address  = 127.0.0.1

La sustituimos por:

bind-address  = 0.0.0.0

Y reiniciamos la base de datos:

sudo service mysql restart

Con esto hemos habilitado el acceso remoto a MariaDB. Ahora crearemos un nuevo usuario para evitar trabajar con root. Para ello accedemos a la consola de MariaDB:

sudo mysql -u root -p

Una vez en la consola de MariaDB creamos nuestro usuario:

CREATE USER 'usuario' IDENTIFIED BY 'contraseña';

Y concedemos acceso remoto y a todas las bases de datos al usuario que acabamos de crear:

GRANT USAGE ON *.* TO 'usuario'@'%' IDENTIFIED BY 'contraseña';

En este punto es buena idea comprobar que todo ha salido bien. Podemos hacerlo abriendo una conexión al servidor de bases desde nuestro equipo de trabajo con alguna herramienta como MySQL Workbench.

Instalamos phpMyAdmin

Esta es una herramienta que siempre me gusta instalar a pesar de que en la mayoría de situaciones trabajo con MySql Workbenck. Para instalar basta con:

sudo apt-get install phpmyadmin

Y una vez instalado podremos acceder a ella mediante http://192.168.1.10/phpmyadmin.

Conclusión

Ya tenemos un servidor web completamente funcional corriendo sobre nuestra Rasperri PI, sencillo, económico y funcional. Ahora solo hay que usarlo.

¿Y tú?, ¿Crees que necesitamos aplicar alguna otra configuración? ¿Haces algo distinto? ¿Echas en falta algún paso? o simplemente ¿te ha servido de ayuda? Comparte tu experiencia y aprendamos todos.