poprhythm
33868ee9bb
"Redirect STDOUT/STDIN to Network Connection in Container" (a reverse-shell detector) was firing legitimately: gitea's sshd/sshd-session dup2 the accepted SSH socket onto stdio for every session (4x per connection), and firefly-iii's wait-for-it.sh does the same TCP-readiness-check dance while waiting for postgres. Both confirmed recurring via netdata's alert history, not one-off. Scoped exceptions added to each's specific binary/cmdline, not the whole container/image. Verified: a gitea SSH login no longer alerts, while a real dup2-based redirect (bash's /dev/tcp exec pattern) from an unrelated container still fires - the exception is narrow, not a blanket disable. "Run shell untrusted" was also flagged as noisy, but investigation showed it fired exactly once, during my own rule-testing window, and never before or since - left alone rather than building a permanent exception for a self-caused test artifact.
69 lines
4.1 KiB
YAML
69 lines
4.1 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" false-positives:
|
|
# - pg_isready: fired every ~10s from inbox-zero-db's healthcheck touching
|
|
# /etc/shadow - NSS/libc user-lookup behavior during process init, not
|
|
# credential harvesting.
|
|
# - lscr.io/linuxserver/obsidian: fires once per container start from
|
|
# `sed -i s/CORRUPT_FILE/NOPASSWD/g /etc/sudoers` - linuxserver.io's
|
|
# own s6-init NOPASSWD setup, same class of init-time file touch.
|
|
- macro: user_known_read_sensitive_files_activities
|
|
condition: >
|
|
(proc.name = pg_isready)
|
|
or (container.image.repository = "lscr.io/linuxserver/obsidian" and proc.name = sed)
|
|
|
|
# "Fileless execution via memfd_create" fires from nvidia-ctk's
|
|
# ldconfig-refresh hook, which runs via memfd_create by design every time
|
|
# an NVIDIA-GPU container (e.g. ollama) starts - normal container-toolkit
|
|
# behavior, not defense evasion. Scoped to the hook's own parent process
|
|
# names rather than the ollama/ollama image, so drift detection stays live
|
|
# for anything else that image does.
|
|
- macro: known_memfd_execution_processes
|
|
condition: (proc.pname in (nvidia-containe, nvidia-ctk))
|
|
|
|
# "Drop and execute new binary in container" (output text: "Executing binary
|
|
# not part of base image") false-positives on three known-benign sources,
|
|
# all confirmed via docker logs falco (2026-08-08 to 2026-08-16):
|
|
# - gitea: re-executes itself for git-shell commands (serv/hook/pre-receive/
|
|
# post-receive) over SSH, which looks identical to a dropped binary.
|
|
# Scoped to proc.name=gitea, not the whole container, so this
|
|
# previously-compromised container still gets checked for any OTHER
|
|
# unexpected binary.
|
|
# - lscr.io/linuxserver/obsidian: Electron's normal /proc/self/exe
|
|
# self-re-exec pattern (zygote/renderer/utility processes), fires ~6x
|
|
# every time the container is recreated (~daily, likely watchtower).
|
|
# Scoped to the whole image since this is normal Electron startup
|
|
# behavior end to end, not one specific binary.
|
|
# - tsl0922/ttyd (Synchronet BBS web terminal): telnet/pv/busybox-extras
|
|
# installed via apk at container start and then used for the BBS's
|
|
# normal telnet workflow. Scoped to those three binaries, not the image,
|
|
# since this is a shell-access container where an unexpected binary is
|
|
# more worth knowing about.
|
|
- macro: known_drop_and_execute_activities
|
|
condition: >
|
|
(container.image.repository = "docker.gitea.com/gitea" and proc.name = gitea)
|
|
or (container.image.repository = "lscr.io/linuxserver/obsidian")
|
|
or (container.image.repository = "tsl0922/ttyd" and proc.name in (telnet, pv, busybox-extras))
|
|
|
|
# "Redirect STDOUT/STDIN to Network Connection in Container" false-positives,
|
|
# both confirmed recurring (not one-off) via netdata's alert history:
|
|
# - gitea: sshd/sshd-session redirect the just-accepted SSH connection's
|
|
# socket onto stdin/stdout/stderr via dup2 - this is simply how every SSH
|
|
# server handles every session, not a reverse shell. Fires 4x per SSH
|
|
# connection (sshd x2, sshd-session x2). Scoped to those two binaries in
|
|
# this one container, not the whole image, since gitea itself spawning
|
|
# this pattern from some other binary would still be worth flagging.
|
|
# - fireflyiii/core: its wait-for-it.sh startup script opens a raw TCP
|
|
# connection to the postgres container to poll for DB readiness, which
|
|
# redirects stdio the same way a reverse shell would mechanically. Scoped
|
|
# to the script's own cmdline, not the whole image.
|
|
- macro: user_known_stand_streams_redirect_activities
|
|
condition: >
|
|
(container.image.repository = "docker.gitea.com/gitea" and proc.name in (sshd, sshd-session))
|
|
or (container.image.repository = "fireflyiii/core" and proc.cmdline contains "wait-for-it.sh")
|