Elementos específicos para prevenir los ataques en Apache.
Ataques de denegación de servicio.
Un ataque de denegación de servicio, básicamente consiste en saturar los recursos de algún tipo de servicio, En el caso del servidor Apache, o cualquier servidor web, se podría decir que un ataque se podría llevar a cabo mediante peticiones ilegítimas a través de aplicaciones diseñadas para tal fin o aprovechando algún fallo de seguridad, de modo que le falten recursos para procesar las legítimas.
Bandwidth Attacks
Este ataque, también conocido como hotlinking, consiste en incrustar enlaces en varios portales web a imágenes o archivos del sitio web atacado de manera que al visitar uno de estos portales automáticamente se realiza una costosa petición al sitio web atacado.
Mediante este ataque se puede utilizar contenido de otros sitios web sin permiso ni «pagar» por el ancho de banda y también se puede llegar a colapsar el servidor atacado.
Este ataque se puede evitar mediante una regla de mod_rewrite que prohíba todas las peticiones de acceso a archivos cuya cabecera HTTP_REFERER, que contiene el sitio web desde el que se ha realizado la petición, no sea el del propio sitio web:
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://mipaginaweb\.es [nocase]
RewriteRule (\.gif|\.jpg|.\png|\.swf)$ $0 [forbidden]
Por muchos recursos de los que disponga un servidor Apache, un ataque de denegación de servicio puede saturar el servidor. Hay que tener en cuenta que un ataque DoS puede ser distribuido, DDoS o Distributed Denial of Service, y contar con un gran número de máquinas que siempre superarán en recursos al servidor o servidores web. Estos ataques pueden ser realizados sin conocimiento del usuario, porque su equipo ha sido infectado y forma parte de una botnet, o conscientemente por razones de «hacktivismo».
Existen varias medidas para mitigar esta amenaza aunque si el ataque es suficientemente grande, y puede serlo ya que una botnet puede componerse de cientos de miles de equipos, únicamente se puede evitar con la colaboración del ISP (Internet Service Provider).
Por fuerza bruta
Se basa simplemente en generar un gran número de peticiones HTTP de manera que el servidor no pueda responder a todas. Es posible realizarlo mediante una aplicación especialmente diseñada para tal fin.
Ataques SYN Flood
Son más refinados que el anterior ya que tratan de colapsar el servidor a nivel de de TCP/IP y no de aplicación. Esto se consigue colapsando una estructura de datos en la que se almacena información sobre las conexiones TCP llamada Transmission Control Block o TCB. Para ello, en el handshake de establecimiento de sesión TCP, el atacante envía el SYN inicial, el servidor responde con SYN-ACK pero el atacante no envía el ACK final.
En Linux se puede mitigar con el mecanismo de SYN cookies que sólo reserva espacio para la conexión cuando se recibe el mensaje de confirmación final. Se puede activar de la siguiente manera:
# echo 1 > /proc/sys/net/ipv4/tcp_syncookies
Otra forma de logarlo es mediante Syn caches que utiliza una estructura de datos aparte y, en el caso de que se complete el handshake, copia los datos a la estructura de datos TCB. Este mecanismo sólo está implementado por defecto en FreeBSD.
No es útil tratar de evitar ataques de sync-flooding aumentando el tamaño de la cola de espera mediante la directiva ListenBacklog.
Número máximo de peticiones concurrentes
Las consecuencias de no configurar Apache según el número de peticiones previstas podrían llegar a ser las mismas que las de un ataque DoS: el servidor deja de responder a peticiones legítimas. Por esta razón es conveniente configurar la cantidad de recursos que se ponen a disposición de Apache en función del hardware disponible y del número y coste de las peticiones estimadas.
Según la carga y capacidad del servidor se puede configurar el número de peticiones máximo que el servidor será capaz de servir en un determinado momento. Esta configuración depende en gran medida del modelo de gestión de peticiones que está utilizando Apache o multiprocessing modules (MPMs). Existen varios tipos:
prefork: utiliza múltiples procesos. Cada uno de ellos se ocupa de una petición. Es el utilizado por defecto en sistemas Unix/Linux.
winnt: Apache se ejecuta en un sólo proceso que contiene varios hilos, threads, de ejecución. Se usa en sistemas Windows.
worker: ejecuta varios procesos que a su vez lanzan varios hilos.
La directiva MaxRequestWorkers, o MaxClients en versiones anteriores a la versión 2.3.13, establece el número máximo de peticiones que se gestionarán concurrentemente. El máximo valor que puede configurarse en esta directiva se controla mediante ServerLimit. Las peticiones concurrentes que superen ese número se colocarán en una cola, cuyo tamaño máximo gobierna la directiva ListenBacklog, a la espera de que un proceso, en el MPM prefork, o hilo, en winnt o worker, complete su petición o que venza un timeout de espera.
Quizás la directiva más crítica en este sentido es LimitRequestBody, útil para limitar el tamaño máximo de las peticiones y archivos que se pueden subir al servidor y que podrían llegar a saturarlo.
Monitorización del uso de recursos.
Teniendo en cuenta que es realmente complejo evitar un ataque DoS en el servidor, la solución más realista es monitorizar el servidor y tener preparado un plan de actuación (que generalmente conlleva acciones por parte del ISP) en caso de que se detecte un ataque.
Aunque más adelante se expondrán otras herramientas de monitorización, para una supervisión sencilla del consumo de recursos se puede utilizar el módulo mod_status. mod_status ofrece información a través de una página web sobre el consumo de recursos del servidor Apache:
Algunos valores medios como el número de peticiones por segundo, número de bytes servidos por segundo o el número de bytes por petición.
El estado de cada proceso de Apache y su porcentaje de uso de la CPU.
Si se está utilizando el HTTPS muestra información sobre el estado de la caché SSL/TLS. También, sobre Apache utilizado como proxy, activando la directiva ProxyStatus.
Para habilitarlo se debe añadir la siguiente configuración:
ExtendedStatus On
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 192.0.2.0/24
</Location>
No se debe olvidar imponer restricciones de acceso, mediante IP por ejemplo, sobre la web de mod_status.
La URL admite un par de parámetros opcionales:
«refresh=N»: para que el resultado se refresque cada N segundos.
auto: sirve los resultados en modo texto para ser procesados fácilmente por otras herramientas.
Monitorización del servicio.
Anteriormente se describió mod_status, un módulo utilizado para supervisar la carga de los procesos e hilos de Apache. Además del consumo de recursos, quizás el evento más importante que se debe detectar son las caídas del servicio o demonio, de Apache.
Una herramienta que se puede utilizar para detectar estos eventos y ejecutar de nuevo el servicio en caso de caídas es Monit. En la siguiente configuración de Monit se aprecia cómo se especifica el proceso a supervisar, los comandos para ejecutar y parar el servicio y las condiciones que provocan que Monit reinicie el servicio:
check process apache with pidfile /var/run/apache2.pid
group www
start program = «/etc/init.d/apache start»
stop program = «/etc/init.d/apache stop»
if failed host localhost port 80
protocol HTTP request «/~hauk/monit/token» then restart
if failed host 192.168.1.1 port 443 type TCPSSL
certmd5 12-34-56-78-90-AB-CD-EF-12-34-56-78-90-AB-CD-EF
protocol HTTP request http://localhost/~hauk/monit/token then restart
if 5 restarts within 5 cycles then timeout
depends on apache_bin
depends on apache_rc
Otra herramienta similar que se puede utilizar es Nagios. Seguridad en Apache 32
Configuración y revisión de los logs
Apache posee dos tipos de logs. Uno almacena información sobre las URLs a las que se han accedido y otro recoge los errores de Apache.
Es conveniente revisar los archivos de log de Apache para detectar errores de configuración, de archivos inexistentes o errores en CGI.
Log de error
En este archivo se almacena información sobre eventos importantes, como inicio de la ejecución de Apache, y sobre los errores que se han producido. La localización de este archivo se establece mediante ErrorLog y su detalle mediante LogLevel:
LogLevel warn
ErrorLog ${APACHE_LOG_DIR}/error.log
En sistemas Unix, se puede filtrar la información de interés de este fichero mediante comandos como el siguiente que genera una lista de errores únicos:
$ cat error.log | cut -d’]’ -f 4-99 | sed -e «s/, referer.*//g» | sort | uniq
Log de acceso
El archivo de log y su formato se configura mediante la directiva CustomLog. Se puede utilizar LogFormat para especificar un formato aparte. En el ejemplo siguiente se ha creado un formato llamado combined:
LogFormat «%h %l %u %t \»%r\» %>s %b \»%{Referer}i\» \»%{User-agent}i\»» combined
CustomLog log/access_log combined
Las especificaciones del formato combined tienen el siguiente significado:
%h: dirección IP de la petición.
%l: nombre de usuario de identd o protocolos similares.
%u: usuario que ha realizado la petición si se ha solicitado autenticación.
%t: la fecha de la petición.
\»%r\»: la URL de la petición entre comillas dobles.
%>s: código de respuesta del servidor.
%b: tamaño de la respuesta, sin incluir las cabeceras.
\»%{Referer}i\»: la cabecera Referer.
\»%{User-agent}i\»: la cabecera User-Agent.
Seguridad en Apache 33
Se pueden utilizar herramientas como AWStats o W3Perl que procesan la información de este fichero para extraer estadísticas y facilitar su acceso mediante formularios, gráficos y rankings.
En vez de guardar la información directamente en un archivo se puede enviar a otra aplicación mediante pipes. Este mecanismo se utiliza para poder rotar los archivos de log automáticamente mediante la aplicación rotatelogs que incluye Apache.
Detección de ataques.
La última fase en el proceso de monitorización es la detección de ataques. Sería extenso definir en profundidad las distintas herramientas que se pueden utilizar con este objetivo. Pero, por citar alguna, se podría utilizar un Web Application Firewall (WAF) como mod_security, entre los ataques que detecta por defecto se pueden resaltar los siguientes:
Violaciones del protocolo HTTP, IPs pertenecientes a listas negras,detección de malware utilizando el API Google Safe Browsing, detección y prevención de ataques de denegación de servicio, ataques web comunes.