
Gixy-Next : Scanner de sécurité de configuration NGINX et vérificateur de performances
Gixy-Next (Gixy) est un scanner de sécurité et un outil de durcissement de configuration NGINX open source qui analyse statiquement votre nginx.conf pour détecter les erreurs de configuration de sécurité, les lacunes de durcissement et les pièges de performance courants avant qu'ils n'atteignent la production. Il s'agit d'un fork activement maintenu du Gixy de Yandex. Le code source de Gixy-Next est disponible sur GitHub.
Gixy-Next peut également être exécuté dans le navigateur sur cette page. Aucun téléchargement n'est nécessaire ; vous pouvez analyser vos configurations sur le site Web (localement, à l'aide de WebAssembly).
Gixy-Next (l'interface CLI gixy ou gixy-next) est distribué sur PyPI. Vous pouvez l'installer avec pip ou uv :
# pip
pip3 install gixy-next
# uv
uv pip install gixy-next
Vous pouvez ensuite l'exécuter :
# gixy defaults to reading /etc/nginx/nginx.conf
gixy
# But you can also specify a path to the configuration
gixy /opt/nginx.conf
Vous pouvez également exporter votre configuration NGINX vers un fichier dump unique (voir nginx -T Vidage de configuration en direct) :
# 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 -
Au lieu de télécharger et d'exécuter Gixy-Next localement, vous pouvez utiliser cette page Web et analyser une configuration depuis votre navigateur Web (localement, à l'aide de WebAssembly).
Gixy-Next est disponible en tant qu'image Docker sur Docker Hub ou GitHub Registry.
Analyser un fichier de configuration local en le montant dans le conteneur :
# 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
Analyser un vidage de configuration NGINX en direct :
# 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
Analyser depuis 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 -
Gixy-Next peut détecter un large éventail d'erreurs de configuration de sécurité et de performances NGINX dans nginx.conf et les fichiers de configuration inclus. Les plugins suivants sont pris en charge :
error_log défini sur offkeepalive_requests faibleQuelque chose n'est pas détecté ? Veuillez ouvrir une issue sur GitHub pour signaler ce qui manque !
Par défaut, gixy lit la configuration NGINX d'un système à partir de /etc/nginx/nginx.conf. Vous pouvez également spécifier l'emplacement en le passant à gixy :
# Analyze the configuration in /opt/nginx.conf
gixy /opt/nginx.conf
Vous pouvez exécuter un sous-ensemble ciblé de vérifications avec --tests :
# Only run these checks
gixy --tests http_splitting,ssrf,version_disclosure
Ou ignorer quelques vérifications bruyantes avec --skips :
# Run everything except these checks
gixy --skips low_keepalive_requests,worker_rlimit_nofile_vs_connections
Pour ne signaler que les problèmes d'une certaine gravité ou plus, utilisez l'option -l cumulable :
# -l for LOW severity issues and higher, -ll for MEDIUM and higher, and -lll for only HIGH severity issues
gixy -ll
Par défaut, la sortie de gixy est colorée en ANSI ; il est préférable de la consulter dans un terminal compatible. Vous pouvez utiliser l'option --format (-f) avec la valeur text pour obtenir une sortie sans couleur :
$ 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
Vous pouvez également utiliser -f json pour obtenir une sortie JSON reproductible et lisible par machine :
$ 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."}]
Vous pouvez également utiliser -f sarif pour obtenir un journal SARIF 2.1.0, par exemple pour l'envoyer à l'analyse de code GitHub :
# Write a SARIF report to a file, e.g. for `github/codeql-action/upload-sarif`
gixy -f sarif -o gixy-results.sarif
Vous pouvez découvrir d'autres options d'utilisation en passant --help à gixy. Vous trouverez également plus d'informations dans le Guide d'utilisation.
Certains plugins exposent des options que vous pouvez définir via des options CLI ou un fichier de configuration. Vous pouvez en savoir plus à ce sujet dans le Guide de configuration.
Contrairement à l'exécution de nginx -t, qui ne vérifie que la syntaxe, Gixy-Next analyse réellement votre configuration et détecte les instances non durcies et les vulnérabilités.
Avec Gixy-Next, vous pouvez effectuer un examen automatisé de la sécurité de la configuration NGINX qui peut s'exécuter localement à chaque modification, que ce soit pour l'audit, la conformité ou les tests généraux, contribuant ainsi à produire des résultats exploitables qui aident à prévenir les serveurs NGINX instables ou lents et à réduire les risques liés aux directives dangereuses et aux paramètres par défaut non sécurisés.
Gixy-Next est maintenu par Joshua Rogers, mais les contributions sont toujours les bienvenues ! Vous pouvez nous aider de différentes manières, par exemple :
Avant de soumettre des modifications dans des pull requests, veuillez lire le document de directives de contribution, Contribuer à Gixy-Next.
La page d'accueil officielle de Gixy-Next est https://gixy.io/. Toute modification de la documentation de Gixy-Next sera automatiquement reflétée sur ce site Web.
Le code source se trouve à l'adresse https://github.com/MegaManSec/Gixy-Next.
Gixy est un analyseur de configuration NGINX qui a été à l'origine développé par Andrew Krasichkov de Yandex. Il a été publié pour la première fois en 2017 et n'est plus maintenu depuis. Il ne prend pas en charge les versions modernes de Python, contient de nombreux bogues et est limité dans ses fonctionnalités et sa capacité à détecter les configurations NGINX vulnérables. Exécuter le Gixy original aujourd'hui sur un système moderne entraînera l'erreur suivante :
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 est donc un fork qui ajoute la prise en charge des systèmes modernes, de nouvelles vérifications, des améliorations de performances, des suggestions de durcissement et la prise en charge des versions modernes de Python et de NGINX.
gixy-ng ?Gixy-Next est en réalité un fork de gixy-ng, qui était lui-même un fork du gixy original. Gixy-Next a été créé après que le mainteneur de gixy-ng a commencé à produire de grandes quantités de modifications assistées par IA et de code auto-généré, à la fois trop volumineux pour être examiné et cassé.
Après un certain temps, le mainteneur de gixy-ng a commencé à soumettre des modifications générées par IA dans la base de code, qui ont introduit des régressions évidentes, cassé le comportement critique de l'outil (ce que tout utilisateur de l'outil aurait remarqué), ajouté des artefacts aléatoires d'outillage IA et introduit du code qui ne faisait tout simplement pas ce qu'il était censé faire. Plus important encore, le mainteneur a également ajouté de la publicité pour son entreprise à toute la documentation, toutes les sorties et tout le code source de gixy-ng.
En d'autres termes, le mainteneur de gixy-ng a pris le gixy original, a demandé à l'IA d'apporter des modifications, a introduit un tas de bogues (et d'autres déchets d'IA), puis a ajouté de la publicité au code. Il a également accepté des contributions sous forme de merge requests, mais a supprimé les informations des auteurs (voir cet article et cet article).
Gixy-Next se concentre sur la restauration de la qualité et a été éprouvé sur des configurations NGINX de près de 100 000 lignes. Il corrige les bogues et les erreurs de détection introduits par les modifications apportées dans gixy-ng, supprime les artefacts/déchets d'outillage IA et s'efforce de garder la base de code examinable et maintenable. Ce fork est destiné à ceux qui s'intéressent à un code propre et à une maintenabilité à long terme.