2011-07-26 27 views
6

Estoy implementando un sistema de demora para que cualquier IP que considere abusiva reciba automáticamente un retraso incremental a través de Sleep().Debo usar Sleep() o simplemente negarlos

Mi pregunta es, ¿dará como resultado un uso adicional de la CPU y, por lo tanto, eliminará mi sitio de todos modos si el atacante sigue abriendo nuevas instancias mientras se retrasa? ¿O el comando sleep() usa una CPU/memoria mínima y no será una gran carga para un script pequeño? No quiero negarlos porque prefiero que no sepan el límite de una manera obvia, pero dispuestos a escuchar por qué debería hacerlo.

[Por favor, no hay discusión sobre por qué im considerar a un IP abusiva en un pequeño sitio, hacer que aquí está el por qué: Me reciente construcción, una secuencia de comandos que se curvan una información de la página & regresa al usuario y me di cuenta de algunos IP de spam mi pequeño script estúpida . CURRICULAR con demasiada frecuencia hace que mis resultados no sean alcanzables desde el servidor y que los usuarios legítimos se salgan de sus resultados. ]

+0

Iría con prohibirlas en un nivel superior si es posible (= menos uso de recursos), [esta pregunta en serverfault] (http://serverfault.com/questions/ 287851/prevent-hammering-script-parsers) parece apto. – Wrikken

+0

@Wrikken, esta no es una pregunta segfault, ya que el OP está preguntando cómo codificar defensivamente contra usuarios abusivos. – Soren

+1

¿Jeff Atwood no escribió algo sobre esto? Se llamaba hellbanning o lagbanning o algo así. Me interesaría saber cómo planeaba implementarlo si continuaba con la decisión sin tener un bajillion de hilos para dormir estropeando el sistema. –

Respuesta

5

La suspensión no utiliza ninguna CPU o memoria que no haya sido utilizada por el proceso que acepta la llamada.

El problema al que se enfrentará con la implementación de suspensión() es que eventualmente se acabarán los descriptores de archivos mientras que el sitio del atacante esperará hasta que su suspensión termine y su sitio parecerá estar abajo para cualquier otra persona quien intenta conectarse

Este es un escenario DDoS clásico: el atacante en realidad no intenta entrar en su máquina (también pueden intentar hacer eso, pero esa es una historia diferente) sino que intentan dañar su sitio consumiendo cada recurso que tiene, ya sea ancho de banda, descriptores de archivos, hilo para procesamiento, etc., y cuando uno de sus recursos se agota, su sitio parece estar inactivo aunque su servidor no está en realidad abajo.

La única defensa real aquí es o bien no aceptar las llamadas, o tener una configuración de firewall dinámico que filtra las llamadas, o un enrutador/firewall que hace lo mismo pero fuera de su servidor.

5

Creo que el problema con esto podría ser que podrías tener una gran cantidad de hilos para dormir en el sistema. Si detecta su abuso, envíe de inmediato un error y termine con él.

Mi preocupación con su método es la repetición de abusadores que obtienen su tiempo de espera de hasta varias horas. Tendrás sus hilos pegados durante mucho tiempo a pesar de que no están usando la CPU. Hay otros recursos a tener en cuenta además de la CPU.

5

Sleep() es una función que "bloquea" la ejecución durante un período de tiempo específico. No es el equivalente de:

while (x<1000000); 

Como eso causaría el uso de la CPU al 100%. Simplemente pone el proceso en un estado "Bloqueado" en el sistema operativo y luego vuelve a poner el proceso en el estado "Listo" una vez que el temporizador está activo.

Tenga en cuenta, sin embargo, que PHP tiene un tiempo de espera predeterminado de 30 segundos. No estoy seguro de si "Sleep()" se ajusta a eso o no (lo dudaría ya que es una llamada al sistema en lugar de una secuencia de comandos)

Puede que su host no le guste tener tantos procesos "bloqueados", así que sea cuidado de eso.

EDITAR: Según Does sleep time count for execution time limit?, parece que "Sleep()" no se ve afectado por "max execution time" (en Linux), como esperaba. Aparentemente lo hace bajo Windows.

1

Si está haciendo lo que también probé, creo que va a estar libre.

Mi secuencia de comandos de autenticación desarrolló algo similar a la idea de Atbanzar Hellbanning. Los SessionID se capturaron en la RAM y se rotaron en cada llamada de página. Si no se cumplieran las condiciones, marcaría esa sesión en particular con un demérito. Después de las tres, comencé a agregar llamadas sleep() a sus ejecuciones. El límite fue variable, pero me decidí por 3 segundos como un número feliz.

Con la autenticación, el atacante se basa en realizar una cierta cantidad de intentos por segundo para que valga la pena atacar. Si este es su punto focal, la introducción del sueño hace que el sistema parezca más lento de lo que realmente es, lo que en mi opinión hará que sea menos deseable atacar.

Si reduce la velocidad en lugar de decir que no, les ofrece una posibilidad ligeramente más razonable de verse menos atractivos.

Dicho esto, es la seguridad a través de un "tipo" de ofuscación, por lo que realmente no se puede confiar demasiado en ello. Es solo otro factor en mi receta general :)