[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f2yuvv4nsxa7kf":3},{"code":4,"message":5,"data":6,"timestamp":26},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":16,"summary_md":17,"topic":18,"github_topics":21,"license":22,"homepage":23,"updated_at":24,"history":25},"Neo23x0\u002Fprocess-watcher",17,"A process monitoring tool that tries to detect exploitation","Go",109,4,14,7,[],"Monitors what a Linux service spawns via eBPF, to catch exploit-driven child processes.","A narrow, root-required eBPF agent that watches one service's process tree and reports what it starts. It fits incident-response or hardening work on a known Linux host, not a general EDR.\n\n## The problem\n\nSuppose an attacker finds a way to make your public-facing nginx, php-fpm or Java service run a command. The service looks normal; only an unexpected child process — a shell, `useradd`, a downloader — reveals the intrusion. Inspecting `\u002Fproc` after the fact misses processes that already exited, and detection based on the service's own logs may never trigger. process-watcher attaches eBPF programs and emits an event when a watched tree spawns a child, so you see the short-lived command plus its parent chain instead of reconstructing it later.\n\n## What's different\n\nThe mechanism is the point: the agent matches on the file name of the program actually executed, not `comm` or `argv[0]`, and tracks descendants across exec, reparenting, double forks and the death of the root, so a command that re-parents to PID 1 is still attributed. Events go to JSONL, TCP\u002FUDP or a webhook, and argument capture is opt-in because command lines can contain secrets. Optional kill rules can signal matching children by image, argv or regex — a blunt, explicit lever.\n\nThe trade-off is strictness. If a requirement is missing, the agent exits with code 3 and never falls back to polling `\u002Fproc`, which the README says would miss short-lived processes. Coverage is binary: either the host qualifies or you get no data. `check-config` and `print-config` run without root, but observation cannot.\n\n## Who should try it\n\nGood fit: a security or platform team running a specific Linux service on a known amd64\u002Farm64 host with a modern kernel, wanting a lightweight, auditable record of what that service spawns — for example during the PHP critical-release window the README calls out. It also suits an IR team watching a suspect service rather than the whole machine.\n\nPoor fit: older kernels, container-only environments, or a host where the service tree cannot be pinned to an image name. It is not a general host intrusion-detection system; it watches the trees you name.\n\n## Requirements and limitations\n\nLinux `amd64`\u002F`arm64`, kernel 5.15+ with BTF (`\u002Fsys\u002Fkernel\u002Fbtf\u002Fvmlinux`); the README notes the version alone is no guarantee because the agent checks the exact functions and fields it needs at start. Root (or `CAP_BPF` + `CAP_PERFMON`, plus `CAP_SYS_PTRACE` for other users' executables and `CAP_KILL` for kill rules) is required, and the initial host PID namespace is mandatory: it refuses to run in a container, and kernel lockdown `confidentiality` blocks it. `sudo .\u002Fprocess-watcher doctor` checks these; tested kernels are in [docs\u002Fcompatibility.md](https:\u002F\u002Fgithub.com\u002FNeo23x0\u002Fprocess-watcher\u002Fblob\u002Fmain\u002Fdocs\u002Fcompatibility.md).\n\nOngoing upkeep matters: maintain the watch list and exclusions, take care with argument capture, and stage-test kill rules. Deployment is a single static binary or a systemd unit via [packaging\u002FINSTALL.md](https:\u002F\u002Fgithub.com\u002FNeo23x0\u002Fprocess-watcher\u002Fblob\u002Fmain\u002Fpackaging\u002FINSTALL.md), with checksums and build attestation for releases.\n\n## HotRepo's take\n\nHotRepo first tracked this on 2026-10-24; on the 2026-10-25 NEW-REPOSITORY board (新项目榜, not the overall Trending board) it showed 109 total stars at #25 — a snapshot, not a daily growth figure. With only two recorded dates, persistence cannot be judged. Before adopting, confirm your kernel passes `doctor` and that your service's real executable name matches what you watch.",{"slug":19,"name":20},"security","Security & Privacy",[],"GPL-3.0",null,"2026-10-25T03:18:09Z",[],1792921154]