PHP: sistema de spam anti-inundación/

Question

realidad estoy trabajando en un proyecto PHP que contará con un sistema de usuario (Iniciar sesión, Register, la contraseña perdida Enviar al correo electrónico, ..) y creo que esto puede ser muy vulnerable a Ataques de fuerza bruta y/o spam (envíe una contraseña al correo electrónico de alguien como 1000 veces, etc. use su fantasía) .

• ¿Los servidores web de hoy (Apache, IIS) tienen algún tipo de defensa incorporada contra Brute-Force?

• ¿Cuál sería la mejor manera de implementar un sistema/Inundación Anti-Spam, si por ejemplo: quieren una página no sea capaz de ser llamado más de dos veces por minuto, sin embargo otra página pueden ser llamados de hasta 100 veces un minuto más o menos.

  • , sin duda tiene que almacenar IP DIRECCIONES, el tiempo de la última vez que visitaron una página y el número de visitas en alguna parte - Pero, ¿sería lo suficientemente eficiente almacenarla en un archivo de texto/base de datos (MySQL)

  • ¿Debo usar captchas para cosas como registrar/recuperar contraseñas perdidas?

  • son captchas "texto" viable? (Algo así como "¿Qué es 5 más 9 menos 2?")

  • La página no será utilizada por tantos usuarios (100-200), ¿realmente tengo que implementar todo esto?

Answer 1

Respecto a CAPTCHA: Recomendaría no usar CAPTCHA a menos que realmente lo necesite. ¿Por qué?

1. es feo.
2. es molesto para sus usuarios. No debe hacer que salten por aros para usar su sitio.

hay algunas alternativas que son muy simples, pueden ser muy eficaces y son totalmente transparentes para _{(casi todos)} usuarios.

1. campos Honeypot: añadir un campo a sus formas con un nombre común como "sitio web". A su lado, agregue una etiqueta que diga algo al efecto de "no escriba en esta casilla". Al usar Javascript, oculta la entrada y la etiqueta. Cuando recibe un envío de formulario, si hay algo en el campo, rechace la entrada.

   Los usuarios con JS no lo verán y estarán bien. Los usuarios sin JS simplemente tendrán que seguir las instrucciones simples. Los Spambots se enamorarán y se revelarán a sí mismos.

2. Faux-CAPTCHA automático: Esto es similar a lo anterior. Agregue un campo de entrada con una etiqueta que diga "Write 'Alex'" (por ejemplo). Usando Javascript (y sabiendo que la mayoría de los robots de spam automatizados no ejecutarán JS), oculte el campo y rellene con 'Alex'. Si el formulario enviado no tiene la palabra mágica allí, ignórelo.

   Los usuarios con JS no lo verán y estarán bien. Los usuarios sin JS simplemente tendrán que seguir las instrucciones simples. Los Spambots no sabrán qué hacer y usted puede ignorar su entrada.

Esto lo protegerá del 99.9% de los robots de spam automatizados. Lo que no hará, incluso en lo más mínimo, es salvaguardarlo contra un ataque dirigido. Alguien podría personalizar su bot para evitar el honeypot o siempre completar el valor correcto.

---

Respecto de bloqueo de fuerza bruta: Una solución de servidor es el único camino viable para hacer esto obviamente. Para uno de mis proyectos actuales, implementé un sistema de protección de fuerza bruta muy similar a lo que describes. Se basó en este Brute Force Protection plugin para CakePHP.

El algoritmo es bastante simple, pero un poco confuso inicialmente.

1. El usuario solicita algún tipo de acción (restablecer la contraseña, por ejemplo)
2. Run: DELETE * FROM brute_force WHERE expires < NOW()

3. Run:

   SELECT COUNT(*) FROM brute_force 
   WHERE action = 'passwordReset' 
   AND ip = <their ip address> 
   

4. Si el recuento es mayor que X luego diles que esperar un poco .

5. De lo contrario, ejecute:

   INSERT INTO brute_force (ip, action, expires) 
   VALUES (<their ip address>, 'passwordReset', NOW() + Y minutes) 
   

6. continuar con la función de restablecimiento de contraseña.

Esto permitirá a los usuarios intentar restablecer una contraseña X veces en Y minutos. Ajusta estos valores como mejor te parezca. Quizás 3 reinicios en 5 minutos? Además, podría tener diferentes valores para cada acción: para algunas cosas (p. Ej .: generar un PDF), es posible que desee restringirlo a 10 en 10 minutos.

Answer 2

1. Sí, el almacenamiento de una dirección IP, visitado más veces y los que se accede en una base de datos estaría bien.
2. Se recomienda el uso de CAPTCHA para registrar/recuperar contraseñas, de modo que las direcciones de correo electrónico no se puedan enviar por correo no deseado. También para detener el forzamiento bruto.
3. Sí, los CAPTCHA de texto son posibles, aunque es mucho más fácil para alguien crackear y escribir un script para automatizar la respuesta. Para un CAPTCHA gratuito, recomendaría Recaptcha.
4. Eso realmente depende de cuánto te importe la seguridad. Sin duda, recomendaría usar un CAPTCHA, ya que son simples de implementar.

Answer 3

El almacenamiento de direcciones IP es una buena práctica para el inicio de sesión y el seguimiento, pero creo que solo un captcha dejaría de enviar spam, ataques de fuerza bruta e inundaciones.

Reconocer texto es de hecho una buena solución.

Answer 4

Además de hacer lo que le está diciendo Gazler, también debe tener alguna manera de contar los intentos de conexión en general. El total de todos los intentos de inicio de sesión es mayor que X, luego comienza a usar el comando de suspensión o simplemente dice que los servidores tienen una carga alta.

Answer 5

Claro, su público objetivo podría no ser grande, pero si está en el dominio público, entonces es vulnerable,

texto de la imagen de están agrietadas fácilmente estos días me creen

para un sistema Anti-Spam/Flood se podría registrar direcciones IP (preferiblemente MySQL) y agregar un límite de tiempo de intentos de inicio de sesión

Answer 6

No trate de poner en práctica todos los la lógica en su PHP - la más baja en su pila puede ponerlo en práctica, la manera más eficiente que puede ser tratada.

La mayoría de los cortafuegos (incluyendo iptables en BSD/Linux) tienen regulación de la conexión. Además, eche un vistazo a mod_security para DDOS/prevención de ataque de fuerza bruta.

Usted debe diseñar la aplicación en torno a la idea de que este tipo de ataques no le dará al atacante acceder a la aplicación - al final del día no hay manera de que pueda prevenir un ataque DOS, aunque se puede limitar su eficacia.

No tiene mucho valor confiar en una dirección IP consistente de su atacante; hay muchas formas de evitarlo.

p. Ej. realizar un seguimiento del número de solicitudes de restablecimiento de contraseña entre inicios de sesión por cada usuario. En el formulario de restablecimiento de contraseña, responda (al cliente) en exactamente de la misma manera si el usuario envía una dirección de correo electrónico desconocida. Registrar direcciones de correo electrónico no válidas.

HTH

C.