Falco es conocido como herramienta para Kubernetes, y casi todas las guías sobre él están escritas para clústeres. Sin embargo, no está atado a los clústeres: vigila llamadas al sistema, y en un servidor corriente con un sitio eso funciona exactamente igual. Simplemente, casi nadie escribe sobre ese caso.

Resulta útil allí donde las demás herramientas callan. Un web shell en un sitio no viola ningún permiso, no produce accesos fallidos y no coincide con ninguna firma si se escribió a mano. Pero muestra un comportamiento anómalo para un servidor web: el proceso de PHP-FPM lanza un intérprete de comandos. Eso es lo que ve Falco.

Qué detecta

Eventos típicos en un servidor corriente:

  • un intérprete engendrado por el proceso del servidor web o de PHP: señal prácticamente inequívoca de un web shell;
  • un programa lanzado desde /tmp, /dev/shm o /var/tmp;
  • archivos sensibles (/etc/shadow, claves privadas) leídos por un proceso que no tiene nada que ver con ellos;
  • modificación de binarios del sistema;
  • una conexión saliente desde un proceso que no debería usar la red.

Instalación

La elección decisiva se hace al instalar: cómo obtiene Falco las llamadas al sistema. La variante moderna se basa en eBPF y no exige ni compilar un módulo del núcleo ni cabeceras del núcleo:

sudo falcoctl driver config --type modern_ebpf
sudo systemctl restart falco

El módulo clásico del núcleo necesita cabeceras y se recompila tras cada actualización del núcleo: en un servidor donde las actualizaciones se instalan solas, esa es una fuente recurrente de servicio muerto. Si el núcleo es lo bastante reciente (5.8 o superior), elija eBPF y olvide el problema.

Para comprobar que llegan eventos de verdad:

sudo systemctl status falco
sudo journalctl -u falco -n 50

El ruido y cómo eliminarlo

Ese es el trabajo de verdad. El conjunto de reglas que viene de fábrica apunta a entornos con contenedores, y en un servidor corriente una parte considerable o no se aplica o se dispara continuamente.

Las reglas incluidas (/etc/falco/falco_rules.yaml) no se editan: el archivo se sustituye al actualizar. Sus cambios van a /etc/falco/falco_rules.local.yaml, y ahí mismo se desactivan las reglas sobrantes:

- rule: Terminal shell in container
  enabled: false

Lo que suele haber que ajustar en un servidor sin contenedores:

  • todas las reglas de contenedores: sin contenedores solo ocupan sitio en el informe;
  • «Write below etc»: se dispara en cada instalación de paquete y en cada cambio suyo en un archivo de configuración. Hace falta una excepción para apt, dpkg y unattended-upgrades, o los eventos llegarán en torrente;
  • «Read sensitive file untrusted»: se dispara con agentes de supervisión, herramientas de copia de seguridad y herramientas de auditoría como Lynis;
  • los arranques desde directorios temporales: hay excepciones legítimas, como la compilación de una aplicación o un navegador automatizado que descomprime un controlador en un directorio temporal. Esos eventos parecen inquietantes pero se explican, y conviene crear la excepción para la ruta concreta enseguida en lugar de volver a razonarlo cada vez.

El orden razonable es el mismo que con cualquier otra herramienta de detección: la primera semana solo observar y crear excepciones, y solo después tratar un evento como señal. La regla es simple: si el informe contiene con regularidad eventos que usted no lee, no le está sirviendo de nada.

Adónde enviar los eventos

La salida se configura en /etc/falco/falco.yaml: un archivo, el diario del sistema o el paso a un programa externo. Para un servidor único basta un archivo con rotación posterior; no olvide la rotación, el archivo de eventos crece como cualquier registro y por omisión nadie lo vigila.

Las prioridades conviene usarlas para separar: los eventos críticos allí donde los verá de inmediato, el resto al diario general para revisarlo después.

Falco y auditd no son lo mismo

Ambos vigilan llamadas al sistema, pero con fines distintos. auditd registra lo que ocurre para poder reconstruir el cuadro más tarde: no evalúa nada ni informa de nada, lleva un diario. Falco aplica reglas en el momento del evento y dice «esto parece sospechoso»: da una señal en lugar de un registro.

Tener ambos es razonable: el diario para reconstruir, las señales para reaccionar. Si hay que elegir uno, auditd resulta más útil en un servidor donde lo importante es reconstruir la secuencia de los hechos tras un incidente; Falco, allí donde se busca una señal temprana sobre un minero en marcha o un web shell.

¿Merece el sitio en un servidor pequeño?

La respuesta honesta: no siempre. Falco procesa llamadas al sistema y se nota en el procesador de una máquina cargada. Si el servidor aloja un sitio y aún no tiene ni control de integridad ni actualizaciones automáticas decentes, no es por ahí por donde hay que empezar.

Su momento llega más tarde, cuando lo básico está hecho y queda la pregunta de qué ocurre en el servidor que los registros no muestran. Cubre una clase de eventos mejor que todas las demás juntas: un intérprete lanzado por el proceso del servidor web. Cómo se ven los eventos repartidos por prioridad y por regla lo muestra la página de demostración de abajo.