sábado, septiembre 29, 2007

Fortificando un Servidor Apache (II de IV)

***************************************************************************************
- Fortificando un Servidor Apache (I de IV)
- Fortificando un Servidor Apache (II de IV)
- Fortificando un Servidor Apache (III de IV)
- Fortificando un Servidor Apache (IV de IV)
***************************************************************************************
Configuración del httpd.conf

Cuando ya tengamos instalado de forma segura el servidor Apache, deberemos pasar a configurar el archivo httpd.conf de manera que nuestro sistema quede fortificado, para ello vamos a ver una serie de parámetros importantes. Como recomendación importante de seguridad, ante posibles fallos de otros servicios del sistema, es recomendable que sólo el administrador del sistema tenga acceso a los archivos de configuración del sistema para evitar que otro usuario pueda manipularlos.

Las cuentas del sistema

Para gestionar el servidor web se necesitan una serie de cuentas que hemos de configurar, en ellas vamos a aplicar los principios de Mínimo Privilegio Posible. Para ello en primer lugar vamos a crear un grupo para los usuarios que puedan gestionar el servidor, es decir, los que puedan administrarlo y detener y arrancar los servicios necesarios que llamaremos web_admins y otro grupo para los usuarios que van a representar a los servidores Web, que llamaremos web_servers.
Para correr el servidor Web, aplicando el MPP, vamos a utilizar un usuario que no tenga ni Shell ni se pueda logar, podemos utilizar el usuario nobody o crear uno para dar aun menos información a un posible atacante. Para ello creamos un usuario del grupo web_servers com home en el directorio dónde vayamos a publicar los documentos y por seguridad le configuraremos un Shell de comandos inexistente.

#useradd –d /opt/apache2/htdocs –g web_admins –s /bin/noshell web_user

Y luego le bloquearemos la cuenta para que no pueda tener login:

#passwd –l web_user

Y comprobamos en el archivo de configuración de cuentas /etc/passwd que el usuario está bien creado – con la shell falsa, el grupo correspondiente y el home correcto - y en el archivo de configuración de contraseñas /etc/shadow que la cuenta está bloqueada, es decir, que tiene el signo de cierre de admiración “!”.

Por último comprueba que no puedes ejecutar login interactivo:

#login web_user

Para hacer que nuestros servicios http corran con estas credenciales deberemos modificar el archivo de configuración httpd.conf en las claves User y Group:

User web_user
Group web_users


Si todo ha ido bien, cuando ejecutemos el demonio httpd con httpd –k start, éste se ejecutará en el sistema con las cuentas no privilegiadas que hemos creado.

Imagen: Privilegios de los demonios httpd

Ocultar Información

Ya hemos hablado antes de la clave ServerTokens Prod para ocultar información en el banner, pero hay otras claves que ayudan a ocultar más información del sistema.

- ServerSignature Off: Evita que se envíe información sobre la versión del servidor en las páginas de error.

- ErrorDocument numError errores/paginaError.html: Esta directiva nos permite cambiar las páginas de respuesta de errores ante cada uno de los tipos de error caracterizados por su número.

Ajustando algunos Límites

Cuando tenemos un servidor web expuesto que puede ser atacado es recomendable ajustar algunos límites de opciones para evitar el daño que pueda producir un ataque.

- Valor de Timeout: Este es el valor que una conexión inactiva va a estar mantenida por el servidor antes de que sea cerrada. El valor por defecto es de 300 segundos pero en un eventual ataque de denegación de servicio a generado a baso de abrir conexiones el impacto será mucho menor con valores de timeout menores. Reduce el valor de la variable Timeout a 40 o 50 segundos.

- Límites del tamaño de las peticiones: A la hora de mantener la conversación entre el cliente y el servidor se pueden configurar límites en cada uno de los apartados tanto de la petición como de la respuesta. Una petición de envío de 4 megas no permitirá subir ficheros al servidor de más de ese tamaño pero si no quieres que se suban ficheros más grandes puedes reducir el impacto de ataques. Algunos valores que puedes ajustar para ajustar el funcionamiento de tu servidor son LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine o LimitXMLRequesBody si estás trabajando con documentos XML.

- Concurrencia: Debes ajustar la concurrencia de usuarios a los límites que soporta tu infraestructura, para ello puedes ajustar los valores MaxClients para definir el número de procesos hijos que pueden ser creados en peticiones http. Por defecto el valor es de 256 luego si tu sistema no soporta estas usuarios concurrentemente tal vez sea recomendable limitar el tope. Esto puede evitar ataques de Denegación de Servicio que bloqueen la memoria de tu sistema. En entornos de multiproceso podemos regular, para optimizar y limitar el consume de recursos los valores de StartServers, MaxSpareServers, MaxRequestsPerChild, ThreadsPerChild, ServerLimit, y MaxSpareThreads. Estas directivas van a regular el número de procesos que se van a abrir, el número de procesos hijos en espera que se pueden tener, el número de threads por proceso, etc… Configura estos valores adecuadamente en entornos críticos y de alto rendimiento. Para realizar un buen ajuste de estos valores es necesario que realices un profile del rendimiento de tu sistema antes.

Permisos sobre Directorios

Al final el servicio httpd va a servir documentos que están almacenados en el sistema de ficheros por lo que es importante securizar en que partes se tiene permisos y en cuales no, para ello por defecto se pueden configurar las opciones más restrictivas sobre el sistema de ficheros y luego configurar en cada directorio las opciones particulares.

Para restringir el sistema de ficheros debemos configurar algo como:

[Directory /]
Order Deny, Allow
Deny from all
Options None
[/Directory]


En esta sección del archivo de configuración estamos restringiendo el acceso a todos los usuarios a todos los ficheros del directorio / y además, con Options None estamos prohibiendo el listado de directorios, la ejecución de programas CGI, la posibilidad de seguir links simbólicos y la de inclusión de documentos del lado del servidor.

La directiva Order indica el modo en que se van a procesar las peticiones, es interesante la manera de funcionar de la misma ya que los resultados de las directivas Deny o Allow dependerán de la configuración de Order.

Tabla Opciones Order

Esto quiere decir que al elegir Order Allow, Deny primero se ejecutarán todos los Allow y luego todos los Deny y si una situación no queda reflejado, es decir, no está explícitamente permitido o hay un conflicto, es decir, está explícitamente permitido y explícitamente denegado, entonces se Deniega el acceso. Por el contrario la configuración Order Deny, Allow funciona a la inversa. Para asegurar la restricción a todos los clientes se añade, en la configuración inicial la opción Deny from all.

A partir esta configuración podemos ir permitiendo o no opciones en cada uno de los directorios, por ejemplo, en el directorio principal dónde vamos a guardar los documentos, generalmente htdocs podremos permitir el acceso añadiendo:

[Directory /htdocs]
Order Allow, Deny
Allow from all
[/Directory]


Las opciones Allow y Deny nos van a permitir configurar reglas de concesión o denegación de acceso a los clientes. Estas reglas pueden aplicarse a todos “all” o a un dominio de origen, o a una dirección IPv4 o a una dirección IPv6 o incluso utilizando variables de entorno a aquellos que cumplan un determinado valor, como por ejemplo, que tengan un determinado cliente.
Podríamos permitir el acceso solo al dominio de nuestra organización:

Allow from elladodelmal.com

O denegar el acceso a todos lo que tuvieran un cliente Firefox:

SetEnvIf User-Agent ^Firefox/2\.0 NO_PASA
[Directory /docroot]
Order Allow, Deny
Allow from all
Deny from env=NO_PASA
[/Directory]


En este ejemplo hemos creado, con la directiva SetEnvif una variable de entorno para aquellos clientes con Firefox/2.0 cuyo valor es NO_PASA. Lógicamente estas opciones también pueden configurarse en los firewalls de acceso, pero, siguiendo la regla de Defensa en Profundidad también debería configurarse en los directorios. Además, es posible que, en accesos en la red local no se pase por algún firewall a nivel de aplicación que pueda inspeccionar rutas de acceso en el protocolo http por lo que es conveniente configurar estas opciones de seguridad en el servidor web.

Si queremos configurar alguna opción en concreta para un directorio, por ejemplo para el directorio de programas cgi, para ejecutables, o si queremos habilitar listados de directorios lo podemos hacer con la directiva Options. Situando un – antes de la directiva esta queda deshabilitada, de lo contrario se habilita.

- All: Representa a todas las opciones. Esto indicaría que todas quedan habilitadas, a excepción de Multiviews.

- None: No queda habilitada ninguna opción.

- ExecCGI: Con esta opción vamos a permitir o denegar la ejecución de scripts cgi de un directorio a través del modulo mod_cgi.

- Indexes: Esta opción permitirá el listado de archivos de un directorio a través del módulo mod_indexes si no se encuentra el archivo DirectoryIndex.

- Includes: Permite la inclusión de archivos del lado del servidor a través del modulo mod_include. Puede ser un riesgo frente a ataques Remote File Inclusion. Es conveniente deshabilitarlo si no se van a usar en ninguna aplicación.

- IncludesNOEXEC: Permite el uso de Includes del lado del servidor pero deshabilita las directivas exec cmd y exec cgi. Esta directiva sí que permite el uso de incluir de forma virtual scripts CGI desde directorios especificados con usando ScriptAlias.

- FollowSymLinks: Permite al usuario navegar por los directorios a través de enlaces simbólicos. Es recomendable deshabilitarlo.

- SymLinksIfOwnerMatch: Permite el seguimiento de links simbólicos solo si el fichero o directorio final es del mismo usuario que el enlace.

- MultiViews: Se permiten Multiviews de contenido, a través del uso del módulo mod_negotiation.

Unos ejemplos de esto serían:

- Options –Indexes ExecCGI –Includes: En este ejemplo se permite la ejecución de scripts CGI pero no se permite el listado de directorios ni la inclusión de documentos del lado del servidor para evitar una eventual inclusión de una Shell.

- Options None: No se permite ninguna opción.

5 comentarios:

asdsdadasdsadasdas dijo...

De puta madre, y aun estas por el 2º capitulo, cuando escribas los 4 haré un resumen de los puntos mas importantes que tendre que seguir cuando instale un apache.

Un matiz, que no se si lo has olvidado o piensas ponerlo en los siguientes capitulos, pero pensé que lo pondrias en "ajustando los limites" de este capitulo, se trata del modulo bandwith que sirve para limitar la velocidad de descarga, numero de threads por ip, etc

Anónimo dijo...

mod_bandwidth, mod_evasive, etc. Tambien tenemos los métodos

(ABRE)LimitExcept GET POST(CIERRA)
Order Allow,Deny
Deny from All
(ABRE)/LimitExcept(CIERRA)

Para qué permitir peticiones OPTIONS, HEAD, etc? (Dará problemas con DAV)

Aunque apache creo que tiene las directivas para hacerlo, un repaso al /etc/security/limits.conf no viene mal. Espero que Chema escriba algo al respecto :)

PD: Yo aunque asturiano, no se escanciar. Tiene que darme verguenza... pero me malacostumbraron :P

Chema Alonso dijo...

Hola thesur y gura,

no he puesto todos los límites de todas las cosas, así que vuestras aportaciones siempre serán bienvenidas, y una vez que esté publicado completo, podréis ayudarme a completarlo!!

saludos!

Anónimo dijo...

En realidad hablar largo y tendido de todas las cosas llevaría mucho tiempo, y además se nos quedaría algo en el tintero. Yo me conformo con los siguientes fascículos.

jrua dijo...

En la línea useradd –d /opt/apache2/htdocs –g web_admins –s /bin/noshell web_user, no sería
useradd –d /opt/apache2/htdocs –g web_ –s web_users /bin/noshell web_user ?, es decir creo que te colaste añadiéndo al usuario sin privilegios al grupo de admin. Corrígeme si me equivoco. Gran Tutorial , un saludo.

Entrada destacada

Tu Latch "Hack Your Innovation Contest": Haz un PoC & Hack por 1.000 €

El pasado Telefónica Innovation Day 2024 lanzamos oficialmente el " Tu Latch Hack Your Innovation Contest " en el que repartimos ...

Entradas populares