Medidas para asegurar el servidor web Apache.
Estructura de los principales archivos que forma Apache2
/etc/apache2/apache2.conf: el archivo raíz es el 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 hos
Asegurarse de tener los últimos parches de seguridad
Todas las modificaciones que se indican a continuación dependerán del uso del servidor y se han de realizar httpd.conf.
Esconder el número de versión de Apache y otra información importante
Muchas instalaciones de Apache por defecto le anuncian al resto del mundo la versión de Apache .Los atacantes pueden utilizar esta información para su propia ventaja al intentar atacar. También hace saber que has dejado la mayoría de los parámetros como venían por defecto.
Hay dos directivas que necesitarás agregar a tu archivo httpd.conf:
ServerSignature Off
ServerTokens Prod
“ServerSignature” (la firma del servidor) aparece al final de páginas generadas por Apache como errores 404, listado de directorios, etc.
“ServerTokens” es la que determina lo que Apache incluirá en la cabecera de respuesta HTTP del servidor. El configurarla como “Prod” implica que enviará:
Server: Apache
Se puede cambiar este texto modificando el código fuente, o utilizando el módulomod_security
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:
Asegurarse que corre bajo su propio usuario y grupo
Muchas instalaciones de Apache corren como el usuario “nobody” (nadie). En caso de que otra aplicación (como un servidor de mails) esté corriendo también como dicho usuario, cualquier ataque a través de Apache podría comprometer también esta otra aplicación, y viceversa.
User apache
Group apache
Asegurarse que archivos fuera de la raíz web no sean accesibles
No queremos que Apache sea capaz de acceder a ningún archivo más allá de su raíz web. Por lo que, asumiendo que todos los sitios alojados se encuentran bajo sólo un directorio (al que llamaremos /web), se configuraría de la siguiente forma:
<Directory />
Order Deny,Allow
Deny from all
Options None
AllowOverride None
</Directory>
<Directory /var/www/htdocs>
Order Allow,Deny
Allow from all
</Directory>
Al activar “Options None” y “AllowOverride None” se desactivarán todas las opciones y sobreescrituras del servidor. Lo que significa que habría que agregarlas explícitamente para todos y cada uno de los directorios que necesiten una opción o sobreescritura.
Permisos sobre los ficheros.
Los usuarios no han 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 se sugieren los siguientes permisos en 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 muy recomendable eliminar estos permisos con los siguientes comandos:
# chmod -R go-r /etc/apache2
# chmod -R go-r /var/log/apache
Autorización a grupos
En el ejemplo de configuración se aprecia cómo se permite el acceso a cualquier usuario válido mediante la configuración «Require valid-user«. Del mismo modo, se puede permitir el acceso a usuarios que, además de válidos, pertenezcan a un determinado grupo:
Require group administradores
O a un listado de usuarios:
Require user jcmengano pcortes
Desactivar la exploración de directorios
Se puede hacer esto con una directiva “Options” dentro de la etiqueta “Directory“. Habría que configurar “Options” como “None” ó “-Indexes”
Options –Indexes
Desactivar inclusiones del lado del servidor
Esto también se logra mediante el parámetro “Options” de la etiqueta “Directory“. Habría que configurar “Options” a “None” ó “-Includes“.
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>
Desactivar ejecución CGI
Si no se está utilizando CGI, se lo desactiva también mediante el parámetro “Options“. Habría que configurarlo a “None” o “-ExecCGI“.
Options –ExecCGI
No permitirle a Apache utilizar enlaces simbólicos
Esta funcionalidad puede posibilitar 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
Desactivar el soporte para archivos “.htaccess”
Esto se realiza mediante la etiqueta “Directory“, pero con el parámetro “AlowOverride” a None.
AllowOverride None
Si se necesitan sobreescribirlos, hay que asegurarse que no puedan ser descargadas o simplemente le modificamos el nombre a algún otro que no sea “htaccess“. Por ejemplo, lo podríamos cambiar por “.httpdoverride” y bloquear la descarga de todos los archivos que comiencen con “.ht” de la siguiente forma:
AccessFileName .httpdoverride
Order allow,deny
Deny from all
Satisfy All
Utilizar mod_security
Es un módulo de Apache muy útil escrito por Ivan Ristic, el autor de Apache Security de O’Reilly Press. Con él podrás hacer lo siguiente:
- Filtrado simple
- Filtrado basado en expresiones regulares
- Validación de codificación Unicode de URLs
- Auditorías
- Prevención de ataques por byte nulo
- Límites de memoria para escritura de información
- Enmascaramiento de identidad del servidor
- Soporte para chroot incluído
- Y más…
Desactivar los módulos no necesarios
Apache incluye varios módulos instalados por defecto que muchas veces encontrarás que no necesitarás algunos de ellos.
Busca las líneas del archivo httpd.conf que contengan “LoadModule“. Para desactivar el módulo, típicamente agregarías # al principio de la línea. Para buscar los módulos, puedes ejecutar:
grep LoadModule httpd.conf
He aquí algunos módulos comúnmente activos pero frecuentemente innecesarios: mod_imap, mod_include, mod_info, mod_userdir, mod_status, mod_cgi, mod_autoindex.
Asegurarse que sólo el súper-usuario tenga acceso a la configuración de Apache y sus ejecutables
Esto se puede hacer (asumiendo que la instalación de Apache se ecuentre en /usr/local/apache) de la siguiente forma:
chown -R root:root /usr/local/apache
chmod -R o-rwx /usr/local/apache
Disminuir el valor de Timeout
Por defecto, el valor del parámetro Timeout es de 300 segundos. Se puede disminuirlo para reducir los posibles efectos de un ataque de denegación de servicio.
Timeout 45
Limitar grandes pedidos
Apache tiene varios parámetros que permiten limitar el tamaño de un pedido, lo que puede ser también útil para minimizar los efectos de un ataque de denegación de servicio. Un buen lugar para comenzar es el parámetro “LimitRequestBody” que, por defecto, está configurado a ilimitado. Si se van a permitir subidas de no más de 1Mb se lo podría configurar como:
LimitRequestBody 1048576
Si no se permitirán subida de archivos se lo puede configurar aún más pequeño.
Otros parámetros a controlar son “LimitRequestFields“, “LimitRequestFieldSize” y “LimitRequestLine“. Éstas están configuradas por defecto a valores razonables en la mayoría de los servidores.
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 FilesMatch para 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>
La 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 denegaría el acceso a todos los directorios CVS (utilizados en sistemas de control de versiones de código fuente):
<DirectoryMatch /CVS/>
Order Allow,Deny
Deny from all
</DirectoryMatch>
Limitar el tamaño de un cuerpo XML
Si se está utilizando mod_dav (típicamente utilizado por subversion) entonces podrías llegar a querer limitar el tamaño máximo del cuerpo de un pedido XML. El parámetro “LimitXMLRequestBody” está sólo disponible en Apache 2 y su valor por defecto es 1 millón de bytes (aproximadamente 1mb). Muchos tutoriales indicarán modificar este valor a 0, lo que implica que archivos de cualquier tamaño podrán ser subidos, lo que puede ser necesario si se está utilizando WebDAV para subir grandes archivos, pero si sólamente se lo está utilizando para control de versiones, probablemente un límite de 10Mb será suficiente.
LimitXMLRequestBody 10485760
Limitar la concurrencia
Apache posee varios parámetros de configuracón que pueden ser utilizados para ajustar el manejo de pedidos simultáneos. “MaxClients” es el máximo número de procesos que serán creados para atender pedidos. El valor por defecto puede ser demasiado alto si el servidor no tiene memoria suficiente para manejar un alto número de pedidos concurrentes.
Otros parámetros como “MaxSpareServers“, “MaxRequestsPerChild” y, en Apache 2, “ThreadsPerChild“, “ServerLimit” y “MaxSpareThreads” son importantes para ajustar la configuración al sistema operativo y hardware.
Restringir el acceso por IP
A partir de la versión 2.4 de Apache la funcionalidad de la directiva Require se ha ampliado, entre otras cosas, permite especificar rangos de IPs autorizadas que antes se implementaban mediante la directiva Allow. Esto permitirá añadir host autorizados para conectarse con ese servidor. Muy útil si se dispone de una IP fija.
Require ip 192.168.205
Por otro lado, se ha definido las directivas, como RequireAll y RequireAny, que permiten la composición de requisitos de acceso. En el siguiente ejemplo, extraído de la web de Apache, se permite el acceso a todo el mundo excepto si pertenecen a la red 192.168.205.255, su host es «*.phishers.example.com», «*.moreidiots.example» o «*.ke»:
<RequireAll>
Require all granted
<RequireNone>
Require ip 192.168.205
Require host phishers.example.com moreidiots.example
Require host ke
</RequireNone>
</RequireAll>
En el ejemplo siguiente se exige que los usuarios pertenezcan al grupo alpha o beta y que no estén incluidos en el grupo reject:
<Directory /www/docs>
<RequireAll>
Require group alpha beta
Require not group reject
</RequireAll>
</Directory>
Ejecutar apache en un entorno chroot
chroot permite ejecutar un programa en su propia jaula completamente aislada. Esto previene que una ruptura en un servicio afecte cualquier otra cosa en el servidor.
Esto puede ser relativamente complicado de configurar en chroot debido a dependecias de librerías. Se mencionó antes que el módulomod_security posee soporte para chroot. Esto hace el proceso tan simple como agregar una directiva a la configuración:
SecChrootDir /chroot/apache