julien/apf_portal
1
0
Fork 0
Code Issues 1 Pull Requests Actions 2 Packages Projects Releases Wiki Activity

docs(setup): make fail2ban opt-in in 70-hardening.sh #222

Merged
julien merged 1 commits from docs/setup-fail2ban-optional into main 2026-05-24 20:04:17 +02:00
Conversation 0 Commits 1 Files Changed 3
+31 -15
julien commented 2026-05-24 20:02:54 +02:00
Owner
Copy Link
Copy Source

Summary

Follow-up on #220 / #221. Makes fail2ban opt-in in 70-hardening.sh instead of installing it unconditionally.

Reasoning: some corp environments already ship brute-force protection at the network layer (ACL / corp firewall / appliance) — fail2ban on the host then becomes redundant and can be the wrong layer to debug from when a rule misfires. The other three hardening steps (UFW enable, sshd lockdown) were already prompt-gated; fail2ban was the odd one out.

What lands

File Change
docs/setup/scripts/70-hardening.sh fail2ban block restructured into three branches: (1) already running → skip; (2) installed but stopped → prompt to enable+start; (3) not installed → prompt to install+enable+start. Each "no" path logs ↪ skip (user choice) so re-runs don't repeatedly nag if the dev has already declined.
docs/setup/01-dev-debian-vm-setup.md Table row for 70-hardening.sh clarified — each sub-step's prompt posture is now visible: UFW prompts before enabling, fail2ban prompts before installing, sshd hardening prompts before applying. unattended-upgrades is the only one applied unconditionally.
docs/setup/README.md Same descriptor adjustment.

Test plan

  • On a fresh Debian VM with no fail2ban installed, run 70-hardening.sh, decline the fail2ban prompt → script continues, fail2ban not installed, no service started.
  • On the same VM, re-run 70-hardening.sh → the fail2ban branch prompts again (the dev may have changed their mind); declining again produces the same ↪ skip (user choice) result.
  • On a VM where fail2ban is pre-installed but stopped (rare, but possible if infra rolled it back), the script offers to start it without re-installing.
  • pnpm exec prettier --check clean on the touched files.
  • bash -n docs/setup/scripts/70-hardening.sh (syntax check) clean.
## Summary Follow-up on [#220](https://git.unespace.com/julien/apf_portal/pulls/220) / [#221](https://git.unespace.com/julien/apf_portal/pulls/221). Makes fail2ban **opt-in** in [`70-hardening.sh`](docs/setup/scripts/70-hardening.sh) instead of installing it unconditionally. Reasoning: some corp environments already ship brute-force protection at the network layer (ACL / corp firewall / appliance) — fail2ban on the host then becomes redundant and can be the wrong layer to debug from when a rule misfires. The other three hardening steps (UFW enable, sshd lockdown) were already prompt-gated; fail2ban was the odd one out. ## What lands | File | Change | | --- | --- | | `docs/setup/scripts/70-hardening.sh` | fail2ban block restructured into three branches: (1) already running → skip; (2) installed but stopped → prompt to enable+start; (3) not installed → prompt to install+enable+start. Each "no" path logs `↪ skip (user choice)` so re-runs don't repeatedly nag if the dev has already declined. | | `docs/setup/01-dev-debian-vm-setup.md` | Table row for `70-hardening.sh` clarified — each sub-step's prompt posture is now visible: UFW prompts before enabling, fail2ban prompts before installing, sshd hardening prompts before applying. `unattended-upgrades` is the only one applied unconditionally. | | `docs/setup/README.md` | Same descriptor adjustment. | ## Test plan - [ ] On a fresh Debian VM with no fail2ban installed, run `70-hardening.sh`, decline the fail2ban prompt → script continues, fail2ban not installed, no service started. - [ ] On the same VM, re-run `70-hardening.sh` → the fail2ban branch prompts again (the dev may have changed their mind); declining again produces the same `↪ skip (user choice)` result. - [ ] On a VM where fail2ban is pre-installed but stopped (rare, but possible if infra rolled it back), the script offers to start it without re-installing. - [x] `pnpm exec prettier --check` clean on the touched files. - [x] `bash -n docs/setup/scripts/70-hardening.sh` (syntax check) clean.
julien added 1 commit 2026-05-24 20:02:55 +02:00
docs(setup): make fail2ban opt-in in 70-hardening.sh
CI / commits (pull_request) Successful in 3m51s
Details
CI / scan (pull_request) Successful in 4m13s
Details
CI / check (pull_request) Successful in 4m24s
Details
CI / a11y (pull_request) Successful in 3m49s
Details
Docs site / build (pull_request) Successful in 3m51s
Details
CI / perf (pull_request) Successful in 6m54s
Details
1d8de3365f 
Three branches now: (1) already running -> skip; (2) installed but
stopped -> prompt to enable+start; (3) not installed -> prompt to
install+enable+start. Each decline path logs `(user choice)` so a
re-run doesn't surprise the dev with a different state.

Reasoning: some corp environments already ship brute-force protection
at the network layer (ACL / corp firewall / appliance). fail2ban on
the host is then redundant and can be the wrong layer to debug from
when a rule misfires. The other three hardening steps (UFW,
sshd lockdown) were already prompt-gated; fail2ban was the odd one out.

Table descriptors in the main doc + setup README updated to make
each sub-step's prompt posture visible.
julien merged commit d99254a280 into main 2026-05-24 20:04:17 +02:00
julien deleted branch docs/setup-fail2ban-optional 2026-05-24 20:04:18 +02:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adastra-bot (AdAstra Bot) julien (Julien Gautier)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: julien/apf_portal#222
Delete Branch "docs/setup-fail2ban-optional"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?