La importancia del bastionado de servidores – Parte 2. Bastionando el servidor

Hoy publicamos el segundo de tres artículos cortesía de Jorge García sobre la importancia del bastionado de servidores. Aquí tenéis todos los artículos de la serie [1] [2] [3]

De acuerdo, tenemos la misión de hospedar una aplicación web de comercio online y ofrecerla al mundo en un servidor que tenemos en propiedad. Nuestro objetivo es que sea lo más inexpugnable posible a todos los niveles. Dado que se trata de una aplicación web, es previsible que el principal vector de entrada de ataques sea a través de vulnerabilidades de la propia aplicación. A ver, no nos engañemos, todos los CMS son firmes candidatos a tener vulnerabilidades severas. El esquema de cómo estará organizada la plataforma es el habitual en un servidor virtual:

Por lo tanto, la cuestión es elegir un CMS con estas premisas:

1. Que se desarrolle activamente y esté respaldado por una comunidad numerosa de desarrolladores o por una gran empresa. Esto nos garantiza que cuando se publique una vulnerabilidad, ésta sea rápidamente corregida.
2. Que el CMS instalado sea la última versión disponible de una rama que tenga soporte, y que se prevea que siga teniéndolo durante bastante tiempo. No hay que olvidar que, dado que no disponemos de entorno de desarrollo en casa, las actualizaciones o migraciones implican pérdida de servicio que a su vez implica potencial pérdida de dinero.
3. Que sea compatible con el sistema operativo del servidor que disponemos. Una consideración que es obvia pero importante.
4. Que el historial de vulnerabilidades críticas sea lo más bajo posible. Un CMS que se desarrolla activamente y tiene buen soporte pero que de media se descubre una vulnerabilidad crítica cada semana no es viable de mantener ni seguro de utilizar.

Como responsable último de la seguridad de los datos hospedados por la aplicación, es importante disponer de cuantas medidas sean necesarias para garantizar la suficiente seguridad de dichos datos. Por este motivo, considero básico disponer de:

1. Sistema operativo moderno y actualizado.
2. Instalación de la mínima cantidad de software necesaria.
3. Cortafuegos software en el propio servidor.
4. Gestión de procesos con SELinux.
5. Cortafuegos de aplicación web.
6. Servidor web Apache.
7. Aplicación web actualizada a la última versión disponible.
8. Suricata IDS para monitorizar el tráfico.
9. Análisis de tráfico HTTP mediante herramienta de análisis de visitas web.
10. Permanecer alerta a las noticias sobre ciberseguridad

Sistema operativo moderno y actualizado

Vamos punto por punto. Lo primero es disponer de un sistema operativo moderno y actualizado. Esto es importante porque un sistema operativo sin soporte (por ejemplo: CentOS 5, Ubuntu 14.04 o Debian 6, por citar algunos) implica que, ante una vulnerabilidad detectada en algún componente del sistema, el fabricante no estará obligado a publicar -y generalmente no lo hará- actualizaciones de seguridad para remediarla, con lo que el sistema quedará vulnerable. Es una cuestión de tiempo que nos comprometan el sistema. En el caso que nos ocupa, el servidor ejecuta CentOS 7 actualizado a la última versión disponible, que dispone de soporte de seguridad hasta junio de 2024, que es un plazo razonable de tiempo antes de tener que migrar a una versión más reciente.

Instalación de la mínima cantidad de software necesaria

Una nota importante a resaltar es que, a menor número de paquetes de software instalados, menor superficie de ataque tendremos. Instalar muchos paquetes y dependencias “por si en un futuro hacen falta” o simplemente si no estamos seguros de si hacen falta o no, favorece enormemente que los ataques puedan ser exitosos.

Por ejemplo, si queremos disponer de un servidor web para servir una aplicación, instalaremos únicamente el paquete del servidor web. Si la aplicación requiere PHP o un lenguaje similar, se instalará el módulo o librerías mínimas. Es muy habitual leer tutoriales en Internet que instalan todos los módulos de Apache o las integraciones de PHP con todos los backends de bases de datos aún cuando el servidor únicamente tiene configurada una -o a veces ninguna- base de datos. Esto es una mala práctica que generalmente demuestra desconocimiento de los requerimientos técnicos de la aplicación que queremos desplegar.

En el caso que nos ocupa, nuestro servidor ejecuta CentOS 7 con Apache y PHP -por requerimientos de la aplicación de mi compañera-. Una observación importante es que muchos CMS requieren de una versión concreta de PHP, lo que lleva a los administradores de sistemas a desplegar cualquier repositorio aleatorio que proporcione dicha versión o, peor aún, instalarla de fuente. Esto no es una práctica recomendable. Si bien es verdad que la versión de PHP de los repositorios oficiales de CentOS/Debian/Ubuntu puede estar desfasada en cuanto a número de versión, siempre tendremos la garantía de que, si aparece una vulnerabilidad, ésta será corregida de forma ágil dado que se trata del repo oficial.

Si el CMS requiere una versión específica de PHP más moderna de la que se incluye en los repositorios oficiales, se deberá desplegar desde un repositorio que nos transmita confianza y garantice, por un lado, que dispondremos de actualizaciones futuras y, por otro lado, que el software que proporciona es legítimo y no está modificado. Para el caso de CentOS, podemos tomar como referencias de confianza los repositorios:

• EPEL. Administrado por la comunidad de Fedora. El más recomendable
• Atomic. Adminsitrado por Atomicorp. Muy recomendable
• Remi. Administrado por Remi, uno de los empaquetadores oficiales de PHP
• Webtatic. Administrado por Andy Thompson. Proporciona los paquetes firmados GPG

Un factor importante de estos repositorios es que a menudo entran en conflicto con los paquetes que proporcionan otros repositorios -incluidos los oficiales-. Esto ocurre porque el mismo paquete (por ejemplo, PHP) es proporcionado por varios repositorios a la vez con diferente número de versión. Esto hace que muchos administradores agreguen el repo, instalen el paquete y después deshabiliten el repo para evitar que al actualizar el sistema se produzcan incongruencias. Esta práctica es incorrecta, ya que este comportamiento dejaría sin actualizaciones a los paquetes de dicho repo que hayamos instalado.

Ni que decir tiene que instalar de fuente un paquete es considerada una práctica de último recurso y no debe realizarse bajo ningún concepto, salvo que sepamos de antemano que vamos a disponer de mecanismos y recursos para poder recompilar cada versión futura y garanticemos que todo vaya a funcionar bien (no olvidemos que las paradas programadas conllevan pérdida de servicio en nuestra instalación y que no disponemos de entorno de desarrollo).

Cortafuegos software en el propio servidor

Una buena práctica en todo servidor -accesible o no desde Internet- es disponer de un cortafuegos software en la propia máquina que garantice que únicamente son accesibles los puertos que el administrador del sistema considere que son relevantes para el desempeño del servicio. Por ejemplo, un servidor web generalmente necesitará tener conectividad a los puertos TCP 80 (HTTP) y TCP 443 (HTTPS). Si el servidor va a ser accedido por SSH para administración (no desde Internet, por favor) entonces también tendremos que tener abierto el puerto TCP 22 (SSH).

¿Y por qué es necesaria esta filtración de puertos a nivel local? Porque en el supuesto de que el servidor se infecte con un malware que levante un puerto de escucha, evitaremos que dicho puerto sea accesible desde otra máquina. Es decir, el malware podría levantar un puerto de escucha pero el cortafuegos no permitiría el acceso al mismo, lo que mitigaría enormemente la propagación del mismo.

Por suerte, CentOS 7 lleva de serie el cortafuegos firewalld. Únicamente debemos permitir el tráfico de los puertos deseados. En nuestro caso, habilitamos el puerto 80 -donde el servidor hará una redirección fulminante al puerto HTTPS- y el puerto 443.

Gestión de procesos con SELinux

Aunque no es el momento de hablar de ello, algunos ataques a servidores web o a la propia aplicación conllevan la descarga del malware -generalmente por etapas- en directorios temporales por parte del servidor infectado. Una vez concluidas las descargas, el malware lo ejecuta el propio servicio web con los permisos que éste disponga.

Una forma de mitigar este hecho en CentOS es mediante el uso de SELinux. Esta herramienta permite restringir el comportamiento de un servicio en ejecución a aquellos supuestos en que el servicio se asume que debe operar. Por ejemplo, para un servidor web es considerado normal que levante ciertos puertos estándar o que sea capaz de servir contenido desde /var/www, pero generalmente no es considerado normal que envíe correos electrónicos -salvo formularios web- ni tampoco es usual que pueda acceder o borrar ficheros del filesystem. Por supuesto puede haber aplicaciones donde esto sea lícito, pero hablamos del caso general. SELinux restringe aquellas acciones no-estándar o sospechosas que un proceso ejecuta. Por supuesto SELinux puede configurarse manualmente para permitir algunas acciones que hayan sido bloqueadas por defecto (por ejemplo, el citado envío de correos electrónicos desde un formulario web).

Es muy habitual leer tutoriales en Internet acerca de “Cómo desplegar la aplicación X en CentOS” y la mayoría citan “Deshabilitar SELinux” como uno de sus primeros pasos “para evitar problemas”. ¡Los problemas se evitan configurándolo! Deshabilitar SELinux es una práctica muy desaconsejable.

Cortafuegos de aplicación web

Aunque sólo tengamos abiertos en el firewall del equipo los puertos TCP 80 y TCP 443 y aunque dispongamos de SELinux configurado para evitar comportamientos anómalos, la aplicación web siempre va a ser susceptible de ataques inyección SQL, XSS, reutilización de credenciales, DoS, etc. Este tipo de ataques nunca son bloqueados en el firewall del equipo -que únicamente bloquea el tráfico desde o hacia puertos distintos de los mencionados- ni tampoco por SELinux, ya que muchos de estos ataques se basan en el funcionamiento habitual de la aplicación (generalmente aprovechando alguna vulnerabilidad conocida).

Por este motivo existen los cortafuegos de aplicación web. Este tipo de cortafuegos inspeccionan el tráfico web desde y hacia la aplicación en busca de peticiones no estándar o sospechosas -por ejemplo, aquéllas que disponen de una sentencia SQL en la propia URL, o que llaman a algún recurso de subida de ficheros en un CMS (upload.php o similar)-. En el caso de CentOS, la herramienta más habitual para este menester es Mod Security. Se trata de un módulo de Apache que, debidamente configurado, nos protege de bastantes de estas amenazas.

La configuración por defecto de Mod Security es bastante restrictiva y, de igual forma que ocurre con un IDS, también funciona a base de firmas que se actualizan con frecuencia (generalmente a través de un repositorio). Esto permite detectar ataques web que se hayan comenzado a utilizar recientemente. A diferencia de un IDS (en modo detección), Mod Security actúa bloqueando las peticiones que considera sospechosas.

Por suerte, Mod Security incluye algunas configuraciones automáticas para corregir falsos positivos en algunas aplicaciones estándar como WordPress o Owncloud (por ejemplo, si la aplicación requiere un método HTTP distinto de GET o POST, por ejemplo, DELETE o PUT -lo cual es habitual en aplicaciones de almacenamiento en la nube-).

Un aspecto interesante es que Mod Security realiza correlación de eventos estableciendo un nivel de sospecha por IP de origen en base a la repetición y patrón de las peticiones analizadas. Es decir, aunque se presenten peticiones de baja sospecha, si se presentan muchas del mismo tipo en cierto intervalo de tiempo desde la misma IP, el cortafuegos bloquea la IP por seguridad devolviendo peticiones 403 hasta que la IP se desbloquee (manual o automáticamente pasado cierto tiempo). Cada IP origen acumula un nivel de sospecha que varía en función del tiempo en base a las peticiones que realizan. Si el nivel alcanza cierto umbral, la IP origen queda bloqueada.

Esto garantiza en todo momento que, aunque una aplicación sea vulnerable, siempre estará protegida por el firewall de aplicación, lo que añade una capa importante de seguridad al sistema.

En el caso que nos ocupa, para el CMS elegido ha habido que hacer personalizaciones a mano, ya que no hay plantilla predefinida para Mod Security.

Servidor web Apache

Toda aplicación web es servida por un servidor web. En el caso que nos ocupa, el servidor web que utilizo es Apache por su versatilidad, seguridad y compatibilidad. Dado que es uno de los componentes clave del sistema, es absolutamente importante que se mantenga actualizado. Una de las múltiples ventajas que proporciona Apache es que dispone de una infinidad de módulos que lo integran con otras tecnologías, como PHP, Mod Security, proxies, etc.

Además de estar actualizado, el servidor web debe estar correctamente configurado para evitar exponer más información de la estrictamente necesaria y además reducir la superficie de ataque, así como paliar posibles vulnerabilidades. Un correcto bastionado del servidor Apache debe incluir:

• No revelar la versión de Apache o, mejor aún, mostrar deliberadamente otra versión o tecnología con el objetivo de confundir al atacante. En mi caso, he modificado el banner que muestra el servidor para que haga creer al visitante que el servidor ejecuta el sistema Microsoft IIS. Es increíble la cantidad de ataques que detecta el IDS intentando explotar vulnerabilidades de ese producto. Esto nos protege automáticamente de ellas, ya que intentan explotar vulnerabilidades de un sistema operativo y servidor web diferente al que realmente estamos ejecutando. Seguridad por ofuscación en toda regla.
• No habilitar el listado de directorios. Esto previene el acceso a los ficheros del directorio web de forma manual a través de la URL.
• Deshabilitar los módulos innecesarios que, por defecto, vienen activos. Es importante conocer bien qué módulos necesita la aplicación que queremos servir.
• Deshabilitar la opción Follow Symlinks. De esta forma evitamos que ante una vulnerabilidad que permita crear ficheros en el directorio web, el atacante pueda crear un enlace simbólico a contenido del sistema (por ejemplo, al fichero /etc/passwd).
• Limitar el tamaño de la petición HTTP. Esto mitiga los ataques de tipo DoS, ya que evita que los atacantes puedan enviar peticiones de tamaño grande, habilitadas por defecto.
• Deshabilitar la navegación fuera del directorio web. Esto mitiga una cantidad enorme de ataques que se basan en introducir en la URL los comandos para subir de nivel de directorio (por ejemplo /../../etc/passwd)
• Configurar la cabecera HTTP X-FRAME-OPTIONS para que únicamente se admita que la página que servimos pueda ser contenida dentro de un iframe desde la propia página que estemos sirviendo (SAMEORIGIN). Esto mitiga ataques de tipo clickjacking, donde se embebe la página que servimos dentro de un iframe de otra página fraudulenta que captura la información introducida en el iframe.
• Restringir los métodos HTTP que no sean de utilidad para las aplicaciones que servimos. Por defecto Apache da servicio a una multitud de métodos HTTP que aumentan la superficie de ataque. Es habitual observar intentos de conexión usando métodos HTTP asociados con conexiones VoIP SIP tratando de explotar alguna vulnerabilidad conocida. Por lo tanto, si la aplicación únicamente necesita, por ejemplo, HEAD, POST y GET, únicamente deberán estar dichos métodos habilitados.
• Habilitar protección contra Cross-site Scripting (XSS). Este tipo de ataques generalmente requiere que la aplicación permita interacción del usuario mediante campos de entrada, tales como comentarios de un foro. Si el campo introducido por el usuario no se sanitiza por la aplicación, éste puede introducir código arbitrario que será ejecutado cada vez que se muestre dicha página (por ejemplo, el comentario del foro anteriormente ejemplificado).
• Deshabilitar método TRACK/TRACE. Estos métodos están diseñados para situaciones donde se requiere debugging y permite realizar ataques XSS contra el servidor, ya que la petición TRACE devuelve la información que se solicita en la petición.
• Ejecutar el proceso Apache desde un usuario no privilegiado. Esto ya lo comentamos en el apartado de SELinux, cuando el malware ejecute código, lo hará con los privilegios de que disponga el servicio web. Es importante que sean los mínimos posibles.
• Utilizar certificados TLS de forma exclusiva, con redirección del puerto 80 al 443.
• Permitir únicamente cifradores TLS que sean seguros, robustos y no vulnerables.

Aplicación web actualizada a la última versión disponible

Esto es un clásico. Al final, la gran mayoría de las vulnerabilidades se presentan en la aplicación, por lo que es de esperar que sea aquí donde más esfuerzos pongamos en la prevención.

Lo primero que debemos considerar es si realmente necesitamos desplegar una aplicación adicional para el cometido que queremos llevar a cabo. A menudo las empresas despliegan muchas aplicaciones porque estiman que mejoran el negocio o la productividad de la empresa, pero pocas veces se paran a valorar el coste de administración de sistemas para mantener la aplicación actualizada. Muchas veces se puede introducir esa funcionalidad en otra aplicación que ya se encuentre disponible -generalmente pagando algún coste de oportunidad- en lugar de desplegar una aplicación nueva. En el caso que nos ocupa, dado que es la única tienda que hospedo, no me queda más remedio que desplegar una aplicación dedicada.

A la hora de planificar el despliegue de una nueva aplicación es importante elegir una solución que esté en mantenimiento activo, es decir, que ante una eventual vulnerabilidad, ésta sea parcheada lo antes posible. Generalmente una gran comunidad de desarrolladores y/o una gran empresa que soporte el producto suele ser garantía suficiente.

En el caso que nos ocupa, al elegir Prestashop tuve en cuenta el extenso tiempo en que se viene desarrollando (la compañía PrestaShop SA se fundó en 2007, aunque el proyecto data de 2005). Esto significa que la empresa lleva 12 años desarrollando la aplicación en sus diferentes versiones, lo cual presupone agilidad en la resolución de incidentes.

Otro factor a tener en cuenta es el histórico de vulnerabilidades y la frecuencia y criticidad con la que aparecen. Una aplicación que se actualiza a menudo pero que presenta vulnerabilidades con mucha frecuencia requiere un esfuerzo grande por parte del administrador del sistema para mantenerla actualizada.
Prestashop dispone de 21 CVEs registrados desde el año 2008, la mitad de ellos el año pasado, con un promedio de 2,6 vulnerabilidades por año:

Podemos observar que es un ratio muy inferior a otro tipo de CMS populares como WordPress, con 219 CVE desde 2008, con un promedio de 19,1 por año:

Una solución que ofrece una funcionalidad similar respecto a comercio online es Magento, una aplicación mucho más joven y algo menos madura que Prestashop, con 11 CVE en 5 años, a un promedio de 2,2 vulnerabilidades por año:

La elección de Prestashop sobre Magento la tomé considerando como criterios la funcionalidad de los módulos, biblioteca de temas y la facilidad de administración, entre otros factores.
También es importante valorar el tiempo de vida de cada rama del producto. Algunos fabricantes invierten muchos recursos desarrollando nuevas versiones del producto, lo que a veces conlleva que las versiones anteriores pierdan el soporte con rapidez, lo cual fuerza a los clientes a estar siempre actualizados a la última rama. Esto muchas veces supone que el cliente tenga que invertir un tiempo adicional adaptando los temas visuales a la nueva rama o que algunos plugins de terceros no sean compatibles, teniendo que elegir entre asumir una pérdida de funcionalidad o ser vulnerables. Esto no es deseable, especialmente cuando no hay un camino oficial de actualización de rama y todo se basa en realizar una copia y migrar los datos a mano.

En el caso de Prestashop, observamos que las dos últimas ramas publicadas, la 1.6 y la 1.7, conviven con mantenimiento activo y están en desarrollo continuo durante bastante tiempo:

Rama 1.7. Publicada la versión 1.7.0 en noviembre de 2016. Actual 1.7.5.2 de mayo de 2019.

Rama 1.6. Publicada la versión 1.6.0.5 en marzo de 2014. Actual 1.6.1.24 de mayo de 2019.

Esto implica que un cliente con la rama 1.6, aunque la hubiera desplegado en 2014, seguiría teniendo soporte de seguridad. Esto es un gran añadido.

Todo esto nos lleva a la monitorización. Tenemos que tener una forma ágil de enterarnos de cuándo ha salido una nueva versión para planificar la actualización lo antes posible. Los ataques más devastadores pueden producirse justo cuando se publica la vulnerabilidad, especialmente si ésta es crítica o fácil de explotar, debido a que es fácil que nos coja desprevenidos. Efectuar una correcta monitorización del versionado de la aplicación y de las versiones disponibles es básico. La práctica más común es desplegar algún check personalizado de Nagios, Zabbix o de la herramienta de monitorización que se utilice para que lo compruebe de forma automática y nos genere un evento/alerta para poder planificar la actualización.

Suricata IDS para monitorizar el tráfico

Aunque dispongamos del sistema correctamente bastionado, una aplicación actualizada a la última versión con soporte y dispongamos de ayudas adicionales como SELinux o Mod Security, siempre conviene disponer de un método para identificar posibles ataques -exitosos o no- de modo que podamos ver de un golpe de vista las alertas de dichos incidentes en lugar de bucear por todos los logs del sistema en busca de anomalías.

Una excelente solución para esto es disponer de un IDS en nuestra red que analice todo el tráfico entrante y saliente del servidor en busca de posibles intentos de explotación de alguna vulnerabilidad. Aunque hay multitud de soluciones en el mercado, las soluciones de código abierto gratuitas más conocidas son Snort y Suricata. El primero data de 1998 mientras que el segundo es mucho más reciente, datando de 2010. Snort está actualmente desarrollado por Cisco mientras que Suricata está desarrollado por la Open Information Security Foundation (OISF).

Suricata corrige algunas de las mayores limitaciones de Snort, principalmente el soporte para multithreading del procesador, lo cual es vital en redes de mucha carga de paquetes por segundo. Algunos -no todos- los sets de reglas de Snort son compatibles con Suricata, lo cual le hace beneficiario de la gran cantidad de reglas desarrolladas por la comunidad de Snort, mucho más numerosa que la de Suricata debido a su también mucho mayor tiempo de vida.

Valorando no solo proteger la nueva tienda online de Prestashop, sino también los otros portales y servicios que hospedo, consideré hace un tiempo que era momento de mejorar la seguridad emplazando un Suricata IDS en el perímetro para analizar el tráfico desde/hacia la DMZ donde están emplazados los servidores y poder tener más información sobre posibles ataques. Fue una idea absolutamente brillante. Darse cuenta del número y la sofisticación de los intentos de explotación de nuestra red nos da una información realista sobre lo activo que está el entorno de la ciberseguridad, aunque la mayoría de veces no nos demos cuenta.

En el caso que nos ocupa aproveché que el firewall de red que ya tenía en uso es Pfsense, que dispone de un módulo de Suricata integrado, y lo configuré. De esta forma, aprovechamos los recursos hardware, minimizamos superficie de ataque y -para una red doméstica- proporciona un rendimiento más que aceptable.

El siguiente paso es configurar los sets de reglas específicos para el tráfico que queremos monitorizar -generalmente los sets de reglas correspondientes a la aplicación web, los de malware y los del sistema operativo del servidor-. Cuantos más sets de reglas tengamos activos, el IDS invertirá más tiempo comprobando si cada paquete hace match en alguna de ellas, por lo que es conveniente activar sólo aquéllos que proporcionen información de utilidad (aquí, menos, es más). Las reglas que hacen mucho ruido y no aportan información importante generalmente distraen al analista de aquellas que sí son relevantes, de modo que tenemos que llegar a un punto intermedio entre querer enterarnos de todo, relevante o no, y aceptar la remota -pero no cero- posibilidad de perdernos alguna alerta por falso negativo.

En el caso que nos ocupa, dado que se trata de un volumen de tráfico muy bajo (unos pocos cientos de visitas por día) y dado que únicamente administro yo la infraestructura, prefiero perderme alguna alerta que tener que procesar miles de ellas que no aportan tanta información, dado que no dispongo del tiempo ni recursos necesarios.

Análisis de tráfico mediante una herramienta de análisis de visitas web

Este consejo es de mi propia cosecha y no lo he visto reflejado en ningún otro sitio, pero lo considero muy relevante. Estamos de acuerdo en que con un IDS en marcha y todas las medidas anteriormente descritas la aplicación tiene un nivel de seguridad muy aceptable, pero hay un factor de ingeniería social que aún podemos aportar.

Mi granito de arena consiste en hacer un análisis de los logs del servidor web correspondientes a la aplicación -la tienda en este caso- mediante alguna aplicación de estadísticas web como Google Analytics o -mejor aún- alguna solución auto hospedada como Matomo.

Para los que no lo conozcan, Matomo “es como un Google Analytics pero hospedado en tu infraestructura y sin ceder los datos a nadie”. Matomo toma los logs de tu aplicación directamente del servidor web y los procesa proporcionando información visual muy detallada sobre el número de visitas, el país y región de origen, sistema operativo, navegador y complementos, tiempo de permanencia en las páginas, etc. Además de ser enormemente útil para conocer mejor el público de tu negocio y saber si las campañas de publicidad funcionan según lo esperado, también lo es desde la perspectiva de la ciberseguridad al proporcionar una herramienta brillante para detectar picos inusuales en el número de visitas, ciertos user-agents que pueden estar asociados al malware, picos de visitas desde algunos países con campañas de malware activas, etc.

En definitiva, es una herramienta más en la que buscar información cuando nos encontramos con un posible incidente. Una simple vista del gráfico de tendencias de visitas puede darnos una idea de si estamos sufriendo un ataque DDoS (si se produce un incremento muy repentino del número de visitantes) o incluso alertarnos de algún problema en alguna regla de firewall que hayamos configurado mal (si se produce un decremento muy repentino del número de visitantes):

Incluso valorando el número de visitas en función de la hora del día nos puede facilitar acotar el incidente temporalmente si observamos alguna singularidad:

El mapa de origen de las visitas nos puede ayudar a correlar posibles eventos en función del país de origen que tenga actividad maliciosa reciente, por ejemplo, nos puede ayudar a detectar la presencia de una botnet:

Aislar la tecnología empleada (dispositivo, sistema operativo, navegador, etc.) también puede resultar útil en la resolución de un incidente:

Conocer qué páginas son las más solicitadas puede ayudarnos a identificar, por ejemplo, el abuso de una API que esté siendo explotada o la presencia de una página anómala que no debiera existir:

Disponer además del fingerprinting tanto a nivel de usuario logueado como de visita anónima, aporta una información valiosísima en cuanto a la correlación de posibles visitas que a primera vista parezcan diferentes -por ejemplo, porque el usuario haya cambiado de IP y de país de origen con una VPN- pero que en realidad se trata de la misma persona. Para esto se pueden utilizar las cookies persistentes o bien una simple correlación de dispositivo, sistema operativo, navegador y resolución de pantalla.

A modo de ejemplo, la siguiente visita puede ser acotada a un dispositivo Samsung Galaxy S8, ejecutando Android 9 con Chrome 73.0, con resolución de pantalla 360×740 desde Nueva York a las 7:58 AM. En el caso de la gestión de un incidente, esta información conjunta puede aportar una gran información.

Por todo esto considero importante recalcar la importancia de tener en cuenta las herramientas de análisis de visitas web como Matomo, especialmente porque no cedemos nuestra información a terceros dado que la hospedamos en nuestra propia infraestructura.

Permanecer alerta a las noticias sobre ciberseguridad

Este punto está estrechamente relacionado con la monitorización que hemos hablado en la sección sobre el mantenimiento actualizado de la aplicación. Estar al día de las últimas noticias de ciberseguridad nos permite anticiparnos a los ataques conociendo las vulnerabilidades en cuanto éstas son publicadas, permitiéndonos un buen margen de maniobra y planificación de la actualización, todo ello generalmente antes de que ésta esté explotándose activamente.

Es conveniente, por tanto, estar suscrito a boletines de seguridad de aquellos fabricantes cuya tecnología tengamos instalada, tanto a nivel de sistema operativo (Red Hat, CentOS, Microsoft, etc.) como de aplicaciones (Prestashop, WordPress, etc.). También es buena idea estar suscrito y visitar con frecuencia boletines generalistas sobre seguridad informática, como los previstos por el CCN-CERT, CSIRT-CV, Hispasec una al día, Portal de concienciación de Generalitat Valenciana o Un informático en el lado del mal, o este mismo blog de SecurityArtWork entre otros muchos. También es recomendable leer con frecuencia los informes de tendencias del malware para conocer cómo y hacia dónde se está moviendo el mercado del malware y poder anticiparnos a posibles amenazas, como éste elaborado por MalwareBytes, éste de McAfee o éste de ESET.