Gixy-Next: scanner di sicurezza per configurazioni NGINX per audit di sicurezza

Panoramica

Gixy-Next (Gixy) è uno scanner di sicurezza open-source per la configurazione NGINX e uno strumento di hardening che analizza staticamente il tuo nginx.conf per rilevare configurazioni errate di sicurezza, lacune di hardening e comuni insidie prestazionali prima che raggiungano la produzione. È un fork attivamente mantenuto del 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, usando 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 defaults to reading /etc/nginx/nginx.conf
gixy
# But you can also specify a path to the configuration
gixy /opt/nginx.conf

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

# Dumps the full NGINX configuration into a single file (including all includes)
nginx -T > ./nginx-dump.conf
# Scan the dump elsewhere (or via stdin):
gixy ./nginx-dump.conf
# or
cat ./nginx-dump.conf | gixy -

Scanner basato sul web

Invece di scaricare ed eseguire Gixy-Next in locale, puoi usare questa pagina web e scansionare una configurazione dal tuo browser web (localmente, usando 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:

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

Scansiona un dump di configurazione live di NGINX:

# Dumps the full NGINX configuration into a single file (including all includes)
nginx -T > ./nginx-dump.conf
# Use Github Registry
docker run --pull=always --rm -v "$PWD/nginx-dump.conf:/nginx-dump.conf:ro" ghcr.io/megamansec/gixy-next /nginx-dump.conf
# Or 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:

# Use Github Registry
nginx -T | docker run --pull=always --rm -i ghcr.io/megamansec/gixy-next gixy-next -
# Or 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 configurazioni errate di NGINX relative a sicurezza e prestazioni in nginx.conf e nei file di configurazione inclusi. Sono supportati i seguenti plugin:

• [add_header_content_type] Impostazione di Content-Type tramite add_header
• [add_header_multiline] Intestazioni di risposta su più righe
• [add_header_redefinition] Ridefinizione delle intestazioni di risposta tramite la direttiva "add_header"
• [alias_traversal] Path traversal tramite alias configurato male
• [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] Salvaguardia mancante per le richieste HTTP/2 misdirected-request
• [http_splitting] HTTP Response Splitting
• [if_is_evil] La direttiva if è dannosa se usata nel contesto location
• [invalid_regex] Gruppi di cattura regex non validi
• [low_keepalive_requests] Valore basso di keepalive_requests
• [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 rewrite redirect/args
• [proxy_buffering_off] Disabilitazione di proxy_buffering
• [proxy_pass_normalized] Problemi di normalizzazione del percorso in proxy_pass
• [quic_bpf_reuseport] Connessioni QUIC eliminate silenziosamente dopo il reload
• [regex_redos] Denial of service tramite espressioni regolari (ReDoS)
• [resolver_external] Utilizzo di nameserver DNS esterni
• [return_bypasses_allow_deny] La direttiva Return bypassa le restrizioni allow/deny
• [ssl_stapling_without_resolver] OCSP stapling fallisce silenziosamente senza un resolver
• [ssrf] Server Side Request Forgery
• [stale_dns_cache] Record DNS nella cache obsoleti/vecchi usati in proxy_pass
• [status_page_exposed] Garantisce che status_page non sia esposta al mondo
• [try_files_is_evil_too] La direttiva try_files è dannosa 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] Utilizzo 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 viene rilevato? Apri una issue su GitHub con ciò che manca!

Utilizzo (flag)

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

# Analyze the configuration in /opt/nginx.conf
gixy /opt/nginx.conf

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

# Only run these checks
gixy --tests http_splitting,ssrf,version_disclosure

Oppure saltare alcuni controlli rumorosi con --skips:

# Run everything except these checks
gixy --skips low_keepalive_requests,worker_rlimit_nofile_vs_connections

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

# -l for LOW severity issues and higher, -ll for MEDIUM and higher, and -lll for only HIGH severity issues
gixy -ll

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

$ 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 caricarlo su GitHub code scanning:

# Write a SARIF report to a file, e.g. for `github/codeql-action/upload-sarif`
gixy -f sarif -o gixy-results.sarif

Puoi trovare ulteriori flag di utilizzo passando --help a gixy. Puoi anche trovare maggiori informazioni nella Guida all'utilizzo.

Opzioni di configurazione e dei plugin

Alcuni plugin espongono opzioni che puoi impostare tramite flag CLI o un file di configurazione. Puoi leggere ulteriori informazioni nella Guida alla configurazione.

Gixy-Next per la sicurezza e la conformità NGINX

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

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

Contribuire

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

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

Prima di inviare modifiche tramite pull request, leggi il documento sulle linee guida per i contributi, Contribuire a Gixy-Next.

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

Il codice sorgente è disponibile su https://github.com/MegaManSec/Gixy-Next.

Cos'è Gixy? (Contesto)

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 non è più stato mantenuto. Non supporta le versioni moderne di Python, contiene numerosi bug e ha funzionalità e capacità limitate nel rilevare configurazioni NGINX vulnerabili. Eseguire oggi il Gixy originale su un sistema moderno produrrà 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 il supporto per i sistemi moderni, nuovi controlli, miglioramenti delle prestazioni, suggerimenti di hardening e supporto per le 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 del gixy originale. 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 troppo grande per essere revisionato sia rotto.

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

In altre parole, il maintainer di gixy-ng ha preso il gixy originale, ha chiesto all'IA di apportare modifiche, ha introdotto una serie di bug (e altra spazzatura IA) e poi ha aggiunto pubblicità al codice. Ha anche accettato contributi sotto forma di merge request, ma ha rimosso le informazioni sugli autori (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 falsi rilevamenti introdotti dalle modifiche apportate in gixy-ng, rimuove artefatti/spazzatura degli strumenti IA e cerca di mantenere il codebase revisionabile e manutenibile. Questo fork è per chi è interessato a codice pulito e manutenibilità a lungo termine.