Files
docker-infrastructure/falco/rules/tune-noise.yaml
T
poprhythm 1858572c4d falco/netdata: tune out gitea SSH false positive, make alert text self-explanatory
- 'Drop and execute new binary in container' fired on every git push/pull
  to gitea over SSH (gitea's own binary re-executing itself for git-shell
  hooks looks like container drift). Scoped exception via
  known_drop_and_execute_activities to proc.name=gitea on that specific
  image, not a blanket container whitelist, so other unexpected binaries
  in that container still get caught.
- netdata alarm text was a static generic blurb requiring a manual
  'docker logs falco' every time to find out what actually happened.
  Now interpolates ${label:rule_name}/${label:priority} (exposed by
  Falco's Prometheus metric) so the Telegram message names the specific
  rule directly. Note: literal double-quotes in the info/summary text
  broke netdata's alarm-notify.sh (silent delivery failure, exit 1) -
  avoided.
- Added netdata/health.d and netdata/go.d to the repo for documentation;
  netdata does not auto-deploy these from git, same as gitea's app.ini -
  copy to /srv/netdata/config/ manually and restart the container.
2026-08-08 22:48:05 +00:00

25 lines
1.5 KiB
YAML

# Tune out stock-rule false positives observed on this specific host, so the
# broad netdata "any Falco match" alarm only pages for things worth paging
# for. Uses Falco's own user_* customization macros rather than disabling
# whole rules, so the underlying security check stays active for everything
# else. Add entries here as new noisy defaults turn up - don't let this list
# grow into blinding Falco to anything actually meaningful.
# "Sensitive file opened for reading by non-trusted program" fired every
# ~10s from inbox-zero-db's pg_isready healthcheck touching /etc/shadow -
# NSS/libc user-lookup behavior during process init, not credential
# harvesting. Scoped to just this binary, not a blanket rule disable.
- macro: user_known_read_sensitive_files_activities
condition: (proc.name = pg_isready)
# "Drop and execute new binary in container" fires on every git push/pull
# to gitea over SSH - gitea's own binary re-executes itself for git-shell
# commands (serv/hook/pre-receive/post-receive), which looks identical to
# drift-detection's "new binary written to the writable layer" pattern.
# Scoped to proc.name=gitea specifically (not the whole container via
# known_drop_and_execute_containers) so this container - the one that was
# actually compromised - still gets checked for any OTHER unexpected
# binary, just not its own expected self-invocation.
- macro: known_drop_and_execute_activities
condition: (container.image.repository = "docker.gitea.com/gitea" and proc.name = gitea)