poprhythm
2ed0565486
git-hook-tamper.yaml's condition used proc.exepath, which resolves to the script interpreter's path (e.g. /bin/busybox) for shebang scripts, not the script's own path - switched to proc.cmdline, which retains the originally invoked path. Confirmed via live-testing both ways. ssh-persistence/cloud-metadata-probe/db-spawned-process round out the post-incident hardening pass with a few more incubating-ruleset adaptations.
31 lines
1.3 KiB
YAML
31 lines
1.3 KiB
YAML
# Custom rule, adapted from falcosecurity/rules' Incubating ruleset (not
|
|
# shipped in this Falco image). Generalizes the lesson from the gitea
|
|
# log-poisoning RCE (a service's own process forking something unexpected)
|
|
# to every other DB-backed service on this host - immich, firefly-iii,
|
|
# romm, inbox-zero-db, etc. A database server forking a child process other
|
|
# than itself is not normal and often follows a SQL injection attack.
|
|
|
|
- list: db_server_binaries
|
|
items: [mysqld, postgres, sqlplus]
|
|
|
|
- macro: user_known_db_spawned_processes
|
|
condition: (never_true)
|
|
|
|
- rule: DB program spawned process
|
|
desc: >
|
|
A program related to a database server created an unexpected child
|
|
process (other than itself). This is not supposed to happen and often
|
|
follows SQL injection attacks - could indicate unauthorized data
|
|
extraction or tampering.
|
|
condition: >
|
|
spawned_process
|
|
and proc.pname in (db_server_binaries)
|
|
and not proc.name in (db_server_binaries)
|
|
and not user_known_db_spawned_processes
|
|
output: >
|
|
Database-related program spawned unexpected process
|
|
(user=%user.name command=%proc.cmdline parent=%proc.pname
|
|
container=%container.name image=%container.image.repository pid=%proc.pid)
|
|
priority: WARNING
|
|
tags: [database, process, mitre_execution]
|