# Fix Task List Companion to `ROOT_CAUSE_ANALYSIS.md`. Items marked `[x]` below have been verified/applied in this local checkout. **The server-side forensics, credential rotation, and Apache config items still need to be done directly on the live production box** — they can't be done from this local copy. Items in P0 are time-sensitive: as long as `kamley1337.php` (or its underlying access path) remains live, the server should be treated as actively compromised. --- ## Forensics — do this first, on the live server (not this local copy) You can't tell from a local checkout when the backdoor arrived or whether others exist. Before or alongside the fixes below, on the actual production box: - [ ] `grep -r "kamley1337\|eval(base64\|\.php" /var/log/apache2/access.log*` (and any rotated/gz logs) to find the first request that hit the shell, and the source IP(s) that have used it since. - [ ] `find /var/www/html/topgun -name "*.php"` and more broadly `find / -newer -type f -mtime -30` to look for other recently modified/added files outside git. - [ ] `crontab -l` for every system user (`for u in $(cut -f1 -d: /etc/passwd); do crontab -l -u $u; done`) — look for unfamiliar scheduled jobs. - [ ] `cat ~/.ssh/authorized_keys` (and for any other user with a home dir) for unrecognized public keys. - [ ] `last -a` / `lastlog` for logins from unfamiliar IPs. - [ ] `ps aux` for unfamiliar node/php/perl/crypto-miner processes, and `netstat -tulpn` for unexpected listening ports or outbound connections. - [ ] Pull the **full** Apache config (not just the two vhost files copied into this repo) — `apache2ctl -S`, `/etc/apache2/sites-enabled/*`, `/etc/apache2/mods-enabled/*php*`, `/etc/apache2/conf-enabled/*` — to find whatever is actually letting `.php` execute despite the `ProxyPass /` catch-all (see `ROOT_CAUSE_ANALYSIS.md` §2). --- ## P0 — Immediate / security-critical 1. **Remove the backdoor** from both locations on the live server: project root `kamley1337.php` and `public/kamley1337.php`. Also re-check after removal that it doesn't reappear (confirms whether the attacker still has independent access). 2. **Rotate every credential** reachable from this server or its `.env`: `CMS_API_KEY` / `CMS_API_SECRET`, server SSH/FTP/cPanel or hosting-panel passwords, and any other secrets stored on the box. Assume anything present in plaintext on disk has been read. 3. **Close the actual entry point**, once identified from the forensics step above — e.g. disable the global PHP handler for this docroot if the app is Node-only, patch/rotate whatever credential or panel was used, or lock down the vulnerable service. 4. **Decide on a full server rebuild.** If the attacker has had unknown-duration read/write access to the whole filesystem (which `kamley1337.php` grants), a targeted cleanup can miss other planted backdoors, cron jobs, or modified system binaries. A clean OS reinstall + redeploy from a verified-clean source tree is the only way to be fully certain, and is the generally recommended response to a confirmed full-filesystem-access compromise. 5. [x] **Initialize git version control** for this project now, with a clean baseline commit, so future changes are diffable and a known-good state exists to compare against and roll back to. Done: repo initialized, baseline commit created (`.env`/`node_modules`/`.next` correctly excluded via `.gitignore`). ## P1 — High priority (security hardening) 6. [x] **Sanitize CMS-sourced HTML** before rendering. All `dangerouslySetInnerHTML` call sites in `components/about/CoachingTeamSection.tsx`, `FounderSection.tsx`, `BranchesSection.tsx` were already wrapped in `DOMPurify.sanitize(...)`. Found and fixed one remaining gap: `TopgunAboutSection.tsx`'s `subsections.map` rendered `sub.description` raw — now sanitized. Grepped the rest of `components/` and `app/` — no other unsanitized usages. 7. [x] **Stop double-defining the CMS secret.** Verified: `.env` no longer has `NEXT_PUBLIC_CMS_API_KEY` / `NEXT_PUBLIC_CMS_API_SECRET`, and `services/fetchData.service.js` / `fetchFormFields.js` read only the non-public `CMS_API_KEY` / `CMS_API_SECRET` with no `NEXT_PUBLIC_...` fallback. 8. [x] **Guard `services/fetchData.service.js`** with `"use server"`. Already present, matching `fetchFormFields.js` / `handleSubmit.js` / `handleSubmitsubs.js`. 9. [~] **Restrict script execution on the docroot.** Both local vhost copies (`topgunshootingacademy.com.conf`, `-le-ssl.conf`) already contain a ` Require all denied ` block — **but this needs to be confirmed as actually deployed on the live Apache server**, not just present in these local reference copies, and the PHP-execution overlap from §2 of the analysis still needs to be found and closed (the deny block is a mitigation, not the root-cause fix). 10. **Add file-integrity monitoring** (even something simple — a nightly cron that hashes the project tree outside `node_modules`/`.next` and diffs against the last run, or a tool like OSSEC/Wazuh/Tripwire) so a planted file is caught within hours, not discovered a week later as "the page is stuck." 11. Put a WAF in front of the app (Cloudflare, or ModSecurity on Apache) and block direct requests for `.php` paths at the edge, since this is a Node-only app and no `.php` should ever legitimately be requested. ## P2 — Medium priority (code / dependency hygiene) 12. [x] Remove the unused `"crypto"` npm dependency. Verified: not present in `package.json`; only the built-in Node module is used. 13. [x] Align `eslint-config-next` with the installed `next` major version. Verified: both are `16.1.6`. 14. [x] Delete the unused leftover template asset. Verified: `public/images/sh.f48a1a04fe8dbf021b4cda1d.html` does not exist. 15. [x] Replace the default boilerplate metadata in `app/layout.tsx`. Verified: real title/description already in place. 16. [x] Remove the `console.log("host", host)` / `console.log("rh", rh)` debug statements. Verified: not present in `services/fetchData.service.js`. ## P3 — Process / monitoring 17. Set up uptime + error monitoring/alerting so a broken site is caught automatically within minutes rather than found by visitors after days. 18. Write down the actual deployment process (build command, process manager/service name used to run it on port 3046, restart procedure) in `README.md` — right now it's still 100% `create-next-app` boilerplate and none of this is documented anywhere. 19. Establish a recurring (e.g. monthly) lightweight security check: confirm no unexpected files in the docroot, review installed npm dependencies for new/unexpected entries, and rotate secrets periodically rather than only after an incident.