Enlace a facebook.
digitalDot diseño webLogo Diseño Web digitalDot

Protección de Servidores VPS contra Ataques DDoS: Cómo detectarlos y mitigar su impacto

Protección de Servidores VPS contra Ataques DDoS
Escrito por Inma Navarro
17 de octubre de 2024
Tiempo de lectura 20 min

Los ataques DDoS (Denegación de Servicio Distribuido), han evolucionado rápidamente. Estos ataques son una de las amenazas más peligrosas para las tiendas online, ya que, pueden comprometer tanto el rendimiento del servidor VPS como la experiencia de usuario, y afectar el posicionamiento SEO.

¿Qué es un ataque DDoS y por qué debería preocuparte?

En un mundo cada vez más digitalizado, las amenazas a la seguridad online están en constante evolución. Entre ellas, los ataques DDoS (Denegación de Servicio Distribuido) son una de las más dañinas y, si tienes una tienda online, podrían ser una amenaza mayor de lo que piensas.

Un ataque DDoS ocurre cuando múltiples sistemas envían una gran cantidad de solicitudes a un servidor con el objetivo de sobrecargar sus recursos (CPU, RAM, ancho de banda, etc.) y hacerlo inaccesible. Para las tiendas online y sitios web, un ataque de este tipo puede causar caídas de servicio, pérdidas económicas y comprometer la experiencia del cliente. Con los servidores VPS de digitalDot protegemos tu tienda de estos ataques.

¿Por qué confiar en nuestro servicio?

¿Cómo puedes estar seguro de que tu negocio está realmente protegido ante estas amenazas? En digitalDot, no sólo prevenimos ataques, sino que nos hemos enfrentado a situaciones críticas como ataques DDoS masivos y hemos salido victoriosos. Nuestros servicios personalizados están diseñados específicamente para tiendas online y empresas que dependen de su presencia digital. Además, trabajamos con los mejores centros de datos y proveedores de hosting nacionales, lo que garantiza un SLA óptimo, atención técnica dedicada y la mejor velocidad de servicio.

Cada año desde digitalDot planteamos una comparativa de hosting en territorio nacional con el objetivo de probar los distintos proveedores y conseguir acuerdos con los mejores partner de los mejores centro de datos de forma que tengamos un buen SLA, una buena atención técnica y un soporte unido a una buena calidad de servicio y velocidad.

El servicio de hosting y alojamiento ha crecido durante los últimos años, ya que, hemos conseguido grandes clientes en el panorama “influencers” que no encontraban la forma de mantener sus campañas de marketing con la calidad y recursos adecuados, poniendo en ocasiones en riesgo sus campañas anuales.

Es cierto que durante nuestro periodo como proveedor de hosting hemos sufrido algún que otro susto, pero sin duda esto es una carrera de resistencia y el objetivo es mantenerse, aprender, e ir adaptándose a los nuevos vectores de ataque emergentes y a la protección contra los mismos.

¿Cómo detectar un ataque DDoS?

Uno de los focos principales es la monitorización por ejemplo el uso de CPU y RAM, una media del uso habitual con el tráfico estimado puede darnos datos para comparar, evaluar y detectar posibles ataques. Debemos tener en cuenta que no siempre podemos hacer uso de estos parámetros, en ocasiones hemos encontrado ataques tan contundentes que antes de llegar la alarma, el atacante ha conseguido su objetivo de producir la denegación del servicio, en estos casos tan severos, la monitorización de tráfico es la única solución.

Todos nuestros servidores VPS cuentan con monitorización tanto de recursos como de tráfico, esto nos permite mediante herramientas poder detectar cuando algo no está funcionando correctamente, usamos software con MRTG (Multi Router Traffic Grapher) o Grafana que nos permite recibir notificaciones en tiempo real y poder monitorizar de manera continua cualquier valor relativo al uso de recursos del servidor, generando un histórico del mismo.

Todos los VPS adicionalmente cuentan con medidas de seguridad adicionales que previenen cualquier vector de ataque que pueda desencadenar en un DDOS como Fail2ban, este funciona verdaderamente bien contra ataques de fuerza bruta pero siempre que el volumen sea bajo.

En algunas ocasiones hemos tenido casos donde Fail2ban se ve sobredimensionado al procesar, desde los logs, todas las peticiones entrantes. Su sistema de reglas es muy eficaz pero no siempre válido en todos los casos.

Los VPS, como gran parte de los sistemas UNIX, cuentan con la capa de seguridad a nivel de Kernel, NetFilter, la cual puede ser gestionada mediante IPTables.

IPtables permite poder implementar reglas para el tráfico entrante, saliente y de reenvío, entre otros. Pongamos el caso en el que tenemos un servidor web ejecutándose en nuestro VPS, no sería necesario, por lo tanto, tener servicios expuestos de manera externa como pueden ser SMTP, Plesk, SAMBA, SSH, FTP, entre otros.

Además, contamos con un capa de Seguridad adicional a nivel superior, una CDN o Red de Distribución de Contenido, siendo CloudFlare la elegida en este caso.

Sin duda recomendamos el cambio a la versión de pago, pero para webs de poco tráfico, por medio de un procedimiento implementado de nuestra parte, hemos conseguido configurarlo de manera correcta, haciendo uso de todas las funcionalidades que ofrece, un sistema bastante sólido de mitigación de ataques DDOS.

Estas medidas reducen de manera considerable el uso de CPU que pueda llegar a ocasionar un ataque DDOS, haciendo que el servidor web no procese la mayor parte del tráfico no deseado.

Recordar, de igual forma, que la CDN proporciona determinadas funcionalidades como son el enmascaramiento de la dirección IP real del servidor, modo Anti-Bots, un WAF o firewall a nivel de aplicación web y un potente sistema de caché.

Es una forma de impedir saltarse nuestras políticas y evitar una restricciones de seguridad, recordemos que las políticas de CloudFlare suelen detectar un 75% de los ataques conocidos pero además van actualizando y manteniéndose al día.

Seguridad en ataques

Otra gran medida de seguridad con la que contamos sería otro WAF, pero esta vez no implementado en el CDN sino por medio del propio servidor web de Apache gracias a un módulo de seguridad, ModSecurity.

Todos los servidores cuentan con un Web Application Firewall para detectar comunicaciones, reglas de filtraciones, bloquear determinados payloads propensos a encadenar SQLi o LFI por medio de Directory Path Traversal. Básicamente lo que hace es detectar de forma automática este tipo de ataques a través de Logs, y unificar resultados con Fail2Ban.

Para poder implementar lo anterior, continúa leyendo ya que te mostramos cómo llevarlo a cabo a través de CLI con bash.

¿Cómo luchamos contra el ataque de DDOS?

Ya hemos implementado numerosas medidas de seguridad preventivas, políticas y sistemas que proporcionan una sensación de seguridad, pero esto nunca es suficiente cuando se trata de tiendas online y datos de tarjetas de crédito. Es importante estar realmente preparados y protegidos para que en los casos reales de ataques puedan solucionarse.

Sabemos que os gustan los casos reales y os contaremos algunos de los ataques que hemos sufrido, como un ataque de datos a un servidor dedicado de bajo recursos.

Casos reales de ataques DDoS

Caso 1: Ataque de bots en una tienda PrestaShop

Debemos tener en cuenta que no todos tienen la misma capacidad de inversión, lo que lleva a contratar servidores VPS de bajo rendimiento. En este caso, una tienda online con Prestashop 1.7 sufrió un ataque de bots.

Aunque el tráfico generado era de pocas peticiones por segundo, los ataques provenían de demasiadas fuentes. Con la caché activa de Prestashop, las peticiones al módulo de Facetas generaron una gran cantidad de archivos de caché, llenando los inodes que Debian 10 podía soportar.

No se activaron alarmas por consumo de disco duro, RAM y CPU, pero al revisar los logs tras la alarma de inodes, detectamos el ataque y tomamos las medidas necesarias, excluyendo la caché para este tipo de ataques.

Caso 2: Ataque de rastreadores de Precios en PrestaShop

Ataque de DDOS con Saturación de CPU y RAM, este ataque lo sufrió una gran tienda de uno de los clientes que más confianza ha tenido en nosotros desde 2014 y le hemos conseguido los primeros puestos en SEO.

Aquí el ataque iba claramente al rastreo de productos, el robo de información y la extracción de datos, comenzamos a notar el incremento de un 20% del consumo del Servidor, la misma IP procedía a realizar una y otra vez visitas de muy poco tiempo durante cada una de las url, los logs crecían detectando peticiones masivas, reconstrucción de caché y alto consumo de ram, adicionalmente detectamos un uso máximo de peticiones al buscador con códigos de referencia intentando conseguir listado de productos afines o diferentes con respectos a la de la tienda atacante.

Una vez recibido el warning de consumo procedimos a analizar con el comando HTOP por donde estaba viniendo el ataque, y pudimos determinar que todo eran peticiones web, ¿son clientes? ¿habrá realizado alguna campaña sin avisarnos? y por ello nos pusimos a analizar el tráfico.

Debemos decir que aunque nuestros clientes han confiado en el CDN de cloudflare, tenemos implementada una medida a partir de la cual, en los logs relativos al servicio web, quedan reflejadas las direcciones IP de origen en lugar de la de los diferentes proxies de CloudFlare, por lo que, a partir de las mismas, podemos sacar conclusiones.

Aquí tenéis un comando que os recomendamos, dentro de la shell y de la carpeta logs donde se ubica nuestro servidor web, podemos obtener un listado ordenado de qué IP realiza tantas peticiones, esto pasa rápidamente a nuestro servidor de Iptables restringiendo y bloqueando al atacante y la procedencia del mismo.

awk '{print $1}' access_ssl_log | sort | uniq -c | sort -n

Caso 3: Ataque a la base de datos de una tienda PrestaShop

Aquí recordamos dos ataques principalmente, tras llegar un prestashop 1.7.9.11 a nuestro equipo de soporte siempre revisamos los módulos y la garantía de los mismos.

En este caso el cliente llegó con un buscador muy visual similar a Doofinder y a Motive, el módulo se llamaba Joli Search. La problemática que encontramos fue que, a pesar de las medidas de seguridad que tenemos por defecto, llegaban warnings reflejados en los registros del sistema en cuanto a CPU y RAM y no teníamos la capacidad de poder acceder al servidor.

Analizando una vez estando dentro, la BD de MYSQL o MariadB, encontramos un consumo de 300% de CPU, las peticiones se estaban encolando y el servidor no era capaz de responder, entrando a la gestión de MYSQL General hicimos uso de este comando:

SHOW PROCESSLIST

(Aquí os dejamos toda la documentación: https://dev.mysql.com/doc/refman/8.4/en/show-processlist.html)

Pudimos ver el consumo de Base de Datos, localizamos una consulta donde el número de peticiones de posibles valores que se habían metido por el where de la consulta era tan alto que saturada al servidor y la tienda online, gracias a nuestro equipo de soporte para PrestaShop pudimos detectar la consulta, mitigar y desarrollar un parche para el módulo de PrestaShop y limitar a 3-4 palabras la entrada del buscador. Como no podía ser de otra forma contactamos con el desarrollador del módulo comentando el problema y la solución.

Para el consumo de BD de datos, aunque realizamos optimizaciones y afinamos para obtener el mejor rendimiento del servidor, mediante el parámetro tmpdir (RAMDISK/TMPFS) y otros ajustes en tiempos y consumo, si el desarrollo del módulo tiene errores afectará tanto a la tienda online como también al servidor VPS.

Caso 4: Ataque fallo de seguridad en Módulo PrestaShop

En otra ocasión nos encontramos con un módulo de diseño de productos personalizados, la alarma por caída del servidor llegó al instante, nuestro equipo de soporte recibió la notificación y revisó el estado de servidor, la conexión por medio de SSH y la monitorización seguía funcionando, al entrar al servidor vimos, como en el caso anterior, un alto consumo de MYSQL, utilizamos la misma consulta de “show processlist” y nos apareció un delete sobre una tabla de un módulo de configuración, era un comando rápido pero secuencial.

Al mismo tiempo que buscamos esa consulta entre el código para localizar en qué módulo o más bien qué parte del módulo se veía afectada, debimos detectar al atacante y lanzar una visualización en tiempo real del tráfico de la web, aquí comenzamos a ver comandos “POST” de continuada contra un controlador del módulo donde tenía un id, al desarrollador se le había pasado controlar si estaba o no logueado en el controlador de borrado.

La medida que tomamos fue rápidamente establecer un die en el borrado para así evitar seguir recibiendo peticiones.

Empleamos IPTables para poder bloquear cualquier tráfico entrante desde esa dirección IP de origen. Al no tratarse de un envío masivo de peticiones como puede ser en el caso de un DDOS, nuestro CDN, en este caso CloudFlare, no lo detectó como tráfico malicioso.

Procedimos a bloquear el borrado de productos, recuperamos los datos borrados de la copia de seguridad y nos comunicamos con el desarrollador que en cuestión de 1 día había publicado el parche correspondiente para controlar el fallo de seguridad del módulo.

Sin duda, sin la eficiencia de los desarrolladores web, junto con el equipo de sistemas de servidores y mantenimiento para PrestaShop, hubiera sido complejo poder detectar este tipo de fallos de seguridad, y por otro lado, también evitar los ataques DDOS.

Pero todo no serán ataques a PrestaShop, ¿verdad?

¿Cómo protegéis WordPress de los ataques?

Bueno, es cierto que aquí hay un plugin más específico de seguridad. Se trata de wordfence, en este caso empleamos la versión gratuita, que con las funcionalidades que ofrece y, gracias a su flexibilidad en la configuración, permite que nuestros técnicos de sistemas puedan implementar determinadas medidas de seguridad para poder mitigar accesos o tráfico no deseados, sería una capa adicional de seguridad con la que contamos a nivel de aplicación web, además de los ya mencionados WAFs de CloudFlare y Apache (Mod_security).

Algunas de las medidas serían:

  • Prevención y bloqueo de ataques por fuerza bruta
  • Limitación de intentos de inicio de sesión (User-Agent en blanco)
  • Bloqueo de solicitudes a ciertas rutas sensibles como al fichero xmlrpc.php para evadir enumeración de usuarios
  • Deshabilitar el acceso a ciertas rutas de enumeración tales como:
    • https://domain.com/wp-json/wp/v2/users
    • https://domains.com?rest_route=/wp/v2/users
  • Bloqueo de direcciones IP
  • Análisis en tiempo real del tráfico que recibe la web

Cabe destacar que, de igual forma, resulta importante dificultar a los atacantes el acceso al panel de login de WordPress, para poder evitar, en primer lugar, los ataques por fuerza bruta ya mencionados, por ello, nuestros técnicos de sistemas hacen uso de plugins como WPS Hide Login para modificar la ruta por defecto que WordPress establece a /wp-admin o /wp-login.php.

En esta ocasión recordamos el caso de una tienda online en WooCommerce, comenzamos a ver un aumento masivo de CPU y RAM, las peticiones no eran altas pero el consumo de Apache sí, por ello comenzamos a analizar el logs de visitas, aquí todo entraba bien, tráfico aparentemente real, así que usamos nuestro comando:

awk '{print $1}' access_ssl_log | sort | uniq -c | sort -n

Con la intención de investigar si había alguna petición masiva o con un alto grado de repetición, no vimos nada extraño y procedimos a ver los errores, aquí fue donde encontramos la sorpresa, el número de peticiones detectados por MODSEcurity era muy alta, pudimos trazar las procedencias de las IP y a través de Iptables cortar el ataque de inmediato.

Caso 5: Ataque a un LMS con WordPress

También nos viene a la cabeza un ataque de creación de cuentas sobre una plataforma LMS.

Teníamos un WordPress donde se impartían clases online, la tienda y los plugins formativos habían sido elaborados por terceros, cada día el nuevo cliente recibía peticiones de creación de cuentas, comenzamos con un proceso de activación de Cloudflare y restricción de procedencia.

Funcionaba pero, a los pocos días el ataque volvió a activarse, comenzamos tirando del bloqueo mediante detección de robots por los registros y url habituales de WordPress, pudimos solucionarlo en cuestión de minutos, pero el ataque se reactivó. Mirando peticiones nos dimos cuenta que los desarrolladores habían instalado un plugin de creación de usuarios y registros, una url propia donde aunque el plugin tenía integración con recaptcha se lo estaban saltando y creando cuentas de forma masiva, por ello, decidimos quitar este captcha y controlar mediante CloudFlare el acceso a la url con una detección de robots. Por fin cortamos de una vez por todas el ataque y mitigamos al completo permitiendo que la academia pudiera seguir dando clases sin molestos registros. Nos hubiera venido bien tener documentación desde el principio, pero algunos desarrollos carecen de documentación o conocimientos por parte del cliente.

Siempre hemos podido localizar ataques de DDOS, es verdad que tenemos un equipo bastante profesional y además contamos con las mejores herramientas de seguridad para proteger servidores o tiendas, siendo esto de gran ayuda. Otras medidas de seguridad que establecemos son Balanceadores de Carga, o protección mediante IDS.

Caso 6: Ataque de creación de cuentas Joomla

Sin duda contamos con un gran aliado como CloudFlare. Recientemente, estábamos trabajando en la migración de una web muy antigua de Joomla a WordPress, lo cual ha sido un proceso largo debido a los desarrollos a medida, el posicionamiento SEO y el diseño. Durante este proyecto, que se ha extendido en el tiempo, detectamos algo inusual: la creación de cuentas y la regeneración constante de peticiones de Cookies de sesión.

Al analizar el tráfico y su procedencia, no encontramos razones para sospechar de las IPs de origen ni de las peticiones. Por ello, cuando otras soluciones no funcionan, tener una herramienta poderosa es fundamental. CloudFlare dispone de un excelente sistema para detectar ataques y bots, y en esta ocasión, tuvimos que proteger la web con su sistema.

Tras una hora de recogida de datos de sólo aquellos que habían pasado el filtrado humano, pudimos comparar los logs antes y después de usar CloudFlare. Esto nos permitió crear un plan de detección y, más adelante, implementar reglas específicas de Fail2ban para proteger Joomla.

¿Tienes problemas con tu tienda online y web? ¿Quieres proteger tu seguridad y la de tus clientes?

Os dejamos aquí un listado de comandos que podéis usar para detectar ataques de DDOS:

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

Si CloudFlare no se encuentra activo, se puede emplear el siguiente comando para poder ver en vivo las direcciones IP desde las que están llegando solicitudes al proceso de nginx, que, en nuestro caso, se establece como proxy inverso en los servidores:

grep -iPo '\d{1,3}(\.\d{1,3}){3}' <( strace -f -tT -e trace=%network -p $( pgrep --full -d , nginx ) 2>&1 )

Checklist: ¿Estás preparado para un ataque DDoS?

  • ¿Tienes monitorización de recursos (CPU, RAM, tráfico) en tu servidor?
  • ¿Has configurado sistemas de protección como Fail2ban e IPTables?
  • ¿Usas un CDN como CloudFlare con configuraciones de seguridad avanzadas?
  • ¿Has implementado un WAF para bloquear intrusiones en tu aplicación web?
  • ¿Estás realizando análisis de logs de forma regular para detectar actividades sospechosas?

Los ataques DDoS son una amenaza constante para cualquier negocio online. La prevención y detección temprana son claves para proteger la seguridad y la estabilidad de tu servidor. En digitalDot, estamos comprometidos con la protección y optimización de tu plataforma online.

¿Tienes problemas con ataques DDoS o necesitas optimizar tu tienda online?

¡Contáctanos para una auditoría de seguridad y descubre cómo podemos ayudarte a proteger tu negocio!

Preguntas frecuentes sobre los ataques de DDoS

¿Qué es un ataque de DDoS?

Un ataque DDoS (Distribuido de Denegación de Servicio) ocurre cuando múltiples dispositivos envían una gran cantidad de tráfico a un servidor o sitio web, sobrecargándolo para que deje de funcionar correctamente o se vuelva inaccesible.

¿Cuánto puede durar un ataque de datos?

La duración de un ataque DDoS varía. Puede durar desde unos minutos hasta varias horas o incluso días, dependiendo de la escala del ataque y de las medidas de protección implementadas.

¿Podéis proteger un DDoS aunque no esté en vuestro VPS?

Sí, podemos ayudarte a protegerte contra un ataque DDoS aunque no utilices nuestro VPS. Usando herramientas como CloudFlare u otros servicios de mitigación de DDoS, podemos implementar protección en tu sitio web o servidor, esté donde esté alojado.

Noticias relacionadas sobre Seguridad web

Actualizar Prestashop últimas versiones importancia

No actualizar PrestaShop puede hundir tu negocio de la noche a la mañana

¿Crees que tu tienda online está a salvo solo porque “nunca te ha pasado nada”? Pues siento decirte que los hackers adoran a los que piensan así. Si tu Prestashop sigue en versiones antiguas (1.6, 1.7 o incluso una 8 sin actualizar), estás dejando la puerta abierta… y ni siquiera…

cuentas eliminadas por google en 2025

Google eliminará cuentas de Gmail inactivas en 2025: cómo evitarlo

Si tienes una o varias cuentas de Gmail que no usas con frecuencia, podrías estar en riesgo de perderla. Desde diciembre de 2024, Google ha comenzado a eliminar cuentas inactivas por más de dos años. Esta medida busca mejorar la seguridad y reducir el riesgo de ataques cibernéticos a cuentas…

Guía sobre las actualizaciones de Joomla digitalDot

Guía completa sobre las actualizaciones de Joomla

Joomla es un CMS que permite crear y gestionar sitios web, pero como cualquier software, necesita mantenerse actualizado para asegurar su funcionamiento óptimo y seguro. Las actualizaciones de Joomla regulares no solo corrigen fallos de seguridad, sino que también mejoran el rendimiento y añaden nuevas características. En esta guía de…

Guía paso a paso para mejorar la seguridad y actualizar WordPress

Guía completa sobre seguridad, actualizaciones y novedades de WordPress

WordPress es el CMS (sistema de gestión de contenidos) más utilizado del mundo y también uno de los más atacados. Su enorme popularidad hace que mantenerlo seguro y actualizado no sea una opción, sino una necesidad. Las actualizaciones de WordPress corrigen vulnerabilidades, mejoran el rendimiento e introducen nuevas funciones que…

errores 400 que son y como solucionaros

¿Qué son los errores 400 y cómo solucionarlos?

¡Alerta! ¡Intruso en el mundo de los errores 400! Si pensabas que el error 404 era el único villano de las páginas rotas, prepárate para conocer a toda su familia. Hoy no venimos a hablarte del clásico "404 Not Found", sino de todos esos menos famosos que también hacen acto…

Actualiza a Windows Server 2022

Windows Server 2022: Seguridad y eficiencia en el entorno empresarial

Con el auge de ataques sofisticados y el fin del soporte para versiones anteriores, las empresas ven la necesidad de actualizar sus infraestructuras tecnológicas. Microsoft lanzó Windows Server 2022 en agosto de 2021, incorporando mejoras avanzadas en seguridad, rendimiento y gestión de entornos híbridos. Esta versión, con soporte extendido hasta…

email corporativo y spam

Cómo configurar tu sistema de correo electrónico para que tus envíos no vayan a spam

En digitalDot sabemos lo crucial que es para cualquier tipo de empresa que los correos electrónicos lleguen a la bandeja de entrada de tus destinatarios y no terminen en la carpeta de spam. Los problemas con servicios de correo como Gmail, Hotmail, y otros proveedores de correo, pueden afectar negativamente…

Copias de seguridad para empresas

Seguridad web: Plan de copias de seguridad

Nadie puede dudar que la seguridad de los datos es primordial y que, las empresas necesitan soluciones robustas y confiables para proteger su información más delicada. En digitalDot implementamos estrategias avanzadas de mantenimiento informático para empresas centradas en la protección de datos, la creación de copias de seguridad y sobre…

Vulnerabilidades críticas en Veeam

Vulnerabilidades críticas detectadas en Veeam

Vulnerabilidades críticas detectadas en Veeam En septiembre de 2024, Veeam, líder en soluciones de respaldo y recuperación de datos, publicó un boletín de seguridad destacando varias vulnerabilidades críticas y de alta gravedad en diversos productos de su cartera, incluidos Veeam Backup & Replication, Veeam ONE y Veeam Service Provider Console.…

crossmenuchevron-down