Header Ads Widget

Ticker

6/recent/ticker-posts

Ingeniería del caos para API: revisión de Gremlin

 Revisamos Gremlin, una herramienta para pruebas de API basada en un espíritu de ingeniería del caos

Descargo de responsabilidad: esta NO es una publicación patrocinada. Nuestra cobertura es parte de nuestro esfuerzo por destacar nuevas e interesantes herramientas en el espacio API.

Internet es un lugar extremadamente complejo. Es esta complejidad, por supuesto, lo que ha hecho que la tecnología sea tan disruptiva. Sin embargo, a pesar de todas las grandes cosas que causa este caos , existen algunas preocupaciones fundamentales que conducen a fallas en el servicio.

Gremlin es una oferta que se centra en gestionar este caos, o al menos entenderlo y abordarlo desde una perspectiva de usabilidad e ingeniería. A diferencia de otras soluciones, que apuntan a arreglar el caos, Gremlin parece más preocupado por manejar la realidad del caos y diseñar la situación en la configuración más positiva.

Para los desarrolladores de API , Gremlin se puede utilizar con fines de prueba creando las condiciones granulares exactas en las que a menudo se producen fallas. En otras palabras, puede someter su API a ataques del mundo real en una situación no real. Por esta razón, vale la pena analizarlo un poco más.

Hoy, veremos a Gremlin y descubriremos el espíritu que impulsa su enfoque. Veremos algo de historia detrás de la ingeniería del caos y entenderemos cómo Gremlin maneja el caos subyacente a la web moderna.

Ingeniería del caos

Gremlin es un enfoque único debido al hecho de que, no solo reconocen el caos de los sistemas subyacentes, sino que parecen contentos con trabajar dentro de sus límites. Mientras que otras soluciones parecen querer organizar el caos y así eliminarlo, Gremlin apunta a aprovechar el caos para obtener un beneficio.

Entonces, ¿cómo hace esto? En pocas palabras, Gremlin intenta simular una variedad de entornos y situaciones en las que la solución en cuestión pasa por la gama del caos; es similar al viejo adagio de muévete rápido y rompe las cosas ", excepto más en la línea de " muévete rápido, romper cosas y aprender lecciones ”. Al simular el entorno en el que una API puede fallar y llevar la API al límite, debería poder encontrar estas vulnerabilidades y problemas antes de que lo que está en juego sea real.

Para citar la documentación de Gremlin :

Chaos Engineering es un enfoque disciplinado para identificar fallas antes de que se conviertan en interrupciones. Al probar de manera proactiva cómo responde un sistema bajo estrés, puede identificar y corregir fallas antes de que acaben en las noticias.

La ingeniería del caos le permite comparar lo que cree que sucederá con lo que realmente sucede en sus sistemas. Literalmente, "rompe cosas a propósito" para aprender a construir sistemas más resistentes.

El proceso de ingeniería

En términos generales, el enfoque de Gremlin sigue tres pasos básicos:

  • Planifique un experimento : esta etapa del proceso es donde realmente comienza el marco para la ingeniería del caos. Gremlin quiere que consideres qué podría salir mal en tu API: ¿qué situación podría causar fallas? Una vez que se sabe, todo lo demás puede encajar.
  • Contener el radio de explosión : esta es esencialmente una etapa de prueba de menor impacto. Aquí, la prueba es en el microcosmos más básico, más pequeño de sí mismo, como una prueba basal de lo que el medio ambiente realmente puede hacer. La prueba más pequeña que le dará datos procesables se encontrará en esta etapa, ya que continúa el trabajo preliminar mientras planifica su experimento sin empujar la API a la etapa de prueba de "salida de ruido".
  • Escalar o aplastar : el paso final, Gremlin advierte que aquí es donde identifica el problema o escala hasta que está en la escala completa de su API. En teoría, si puede escalar hasta su carga API teórica máxima, puede estar relativamente seguro de que sus resultados escalarán en la vida real.

Gremlin es un enfoque interesante en el sentido de que, en última instancia, proporciona una especie de modelo de " falla como servicio ". Si bien esto tiene sus propias advertencias y consideraciones, en particular el problema de que la fijación de problemas particulares podría resultar en "empantanado" en minucias, el enfoque sigue siendo válido como una solución de prueba general.

¿Qué es Gremlin?

Antes de continuar, hay una pregunta sobre qué es realmente Gremlin. Por un lado, mucho de lo que estamos a punto de hablar parece que requiere que la base de código se integre en la API y, sin embargo, el servicio no es una arquitectura o un marco. Por otro lado, los ataques hacen un daño similar al interno. La pregunta entonces es: "¿qué es Gremlin en relación con mi API?"

La respuesta más simple es que Gremlin es un servicio de componentes para pruebas . No piense en Gremlin tanto como una arquitectura o un marco, ya que esto implica una integración más intensa de la que realmente está ocurriendo. Tampoco lo considere un servicio de pruebas de penetración o un proveedor externo; lo que está sucediendo es mucho más local. Al final de todo, Gremlin se anuncia a sí mismo como un “conjunto completo de módulos de prueba de fallas de nivel empresarial”, y esa es una descripción tan adecuada como podría esperarse.

Tipos de ataque y pruebas

Gremlin tiene un montón de ataques específicos Estos ataques operan en etapas, moviéndose a través de cada etapa en orden de importancia. Gremlin define estas etapas de la siguiente manera:

Running| Attack running on the host—–:|:—–:
Halt| Attack told to halt
RollbackStarted| Code to rollback has started
RollbackTriggered| Daemon started a rollback of client
InterruptTriggered| Daemon issued an interrupt to the client
HaltDistributed| Distributed to the host but not yet halted
Initializing| Attack is creating the desired impact
Distributed| Distributed to the host but not yet running
Pending| Created but not yet distributed
Failed| Client reported unexpected failure
HaltFailed| Halt on client did not complete
InitializationFailed| Creating the impact failed
LostCommunication| Client never reported finishing/receiving execution
ClientAborted| Something on the client/daemon side stopped the Gremlin and it was aborted without user intervention
UserHalted| User issued a halt
Successful| Completed running on the Host
TargetNotFound| Attack not scoped to any current targets

Cuando se configura un ataque en Gremlin, se realiza una o más ejecuciones, que es el ataque que se ejecuta contra un proceso específico. Luego, el ataque avanza a través de cada etapa, generando datos útiles.

Gremlins de recursos

Los recursos Gremlins son los específicos de problemas de recursos para la API. Cada llamada a una API requiere una cantidad específica de recursos y, aunque a menudo consideramos que el equilibrio óptimo es "lo suficientemente bueno", las funciones y aplicaciones desequilibradas en la API podrían generar grandes desequilibrios entre el servicio en el mundo real con carga real, causando un verdadero fracaso. Gremlim señala los siguientes paradigmas generales de Gremlin como parte de su documentación:

  • CPU : crea flujos de datos para simular una carga alta para uno o más de los núcleos de la CPU. Esto está destinado a simular una carga extrema en los procesadores, como sería el caso de una oleada repentina de transformación, codificación u otras solicitudes de manipulación de datos.
  • Memoria : toma RAM del proceso, simulando una ráfaga de memoria masiva. Esto podría imitar tanto las demandas extremas de memoria como una fuga de memoria descontrolada para ver cómo la API identificaría y rectificaría tal problema.
  • IO : I / O significa entrada / salida, y esto es exactamente lo que enfatiza este Gremlin. Esto sería similar a un disco duro sometido a una increíble cantidad de ciclos de lectura / escritura por encima y más allá de las cantidades proyectadas normales.
  • Disco : similar a la E / S pero con una metodología distinta, la prueba de disco solo escribe contenido en el disco hasta un cierto porcentaje para simular las limitaciones del mundo real de los medios de almacenamiento y la recuperación de datos aleatoria.

Todas estas pruebas son específicas de los recursos y, como tales, son excelentes para probar la recuperación óptima, la generación de rutas y otras llamadas específicas de recursos. Muchos de estos también pueden ayudar a magnificar las condiciones existentes que pueden no ser evidentes, como identificar fugas de memoria mínimas que de otro modo se considerarían anomalías estadísticas; es mucho más difícil ignorar esta pérdida de memoria cuando los datos son extremadamente altos y el porcentaje aumenta rápidamente. a niveles insostenibles.

Gremlins de la red

Mientras que los Gremlins de recursos atacan los recursos locales, los Gremlins de la red atacan los recursos remotos . Estas pruebas le permiten someter la API a cambios en el estado de la red o su estado operativo, probando tanto los sistemas de recuperación como de detección. Gremlin define los siguientes Gremlins en su documentación:

  • Blackhole : este Gremlin descarta todo el tráfico de red de un patrón de coincidencia específico, es decir, "todo el tráfico entrante de una máquina específica que utiliza este protocolo específico". Esto es excelente para probar sistemas de identificación y se usa mejor en combinación con rangos de IP específicos o nombres de host para simular fallas en partes de su red más amplia. Esto puede usarse con gran efecto para probar la redundancia de su red y los sistemas de redireccionamiento, ya que puede simular de manera efectiva la pérdida de un conmutador o enrutador en la red; de esta manera, también puede ayudar a probar un DDoS aislado en un componente de red específico.
  • Latencia : La latencia es el tiempo que transcurre entre una solicitud y su cumplimiento. Este Gremlin inyecta latencia en el tráfico de la red de salida, lo que permite cambios de latencia arbitrarios para desplazar el código. Esto es más útil para simular la degradación de la red que cualquier otra cosa, ya que básicamente ralentiza todo en una rama de red aislada.
  • Pérdida de paquetes: en esencia, esto simplemente elimina los paquetes que coinciden con el tráfico de red de salida. Esto se usa mejor cuando se prueba la recuperación de paquetes y las políticas de reenvío, y cuando se combina con la latencia, puede simular de manera efectiva un DDoS en toda la red en todos los dispositivos conectados a la red.
  • DNS : bloquea el acceso al servidor DNS. Probar la resolución local y las copias de seguridad del sistema con esto puede ayudar a identificar algunas fallas importantes en los sistemas internos y garantizar que se pueda mantener la funcionalidad de la red incluso si se desconectan partes fundamentales de la red.

Gremlins estatales

Estos Gremlins introducen el caos en su sistema y son probablemente los elementos de prueba más caóticos de esta suite.

  • Apagado : esto provoca un reinicio, o lo que la documentación de Gremlin llama un "paro". La idea aquí es simular la pérdida de un servidor o un clúster en un servidor, pero también puede imitar algo como un corte de energía. El uso principal de algo como esto es para probar la recuperación y la planificación de respaldo: esta función modela un apagado, por lo que el propósito de dicho apagado es realmente discutible, ya sea una tormenta, una inundación, un terremoto, un corte de energía, etc. Hay un montón de valor en este tipo de comando también, ya que puede usarlo para probar específicamente su enfoque de redundancia de memoria, especialmente si el apagado es inesperado y sin signos de estrés en la arquitectura subyacente.
  • Viaje en el tiempo : por mucho que me gustaría que esto me llevara a los años 50 en un DeLorean, esta función solo cambia la hora del sistema anfitrión. Si bien esto parece trivial, cambiar la hora en un host puede tener algunos impactos bastante significativos. Todo, desde los errores del horario de verano, que pueden causar problemas de memoria y escritura, hasta el error histórico Y2K, todos tienen sus raíces fundamentales en un problema de este tipo. En consecuencia, ser capaz de probarlo es muy útil.
  • Asesino de procesos : esto hace lo que dice en la lata: mata un proceso específico. Esto puede ayudar a realizar pruebas contra fallas de dependencia, fallas de funciones y enrutamiento de código deficiente. Este es quizás el ataque más dañino en muchos sentidos, y debe considerarse la joya de la corona de la categoría de patrón de ataque estatal. Tenga en cuenta que, al igual que el cierre, realmente no importa qué razón teórica haya para que se elimine el proceso; puede ser literalmente cualquier razón hipotética, pero el resultado final de un proceso muerto sigue siendo el mismo, por lo que esto encaja en un amplia variedad de patrones de ataque y vectores de amenaza.

Ataques de aplicaciones

Los ataques a aplicaciones son ataques específicos contra la aplicación, generalmente mediante el aprovechamiento de algún tipo de inyección. Gremlin le permite crear ataques utilizando la biblioteca ALFI (Application-Level Fault Injection) y una interfaz de usuario web contra aplicaciones y tipos de tráfico específicos. Al permitir que estos ataques sean más específicos y granulares, estos ataques pueden simular tipos de ataques muy específicos.

Por ejemplo, si desea atacar específicamente la dirección del cliente que obtiene un registro, puede especificar tanto el tipo de falla a nivel de aplicación como el tipo de tráfico coincidente específico, así como la duración del ataque y la situación en la que este ataque vive. Puede simular una llamada que falla lentamente, por ejemplo, o un ataque que falla cada enésima vez.

Gremlin proporciona los siguientes tres ejemplos de este tipo de ataque en su documentación:

  • Simule una interrupción en la producción creando un ataque solo en su ID de cliente. Luego, puede buscar señales de problemas cuando inicie sesión como usted mismo, mientras que ningún otro usuario se da cuenta de que se está produciendo un ataque.
  • Simule un problema con un punto final específico. La falla parcial en los sistemas distribuidos es bastante común: algunos puntos finales pueden no estar disponibles mientras que otros funcionan perfectamente. Para simular tal escenario, puede crear un ataque dirigido solo a algunos puntos finales y luego determinar cómo reacciona su sistema.
  • Prueba de fallas siempre activa. Si limita un ataque a un conjunto de dispositivos que controla, entonces puede ejecutar pruebas contra esos dispositivos de forma regular y evaluar cómo funciona la experiencia del usuario cuando el sistema se degrada.

Gremlin y tu API

Con toda la discusión sobre los ataques de Gremlin, me viene a la mente una sola pregunta: ¿cuál es la relación de Gremlin con su API? Principalmente, existe una preocupación obvia en cuanto a proteger a Gremlin para que sus ataques no puedan ser aplicados por usuarios externos contra su API y, por supuesto, existe la preocupación de qué cantidad de su API está realmente expuesta.

En primer lugar, debe tenerse en cuenta que Gremlin está construido desde cero para no requerir ningún privilegio de root en los hosts que prueba. Como la documentación deja muy claro, cada usuario "gremlin" tiene privilegios predeterminados de Linux y de ninguna manera es un "superusuario". Dicho esto, hay cuatro componentes principales de Linux sobre los que Gremlin tiene control total:

  • cap_sys_boot: se utiliza para todos los ataques de apagado y reinicio.
  • cap_sys_time: se utiliza para todos los ataques de viaje en el tiempo.
  • cap_net_admin: se utiliza para todos los ataques de red.
  • cap_kill: se utiliza para matar un proceso.

Tener tanta exposición puede ser una preocupación: aunque el usuario de Gremlin se crea con derechos predeterminados, los ataques de escalada de privilegios no son desconocidos. En consecuencia, Gremlin ofrece varios sistemas de seguridad para reducir los vectores de ataque para estas capacidades particulares.

En primer lugar, Gremlin realiza auditorías de seguridad de rutina Esta auditoría se realiza en todo el código base, tanto para sus servicios web como para la API, y tanto los hallazgos del auditor más recientes como las actividades de corrección se codifican en una Carta de evaluación que se puede proporcionar a pedido. Honestamente, esta es la solución de seguridad más grande de toda su oferta: si bien los problemas de parcheo son excelentes y dar consejos sobre el aislamiento puede ser efectivo, probar el sistema y proporcionar documentación para cada etapa de prueba y corrección es enormemente valioso.

Para ir más allá, Gremlin ofrece algunas implementaciones de seguridad. Primero, ofrecen autenticación de dos factores, que es muy útil para evitar el acceso no autorizado a las cuentas de Gremlin. En segundo lugar, ofrecen SAML SSO, que es una forma muy poderosa de integrar un sistema de seguridad federado, como los que se encuentran en muchos backends de API, en la instalación local de Gremlin.

Configuración de Gremlin

Si quieres ver cómo funciona Gremlin por ti mismo, puedes seguir estos pasos para instalarlo localmente. Gremlin puede funcionar en una tonelada de plataformas diferentes, y aunque el proceso es muy simple de ejecutar, existen pequeñas diferencias entre cada una. Gremlin debe instalarse en cada máquina host que esté siendo atacada y, debido a esto, el proceso real de instalación puede variar algo entre cada base de código específica.

Para simplificarlo, veremos cómo instalar Gremlin en Debian. El primer paso de este proceso es agregar el repositorio de Gremlin. Al agregar la fuente del repositorio en Debian, podremos solicitar los paquetes correctos en pasos posteriores. Agregue el repositorio usando el siguiente código:

echo "deb https://deb.gremlin.com/ release non-free" | sudo tee /etc/apt/sources.list.d/gremlin.list

A continuación, importaremos la clave GPG, que nos permitirá acceder a los archivos encriptados para la configuración de Gremlin:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C81FC2F43A48B25808F9583BDFF170F324D41134 9CDB294B29A5B1E2E00C24C022E8EF3461A50EF6

Desde aquí, instalar Gremlin es muy fácil:

sudo apt-get update && sudo apt-get install -y gremlin gremlind

Sencillez y granularidad

Si bien hemos pasado mucho tiempo discutiendo cómo funciona realmente Gremlin, deberíamos discutir brevemente la experiencia de usar Gremlin. Dos términos vienen a la mente cuando se trabaja en la documentación: simplicidad y granularidad.

La instalación en múltiples sistemas, desde Ubuntu hasta Docker, es extremadamente simple, a menudo concluye en un puñado de líneas de código. La configuración es a menudo igualmente simple, y la excelente documentación se destaca por encima de otros como un gran ejemplo de documentación simple, informativa y completa.

La configuración de los ataques también es muy simple y se puede configurar fácil y rápidamente a través de la aplicación web Gremlin. Por otro lado, tener una aplicación web para configurar estos ataques es útil, ya que la experiencia de prueba está separada entre lo que esperaría ver en la CLI y lo que está creando específicamente como un ataque; podría ser una diferenciación psicológica sutil. , pero en última instancia es más útil que lo contrario.

Otra cosa a considerar aquí es la granularidad de todo. Cada ataque puede ser específico para el tipo de aplicación, el tipo de tráfico de red, la especificidad y la programación de cada ataque, y más. Gremlin cuenta con un nivel de granularidad entre el 0.01% del tráfico y el 100%; tener un rango tan amplio permite escalar las pruebas, lo cual es muy importante cuando se trata de API de producción.

Conclusión

En última instancia, Gremlin encaja en un nicho: pruebas granulares y escalables frente a una base de código API del mundo real. Si esta es la opción óptima en cada situación o no, depende en gran medida de la API en sí y de los tipos de ataques esperados. Dicho esto, la mayoría de las API en la mayoría de las situaciones podrían beneficiarse de Gremlin, aunque solo sea para probar los recursos subyacentes al sistema de API.

¿Has usado alguna vez Gremlin? ¿Cuáles son tus pensamientos? Háganos saber en los comentarios a continuación.

Publicar un comentario

0 Comentarios