¿Cómo hacer un pentest? ¿Cómo gestionar el proceso en nuestro sitio en vivo sin caídas?

La regla más crítica para evitar caídas es limitar la velocidad de las herramientas de escaneo (rate limit). Ponles como norma mandar máximo de 5 a 10 peticiones por segundo. Y exígeles que los intentos de inyección masiva en endpoints de búsqueda que pesen mucho en la base de datos se hagan de forma manual y bien controlada.

Puntos clave que deben estar en el pliego de condiciones antes de empezar: 1) No se aplicarán ataques DoS/DDoS ni fuerza bruta en producción, 2) Prohibido borrar o actualizar datos en la base de datos real, 3) Las pruebas solo se harán de 01:00 a 06:00, 4) Si se encuentra un fallo crítico, se avisará de inmediato sin esperar a la fecha del informe.

En nuestro primer pentest, el auditor se puso a hacer pruebas automáticas en el formulario de registro y disparó nuestro servicio de SMS. En 3 horas salieron 14.000 SMS de verificación y el operador nos bloqueó la línea por sospecha de spam. Antes de empezar, pongan sí o sí en modo mock/dummy los servicios externos de notificaciones, SMS y pagos.

¿Tu cliente te exige una prueba con alguna acreditación local específica o les sirve el informe de una empresa con certificaciones internacionales (como CREST o OSCP)? Esta diferencia cambia totalmente las empresas a las que pedir presupuesto y lo que vas a terminar pagando.

Hicimos un pentest de caja gris para una plataforma B2B de tamaño similar. El proceso duró 5 días laborables en total. Salieron 2 fallos críticos y 4 medios. Como elegimos la franja horaria correcta, el uso de CPU del servidor nunca pasó del 40% y no tuvimos ni un solo corte.

Si la infraestructura de tus servidores lo permite, saca una copia anonimizada de la base de datos real y monta un entorno espejo en un servidor de staging. Si haces la prueba ahí, el tráfico real de usuarios y pedidos no corre ningún riesgo.

No te comas la cabeza ningún profesional de seguridad serio que trabaje con empresas va a hacer una locura que tire un sistema en vivo. Mientras mantengas una comunicación fluida y dejes fuera las pruebas de DoS el proceso sale como la seda.

Ed: ya se preguntó abajo, dejé la respuesta en el segundo mensaje.

Antes de empezar, se debe firmar en físico el Acuerdo de Confidencialidad y el Documento de Autorización. Definir los límites de responsabilidad legal y que tu empresa mantenga la potestad de parar la prueba en cualquier momento es vital para la gestión de la seguridad.

Hay una cosa a la que hay que prestar atención. La gente no defiende el proceso, defiende la costumbre. La resistencia viene de ahí.

Hay que ir paso a paso. Si el camino de la notificación es largo, la notificación no llega; una notificación que no llega significa un incidente detectado tarde.

Espero que le sea útil.

Estoy siguiendo esto.

No sabía eso.

A mí me pasó justo al revés por eso escribo. Los entornos de prueba olvidados son una puerta de entrada más frecuente que el sistema en producción.

Comprobado por experiencia.

En su momento, nosotros también nos atascamos ahí. Si la verificación en dos pasos está activa, una contraseña robada no sirve de nada por sí sola.

Lo dejo como nota, por si sirve.

Creo que este consejo no sirve para todos. o sea si la verificación en dos pasos está activa, una contraseña robada no sirve de nada por sí sola.

Gracias por escribir esto, es lo correcto. Si regañas las falsas alarmas, nadie volverá a reportar.

Por supuesto, cambia si tu situación es diferente.

Pienso diferente. Las soluciones que funcionan a pequeña escala se rompen al crecer, aprendí esto tarde.

Yo seguiría por ese camino.

¿Podría ampliar un poco esto? La respuesta varía mucho según el sector, no hay una regla general.

También me gustaría saber si alguien lo hace de otra manera.