Build the nginx, Apache and IIS service packs

Aperta
  • Qualcosa non va?
#95 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
apache, bash, nginx, powershell
Ambito
security, testing

Direzione di ricerca

Start on branch phase-7/service-packs-web in module phases/harden/modules/pack_web/ (ID harden.pack_web). Read spec design 11 and dependencies #80 and #89 first. Write bats and Pester acceptance tests before building nginx, Apache and IIS packs with ModSecurity detection-only. Done means all listed acceptance tests pass and untested versions stay unchanged.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area: services phase: harden platform: linux platform: windows type: build

Read first

Read these before starting. If this issue and the spec disagree, the spec wins; say so in the pull request.

Summary

Build the service packs for the web servers nginx, Apache and IIS: tested, repeatable settings that harden each app in place (hide the version, turn off directory listing, add safe headers). Settings that could change what the scoring engine sees wait for approval. ModSecurity with the OWASP Core Rule Set (a web application firewall) runs in detection-only mode, and a blocking rule for one flaw is applied only after approval. A pack changes settings in place and never installs or replaces a service.

Depends on

  • Blocked by #80 (restore points, taken before a pack changes anything) and #89 (the checkpoint summary).
  • Blocks #102 (service replacement).

Location & Context

  • Branch: phase-7/service-packs-web. Module ID: harden.pack_web, in phases/harden/modules/pack_web/ (new), with module.yml, the .sh and .ps1 entry points and about.txt (design 00, section 4).
  • ModSecurity itself is installed by the packages module (#79); this pack only configures it.
  • Tests: tests/phases/harden/pack_web/ (new), in bats and Pester.

Current Behavior

The web servers are left at their defaults. There are no repeatable, tested settings or web application firewall rules.

Plan

  1. Build packs for nginx, Apache and IIS. Each setting goes into an add-on file, is checked with the app's own test (nginx -t, apachectl configtest, the IIS configuration validator), reloads gently, and runs under a revert timer.
  2. Configure ModSecurity with the Core Rule Set in detection-only mode, and approved blocking rules for one flaw (section 6.1).
  3. Apply nothing automatically on a version not listed as tested.

Acceptance tests

Write these first, in bats and Pester:

  • Each pack, run twice on its lab host, changes nothing the second time.
  • A setting that fails the app's own syntax test is not applied and leaves the service unchanged.
  • A forced probe failure is reverted by the timer.
  • An approved web application firewall rule blocks the planted exploit request while the scoring-style probe passes.
  • On a version not listed as tested, the pack applies nothing automatically.
  • Negative test: protected accounts and scored services are untouched before and after.

Done when

  • The Linux and Windows versions both pass CI, including the real-host tests on the Ubuntu and Windows Server runners. A test never cuts the runner off from GitHub.
  • The manual entry and the module's help page (about.txt) are written.
  • The module is added to the shipped profiles that use it.
  • The tests above pass in the lab on the nginx, Apache and IIS lab hosts (docs/lab/README.md).

Out of scope

  • Installing ModSecurity or any module: #79.
  • The mail, DNS, database, share and host settings packs: #96 and #97.
  • Web application settings and code: runbooks for a person.
  • Moving or containerizing a web service: #102.
Lingua principale
PowerShell
Stelle
0
Fork
0
Merge medio
2h 7m
PR unite (30g)
53

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dotnetdork/Labyrinth

Tutte le issue di dotnetdork/Labyrinth

Issue simili

Altre issue su Security

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.