Tomar prestado de las otras respuestas & comentarios coz estoy de acuerdo con ellos:
Deflect = Not-the-same-as reflect back to the attacker.
La práctica común que viene a la mente en este contexto es la siguiente:
Your assets can be protected using deflection to a honeypot.
... la armadura está entre el cuerpo del objetivo y la bala y la bala
Tiene que pasar por la armadura.
No puedo pensar en muchas situaciones donde un honeypot se encuentra entre el atacante y los activos bajo protección. Ese suele ser el rol de un firewall (firewall de red o firewall de aplicaciones web de algún tipo).
Honeypots en la práctica: cómo protegen distrayéndolos.
Puede ser un honeypot de baja interacción (el caso más común porque es más fácil de configurar y mantener) que se coloca de tal manera que desvía la atención del atacante al parecer que es fácil de hackear y configura la protección para el atacante. Principales activos.
por ejemplo, para proteger x.yourasset.com, puede configurar x-be.yourasset.com y x-private.yourasset.com como honeypots a los que normalmente no debe conectarse ningún cliente legítimo. Cuando alguien se conecta a ellos, utilizas algún tipo de automatización mediante scripts que les impide llegar a * .yourasset.com. Aquí el ban-trigger simplemente se conecta al honeypot. No se necesita una interacción profunda.
Un honeypot de interacción intermedia (de nuevo bastante común) le permitiría a un atacante conectarse y darles una ruta de bucle infinito, por ejemplo, permitir que SSH se conecte con una cuenta y contraseña inexistentes; luego presente un sistema de archivos ficticio con directorios interminables para recorrer. Esto desperdicia tiempo de atacante y puede o no ayudar directamente a la seguridad de tu activo, a menos que también uses esto con algún tipo de prohibición.
In both the above cases, the honeypot is not "placed in front of" the asset.
Otra posibilidad es usar honeypots de alta interacción (poco común). Esto requiere un poco de esfuerzo para configurar y administrar. Aquí, dejas que el usuario interactúe con tu activo principal, pero si ves algo inusual, cambia la sesión al honeypot.
p.ej. Su formulario web podría tener campos ocultos que suenan legítimos (por ejemplo, spl-discount, secret-auth) que el flujo normal nunca llenaría. En su servidor, primero verifica esos campos y, si están llenos, envía un redireccionamiento a un honeypot. También puede hacer esto utilizando algo como el proyecto OWASP AppSensor .
- que parece un envío normal normal, "gracias ... procesando ..."
- eso toma varios segundos para cada actualización de pantalla y desperdicia más tiempo: "gracias por su paciencia ..."
- que podría seguir solicitando más información: "solo necesitamos más información antes de completar el procesamiento" "le enviamos un código de seguridad adicional a su dirección de correo electrónico ... ingréselo para verificar su cuenta y obtener seguridad adicional" ( por supuesto, es posible que no hayas enviado ningún código)
- y finalmente lo ignora con algo como "lo sentimos, inténtalo de nuevo más tarde".
Esto puede o no combinarse con la prohibición, pero ayuda de muchas maneras, incluida la recopilación de datos sobre el atacante y sus TTP (herramientas, técnicas y procedimientos), que serán útiles en otras medidas defensivas.