Mantener una plataforma como GitHub en línea y respondiendo a las peticiones requiere de una infraestructura de seguridad robusta. Límites de tasa, controles de tráfico y otras medidas de protección se despliegan en múltiples capas para defenderse de abusos y ataques. Sin embargo, estas protecciones pueden volverse obsoletas y comenzar a bloquear a usuarios legítimos, especialmente si se implementaron como respuesta de emergencia durante incidentes.
El problema de las protecciones olvidadas
Recientemente, usuarios de GitHub reportaron errores de “demasiadas solicitudes” al realizar acciones normales, como seguir enlaces o navegar por la plataforma. Tras investigar, GitHub descubrió que reglas de protección, implementadas durante incidentes pasados, seguían activas. Estas reglas, basadas en patrones asociados con tráfico malicioso, también estaban afectando a solicitudes legítimas.
Estos patrones combinan técnicas de huella digital (fingerprinting) estándar con lógica de negocio específica de la plataforma, creando señales compuestas para diferenciar el uso legítimo del abusivo. El problema es que estas señales compuestas pueden generar falsos positivos.
Aunque el impacto general fue pequeño (aproximadamente 0.003-0.004% del tráfico total), significó que usuarios reales fueron bloqueados incorrectamente. GitHub reconoce que incluso un pequeño porcentaje de bloqueos incorrectos es inaceptable.
Este es un desafío común en la defensa de plataformas a gran escala. Las mitigaciones implementadas rápidamente durante incidentes, aunque necesarias en ese momento, pueden no envejecer bien a medida que evolucionan las amenazas y cambian las herramientas y el comportamiento de los usuarios legítimos.
Rastreando el problema
La investigación reveló la complejidad de rastrear el origen de los bloqueos. La infraestructura de protección de GitHub está organizada en múltiples capas, cada una con la capacidad de limitar o bloquear solicitudes. Determinar qué capa bloqueó una solicitud requiere correlacionar registros de diferentes sistemas, cada uno con sus propios esquemas.
En este caso, el equipo de GitHub partió de los reportes de los usuarios y rastreó las solicitudes a través de las diferentes capas de infraestructura:
- Reportes de usuarios proporcionaron marcas de tiempo y patrones de comportamiento aproximados.
- Registros de la capa perimetral (edge tier) mostraron las solicitudes que llegaban a la infraestructura.
- Registros de la capa de aplicación revelaron respuestas 429 “Too Many Requests”.
- El análisis de las reglas de protección identificó qué reglas coincidían con estas solicitudes.
El ciclo de vida de las mitigaciones
El problema principal fue la falta de gestión del ciclo de vida de las mitigaciones. Aunque cada protección era necesaria cuando se agregó, la falta de fechas de expiración, revisiones post-incidente y monitoreo de impacto convirtió estas reglas en deuda técnica.
Soluciones y mejoras
GitHub revisó las mitigaciones, analizando qué bloqueaban actualmente en comparación con lo que debían bloquear originalmente. Eliminaron las reglas que ya no cumplían su propósito y mantuvieron las protecciones contra amenazas activas.
Además, están implementando mejoras en la gestión del ciclo de vida de los controles de protección:
- Mejor visibilidad en todas las capas de protección para rastrear el origen de los límites de tasa y los bloqueos.
- Tratar las mitigaciones de incidentes como temporales por defecto. Hacerlas permanentes requerirá una decisión intencional y documentada.
- Prácticas post-incidente que evalúen los controles de emergencia y los conviertan en soluciones sostenibles y específicas.
Conclusión
La lección principal es que los mecanismos de defensa, incluso aquellos implementados rápidamente durante incidentes, necesitan el mismo cuidado que los sistemas que protegen. Requieren observabilidad, documentación y mantenimiento activo. De lo contrario, se convierten en deuda técnica que se acumula silenciosamente.
GitHub agradece a los usuarios que reportaron los problemas, ya que su retroalimentación condujo directamente a estas mejoras.
Leave a Comment