Los administradores de sistemas, y en concreto, los administradores de servidores web, siempre debemos tener en mente que todo esquema de seguridad tiene que cumplir una serie de principios básicos:
- El de la prevención: como casi todo en la vida, más vale prevenir que curar. Se deben tomar todas las medidas posibles a nivel de sistema y de software adicional (tanto principal como complementario) que permitan securizar un determinado servicio. En el ejemplo que nos ocupa, hay medidas que se pueden tomar en el propio servidor Apache (implementando módulos y directivas), en software de terceros (un caso muy cercano es el de OpenSSL) y a nivel de sistema (cortafuegos, auditorías y logueo de actividades).
- El de la funcionalidad: las medidas que tomemos para securizar nuestros entornos no deben suponer una merma en la calidad y funcionalidad del servicio que prestamos. Por ejemplo, si queremos evitar ataques DDoS las medidas que tomemos, si son muy estrictas, podrían identificar a usuarios legítimos como atacantes y bloquear su acceso, lo que afectaría evidentemente a la calidad del servicio final. Otro ejemplo: la longitud mínima de clave recomendada en estos momentos es de 2048 bits. Subirlo a 4096 bits haría que estuviéramos más seguros, pero el rendimiento de nuestro servidor web se resentiría notablemente. Debemos tener en mente que para toda operación de cifrado existe otra de descifrado, y que ambas suponen trabajo adicional para la CPU.
Voy a intentar centrarme en el servidor web Apache, que a día de hoy sigue siendo el rey de la colina.
Mantenerse actualizado es básico
Muchas veces -especialmente cuando las políticas de seguridad de una organización son conservadoras- se dice que aplicando parches de seguridad tapas unos agujeros para abrir otros. Lejos de eso, de lo que se trata es de estar protegido frente a las últimas vulnerabilidades, que son las que se van a aprovechar al máximo por los atacantes con mejores conocimientos. Las antiguas vulnerabilidades, por si fuera poco, serán tan conocidas que abrirán la posibilidad de que atacantes con no demasiados conocimientos puedan llevar a cabo ataques exitosos (script kiddie). Por otro lado, creo que hay que mantener actualizado tanto el sistema operativo (ya sea GNU/Linux, Windows Server, etc…) como el software adicional (servidores web, de aplicaciones…)
Medidas básicas de seguridad para el servidor web Apache
En un servidor web Apache se pueden tomar medidas de seguridad básicas sin necesidad de implementar más software o módulos de terceros. Cosas tan básicas a implementar como:
- Que el proceso de Apache se ejecute con un usuario único distinto de root y con permisos restringidos.
- Proteger el directorio raíz del sistema.
- Limitar accesos por rangos de IP.
- Deshabilitar la ejecución de scripts CGI. Son una fuente inagotable de problemas, ya que se ejecutan del lado del servidor.
Evidentemente hay muchas más medidas que podéis tomar según las necesidades del entorno. Tenéis amplia documentación, por ejemplo en Tecmint, Techrepublic o la propia web de Apache.
Mod_security: WAF (Web Application Firewall) y reglas de securización
Y aquí ya pasamos a uno de los grandes inventos después del descubrimiento del fuego. El módulo mod_security actúa como un firewall para nuestro servidor web. ¿Qué significa esto? Que todas las peticiones que lleguen pasan antes por mod_security, el cual analiza y previene de intrusiones y ataques (en este sentido se podría decir que actúa también como un sistema de prevención de intrusos). Está disponible no sólo para Apache, sino también para IIS y Nginx. Para los servidores de aplicaciones, como Tomcat, Jboss o Weblogic, aún está en fase experimental.
Si estás pensando en instalarla desde GNU/Linux, está disponible desde repositorios tanto para Debian/Red Hat y derivadas de ambas ramas. Siempre podremos, como siempre, compilarlo desde código fuente.
Por otro lado, el punto fuerte de mod_security lo ofrece el conjunto de reglas (CRS, Core Rule Set) de OWASP (Open Web Application Security Project) que están en constante desarrollo y actualización para adaptarse a los cambios y amenazas de la red. No confundir por tanto el módulo con el CSR. Primero se instala mod_security, y posteriormente se realiza la implementación de las reglas (CSR).
En su conjunto habremos ganado en tranquilidad y podremos dormir a pierna suelta. Tendremos, por ejemplo:
- Filtros y análisis de protocolo HTTP y HTTPS.
- Análisis de cabeceras HTTP.
- Protección frente a inyecciones SQL.
- Creación de reglas personalizadas de detección.
- Ejecución de Apache en una jaula “chroot” securizada.
Desde el sitio web del proyecto además ofrecen una plataforma de demostraciones para poner a prueba la robustez del módulo.
Mod_qos: Calidad de Servicio (QoS, Quality of Service) y protección contra DDoS
Mod_qos es otro de los grandes junto a mod_security. Podría considerarse el heredero de mod_evasive, el cual estaba diseñado específicamente para protegernos de ataques de denegación de servicio (DoS, Denial of Service). El problema de mod_evasive es que en estos momentos sólo está disponible para la ya vieja rama 1.3 y 2.0 de Apache. Hoy en día las ramas estables son 2.2 y 2.4, así que se ha quedado un poco vetusto. Además mod_qos ofrece algo más que protección frente a ataques de denegación de servicio:
- Ajuste dinámico del ancho de banda dedicado a cada conexión.
- Límite del número de conexiones recurrentes a determinadas URLs. A su vez, también puede ajustar un límite de conexiones por IP.
- Ajuste dinámico de Keep Alive en las conexiones.
- Análisis de cabeceras HTTP para evitar operaciones no autorizadas.