Skip to content

Alerts: eliminate the false positives, and stay silent on dispatch - #26

Open
OpenSource-For-Freedom wants to merge 1 commit into
mainfrom
fix/alerts-zero-false-positives
Open

Alerts: eliminate the false positives, and stay silent on dispatch#26
OpenSource-For-Freedom wants to merge 1 commit into
mainfrom
fix/alerts-zero-false-positives

Conversation

@OpenSource-For-Freedom

Copy link
Copy Markdown
Owner

Rebuilt the event catalogue around zero false positives, and stopped manual dispatches posting status cards.

The three collectors that would have ruined the channel

Collector Problem
Every sudo command Ordinary admin work buries the signal
RestartCount > 0 Cumulative counter. After any deploy it alerts on every run, forever, until the container is recreated. A permanent alert is the same as no alert.
Whitelist edits Adding a player is routine, not an incident

What is watched now

Event Severity Why it will not false-positive
SSH login medium Only two accounts should ever log in here
SSH login, unknown username high Not routine on this box by definition
Failed auth burst (10+) high Port 22 is closed to all but DO console ranges, so real failures are ~0
Sensitive sudo only high Measured live: 1 sudo command in 24h, 0 sensitive
fail2ban ban medium Rare, always meaningful
Container not running high Unambiguous
Container restarted medium Compares StartedAt, so one alert per real restart
ops.json changed high Granting operator is privilege escalation in-game
sudoers / sshd_config / authorized_keys changed high Real tampering signals
New user account high Rare
Disk 90%+ high Rare

Deliberately not watched: routine sudo, whitelist add/remove, cumulative restart counts.

Dispatch no longer posts a status card

always_post defaults to false. A dispatch is for checking the server, not for generating a message.

Verified on the live droplet

run 1: "no security events since 18:25:32"
run 2: "no security events since 18:37:45"   <- immediately after, no duplicate
sudo in last 24h: 1     of which sensitive: 0

The script in this PR was read back off the running droplet, not from a local copy, so the repo and the live box are identical by construction rather than by assumption.

The first version of the droplet monitor would have made its own channel
worthless. Three collectors fired during normal operation:

  every sudo command   ordinary admin work buried the signal
  RestartCount > 0     that counter is CUMULATIVE, so after any deploy it
                       alerted on EVERY run forever until the container was
                       recreated. A permanent alert is the same as no alert.
  whitelist edits      adding a player is routine, not an incident

What is watched now is deliberately narrow: rare things a person would
want to know about within minutes.

  SSH logins           every one, and an UNKNOWN username escalates to
                       high. Only two accounts should ever log in here.
  Failed auth burst    10+ since the last check. Port 22 is closed to all
                       but DigitalOcean console ranges, so genuine
                       failures are ~0 and a burst means something changed.
  Sensitive sudo only  useradd/usermod/passwd/visudo/sudoers/
                       authorized_keys/sshd_config/iptables/ufw/
                       systemctl enable-disable-mask. Measured on the live
                       box: 1 sudo command in 24h, of which 0 sensitive.
  fail2ban bans
  Container not running, or restarted since the last check, compared by
                       StartedAt rather than the cumulative counter, so
                       exactly one alert per real restart
  ops.json changed     granting operator is privilege escalation in-game
  sudoers, sshd_config, authorized_keys changed
  New user accounts
  Disk at 90%

Deliberately not watched: routine sudo, whitelist add/remove, cumulative
restart counts.

The health workflow also stops posting a status card on manual dispatch.
A dispatch is for checking the server, not for producing a message; tick
always_post when deliberately confirming the wiring.

The script committed here was read back OFF the running droplet rather
than from a local copy, so the repo and the live box are identical by
construction rather than by assumption. Verified before committing: two
consecutive runs both reported nothing, which is correct on a quiet box
and the exact case the old version got wrong.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant