Vai al contenuto
Web server hardening

Linter security per Apache e Nginx

Incolla un blocco di config Apache.htaccess o Nginx server e ottieni un audit security: SSL/TLS deboli (TLSv1, TLSv1.1, RC4, 3DES), server_tokens on, ServerTokens Full, autoindex, exposed status (/server-status, /nginx_status), header sicurezza mancanti, rate limit assente, listen 80 senza redirect HTTPS, location root non ristretta. Auto-detect del dialetto. Findings severity-coded con riferimenti normativi.

Come usare il linter

  1. 1

    Recupera il blocco di config

    Apache: cat /etc/apache2/sites-enabled/*.conf oppure il file .htaccess dell'app. Nginx: cat /etc/nginx/sites-enabled/* oppure il blocco server {... } rilevante. Se hai più file (modulari con include), incolla il blocco principale - il linter non risolve include ricorsivi.

  2. 2

    Incolla nel tool

    Sintassi originale, commenti inclusi (verranno ignorati). Il linter auto-rileva il dialetto: presenza di RewriteRule, <Directory>, Options -> Apache; presenza di server {, location {, add_header -> Nginx. Forzature manuali non supportate (lo scope è essere zero-config).

  3. 3

    Lint

    Output: lista findings ordinati per severita' (critico/alto/medio/basso/info), con codice direttiva o pattern problematico, descrizione del rischio, remediation suggerita, riferimento normativo (NIS2 art. 24, OWASP Web Server Misconfig, Mozilla SSL Configuration Generator).

  4. 4

    Esporta report

    Bottone 'Copia report' produce un riepilogo testuale incollabile in mail interna, ticket di ops, ticket di security. Per export PDF usa la funzione 'Stampa' del browser (CSS print-ottimizzato). Bonus: i findings sono action-oriented, possono essere convertiti in tickets atomici per la pipeline di hardening.

Perché linting è il livello prima dell'audit

Triage automatico vs review manuale. Una config Apache di 200 righe o un nginx.conf di 400 righe è un buon candidato per il linting automatico: la maggior parte degli errori di hardening è pattern matching (mancanza di una direttiva, presenza di un valore ovviamente sbagliato come ssl_protocols TLSv1). Il linter intercetta il 70-80% dei findings tipici di un audit cyber in pochi secondi, lasciando alla review manuale i casi complessi (ridondanze fra <Location> apache, override di add_header nginx, interazioni fra VirtualHost multipli).

Cosa controlla davvero questo linter. 25 controlli puntuali distribuiti su 5 famiglie: SSL/TLS (protocolli abilitati, ciphers, HSTS, OCSP stapling), information disclosure (server tokens, server signature, X-Powered-By, autoindex), access control (location root, exposed admin pages, exposed status), headers di sicurezza (X-Frame-Options, X-Content-Type-Options, CSP, Permissions-Policy emessi via add_header/Header), availability (rate limiting con limit_req nginx, listen 80 senza redirect HTTPS).

Limiti del linting. Il tool non risolve ricorsivamente le direttive include /etc/nginx/snippets/*.conf, quindi la config che vede è quella che incolli, non l'effettiva runtime composta dagli include. Non valuta le interazioni fra moduli compilati come mod_security, né la postura del filesystem (permessi e ownership di /etc/nginx/sites-enabled/). Per audit completi serve un agent server-side che ispezioni il sistema runtime (lynis e altri) o un consulente che lo analizzi nel suo insieme.

Privacy operativa. La config che incolli viene processata direttamente nel browser: utile per audit di sistemi interni, ambienti staging non accessibili dall'esterno e per evitare di trasferire a un servizio terzo configurazioni potenzialmente sensibili (path interni, credenziali in chiaro per misconfigured directive).

Famiglie di controlli applicate

SSL / TLS

  • Protocolli deboli: TLSv1, TLSv1.1, SSLv2, SSLv3 -> CRITICO
  • Cipher deboli: RC4, 3DES, EXPORT, NULL -> ALTO
  • SSL session caching configurato (performance + security)
  • OCSP stapling abilitato

Information disclosure

  • Apache: ServerTokens Full/OS/Major/Minor -> INFO
  • Apache: ServerSignature On -> INFO
  • Nginx: server_tokens on (default!) -> INFO
  • Apache: Options +Indexes -> MEDIO
  • Nginx: autoindex on -> MEDIO

Access control

  • Apache: <Location /server-status> senza Require ristretta -> ALTO
  • Nginx: location /nginx_status senza allow/deny -> ALTO
  • Apache: RemoveHandler.phtml mancante (PHP eseguibile) -> MEDIO se applicabile
  • Apache: AllowOverride All in <Directory /> -> MEDIO

Security headers

  • X-Frame-Options assente -> ALTO
  • X-Content-Type-Options nosniff assente -> MEDIO
  • HSTS (Strict-Transport-Security) assente sul vhost SSL -> ALTO
  • Content-Security-Policy assente -> ALTO
  • Permissions-Policy assente -> MEDIO
  • Referrer-Policy assente -> MEDIO

Availability

  • Nginx: limit_req_zone + limit_req assenti su endpoint sensibili (auth, register, password-reset) -> MEDIO
  • Apache/Nginx: listen 80 senza redirect a HTTPS -> ALTO
  • Nginx: client_max_body_size non specificato (default 1MB, attenzione upload-friendly) -> INFO

Glossario

Termini tecnici usati in questa pagina, spiegati in due righe.

Apache.htaccess #
File di config per-directory, sintassi Apache. Permette ai sysadmin senza accesso al main config (es. shared hosting) di configurare rewriting, header, autenticazione. Lento (parsato a ogni request), ma flessibile. Disabilitato in scenari high-perf con AllowOverride None.
Nginx server block #
Blocco di config che definisce un virtual host. Sintassi: server { listen...; server_name...; location / {... } }. Risolto a startup di nginx, no overhead per request. Standard de facto per nginx in production.
TLSv1.0 / TLSv1.1 #
Versioni TLS deprecate (RFC 8996, 2021). NIST e PCI DSS richiedono TLSv1.2 minimo dal 2018. Mantenere abilitati per legacy client è un rischio (POODLE, BEAST, LUCKY13).
OCSP stapling #
Online Certificate Status Protocol stapling. Il server include la risposta OCSP del CA nella TLS handshake, evitando al client di contattare la CA per verificare lo stato del cert (revoked? expired?). Riduce latenza e migliora privacy.
ServerTokens #
Direttiva Apache che controlla l'header Server. Valori: Full (default, espone OS+modules+versions), Prod (solo "Apache"), Major ("Apache/2"), Minor, Min, OS. Best practice: ServerTokens Prod.
limit_req_zone #
Direttiva Nginx per rate limiting. Definisce una zona di memoria condivisa (storage del leaky bucket) e un rate (es. 10 req/s). Si applica via limit_req zone=name burst=20 nodelay; dentro location {}.
AllowOverride #
Direttiva Apache che controlla quali direttive il .htaccess può override. All = tutto permesso (default storico, comodo, lento e sicurezza opaca). None =.htaccess ignorato (high-perf, sicurezza esplicita). FileInfo, AuthConfig, Limit, Indexes, Options = controlli granulari.
OCSP Must-Staple #
Estensione X.509 che richiede a un client di rifiutare il certificato se OCSP stapling non è presente. Mitiga downgrade attack contro OCSP. Non ancora ampia adozione per rischio di self-DOS.

Domande frequenti sul linter

Auto-detect del dialetto sbaglia: come forzo?
Non c'e' force manuale (scope KISS). L'euristica controlla pattern unici: se incolli un blocco con server { o add_header -> Nginx; con RewriteRule o <Directory> -> Apache. Se la tua config è troppo minimale per essere classificata, il tool default a Apache (per retrocompat con.htaccess minimi). Per Nginx senza pattern caratteristici: aggiungi una linea fittizia server { listen 443; } in cima per forzare il detect.
Il linter trova vulnerabilita' note (CVE)?
No, è un linter di hardening, non uno scanner CVE. Per CVE su nginx core o Apache modules: tool dedicati come lynis, nuclei con template hardening, oppure SaaS commerciali. Il linter qui copre la postura statica della config: misconfiguration scoperte (server_tokens on), mancanze (header missing), pattern noti come problematici (ssl_protocols TLSv1).
Come trovo i pattern di rate limiting necessari?
Per nginx, due strati. (1) Globale anti-DOS: limit_req_zone $binary_remote_addr zone=global:10m rate=30r/s; nel http {}, poi limit_req zone=global burst=60 nodelay; nei server {}. (2) Auth specifico: zone separata rate=5r/s per endpoint /login, /password-reset, /register. Per Apache: mod_evasive o mod_qos esterni.
Il linter analizza anche file include? (nginx /etc/nginx/snippets/*.conf)
No, analizza solo il blocco incollato. Per analizzare config modulari: concatena cat /etc/nginx/sites-enabled/* /etc/nginx/snippets/*.conf e incolla il risultato. La maggior parte dei findings è indipendente dall'ordine, quindi la concatenazione produce risultati corretti.
Apache 2.4: <code>Order allow,deny / Allow from all</code> è deprecato?
Si. Apache 2.4 ha sostituito la sintassi del 2.2 con Require. Best practice: Require all granted (consenti tutti), Require ip 192.168.0.0/16 (consenti solo IP locali), Require local (solo localhost). La vecchia sintassi è supportata via mod_access_compat ma è deprecated.
Posso lintare config rsyslog, postfix, ssh? (non solo web)
No, scope è Apache + Nginx (web server). Per altri demoni esistono linter dedicati (sshd -t per ssh config, postfix check per postfix, rsyslogd -N1 per rsyslog). Per audit cyber distribuito: lynis è il tool di riferimento, gratuito (script bash, no agent). Esegue 200+ check su tutti i layer del sistema.
Il linter mi segnala 'CSP assente' ma uso Cloudflare Workers per emetterla. Come ignoro?
Il linter non sa cosa fa Cloudflare. Per gestire false positive di scope: il report è indicativo, valuta caso per caso. Se hai già difese a un layer superiore (CDN, WAF, reverse proxy), il finding è sopravvalutato dal linter ma il rischio reale è minore. Documentalo nel report di audit interno con riga 'Mitigato a Cloudflare layer'.
Quale tool migliore per audit nginx + caching?
Per audit nginx in produzione conviene combinare più strumenti: nginx -V per verificare i moduli compilati e i flag di build, curl -I per ispezionare gli header di cache (X-Cache, Age, Cache-Control), e i tool di vulnerability scanning generici come nuclei con i template di categoria http/misconfiguration per intercettare i pattern di hardening errato più diffusi.
Il linter copre Caddy, Traefik, HAProxy?
No. Scope è Apache + Nginx, i più diffusi in PMI italiane. Caddy ha hardening default eccellente (TLS forced, HSTS auto), serve audit minimale. Traefik usa middleware approach diverso: i header sono in middleware YAML, non in server block. HAProxy sintassi distinta. Possibile estensione roadmap, non priorità immediata.
Posso integrare il linter in CI/CD? E' API?
Non c'e' un endpoint API. Il tool è SPA. Per CI: il vero hardening lint server-side si fa con nginx -t (validazione sintassi), apache2ctl configtest, e tool dedicati come cfg-check per Apache. Il pattern matching di security rule lo si fa con grep -E su pattern noti, oppure con regole nuclei custom. La logica di questo linter è open source (vanilla JS), riusabile come baseline per uno script CI.

Vuoi un audit completo dei tuoi web server?

Questo linter è un buon punto di partenza per il triage automatico. Un audit professionale dell'infrastruttura web esamina TLS termination, fail2ban, rate limiting, isolation per virtual host, hardening del PHP-FPM, log rotation, monitoring. Lavoro su VPS unmanaged Linux (Debian, Ubuntu, AlmaLinux, Rocky).

Audit dei tuoi web server

Vuoi una stima realistica per il tuo progetto?

Wizard di 7 domande, 2 minuti, gratuito. Output: range di giorni-uomo, range di prezzo orientativo e raccomandazione di ingaggio. Tariffa di riferimento 300 euro al giorno. Pensato per progetti backend custom, integrazioni, audit di sicurezza o automazione AI.

Calcola il preventivo