De aquí a un tiempo he visto algunos scripts bastante simples que, sorprendentemente, hacen bastante daño a malas configuraciones de sitios con wordpress. El sistema de DoS (Denial of Service, Denegación de Servicio) que se usa para el ataque es de tipo flood (inundación) enviando un número muy alto de peticiones. Por ejemplo: Under Security.
Normalmente, estos scripts se realizan buscando las peticiones más lentas de los sistemas web. Una vez detectadas, se procede a lanzar muchas de estas peticiones en muy poco tiempo. Los servidores web, ante una avalancha de peticiones, normalmente, comienzan a crear forks o workers (según el servidor y modo de funcionamiento) hasta llegar al límite máximo configurado… o a que se sature el sistema y termine no respondiendo.
Los sistemas GNU/Linux, al igual que la mayoría, tienen un uso de memoria limitada por el tamaño de la misma que haya instalada. Estos sistemas manejan una caché bastante grande y por ello, aunque se tenga 1GB o más instalado en el sistema, siempre se anda con una ocupación bastante alta de la memoria del sistema. Cuando esta se agota, se recurre a la memoria de intercambio (swap), que es mucho más lenta que la memoria convencional, por lo que el sistema comienza a ralentizarse.
Para evitar estos problemas, lo ideal es configurar de forma adecuada el servidor web, acorde a la memoria disponible, el número máximo de hilos que se puedan crear y el número máximo de forks o workers que se puedan lanzar para atender peticiones. Con esto evitamos que la memoria se use en exceso y, aunque las peticiones se atiendan más lentas, se asegure que el sistema permanecerá estable.
También habría que revisar la pila de entrada TCP para el puerto 80 (se puede ver a través de netstat en cualquier sistema GNU/Linux), por si acaso se saturase mucho, comenzar a cortar, vía cortafuegos (iptables), las direcciones IP que estén haciendo flood.
2 Comments
El comentario me parece muy acertado y lo he sufrido en varias webs que administro hace poco.
Lo que quizá te falte en este post para darle valor, son unos enlaces donde se explaye un poco más el tema, ya que esto queda algo corto, como una explicación.
(Ejem: si te duele la cabeza tomate una aspirina)
[Reply]
bombadil Respuesta:
Febrero 5th, 2010, 09:42
Hola José Luis,
creía que la explicación del flood era suficiente, pero como veo que habrá más gente con ansias de saber aún más sobre este tipo de ataques, y supongo que también los mecanismos para protegerse, habrá que esforzarse en escribir algo más
¿Alguna idea, enlace o duda específica que te haya quedado para extenderla?
Gracias por el comentario.
[Reply]
En principio lo del flood está claro, bloqueando paquetes malformados, marcando los paquetes con iptables y luego solo permitiendo X peticiones por ip cada Y minutos se soluciona (y algún otro detalle)
El ajuste de apache y php siempre es complejo para no ser demasiado restrictivo y dejar algo sin funcionar correctamente.
En cuanto a protección en wordpress si estoy un poco mas perdido, y quizá sea cosas de aplicar wp super cache o similar que no tengo aun activado.
[Reply]
bombadil Respuesta:
Febrero 8th, 2010, 10:14
Hola José,
vas bien, según veo. El tema de “acelerar” PHP sirve para que la CPU no tenga que trabajar tanto y que en muchas ocasiones, si la web no cambia, no se tenga que enviar el contenido, solo la parte referente a la caché.
No obstante, no hay que olvidar que Wordpress es dinámico, no son páginas estáticas que simplemente se ven, sino que cada consulta, requiere de un procesado de información y, con ciertos plugins activos (como estadísticas o similares) ese procesado se incrementa sensiblemente.
La mejor forma de acelerar Wordpress es dejarlo lo más simple posible, deshabilitar las opciones de XMLRPC (si es que no las necesitas) y limitar los hilos y/o procesos de Apache a los necesarios para no saturar la memoria de tu equipo.
Ten en cuenta de que la CPU es un recurso valioso, pero lo que más puede ralentizar tu sistema es la falta de memoria, que podría provocar incluso la caída del mismo.
Gracias de nuevo por el comentario
[Reply]