Falco: ¿qué es y cómo nos ayuda con nuestra seguridad?

¿Sabías que el 95% de las brechas de seguridad son causadas por errores humanos? La seguridad es un aspecto al que debemos prestar atención. Todos los días hay múltiples noticias que nos informan de graves incidentes de seguridad que afectan a empresas, organizaciones y a millones de personas.

Las plataformas en las que implementamos soluciones IT, proporcionan una alta personalización con múltiples configuraciones que pueden afectar a la estrategia de seguridad.

En este post hablaré de una herramienta que aporta su granito de arena informándonos de las operaciones que se producen en nuestras plataformas.

¿Qué es Falco?

Falco es un proyecto de seguridad en tiempo de ejecución nativo de la nube, fue desarrollado por Sysdig y posteriormente donado a la CNCF. Actualmente, es un proyecto en incubación.

Usa llamadas al sistema para asegurarlo y monitorizarlo, permite buscar comportamientos inusuales, como escaladas de privilegios, operaciones de lectura y escritura en directorios y ficheros, cambios de propiedad, o ejecuciones de binarios entre otras comprobaciones. Estos comportamientos son evaluados a través de ficheros con reglas y posteriormente genera alertas.

Es posible implementar Falco en máquinas locales, en la nube o clústeres de Kubernetes administrados, por lo tanto, puede recibir eventos de distintas fuentes.

La siguiente imagen nos da una visión general sobre el flujo de datos entre inputs, Falco y outputs.

Arquitectura

En este punto centraremos la atención en los componentes de Falco. Su arquitectura se compone de:

• Userspace program. Maneja las señales, analiza la información del driver de Falco y envía alertas.
• Configuration. Define cómo se ejecuta Falco, reglas a evaluar y cómo realizar alertas.
• Driver. Es un software que se ejecuta junto al controlador de Falco y envía un flujo de información de llamadas al sistema. Falco admite los siguientes controladores:
  • Módulo de Kernel integrado con libscap y libsinsp.
  • Sonda eBPF.
  • Instrumentación de Userspace.
• Plugins. Permite ampliar la funcionalidad de Falco agregando nuevas fuentes de eventos.

Reglas

Las reglas son declaradas en ficheros YAML que pueden estar compuestos por hasta tres tipos de elementos:

• Rule. Son condiciones que se evalúan para conocer si han sido incumplidas. Pueden contener otras Rules, Macros y Lists.
• Macro. Son fragmentos de condición de Rules que pueden ser reutilizados en otras Macros o Rules.
• List. Son colecciones de elementos que pueden incluirse en Rules, Macros u otras Lists.

- macro: container
  condition: container.id != host

- list: shell_binaries
  items: [bash, csh, ksh, sh, tcsh, zsh, dash]

- macro: shell_procs
  condition: proc.name in (shell_binaries)

- rule: shell_in_container
  desc: notice shell activity within a container
  condition: >
    container and 
    shell_procs    
  output: >
    shell in a container
    (user=%user.name container_id=%container.id container_name=%container.name 
    shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)    
  priority: WARNING

La regla anterior será evaluada y posteriormente determinada como incumplida cuando el nombre del ejecutable que genera el evento, sea alguno de los elementos de la lista shell_binaries (bash, csh, ksh, sh, tcsh, zsh, dash) y cuando ocurra dentro de un contenedor (container.id != host).

Falco se inicia con reglas predeterminadas, pero es posible establecer reglas propias. La documentación ofrece referencias a todos los campos soportados tanto para condiciones como para los mensajes generados cuando una regla se incumple.

Alertas

Cuando una regla se incumple se genera una alerta. Las alertas pueden ser enviadas hacia distintos canales:

• Salida estándar (Standard Output). Este canal es útil cuando utilizamos herramientas como Fluentd o Logstash para capturar los registros.
• Fichero.
• Syslog.
• Programa externo. Podría ser un servidor de correo o publicar en un canal de Slack a través de un webhook.
• Endpoint HTTP o HTTPS.
• Cliente externo via gRPC API. Por ejemplo, falco-exporter (exporter de Prometheus).

La salida generada cuando una regla se incumple, podría ser así:

09:29:25.296597224 Warning Shell in a container (user=root container_id=7d4a76ce9019 container_name=httpd shell=sh parent=runc cmdline=sh)

Otra opción es enviar las alertas a Falco Sidekick. Es una herramienta complementaria a Falco que permite recibir las alertas y reenviarlas a servicios comunes como Google Chat, Datadog, Alertmanager, Loki, AWS Lambda, GCP Pubsub o Apache Kafka, entre muchos otros. Cuando Falco Sidekick es utilizado, conviene hacer uso de Falco Sidekick-ui.

Falco Sidekick-ui es una simple herramienta que se compone de una aplicación web y un servidor Redis. Permite mostrar información de los eventos recibidos por Falco Sidekick a través de una interfaz web.

Plugins

Permiten a los usuarios ampliar la funcionalidad de Falco agregando nuevas fuentes de eventos. Actualmente, los plugins admitidos son los siguientes:

• K8saudit. Eventos de auditoría de Kubernetes.
• Cloudtrail. Registros JSON de AWS Cloudtrail o AWS S3.
• Json. Permite extraer valores de cualquier JSON.
• Dummy. El propósito de su uso es con fines de documentación.
• Dummy_c. Como dummy, pero escrito en C++.
• Docker. Eventos Docker.
• Seccomp Agent. Eventos de agentes de Seccomp.
• Okta. Eventos de registro de Okta.
• Github. Eventos de webhook de Github.
• K8saudit-eks. Eventos de auditoría de Kubernetes de los clústeres de AWS EKS.
• Nomad. Lee eventos de Hashicorp Nomad.

Cada uno de los plugins tiene configuración propia y proporciona nuevos campos para explotar los eventos recibidos. Utilizan reglas específicas de forma predeterminada y pueden servir como base para el desarrollo de nuevas reglas.

Event sources

De forma nativa, Falco consume eventos del Kernel de Linux. Sin embargo, es posible añadir otras fuentes según el caso de uso:

• Eventos de AWS Cloudtrail. Provenientes de AWS S3 o AWS SQS/SNS.
• Eventos de Auditoría de Kubernetes. Habilita un servidor web en Falco que acepta peticiones POST en formato JSON.
• Eventos de Okta.
• Eventos de muestra. A través de events-generator, se generan eventos de muestra para k8saudit y syscall. El uso de esta fuente tiene como finalidad evaluar el correcto funcionamiento de Falco en una circunstancia controlada.

Falco en acción

Veamos cómo funciona Falco con un ejemplo:

Paso 1

En primer lugar, definimos el fichero ~/.minikube/files/etc/ssl/certs/minikube-audit-policy.yaml con una política para los logs de auditoría.

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
 - "RequestReceived"
rules:
 - level: RequestResponse
   resources:
   - group: ""
     resources: ["pods", "deployments"]

 - level: RequestResponse
   resources:
   - group: "rbac.authorization.k8s.io"
     resources: ["clusterroles", "clusterrolebindings"]

 - level: Metadata
   resources:
   - group: ""
     resources: ["pods/log", "pods/status"]

 - level: None
   resources:
   - group: ""
     resources: ["configmaps"]
     resourceNames: ["controller-leader"]

 - level: None
   users: ["system:kube-proxy"]
   verbs: ["watch"]
   resources:
   - group: ""
     resources: ["endpoints", "services"]

 - level: None
   userGroups: ["system:authenticated"]
   nonResourceURLs:
   - "/api*"
   - "/version"

 - level: Request
   resources:
   - group: ""
     resources: ["configmaps"]
   namespaces: ["kube-system"]

 - level: RequestResponse
   resources:
   - group: ""
     resources: ["configmaps"]

 - level: Metadata
   resources:
   - group: ""
     resources: ["secrets"]

 - level: Request
   resources:
   - group: ""
   - group: "extensions"

 - level: Metadata
   omitStages:
     - "RequestReceived"

Posteriormente, definimos el fichero ~/.minikube/files/etc/ssl/certs/minikube-webhook-config.yaml para configurar un webhook backend.

apiVersion: v1
kind: Config
clusters:
- name: falco
 cluster:
   server: http://localhost:30007/k8s-audit
contexts:
- context:
   cluster: falco
   user: ""
 name: default-context
current-context: default-context
preferences: {}
users: []

Paso 2

Iniciamos un clúster de Kubernetes con Minikube configurado para que Falco pueda funcionar correctamente y habilitamos un Ingress Controller:

$ minikube start --extra-config=apiserver.audit-policy-file=/etc/ssl/certs/minikube-audit-policy.yaml --extra-config=apiserver.audit-log-path=- --extra-config=apiserver.audit-webhook-config-file=/etc/ssl/certs/minikube-webhook-config.yaml --extra-config=apiserver.audit-webhook-batch-max-size=10 --extra-config=apiserver.audit-webhook-batch-max-wait=5s --cpus=4
 --driver=virtualbox

$ minikube addons enable ingress

Paso 3

En este tercer paso instalamos Falco. Al ser una configuración más amplia definimos previamente un fichero de configuración.

falcoctl:
 config:
   artifact:
     install:
       refs: [falco-rules:0, k8saudit-rules:0.5]
     follow:
       refs: [falco-rules:0, k8saudit-rules:0.5]

services:
 - name: k8saudit-webhook
   type: NodePort
   ports:
     - port: 9765
       nodePort: 30007
       protocol: TCP

driver:
 enabled: false

falco:
 rules_file:
   - /etc/falco/k8s_audit_rules.yaml

 plugins:
   - name: k8saudit
     library_path: libk8saudit.so
     init_config:
       ""
     open_params: "http://:9765/k8s-audit"
   - name: json
     library_path: libjson.so
     init_config: ""
 load_plugins: [k8saudit, json]

 time_format_iso_8601: true
 json_output: true

 http_output:
   enabled: true
   url: "http://falcosidekick:2801"
   userAgent: "falcosecurity/falco"

Instalamos Falco con Helm y el fichero de configuración.

$ helm upgrade --install falco falcosecurity/falco -f falco.yaml -n falco --create-namespace --version 3.0.0

Paso 4

Alertmanager será el receptor de alertas provenientes de Falco Sidekick, lo instalamos con Helm. Obtenemos la IP de Minikube para poder entrar a las aplicaciones a través del Ingress Controller.

$ export MINIKUBE_IP=$(minikube ip)
$ helm upgrade --install alertmanager prometheus-community/alertmanager -n alertmanager --set ingress.enabled="true" --set ingress.hosts[0].host="alertmanager.${MINIKUBE_IP}.nip.io" --set ingress.hosts[0].paths[0].path="/" --set ingress.hosts[0].paths[0].pathType="ImplementationSpecific" --create-namespace --version 0.26.0

Paso 5

En este paso vamos a instalar Falco Sidekick del mismo modo, con Helm. Recibirá todas las alertas de Falco.

$ export MINIKUBE_IP=$(minikube ip)
$ helm upgrade --install falcosidekick falcosecurity/falcosidekick -n falco --set config.alertmanager.hostport="http://alertmanager.alertmanager.svc:9093" --set webui.enabled="true" --set webui.ingress.enabled="true" --set webui.ingress.hosts[0].host="falcosidekick-ui.${MINIKUBE_IP}.nip.io" --set webui.ingress.hosts[0].paths[0].path="/" --version 0.5.16

Paso 6

En el sexto paso obtendremos las URLs de las aplicaciones y comprobamos su accesibilidad.

$ k get ingress -A -o custom-columns=HOSTS:.spec.rules[0].host
HOSTS
alertmanager.192.168.59.124.nip.io
falcosidekick-ui.192.168.59.124.nip.io

Paso 7

En este último paso, comprobaremos todo el flujo de información entre todos los componentes con dos ejemplos.

Por un lado, creamos un configmap con información sensible, algo totalmente desaconsejable.

apiVersion: v1
data:
 access.properties: |
   aws_access_key_id = MY-ID
   aws_secret_access_key = MY-KEY
kind: ConfigMap
metadata:
 name: my-config
 namespace: default

Y, por otro lado, iniciaremos una shell en un contenedor.

kubectl -n falco exec -it daemonsets/falco -- bash
Defaulted container "falco" out of: falco, falcoctl-artifact-follow, falcoctl-artifact-install (init)
root@falco-777fc:/#

Escaso segundos después, recibimos las alertas.

• Falco Sidekick

• Alertmanager

Conclusiones

Falco de manera nativa es una herramienta bastante potente, que aporta mucho valor monitorizando lo que ocurre en nuestros sistemas en tiempo de ejecución.

Analiza eventos que provienen de la API de Kubernetes, tanto en servicios gestionados (AKS, GKE, EKS) como no gestionados (OpenShift), junto a eventos syscalls.

Con respecto al envío de alertas, permite una gran cantidad de posibilidades, y podría potenciarse aún más mediante el envío de alertas a servicios como Azure Event Hub, o AWS Cloudwatch o GCP Chronicle. Incluso podrían llegar a ser explotados con sistemas como Splunk, Azure Sentinel o AWS Security Hub entre muchas otras opciones según el caso de uso.