Gixy-Next: scanner di sicurezza per la configurazione NGINX per audit di sicurezza

Panoramica

Gixy-Next (Gixy) è uno scanner di sicurezza per la configurazione NGINX open-source e uno strumento di hardening che analizza staticamente il tuo nginx.conf per rilevare misconfigurazioni di sicurezza, lacune nell'hardening e comuni problemi di prestazioni prima che raggiungano la produzione. È un fork attivamente mantenuto di Gixy di Yandex. Il codice sorgente di Gixy-Next è disponibile su GitHub.

Gixy-Next può anche essere eseguito nel browser su questa pagina. Non è necessario alcun download; puoi scansionare le tue configurazioni sul sito web (localmente, utilizzando WebAssembly).

Avvio rapido

Gixy-Next (la CLI gixy o gixy-next) è distribuito su PyPI. Puoi installarlo con pip o uv:

# pip
pip3 install gixy-next
# uv
uv pip install gixy-next

Puoi quindi eseguirlo:

# gixy legge di default /etc/nginx/nginx.conf
gixy
# Ma puoi anche specificare un percorso alla configurazione
gixy /opt/nginx.conf

Puoi anche esportare la tua configurazione NGINX in un singolo file di dump (vedi nginx -T Live Configuration Dump):

# Esegue il dump dell'intera configurazione NGINX in un singolo file (inclusi tutti gli include)
nginx -T > ./nginx-dump.conf
# Scansiona il dump altrove (o tramite stdin):
gixy ./nginx-dump.conf
# oppure
cat ./nginx-dump.conf | gixy -

Scanner basato sul web

Invece di scaricare ed eseguire Gixy-Next localmente, puoi usare questa pagina web e scansionare una configurazione dal tuo browser web (localmente, utilizzando WebAssembly).

Scansione con Docker

Gixy-Next è disponibile come immagine Docker da Docker Hub o GitHub Registry.

Scansiona un file di configurazione locale montandolo nel container:

# Usa Github Registry
docker run --pull=always --rm -v "$PWD/nginx.conf:/nginx.conf:ro" ghcr.io/megamansec/gixy-next /nginx.conf
# Oppure Docker Hub
docker run --pull=always --rm -v "$PWD/nginx.conf:/nginx.conf:ro" megamansec/gixy-next /nginx.conf

Scansiona un dump della configurazione NGINX live:

# Esegue il dump dell'intera configurazione NGINX in un singolo file (inclusi tutti gli include)
nginx -T > ./nginx-dump.conf
# Usa Github Registry
docker run --pull=always --rm -v "$PWD/nginx-dump.conf:/nginx-dump.conf:ro" ghcr.io/megamansec/gixy-next /nginx-dump.conf
# Oppure Docker Hub
docker run --pull=always --rm -v "$PWD/nginx-dump.conf:/nginx-dump.conf:ro" megamansec/gixy-next /nginx-dump.conf

Scansiona da stdin:

# Usa Github Registry
nginx -T | docker run --pull=always --rm -i ghcr.io/megamansec/gixy-next gixy-next -
# Oppure Docker Hub
nginx -T | docker run --pull=always --rm -i megamansec/gixy-next gixy-next -

Cosa può fare

Gixy-Next può rilevare un'ampia gamma di misconfigurazioni di sicurezza e prestazioni NGINX in nginx.conf e nei file di configurazione inclusi. Sono supportati i seguenti plugin:

• [add_header_content_type] Impostare Content-Type tramite add_header
• [add_header_multiline] Header di risposta multilinea
• [add_header_redefinition] Ridefinizione degli header di risposta tramite la direttiva "add_header"
• [alias_traversal] Path traversal tramite alias mal configurato
• [allow_without_deny] Allow specificato senza deny
• [default_server_flag] Flag default_server mancante
• [error_log_off] error_log impostato su off
• [hash_without_default] Default mancante nei blocchi hash
• [host_spoofing] Falsificazione dell'header Host della richiesta
• [http2_misdirected_request] Protezione mancante contro richieste HTTP/2 mal indirizzate
• [http_splitting] HTTP Response Splitting
• [if_is_evil] If is evil quando usato nel contesto location
• [invalid_regex] Gruppi di cattura regex non validi
• [low_keepalive_requests] keepalive_requests basso
• [missing_worker_processes] worker_processes mancante
• [mixed_case_variable] Riferimenti a variabili con maiuscole/minuscole miste
• [origins] Problemi con la validazione degli header referer/origin
• [overlapping_captures] Catture sovrapposte nel contesto di rewrite redirect/args
• [proxy_buffering_off] Disabilitazione di proxy_buffering
• [proxy_pass_normalized] Problemi di normalizzazione del percorso in proxy_pass
• [proxy_set_header_redefinition] Ridefinizione degli header di richiesta inoltrati tramite la direttiva "proxy_set_header"
• [quic_bpf_reuseport] Connessioni QUIC eliminate silenziosamente dopo il reload
• [regex_redos] Denial of service tramite espressioni regolari (ReDoS)
• [resolver_external] Uso di nameserver DNS esterni
• [return_bypasses_allow_deny] La direttiva return aggira le restrizioni allow/deny
• [ssl_ecdh_curve] I gruppi post-quantum impediscono l'avvio di NGINX su OpenSSL più vecchi
• [ssl_stapling_letsencrypt] OCSP stapling non fa nulla per un certificato Let's Encrypt
• [ssl_stapling_without_resolver] OCSP stapling fallisce silenziosamente senza un resolver
• [ssrf] Server Side Request Forgery
• [stale_dns_cache] Record DNS in cache obsoleti/scaduti usati in proxy_pass
• [status_page_exposed] Garantisce che status_page non sia esposto al mondo
• [try_files_is_evil_too] La direttiva try_files è evil senza open_file_cache
• [unanchored_regex] Espressioni regolari non ancorate
• [unnamed_groups] Gruppi di cattura senza nome nella query string di rewrite
• [valid_referers] none/blocked in valid_referers
• [version_disclosure] Uso di valori non sicuri per server_tokens
• [worker_rlimit_nofile_vs_connections] worker_rlimit_nofile deve essere almeno il doppio di worker_connections

Qualcosa non rilevato? Apri una issue su GitHub indicando cosa manca!

Utilizzo (flag)

gixy legge di default la configurazione NGINX di un sistema da /etc/nginx/nginx.conf. Puoi anche specificare la posizione passandola a gixy:

# Analizza la configurazione in /opt/nginx.conf
gixy /opt/nginx.conf

Puoi eseguire un sottoinsieme mirato di controlli con --tests:

# Esegui solo questi controlli
gixy --tests http_splitting,ssrf,version_disclosure

Oppure saltare alcuni controlli rumorosi con --skips:

# Esegui tutto tranne questi controlli
gixy --skips low_keepalive_requests,worker_rlimit_nofile_vs_connections

Per segnalare solo problemi di una certa severità o superiore, usa il flag cumulativo -l:

# -l per problemi di severità LOW e superiore, -ll per MEDIUM e superiore, e -lll per soli problemi di severità HIGH
gixy -ll

Di default, l'output di gixy è colorato con ANSI; meglio visualizzarlo in un terminale compatibile. Puoi usare il flag --format (-f) con il valore text per ottenere un output non colorato:

$ gixy -f text

==================== Results ===================

Problem: [http_splitting] Possible HTTP-Splitting vulnerability.
Description: Using variables that can contain "\n" may lead to http injection.
Additional info: https://gixy.io/plugins/http_splitting/
Reason: At least variable "$action" can contain "\n"
Pseudo config:
include /etc/nginx/sites/default.conf;

	server {

		location ~ /v1/((?<action>[^.]*)\.json)?$ {
			add_header X-Action $action;
		}
	}


==================== Summary ===================
Total issues:
    Informational: 0
    Low: 0
    Medium: 0
    High: 1

Puoi anche usare -f json per ottenere un output JSON riproducibile e leggibile dalla macchina:

$ gixy -f json
[{"config":"\nserver {\n\n\tlocation ~ /v1/((?<action>[^.]*)\\.json)?$ {\n\t\tadd_header X-Action $action;\n\t}\n}","description":"Using variables that can contain \"\\n\" or \"\\r\" may lead to http injection.","file":"/etc/nginx/nginx.conf","line":4,"path":"/etc/nginx/nginx.conf","plugin":"http_splitting","reason":"At least variable \"$action\" can contain \"\\n\"","reference":"https://gixy.io/plugins/http_splitting/","severity":"HIGH","summary":"Possible HTTP-Splitting vulnerability."}]

Puoi anche usare -f sarif per ottenere un log SARIF 2.1.0, ad esempio per il caricamento su GitHub code scanning:

# Scrivi un report SARIF su un file, ad esempio per `github/codeql-action/upload-sarif`
gixy -f sarif -o gixy-results.sarif

Ulteriori flag per l'utilizzo possono essere trovati passando --help a gixy. Puoi anche trovare maggiori informazioni nella Guida all'utilizzo.

Configurazione e opzioni dei plugin

Alcuni plugin espongono opzioni che puoi impostare tramite flag CLI o un file di configurazione. Puoi leggere di più al riguardo nella Guida alla configurazione.

Gixy-Next per la sicurezza e la conformità di NGINX

A differenza dell'esecuzione di nginx -t che controlla solo la sintassi, Gixy-Next analizza effettivamente la tua configurazione e rileva istanze non protette e vulnerabilità.

Con Gixy-Next, puoi eseguire una revisione automatizzata della sicurezza della configurazione NGINX che può essere eseguita localmente ad ogni modifica, sia per audit, conformità o test generali, aiutando a produrre risultati attuabili che aiutano a prevenire server NGINX instabili/lenti e a ridurre il rischio derivante da direttive non sicure e default insicuri.

Contribuire

Gixy-Next è mantenuto da Joshua Rogers, ma i contributi sono sempre benvenuti! Puoi aiutarci in diversi modi, come:

• Segnalare bug.
• Suggerire nuovi plugin per il rilevamento.
• Migliorare la documentazione.
• Correggere, rifattorizzare, migliorare e scrivere nuovo codice.

Prima di inviare qualsiasi modifica in pull request, leggi il documento delle linee guida per i contributi, Contributing to Gixy-Next.

La homepage ufficiale di Gixy-Next è https://gixy.io/. Qualsiasi modifica alla documentazione in Gixy-Next si rifletterà automaticamente su quel sito web.

Il codice sorgente può essere trovato su https://github.com/MegaManSec/Gixy-Next.

Cos'è Gixy? (Background)

Gixy è un analizzatore di configurazione NGINX che è stato originariamente sviluppato da Andrew Krasichkov di Yandex. È stato rilasciato per la prima volta nel 2017 e da allora è diventato non mantenuto. Non supporta versioni moderne di Python, contiene numerosi bug ed è limitato nella sua funzionalità e capacità di rilevare configurazioni NGINX vulnerabili. Eseguire l'originale Gixy oggi su un sistema moderno comporterà il seguente errore:

  File "gixy/core/sre_parse/sre_parse.py", line 61, in <module>
    "t": SRE_FLAG_TEMPLATE,
         ^^^^^^^^^^^^^^^^^
NameError: name 'SRE_FLAG_TEMPLATE' is not defined. Did you mean: 'SRE_FLAG_VERBOSE'?

Gixy-Next, quindi, è un fork che aggiunge supporto per sistemi moderni, aggiunge nuovi controlli, miglioramenti delle prestazioni, suggerimenti di hardening e supporto per versioni moderne di Python e NGINX.

Perché non gixy-ng?

Gixy-Next è in realtà un fork di gixy-ng, che a sua volta era un fork dell'originale gixy. Gixy-Next è stato creato dopo che il maintainer di gixy-ng ha iniziato a produrre grandi quantità di modifiche assistite dall'IA e codice auto-generato che era sia irrivedibile per dimensioni che rotto.

Dopo qualche tempo, il maintainer di gixy-ng ha iniziato a committare modifiche generate dall'IA nel codebase che hanno introdotto ovvie regressioni, rotto il comportamento critico dello strumento (che chiunque usasse lo strumento avrebbe notato), aggiunto artefatti casuali di strumenti IA e introdotto codice che semplicemente non faceva ciò che doveva fare. Ancora più importante, il maintainer ha anche aggiunto marketing per la propria attività in tutta la documentazione, tutto l'output e tutto il codice sorgente di gixy-ng.

In altre parole, il maintainer di gixy-ng ha preso l'originale gixy, ha chiesto all'IA di apportare modifiche, ha introdotto un sacco di bug (e altro slop dell'IA), e poi ha aggiunto pubblicità al codice. Ha anche accettato contributi sotto forma di merge request, ma ha rimosso le informazioni dell'autore (vedi questo post e questo post).

Gixy-Next si concentra sul ripristino della qualità ed è stato testato sul campo su configurazioni NGINX lunghe quasi 100.000 righe. Corregge bug e rilevamenti errati introdotti dalle modifiche apportate in gixy-ng, rimuove artefatti/immondizia degli strumenti IA e cerca di mantenere il codebase revisionabile e manutenibile. Questo fork è per coloro che sono interessati a codice pulito e manutenibilità a lungo termine.