Una de las grandes diferencias de Apache con el resto de servidores webs más recientes es la manera en la que maneja la información, mientras Apache realiza las peticiones de manera sincrónica, Lighttpd y también NGINX realizan estas operaciones de manera asincrónica permitiendo en definitiva gestionar la información de una manera más eficiente.
Si bien es cierto que Apache cuenta con muchos más plugins y mucha más documentación disponible al alcance de todos en internet que Lighttpd, en cuestión de rendimiento Apache sigue quedando un poco atrás, independientemente de que hoy en día sea el más usado.
A la hora de configurar un servidor web es muy importante ser lo más estricto, dentro de lo posible, para intentar prevenir cualquier intento de ataque que pudiera producirse. Como bien todos sabemos esta no es la solución, pero en numerosas ocasiones es evidente que puede entorpecer bastante la tarea de cualquier atacante si este está bien configurado.
Configuración Lighttpd
Por defecto el fichero de configuración de Lighttpd se puede encontrar en la siguiente ubicación.
Grupos/Usuarios
Es importante que el Servidor Web corra con su usuario y su grupo con los privilegios estrictamente mínimos y necesarios para ello. A continuación se incluyen las directivas para definir el usuario y los grupos. Por defecto en este tipo de configuraciones es "lighttpd", también es importante asignar unos permisos y grupos bien definidos a nuestro directorio Web así como dar permisos.
Listado de Directorios
Lo más recomendable es denegar el listado de directorios en toda la raíz del Servidor Web. Podemos hacerlo con la siguiente directiva.
Server Banner
A la hora de determinar que cabecera de servidor usaremos podemos barajar las siguientes opciones como son ocultar la versión o suplantar la cabecera por la de otro Servidor Web que no tengamos instalados. Obviamente la opción menos aconsejable es la de anunciar realmente el Servidor Web que estamos usando, en este caso Lighttpd.
Una posible desventaja la hora de suplantar la cabecera es que herramientas automatizada, escáneres de vulnerabilidades o cualquier otro tipo de herramientas que identifiquen nuestro servidor web por medio de estas cabeceras lanzaran ataques para ese servidor Web anunciado, por tanto la mejor opción siempre será no mostrar información de ningún tipo.
Por ejemplo, si se define la cabecera como Unknow numerosos escáneres de vulnerabilidades Web entre ellos Acunetix WVS mostraran que la cabecera esta falseada.
Podemos definir un Banner para nuestro Servidor Web usando la siguiente directiva.
Symlink
Es recomendable deshabilitar cualquier funcionalidad que no vayamos a utilizar, si no vamos a usar el seguimiento de symlink en Lighttpd es recomendable deshabilitarlo mediante la siguiente directiva.
Not Found Handler
En numerosas ocasiones nuestro sitios pueden ser escaneados por distintos crawlers que a través de fuerza bruta de directorios y analizando los códigos de respuesta HTTP pueden definir un árbol del directorio del Sitio Web.
Ya que la mayoría de las herramientas están basadas en el análisis de códigos de respuesta para definir si un directorio existe o no, por tanto vamos a redirigir cualquier directorio o fichero no encontrado a nuestro index, de manera que cualquier respuesta la dará como existente, y que para un atacante sea imposible mediante esta técnica listar nuestros directorios y ficheros.
Sin embargo hay otros tipos de herramientas como por ejemplo OWASP DirBuster que cuando comprueban estos comportamientos de respuesta en el servidor, intentan generar otros patrones alternativos para definir la existencia de estos ficheros y directorios. Estas se basan en el tamaño del contenido para definir si el directorio existe o no cuando no se puede determinar a través del código de respuesta HTTP.
Para protegernos ante estas técnicas lo que haremos será implementar en nuestro index un sistema que genere un comentario HTML en el código. De manera que cada solicitud genere un tamaño distinto de respuesta y como consecuente la herramienta generará un alto volumen de falsos positivos imposibilitando a un atacante listar nuestros directorios.
MultiRange Requests
Las peticiones multi-rango son peticiones de uno o más sub-rangos de un archivo. Éstas son útiles para la reanudación de descargas interrumpidas y para traer pequeños fragmentos de ficheros de gran tamaño. Si no vamos a permitir la descarga de ficheros es recomendable deshabilitar este tipo de peticiones.
Si vamos a permitir visualizar ficheros PDF’s mediante el plugin de Adobe Acrobat es recomendable deshabilitar las peticiones multi-rango para este tipo de ficheros ya que puede provocar una denegación de servicio en el plugin si este tipo de peticiones están activadas.
Alive Requests
Es posible definir cuantas conexiones pueden permanecer vivas hasta que se cierra la conexión, el valor por defecto es de 16, 0 es ilimitado, aunque podemos redefinir esto con la siguiente directiva.
Para definir cuantos segundos pueden pasar hasta que una conexión pasa de abierta a estar libre, el valor por defecto son 5 segundos.
Max Request Size
Si nuestro Servidor Web no va aceptar subidas de ficheros ni tampoco vamos a necesitar realizar peticiones de gran tamaño, podemos limitar el tamaño máximo de una petición, el valor por defecto es ilimitado.
Traffic Shaping
Se puede limitar el volumen del tráfico por servidor o por conexión de manera que se distribuyan de una manera más estable los recursos del servidor, las directivas están expresadas en kilobytes por segundo.
HTTP Methods
Mediante la siguiente directiva definiremos los métodos HTTP que nuestro Servidor Web aceptará, la directiva usada es por lista blanca, es decir que cualquier método HTTP que no esté incluido no se interpretará, devolviendo un error 403 Forbidden.
Deny File/Extensions
A la hora de denegar extensiones o nombres de ficheros es importante entender por qué estos pueden suponer un riesgo en el momento de explotar un sistema y de qué manera nos pueden proteger ante un ataque. A continuación se incluye una lista de extensiones básicas y nombres de ficheros que sería recomendable denegar el acceso y también una breve descripción de por qué sería aconsejable denegar esta extensión o nombre de fichero.
| Extensión/Fichero | Descripción |
| bak bck backup back |
Suele ser una extensión comúnmente usada a la hora de realizar una copia de seguridad de un fichero en el servidor local. |
| ini | Posiblemente no queramos mostrar ningún tipo de fichero de configuración expuesto en nuestro servidor por tanto no es una mala idea denegar este tipo. |
| git | En numerosas ocasiones los desarrolladores suben ficheros a entornos que están en desarrollo directamente desde GitHub y estos expuestos en la raíz del servidor ficheros relacionados con el repositorio. |
| sql sql.tar sql.tar.gz sql.zip |
Si algún administrador deja expuesto algún fichero de copia de seguridad de SQL no sería lo más apropiado que este fuese accesible para la descarga. Por tanto denegar este tipo de archivos siempre será una buena opción. |
| swp swo |
Este tipo de fichero es una extensión asociada a SWAP podría contener algún tipo de información de un fichero que se editó previamente. |
| save | Esta extensión es usada por la utilidad de Unix nano, por ejemplo mientras se edita un fichero a través de SSH, si la conexión cae, el fichero que se estaba modificando en cuestión permanecerá con esta extensión. Aunque en principio no parece suponer un riesgo pero imaginémonos que un administrador estaba editando el fichero de configuración de un Wordpress ‘wp-config.php’. Si un atacante intenta determinar si el fichero ‘wp-config.php.save’ existe podrá visualizar su contenido y así extraer las credenciales de la base de datos, si a esto le añadimos que tiene phpMyAdmin instalado y accesible, les estaríamos dando una puerta de acceso a nuestro servidor web. |
| phpinfo.php | En muchas ocasiones al instalar aplicaciones webs estas incluyen en su instalación estos ficheros para verificar la configuración de PHP. Por tanto si su servidor web tiene instalado PHP sería recomendable denegar este tipo de fichero. |
| leeme readme licencia license changelog .txt .htm .html |
Estos ficheros están presentes en la mayoría de las aplicaciones web o componentes de CMS que se instalen, suelen contener información acerca de la versión usada, configuraciones por defecto, etc… Por tanto también es importante denegar estos tipos de ficheros para que la tarea de identificación de servicios no sea tan fácil para cualquier atacante. |
| log | Siempre existe la posibilidad de que cualquier aplicación web genere un fichero de log en directorio web. |
| .php3 .php5 |
En numerosas ocasiones atacantes usan estas extensiones que PHP interpreta para evadir filtros donde por ejemplo la extensión .php esta denegada en un directorio de subida. |
| README | Extensión comúnmente usada para ficheros README que puede permitirnos dar información acerca del software instalado en numerosas ocasiones. |
| filepart | Extensión asociada a la aplicación WinSCP, mientras se transfiere un fichero el fragmento mantiene con esta extensión, en ocasiones la transferencia falla dejando expuestos fragmentos del código fuente del archivo. |
Mod_Evasive
Este módulo está diseñado para evitar ataques de denegación de servicio contra nuestro servidor Web, a continuación vamos a explicar una serie de directivas aconsejables para intentar mitigar este tipo de ataques.
Hay que añadir a la configuración de Lighttpd los módulos que usaremos, por tanto añadimos la directiva para cargar este módulo.
En primer lugar vamos a denegar el número de conexiones máximas que una IP puede realizar sobre nuestro servidor añadiendo la siguiente directiva, en el siguiente ejemplo se limitó a 10 este valor.
Mod_Expire
Este módulo quizás no este tanto relacionado con el hardening pero si con el rendimiento, proporcionando una caché a tipos de ficheros que se definan en las directivas.
Lo ideal es tener las hojas de estilo, scripts e imágenes en servidores CDN (Content Delivery Network) aunque muchas veces por problemas de recursos esto no es posible, una buena alternativa es usar este módulo para que el navegador tenga en caché estos tipos de ficheros que son los que más tráfico de red generan en nuestro Servidor Web.
El propósito, es que el Servidor Web responda sólo a peticiones que no tiene el navegador del cliente en su caché, reduciendo notablemente la carga y la velocidad del sitio.
En el siguiente ejemplo se definió una caducidad de una semana para tipos de fichero como imágenes, hojas de estilo y scripts.
Mod_AccessLog
Este módulo registra todo tipo de solicitudes realizadas por Lighttpd en archivos, pipes o syslog. El formato de salida de estos registros se puede personalizar usando distintas directivas.
En el formato de salida descrito anteriormente se añade el registro de las peticiones realizadas por el método POST.
HTTP Security Headers
A continuación definiremos una serie de directivas para añadir cabeceras de seguridad a la respuesta que nuestro Servidor Web le dará al cliente, las cabeceras básicas que la mayoría deberían incluir son las que se definen a continuación, aunque hay muchas más.
| Cabecera | Descripción |
| X-Frame-Options | Esta cabecera permite evitar ataques de Clickjacking, de manera que el navegador no rechazará cualquier contenido que venga desde un FRAME. |
| X-XSS-Protection | Esta cabecera permite a los dominios y sitios activar o desactivar las protecciones de ataques de XSS |
| X-Content-Type-Options | Esta cabecera permite evitar ataques de MIME Type Confusión. De manera que el servidor sólo cargará hojas de estilo y scripts si su MIME Type es correcto. |
| Content-Security-Policy | Con esta directiva definimos una política de seguridad de contenidos. Es decir definimos las fuentes desde las que se cargarán las hojas de estilo, scripts, flash,etc... |
| Strict-Transport-Security | La información y el propósito de esta cabecera está descrito más abajo en el apartado de HSTS. |
Las directivas para incluir las siguientes Cabeceras de Seguridad en Lighttpd son:
Denegar acceso a IP’s
En ocasiones nos encontramos cualquier IPs que está tratando de acceder a contenidos restringidos, molestos bots, etc…para denegar el acceso a una IP podemos usar esta directiva:
SSL
En las siguientes directivas se desactivó la compresión en TLSv1.0 (CRIME), se deshabilitó los protocolos SSLv2 (FUBAR) y SSLv3 (POODLE), se añadió una curva elíptica, una clave de Diffie Hellman y se desactivaron cifrados débiles como RC4 (BEAST) y DES definiendo así otros protocolos modernos de cifrado como son AES:
Foward Secrecy & Diffie Hellman
Para generar un parámetro DHE fuerte usaremos la herramienta de openssl:
Una vez generado dicho fichero añadimos la siguiente directiva para añadir los parametros de Diffie-Hellman (DH)
HTTP Strict Transport Security (HSTS)
El protocolo HTTP Strict Transport Security (HSTS) estandariza el mecanismo por el cual los servidores web se "declaran" accesibles únicamente a través de protocolo seguro. (HTTPS)
Cuando realizamos una petición a través de HTTP y es redirigida a HTTPS, el cliente realiza la primera conexión sin encriptar antes de ser redirigido.
Esto abre potencialmente ataques tipo MITM (Man In The Middle), ya que la primera petición puede ser interceptada para modificar el sitio seguro original.
Incluso con la lista precargada STS, HSTS no puede evitar ser víctima de ataques avanzados como BEAST o CRIME porque los ataques son contra TLS/SSL en sí.
El estándar propuesto para HSTS está definido en RFC 6797 publicado.
El módulo que usaremos para definir HSTS es mod_setenv el cual es necesario cargar previamente en la directiva server.modules y ser usado solamente cuando se realiza una conexión segura (HTTPS) y nunca cuando se utiliza HTTP.
El valor ‘max-age’ está representado en segundos y define cuanto tiempo el operador del servidor web está dispuesto a comprometerse a utilizar solamente HTTPS, es recomendable establecer un valor grande como 31536000 (12 Meses) o 63072000 (24 Meses).
Por otro lado con ‘includeSubdomains’ indicamos que la política STS aplica a cualquier subdominio.
Aparte en los ficheros del servidor web hay que implementar HSTS, en el ejemplo siguiente se muestra un ejemplo de la implementación en PHP.
Hearthbleed
Es una vulnerabilidad publicada en Abril de 2014 y descubierta por Neel Mehta del equipo de Google Security en la librería criptográfica de OpenSSL, que es muy usada para la implementación del protocolo TLS (Transport Layer Security).
A continuación se describen que versiones de OpenSSL son vulnerables según los investigadores de esta vulnerabilidad:
| Versión | ¿Vulnerable? |
| OpenSSL 1.0.1g | NO |
| OpenSSL 1.0.1 hasta 1.0.1f | SI |
| OpenSSL 1.0.0 | NO |
| OpenSSL 0.9.8 | NO |
Puede consultar referencias de esta vulnerabilidad en los siguientes enlaces:
User Agent Deny
A continuación vamos a definir una serie de políticas que nos ayudarán a prevenir qué herramientas de análisis de vulnerabilidades, scripts automatizados, robots, crawlers, mailers, scriptkiddies pueden navegar por nuestro sitio.
Obviamente este tipo de filtro se puede evitar cambiando el User Agent del navegador pero son muchas las herramientas que incluyen estos valores sin dar opción a cambiarlos.
Por ejemplo Acunetix usa tres cabeceras para realizar sus análisis, que siempre están presentes, como son Acunetix-Product, Acunetix-Scanning-agreement y Acunetix-User-agreement a excepción del editor HTTP que permite deshabilitarlas temporalmente, pero vienen activas por defecto.
Se podrían también añadir unas directivas usando el módulo ModMagnet de Lighttpd para denegar el acceso si se detectan algunas de estas cabeceras.
Pero realmente nos vamos a centrar en denegar acceso mediante los User Agents que suele englobar la mayoría de estas herramientas, a continuación voy a incluir un resumen de la lista de los User Agents que se deberían denegar.
| User Agent | Descripción |
| Acunetix | Escáner de vulnerabilidades |
| Arachnini | Escáner de vulnerabilidades |
| Binlar | Spider |
| Blackwidow | Escáner de vulnerabilidades |
| Brutus | Herramienta de hacking |
| Casper | Escáner de vulnerabilidades |
| clsHTTP | Bot |
| DirBuster | Herramienta de hacking |
| EmailCollector | Mail spider |
| EmailSiphon | Mail spider |
| EmailWolf | Mail spider |
| FHscan | Escáner de vulnerabilidades |
| FlashGet | Herramienta de descarga |
| Harvest | Herramienta de hacking |
| Havij | Herramienta de hacking |
| Internet Ninja | Herramienta de análisis |
| JBroFuzz | Herramienta de hacking |
| JOC Web Spider | Spider |
| LWP | Perl App (LWP) |
| Libwww | Perl App (libwww) |
| Nessus | Herramienta de hacking |
| Net Vampire | Herramienta de descarga |
| NetSpider | Spider |
| Nikto | Herramienta de hacking |
| NSAuditor | Herramienta de hacking |
| OpenVAS | Herramienta de hacking |
| PageGrabber | Herramienta de descarga |
| SQLMap | Herramienta de hacking |
| Sucuri | Herramienta de hacking |
| WebBandit | Herramienta de hacking |
En el siguiente ejemplo sólo se añaden cinco User Agents pero se pueden ir añadiendo más a la lista e ir actualizándola, la directiva a usar para denegar esto es:
Mod_Rewrite
Los módulos se pueden usar para propósitos que no son comunes, por ejemplo ahora vamos a ver de qué modo nos puede proteger mod_rewrite ante accesos no autorizados.
Por lo general la gente suele definir directivas donde si la IP no es válida le lance un forbidden, en principio esto nos sirve para el propósito pero no es la forma más idónea de realizar esto ya que damos información de que dicho directorio estaba presente y le aplicamos dicha directiva.
La idea es usar Mod_Rewrite para montar los directorios dependiendo si la IP proviene de una fuente fiable, montarle los respectivos directorios Web y si no es autorizada montar otros directorios, de manera que sea invisible para un atacante determinar si un fichero o directorio existe.
En el ejemplo descrito anteriormente lo que definimos es que si la IP viene de 222.111.222.111 permita accede a los directorios private/ y phpmyadmin/ y si no montamos un index.html en raíz y el fichero robots.txt lo definimos también accesible.
También podemos usar este módulo para ocultar extensiones de ficheros que permitan a atacantes identificar las distintas tecnologías usadas, o incluso suplantar estas extensiones de tipo de ficheros.
File Hijacking
En numerosas ocasiones sitios de terceros usan recursos de nuestro sitio como por ejemplo imágenes. Cada vez que se realizan este tipo de peticiones desde terceros, se consume ancho de banda, de manera que podemos denegar el acceso a sitios externos al nuestro con la siguiente directiva.
Autor: José Carlos Expósito - CEH
Departamento de Auditoría
