Yenisey Espinel Hernández / yespinelh@gmail.com
En la actualidad la tecnología y el quehacer diario de la mayoría de la población mundial van juntos y de la mano en todo momento. La vida se nos convierte en un diario interactuar constante con los nuevos avances mundiales en este campo. Pero solo no avanzamos en el hardware, también, este viene acompañado por los nuevos servicios y aplicaciones que se van desarrollando.
Las plataformas web desbordan el mercado de demandas y ofertas, se han hecho imprescindibles en el quehacer diario. Los llamados webservices se han convertido en lo más solicitado en la actualidad.
Pero, ¿Nos hemos detenido a pensar en la seguridad de implementación de estos servicios, en las consecuencias y ajustes técnicos a tener en cuenta?
Mi objetivo es referirme a uno de los aspectos a tener en cuenta para la seguridad de nuestros sitios web y los servidores en donde se hospedan estos.
Apache es aún el servidor Web de mayor uso en línea, sirve miles de aplicaciones y todas ellas con diversas configuraciones y requerimientos, además es utilizado en una inmensa mayoría de servidores compartidos o hosting y a pesar de las excelentes características de apache como servidor Web, en condiciones de su uso compartido (siendo hosting el caso más popular) plantea diversos problemas, el principal es relacionado a los permisos de acceso a ficheros, es decir de seguridad y es justamente donde ITK entra a jugar.
Siempre hay usuarios del servicio que intentan conocer escamar un poco más hasta ver donde pueden llegar, ya sea con buena o mala intención. También nos encontramos con webmasters o administradores inexpertos de sitios y portales, que dejan huecos de seguridad permitiendo que sus sitios se conviertan en blancos vulnerables a un ataque. Pero, ¿Qué sucede y en que nos afecta esto? Simple, cuando brindamos un servicio de hospedaje de portales y sitios web estos son publicados en la mayoría de los casos con apache, usando para esto configuraciones de hosts virtuales (VirtualHost), esto nos trae el problema de que por defecto todos los hostings son publicados de igual manera con el servicio de apache, que predeterminadamente usa el mismo usuario para los permisos de directorio y de manejo de la información (usuario /sbin/nologin), y por ende del sistema de ficheros del sitio, dejando vulnerables a todos los sitios hospedados, si solo uno de ellos lo es, ya que el usuario apache tiene control total sobre todos y cada uno de los sitios, así mismo deja vulnerable el sistema de ficheros del propio servidor.
Acá presento una forma de evitar esto, dejando cada sitio virtual con un usuario diferente, de esta forma el sitio sólo tiene acceso a sus propios archivos. Para lograrlo utilizaremos un parche que crea un nuevo worker. La solución recae en mpm-itk (HTTPD.ITK).
ITK es un módulo más de multiprocesamiento para apache, que agrega una nueva característica, la posibilidad de ejecutar apache con el UserID de un usuario diferente por cada virtualhost, además permite cambiar el valor nice del proceso que corresponde a dicho virtualhost.
Dicho de otra manera, el HTTPD.ITK. lo que hace es enjaular cada webhosting para que corran con un usuario diferente al apache, esto le da seguridad de que no entraran al sitio usando cualquier gestor que puedan poner en los restantes sitios. Independiza los permisos de cada sitio.
El procedimiento para su instalación e implementación es muy sencillo:
Descargar el instalador de HTTPD.ITK. para el tipo de Sistema Operativo en que está montado su webhosting e instalarlo. Tener en cuenta que si contamos con un clúster web debe estar instalado en cada uno de los servers del clúster de igual manera como se instaló el apache, instalando además, todas las dependencias que solicite, y de hecho por defecto no queda con el módulo itk activo, así que no afecta el parche que aplicamos. Para activarlo se debe editar el archivo httpd.conf y agregar las siguientes líneas:
HTTPD=/usr/sbin/httpd.itk
umask 0002
y luego reiniciar el apache. El umask es opcional, pero recomendable para que los archivos que se suban mediante el sitio queden con permisos más restringidos.
También debe de pensarse en un usuario (usuario_vhost)y un grupo (grupo_vhost) para cada uno de los hostings, si se aplica en un clúster web especificar el userID y el groupID de manera manual, para evitar diferencias de identificadores e incoherencias en la asignación de permisos. Se le especifica que su carpeta home (del usuario) será la carpeta que contiene el hosting. Este usuario y grupo son la parte más importante del proceso, ya que a partir de que se complete el mismo, el usuario apache (usuario por defecto, por el que corren o se publica cada sitio web) no tendrá acceso a la carpeta del sitio y este se sustituirá por el usuario y grupo designados. Por lo tanto a la carpeta del sitio deberá asignársele los permisos correspondientes: quitarle el acceso total al usuario y grupo apache, y darle acceso pleno al usuario y grupo creados propiamente para ese sitio.
Para utilizar el módulo debes agregar lo siguiente dentro de la configuración del VirtualHost:
AssignUserID usuario_vhost grupo_vhost
Es sencillo, funciona bien como servicio y es ligero, es un proceso completamente transparente para el usuario y el sitio corre en perfectas condiciones. Si se le aplica el proceso a un sitio que se está montando por primera vez solo se sigue un numero de pasos, se aplican permisos al sistema de ficheros del sitio y sale por primera vez al público como si nada, completamente transparente; sin embargo, al aplicársele a un sitio previamente montado y publicado en ese momento por apache, el sitio saldrá de línea durante el momento en que se le aplique los permisos a los ficheros, se cambie el fichero de configuración de virtualhosting y se recargue el apache, esto es debido a que dentro del proceso de aplicación de permisos se les da privilegios al usuario que le corresponde al sitio y a su grupo, y se le quita completamente a todos los demás usuarios incluyendo el apache que es por el que corría (por supuesto el root nunca los pierde), pero luego de terminar el proceso y recargar el apache sale el sitio como si nunca nada hubiese sucedido.
Solo un detalle, cuando se usa o se tiene instalado httpd-itk, para matar el demonio http, no funciona killall -9 httpd, debe de usarse killall -9 httpd.itk, sin embargo para trabajar directamente con el servicio se puede usar normalmente service httpd <opcion> o /etc/init.d/httpd <opcion>.
Hay que tener cuidado que al hacer cualquier cambio en los ficheros del sitio no se cambien los permisos anteriormente asignados, de tener alguna duda siempre se puede recurrir a aplicarlos nuevamente a la carpeta contenedora de manera recursiva hacia el contenido de la misma.
El Módulo Multi-Procesador ITK (MPM) funciona de la misma forma que el clásico módulo «prefork» (es decir, sin hilos), excepto que le permite limitar cada vhost individual a un usuario particular. Le permite ejecutar varios sitios web con un simple servidor sin preocuparse que pudieran leer los archivos del resto. Este es un MPM de terceros que no está incluido en el httpd normal de Apache.