La presente serie de notas de actualidad tiene el objetivo de informar de cómo implantar el servidor web Apache de forma segura. Aunque hay que tener en cuenta otros factores en la seguridad del servidor web, como por ejemplo el bastionado del servidor, estos temas no se tratarán en esta guía debido a su extensión.
Seguridad en Apache I: configuración e instalación
En esta primera entrega se explicará cómo modificar la configuración de Apache y las medidas de seguridad que se deben aplicar al instalar el software.
Los servidores web son elementos especialmente sensibles ya que por definición la mayoría son accesibles a través de Internet y debido a que cada vez más aplicaciones se ejecutan a través del navegador. Ataques de denegación de servicio, defacements o inyección de código malicioso son algunas de las consecuencias de no tener una instalación segura del servidor web.
La presente serie de notas de actualidad tiene el objetivo de informar de cómo implantar el servidor web Apache de forma segura. Aunque hay que tener en cuenta otros factores en la seguridad del servidor web, como por ejemplo el bastionado del servidor, estos temas no se tratarán en esta guía debido a su extensión.
Directivas y archivos de configuración
Es importante resaltar que según la distribución de Linux/Unix utilizada, el número, las rutas y los nombres de los archivos de configuración de Apache pueden variar. Con el siguiente comando, se pueden averiguar datos sobre una instalación concreta incluyendo cúal es el archivo de configuración:
Este archivo de configuración puede incluir a su vez otros más utilizando la directiva Include (en Apache se llama directivas a las distintas opciones de configuración).
Por ejemplo en sistemas Debian/Ubuntu utiliza la siguiente estructura de archivos de configuración diseñada para facilitar la administración:
/etc/apache2/apache2.conf: el archivo raíz es que incluye a los demás. No se debe modificar este archivo.
mods-enabled/*.load y mods-enabled/*.conf: la finalidad de estos archivos es la carga y configuración de los módulos de Apache.
httpd.conf: directivas aplicables a todos los servidores web.
ports.conf: define en qué puertos "escuchará" Apache.
conf.d/: directorio que contiene archivos de configuración para cada funcionalidad de apache (charset, php, security, etc.)
sites-enabled/: directorio que contiene los archivos de configuración de cada virtual host.
Seguridad en la instalación
Afortunadamente, las instalaciones de Apache en sistemas Linux/Unix a través de los mecanismos de gestión de paquetes incluyen muchas de las opciones que se citan a continuación activadas o implantadas por defecto.
Deshabilitar los módulos que no se utilicen. De este modo no sólo se evitarán ataques sobre estos módulos sino que también Apache en ejecución consumirá menos recursos.
Permisos sobre ficheros:
Crear un usuario y grupo exclusivo para la ejecución de Apache. Este usuario y grupo se configura con las directivas User y Group. En cuanto a los permisos de ficheros, el owner del binario de Apache ha de ser root para poder abrir el puerto 80, aunque después cambia el usuario del proceso al propio de Apache. El resto de usuarios no ha de tener permisos de escritura sobre este fichero ya que entonces podría sustituirlo por otro malicioso que se ejecutaría con los máximos privilegios. Por ello estos son los permisos que deben tener los binarios de Apache:
# chown -R root:root /usr/local/apache
# find /usr/lib/apache2/ -type d | xargs chmod 755
# find /usr/lib/apache2/ -type f | xargs chmod 644
Por otro lado, en muchas instalaciones por defecto otros usuarios tienen permisos de lectura sobre los archivos de configuración y de logs de Apache. Es conveniente eliminar estos permisos con los siguientes comandos:
# chmod -R go-r /etc/apache2 # chmod -R go-r /var/log/apache2
<Directory />
Order Deny,Allow Deny from all Options None AllowOverride None
</Directory>
<Directory /var/www/htdocs>
Order Allow,Deny Allow from all
</Directory>
Las directivas Allow y Deny son utilizadas para permitir o denegar respectivamente el acceso a un directorio y Order especifica el orden en el que serán evaluadas.
Revisar las directivas Alias
Vetar la resolución de enlaces simbólicos
Options -FollowSymLinks +SymLinksIfOwnerMatch
A continuación, se detallarán varias medidas para tratar de exponer la mínima información posible.
Deshabilitar el listado de ficheros
<Directory /> Order Deny,Allow Deny from all Options None AllowOverride None </Directory>
Limitar el acceso a archivos por extensión
<Files ~ "^\.ht"> Order allow,deny Deny from all </Files>
<FilesMatch "(\.bak$|\.BAK$)"> Order Allow,Deny Deny from all</FilesMatch>
<DirectoryMatch /CVS/> Order Allow,Deny Deny from all </DirectoryMatch>
Información en la cabecera Server
En el siguiente artículo se explicarán las distintas maneras posibles en Apache de «ejecutar código» y las medidas de seguridad que se deberían tener en cuenta.
Aunque no se citan en este artículo por su extensión, la mayor fuente de riesgo se encuentra en los posibles errores de programación de los propios scripts, como no validar la entrada, errores en la gestión de sesión o condiciones de carrera.
¿CGI o módulo?
Los dos mecanismos que permiten a Apache servir páginas web dinámicas se diferencian principalmente en el modo de invocación del intérprete o programa que crea el contenido dinámico. Mediante el mecanismo de módulos, el intérprete o máquina virtual se encuentra integrada en el proceso de Apache y mediante CGI es un proceso externo e independiente.
Por ello, el mecanismo del módulo es más eficiente y puede utilizar características de Apache, como los archivos .htaccess (que se describirán más adelante). Pero, por otro lado, todos los scripts se ejecutan bajo el mismo usuario, el de Apache, lo que en servidores compartidos permitiría acceder a los scripts de servicios web de otros usuarios. En cambio, mediante CGI se pueden utilizar la herramienta suEXEC para definir unos permisos sobre los scripts que no permitan al usuario de Apache tener acceso a ellos. Esta herramienta permite ejecutar los scripts mediante el usuario y grupo definido en la directiva SuexecUserGroup.
Por otra parte, si existe algún problema en la ejecución que hace que el programa se «cuelgue», como módulo afectará a todo el servidor, en cambio, como CGI, al crear un nuevo proceso, que ejecuta la petición sólo afectará a la petición determinada.
CGI Módulo
Eficiente No Si
.htaccess No Si
Control de acceso Si No
Resistencia a errores Si No
Una alternativa a estas dos tecnologías, es utilizar FastCGI, que incorpora las ventajas de CGI junto con mecanismos más eficientes de ejecución.
Medidas de seguridad
Mediante la directiva ScriptAlias, similar a «Alias» descrita en artículos anteriores, se especifica el patrón de las URLs que corresponden a scripts y el directorio en el que se encuentran, de manera que los scripts que estén contenidos en ese directorio serán ejecutados: ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
El directorio al que hace referencia ScriptAlias ha de encontrarse fuera del DocumentRoot, sino se podrían mostrar su código fuente accediendo al directorio final sin usar el alias.
Para evitar la ejecución de scripts en el DocumentRoot se puede utilizar la directiva «Options» vista anteriormente: Options -ExecCGI
Actualmente, las páginas web integran contenido dinámico mediante etiquetas HTML especiales, como <? en php, utilizando directivas de Apache como las presentes a continuación: Action application/x-httpd-php modules/libphp.so <FilesMatch "\.phpquot;> SetHandler application/x-httpd-php </FilesMatch>
Estas directivas, en resumen, dictan que cualquier petición de archivo con extensión .php sea servida por libphp.so, la librería dinámica que ejecuta PHP. Esta configuración evita que se pueda acceder al código fuente, ya que no devolverá el archivo directamente sino que lo hará a través de libphp.so. Aunque, por seguridad, es conveniente tratar de aislar la información confidencial que utilicen estos scripts en un directorio fuera de DocumentRoot para que si se produjera un error en el handler no se tuviera acceso al código fuente.
Por último, se debe mantener actualizado el framework de ejecución para evitar que se exploten vulnerabilidades que puedan descubrirse como la publicada en mayo del 2012 en PHP que permitía la ejecución de código arbitrario.
Leer más: Segu-Info: Guía de Seguridad en Apache http://blog.segu-info.com.ar/2012/05/guia-de-seguridad-en-apache.html#ixzz1x9Lbk7pt
# find /usr/lib/apache2/ -type d | xargs chmod 755
# find /usr/lib/apache2/ -type f | xargs chmod 644
Por otro lado, en muchas instalaciones por defecto otros usuarios tienen permisos de lectura sobre los archivos de configuración y de logs de Apache. Es conveniente eliminar estos permisos con los siguientes comandos:
# chmod -R go-r /etc/apache2 # chmod -R go-r /var/log/apache2
Seguridad en Apache II: control de los archivos publicados
El directorio especificado mediante la directiva DocumentRoot es el directorio desde el que se servirán los archivos de Apache. Aún así, existen errores de configuración que pueden posibilitar el acceso a otros directorios. Denegar el acceso por defecto
Es conveniente denegar el acceso a todos los directorios por defecto y permitir el acceso sólo al directorio especificado en el DocumentRoot explícitamente:Order Deny,Allow Deny from all Options None AllowOverride None
</Directory>
<Directory /var/www/htdocs>
Order Allow,Deny Allow from all
</Directory>
Las directivas Allow y Deny son utilizadas para permitir o denegar respectivamente el acceso a un directorio y Order especifica el orden en el que serán evaluadas.
La directiva <Directory> sirve para aplicar un serie de directivas al directorio especificado y a todos sus subdirectorios. Lo más común es que existan varias de estas directivas y que, como también se aplican a los subdirectorios, existan directivas contradictorias aplicadas a un directorio. En este caso, la directiva del <Directory> más específico es la que prevalece. En el ejemplo anterior, existen directivas de acceso contradictorias en el directorio /var/www/htdocs, pero se imponen las que permiten el acceso por estar contenidas en un <Directory> más específico.
El cometido de las directivas Options y AllowOverride se explicarán en entregas posteriores.
Revisar las directivas Alias
Para servir un archivo Apache concatena el directorio especificado en DocumentRoot con la parte de la ruta de la URL:
Pero mediante la directiva Alias se puede modificar esta resolución. Si la URL coincide con el primer parámetro de la URL, Apache servirá desde el directorio especificado en el segundo parámetro:
Para evitar filtrar información se debe analizar la necesidad de esta directiva y de las similares AliasMatch, ScriptAlias y ScriptAliasMatch.
Vetar la resolución de enlaces simbólicos
En sistemas Unix/Linux, Apache puede recibir una petición a un archivo que es, a nivel de sistema operativo del servidor, un enlace simbólico y devolver el archivo apuntado por él aunque se encuentre fuera del DocumentRoot.
Esta funcionalidad además posibilita que un atacante, que tenga permisos de escritura sobre el DocumentRoot, cree un enlace simbólico a archivos contenidos fuera del DocumentRoot para luego acceder a ellos a través del navegador.
Para deshabilitar esta posibilidad se debe aplicar la siguiente directiva:
Options -FollowSymLinks
Como alternativa, se puede habilitar esta funcionalidad pero sólo si el archivo destino pertenece al mismo usuario que el enlace simbólico:
Options -FollowSymLinks +SymLinksIfOwnerMatch
Seguridad en Apache III: ocultar información
Una de las primeras fases de los ataques sobre los sistemas de información es la revelación de información (o information disclosure). Cuanta más información tenga el atacante, más fácil le resultara encontrar vulnerabilidades existentes en el sistema atacado.A continuación, se detallarán varias medidas para tratar de exponer la mínima información posible.
Deshabilitar el listado de ficheros
Si se le envía a Apache una URL que solicita un directorio y no un archivo concreto, Apache permite mostrar los contenidos de este directorio. Esta funcionalidad puede ser aprovechada por un atacante para descubrir archivos que el administrador del sitio no tenía intención de publicar.
Esta característica de Apache es controlada por la directiva Options, para desactivarla se debe aplicar la siguiente configuración: Options -Indexes
Como su propio nombre indica, mediante esta directiva se controlan varias opciones de configuración. Puede aceptar varios valores, entre ellos All yNone para activar o desactivar todas las opciones disponibles. De hecho, en la configuración del directorio raíz se recomienda desactivar todas por seguridad, lo que incluiría la opción Indexes:
<Directory /> Order Deny,Allow Deny from all Options None AllowOverride None </Directory>
Limitar el acceso a archivos por extensión
En algunas ocasiones determinados ficheros deben existir dentro del DocumentRoot del servidor pero no se desea que estén disponibles, como los ficheros .htaccess y .htpasswd, cuya funcionalidad se explicará posteriormente. En estos casos, se pueden utilizar las directivas Files y FilesMatchpara denegar su acceso.
En el siguiente ejemplo, se deniega el acceso a todos los ficheros que comienzan por los caracteres ".ht" (entre ellos .htaccess y .htpasswd):
<Files ~ "^\.ht"> Order allow,deny Deny from all </Files>
Las siguiente configuración evita que se publiquen los archivos de copia de seguridad:
<FilesMatch "(\.bak$|\.BAK$)"> Order Allow,Deny Deny from all</FilesMatch>
Files y FilesMatch sólo actúan sobre el nombre del archivo, para filtrar directorios, se debe utilizar DirectoryMatch. Mediante las directivas presentes a continuación se vetaría el acceso a todos los directorios CVS:
<DirectoryMatch /CVS/> Order Allow,Deny Deny from all </DirectoryMatch>
Información en la cabecera Server
En las respuestas HTTP se incluye la cabecera Server que contiene información sobre el software que ejecuta el servidor web:
Si se desea restringir esta información se puede utilizar la directiva ServerTokens, aunque no se puede restringir la información enviada completamente ya que la configuración más restrictiva es Prod que, como se aprecia a continuación, envía el nombre del servidor web:
Mediante el módulo mod_security es posible modificar el valor de esta cabecera completamente: SecServerSignature "Microsoft-IIS/5.0"
Aunque mod_security es un módulo de gran utilidad, se desaconseja su instalación únicamente para enmascarar el servidor ya que un hacker dispone de múltiples herramientas de fingerprinting como HTTPrint, que basándose en pequeñas diferencias de implantación del protocolo HTTP, permite obtener la versión del navegador web:
Para obtener más información sobre fingerprinting y recopilación de información, se puede consultar el informe "Pentest: recolección de información".
Información en páginas generadas por el servidor
La directiva ServerSignature establece si se desea mostrar la versión del servidor, el correo del administrador y el nombre del servidor virtual en las páginas generadas por Apache (por ejemplo, errores o listados de directorio FTP). Para no mostrar información se puede establecer a Off.
La dirección de correo electrónico del administrador, que muestra en determinadas páginas de error para que el internauta pueda notificar el error, se establece mediante la directiva ServerAdmin. No es recomendable establecer una personal, sino una genérica con este fin específico.
Por otro lado, Apache muestra una página de error genérica cuando se produce un error que revela información sobre la versión del software ejecutada:
Mediante la directiva ErrorDocument se puede modificar este texto, incluso invocar un script que lo construya dinámicamente. Aunque esta directiva es poco flexible ya que hay que crear una entrada por cada código de error. Por ejemplo: ErrorDocument 404 /error/404.html ErrorDocument 500 "Error en el servidor"
Seguridad en Apache IV: CGI y módulos
Pocos portales en la actualidad ofrecen únicamente archivos HTML (contenido estático). La mayor parte crea las páginas web dinámicamente o implementa una lógica de negocio mediante un lenguaje de programación como PHP, Java o .NET.En el siguiente artículo se explicarán las distintas maneras posibles en Apache de «ejecutar código» y las medidas de seguridad que se deberían tener en cuenta.
Aunque no se citan en este artículo por su extensión, la mayor fuente de riesgo se encuentra en los posibles errores de programación de los propios scripts, como no validar la entrada, errores en la gestión de sesión o condiciones de carrera.
¿CGI o módulo?
Los dos mecanismos que permiten a Apache servir páginas web dinámicas se diferencian principalmente en el modo de invocación del intérprete o programa que crea el contenido dinámico. Mediante el mecanismo de módulos, el intérprete o máquina virtual se encuentra integrada en el proceso de Apache y mediante CGI es un proceso externo e independiente.
Por ello, el mecanismo del módulo es más eficiente y puede utilizar características de Apache, como los archivos .htaccess (que se describirán más adelante). Pero, por otro lado, todos los scripts se ejecutan bajo el mismo usuario, el de Apache, lo que en servidores compartidos permitiría acceder a los scripts de servicios web de otros usuarios. En cambio, mediante CGI se pueden utilizar la herramienta suEXEC para definir unos permisos sobre los scripts que no permitan al usuario de Apache tener acceso a ellos. Esta herramienta permite ejecutar los scripts mediante el usuario y grupo definido en la directiva SuexecUserGroup.
Por otra parte, si existe algún problema en la ejecución que hace que el programa se «cuelgue», como módulo afectará a todo el servidor, en cambio, como CGI, al crear un nuevo proceso, que ejecuta la petición sólo afectará a la petición determinada.
CGI Módulo
Eficiente No Si
.htaccess No Si
Control de acceso Si No
Resistencia a errores Si No
Una alternativa a estas dos tecnologías, es utilizar FastCGI, que incorpora las ventajas de CGI junto con mecanismos más eficientes de ejecución.
Medidas de seguridad
Mediante la directiva ScriptAlias, similar a «Alias» descrita en artículos anteriores, se especifica el patrón de las URLs que corresponden a scripts y el directorio en el que se encuentran, de manera que los scripts que estén contenidos en ese directorio serán ejecutados: ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
El directorio al que hace referencia ScriptAlias ha de encontrarse fuera del DocumentRoot, sino se podrían mostrar su código fuente accediendo al directorio final sin usar el alias.
Para evitar la ejecución de scripts en el DocumentRoot se puede utilizar la directiva «Options» vista anteriormente: Options -ExecCGI
Actualmente, las páginas web integran contenido dinámico mediante etiquetas HTML especiales, como <? en php, utilizando directivas de Apache como las presentes a continuación: Action application/x-httpd-php modules/libphp.so <FilesMatch "\.phpquot;> SetHandler application/x-httpd-php </FilesMatch>
Estas directivas, en resumen, dictan que cualquier petición de archivo con extensión .php sea servida por libphp.so, la librería dinámica que ejecuta PHP. Esta configuración evita que se pueda acceder al código fuente, ya que no devolverá el archivo directamente sino que lo hará a través de libphp.so. Aunque, por seguridad, es conveniente tratar de aislar la información confidencial que utilicen estos scripts en un directorio fuera de DocumentRoot para que si se produjera un error en el handler no se tuviera acceso al código fuente.
Por último, se debe mantener actualizado el framework de ejecución para evitar que se exploten vulnerabilidades que puedan descubrirse como la publicada en mayo del 2012 en PHP que permitía la ejecución de código arbitrario.
Leer más: Segu-Info: Guía de Seguridad en Apache http://blog.segu-info.com.ar/2012/05/guia-de-seguridad-en-apache.html#ixzz1x9Lbk7pt
Under Creative Commons License: Attribution Non-Commercial Share Alike
