Posible DoS
Cuando tienes un servidor en producción con software -how to say...- "standard" desarrollado en PHP estás abierto a que cientos -miles- de bots descubran que no tienes tiempo de usar siempre las últimas versiones en todo.
Estoy hablando de los siempre polémicos *Nuke, Drupal, phpBB y demás variedad de software que, si bien es una alternativa sencilla en algunos casos concretos, suele ser una verdadera lacra en cuanto a lo que seguridad del sistema se refiere.
Sin ir más lejos hace menos de 24h. se han producido varios ataques a un Drupal alojado en un servidor que administro. Cierto que debería estar al día de lo ocurrido la semana pasada con las múltiples vulnerabilidades encontradas, pero no siempre puede uno atender a sus obligaciones con este tipo de software.
El resultado, un DoS en toda regla (no sé si distribuido, imagino que no), pero revisando lo poco que he podido rescatar de algunos logs he visto demasiadas entradas sospechosas a páginas index.php e install.php segundos antes de que todo se haya ido al garete.
La solución ha pasado por reiniciar la máquina, pasar varios fsck -nota mental: hacerlo en las particiones adecuadas suele calmar bastante los nervios- y borrar algunos .pid que habían quedado abiertos debido al reset.
Intentando sacar una lectura positiva creo que he aprendido una pequeña lección con respecto a todas estas piezas de software para todo. En un servidor en producción no se deberían jugar con joyas a no ser que se limiten los recursos enjaulando y limitando de alguna forma su intervalo de actuación.
Por otra parte y como acto de contrición intentaré echarle un vistazo a mod_security, Jail y algún otro lenguaje para gestionar contenidos dinámicos que no empiece por 'efe' (ph para los no entendidos xD).
Actualización: Según me ha comentado Borja, ayer también ha petado KernelTrap, otro Drupal :(.
Gura@26.10.2007, 'Re: Posible DoS'
Que putada. Yo voy a compartir el dedicado con unas amistades y me preocupa eso. La gente no mira si su drupal o wordpress está en sus ultimas versiones y cuando hay varios cms se hace insostenible. Lo que hago es utilizar mod_security para paliar ataques tipicos y luego open_basedir para que aunque la aplicación sea vulnerable y puedas hacer el cucharón a /etc/passwd, no se pueda. El problema ahi reside en las galerias que tiran de imagemagick y demas.
Muchas vulnerabilidades de PHP son que pueden saltarse esas restricciones, pero para eso necesitan meter codigo en tu servidor... y ejecutarlo. Remote File Inclusion por ejemplo. Contra esto creo que tambien puedes evitar los fsockopen y los fopen a url remotas.
r0sk@26.10.2007, 'Re: Posible DoS'
Aunque tienen más peligro la escalada de privilegios y la ejecución de código arbitrario en el servidor, como bien dices hay muchas medidas que podamos tener en cuenta para intentar controlar de alguna forma -si es que se puede- estos factores.
Pero cuando se trata de una denegación de servicio y un script ejecutado en circunstancias especiales empieza a comerse RAM y procesador la actuación del administrador está bastante limitada (y más en servidores remotos)... Haciendo homenaje a una famosa serie de los 90: Los problemas crecen (nunca mejor dicho).
Gura@26.10.2007, 'Re: Posible DoS'
En linux disponemos de /etc/security/limits.conf, y en FreeBSD hay algo parecido que en su día lo miré. la doc oficial habla de ello.
