Reglas de ejecución

5 tareas · 40 min · Principiante

La auditoría de la API no ve lo que ocurre dentro de un contenedor ya en marcha. Para eso se instala un sensor en cada nodo que observa las llamadas al sistema de los procesos y las compara con reglas: un intérprete de órdenes que nace en un contenedor de producción, un gestor de paquetes que se lanza donde nadie debería instalar nada, un archivo de configuración que alguien abre para escribir. En Embotelladora Ceiba Dorada lees las reglas de un sensor, sus excepciones y siete alertas de un día. Aprendes a leer una regla, a contar sus alertas y a decidir si un ruido se arregla con una excepción o con otra cosa.

0 de 5 · 0%

Objetivo de la sala

Una regla de un sensor de ejecución como Falco, un proyecto de código abierto con licencia Apache 2.0, tiene un nombre, una descripción, una condición, un mensaje de salida y una prioridad. Opcionalmente trae etiquetas, excepciones y la fuente de eventos que evalúa. Los nombres repetidos se guardan en macros (condiciones con nombre) y listas (colecciones de valores).

La prioridad va de la más grave a la menos grave: EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFORMATIONAL y DEBUG. Mira las prioridades de reglas_de_ejecucion.

Responde para continuar

¿Qué significa la prioridad de una regla?

La gravedad que se asigna a la alerta, para ordenarla y enrutarla; no cambia el orden de evaluación Que la regla de prioridad ERROR se apaga sola cuando pasa una hora sin que se produzca ninguna alerta Que las reglas de prioridad más alta se evalúan primero y las otras solo si estas no cuadran

Una regla ruidosa se mide: cuántas alertas produce, en qué namespaces y qué parte son esperadas. Sin la cuenta, la conversación sobre si una regla «molesta» es de opiniones. Abre alertas_del_sensor.

Responde para continuar

Escribe cuántas alertas de la regla shell-en-contenedor ocurrieron en el namespace tienda.

Ver pista de ayuda

Filtra por `regla` y por `namespace` y cuenta las filas.

Un contenedor se construye a partir de una imagen que alguien revisó. Si dentro del contenedor en marcha aparece un gestor de paquetes instalando algo, el contenedor ya no es lo que se revisó: eso se llama deriva. Una regla de deriva no necesita saber qué se instaló, le basta con ver quién lanzó el gestor.

Responde para continuar

Escribe el nombre del proceso que disparó la regla paquete-instalado-en-ejecucion.

Ver pista de ayuda

Busca la fila de esa regla en `alertas_del_sensor` y lee la columna `proceso`.

La alerta trae el namespace, el pod, el proceso, el usuario del contenedor y la línea de comando. Con esos campos se puede mandar la alerta al equipo dueño del namespace sin tener que preguntar a nadie qué pasó primero. La regla de escritura bajo /etc es de las que alertan poco y conviene mirar cada vez.

Responde para continuar

Escribe el nombre del pod que disparó la regla escritura-bajo-etc.

Ver pista de ayuda

Busca la fila de esa regla en `alertas_del_sensor`.

La tabla excepciones trae una sola: los pods de respaldo nocturno del namespace operaciones no alertan por abrir un intérprete de órdenes, con dueño y fecha de vencimiento. Un compañero propone cortar de raíz el ruido de la regla shell-en-contenedor poniendo enabled: false, porque en tienda también molesta.

Responde para continuar

¿Qué responde un ingeniero de detección?

Mantener la regla y acotar el ruido con excepciones nombradas, con dueño y vencimiento, como la de respaldo Subir su prioridad a CRITICAL para que el equipo de tienda la atienda antes y deje de ignorarla Aceptar: una regla apagada no puede producir falsos positivos, y los equipos pueden activarla de nuevo cuando lo pidan

Inicia sesión para registrar tus puntos y progreso en el ranking.

Entrar · Registrarse

1 Anatomía de una regla

2 Contar el ruido de una regla Lab

3 Deriva en un contenedor vivo Lab

4 El pod que escribió bajo /etc Lab

5 Excepción, no apagado

Whoami-Labs Pro utiliza cookies