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.
This commit is contained in:
@@ -11,3 +11,14 @@
|
||||
# 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)
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
jobs:
|
||||
- name: falco
|
||||
url: http://falco:8765/metrics
|
||||
@@ -0,0 +1,12 @@
|
||||
template: falco_rule_match
|
||||
on: prometheus.falco.falcosecurity_falco_rules_matches_total
|
||||
class: Security
|
||||
type: System
|
||||
component: Falco
|
||||
units: matches
|
||||
every: 10s
|
||||
lookup: sum -120s unaligned
|
||||
crit: $this > 0
|
||||
summary: Falco rule fired - ${label:rule_name}
|
||||
info: Falco priority ${label:priority} rule ${label:rule_name} matched on this host. Run: docker logs falco to see which container/process/command triggered it. If the rule name mentions crypto miner or miner pool port, treat it as an active compromise and investigate immediately.
|
||||
to: sysadmin
|
||||
Reference in New Issue
Block a user