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.
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.
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:
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:
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:
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:
¿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.
DigitalDot Servicios Informáticos, S.L. utiliza cookies propias y de terceros para mejorar nuestros servicios y mostrarte publicidad relacionada con sus preferencias mediante el análisis de tus hábitos de navegación. Puedes aceptarlas con el botón "Aceptar", rechazarlas en el botón "Rechazar" o configurarlas con el botón "Gestionar preferencias". Puedes consultar más información detallada sobre las cookies utilizadas en este sitio web desde nuestra política de cookies.
Funcional
Siempre activo
Las cookies funcionales son absolutamente imprescindibles para que el sitio web funcione correctamente. Estas cookies garantizan las funcionalidades básicas y las características de seguridad del sitio web, de forma anónima.
Preferencias
El almacenamiento o acceso técnico es necesario para la finalidad legítima de almacenar preferencias no solicitadas por el abonado o usuario.
Estadísticas
El almacenamiento o acceso técnico que es utilizado exclusivamente con fines estadísticos.Las cookies estadísticas se utilizan para entender cómo interactúan los visitantes con el sitio web. Estas cookies ayudan a proporcionar información sobre las métricas del número de visitantes, la tasa de rebote, la fuente de tráfico, etc.
Marketing
Las cookies de marketing son necesarias para crear perfiles de usuario para enviar y personalizar publicidad, o para rastrear al usuario en una web o en varias web con fines de marketing similares.