
Gixy-Next v0.6.0
Gixy-Next: NGINX कॉन्फ़िगरेशन सुरक्षा स्कैनर और प्रदर्शन जाँचकर्ता
Gixy-Next: सुरक्षा ऑडिट के लिए NGINX कॉन्फ़िगरेशन सुरक्षा स्कैनर
अवलोकन
Gixy-Next (Gixy) एक ओपन-सोर्स NGINX कॉन्फ़िगरेशन सुरक्षा स्कैनर और हार्डनिंग टूल है जो आपके nginx.conf का स्थिर विश्लेषण करता है ताकि सुरक्षा गलत कॉन्फ़िगरेशन, हार्डनिंग अंतराल, और सामान्य प्रदर्शन समस्याओं को प्रोडक्शन में पहुँचने से पहले पहचान सके। यह Yandex के Gixy का एक सक्रिय रूप से अनुरक्षित फ़ोर्क है। Gixy-Next का सोर्स कोड GitHub पर उपलब्ध है।
Gixy-Next को इस पृष्ठ पर ब्राउज़र में भी चलाया जा सकता है। किसी डाउनलोड की आवश्यकता नहीं है; आप वेबसाइट पर अपने कॉन्फ़िगरेशन स्कैन कर सकते हैं (स्थानीय रूप से, WebAssembly का उपयोग करके)।
त्वरित आरंभ
Gixy-Next (gixy या gixy-next CLI) PyPI पर वितरित किया जाता है। आप इसे pip या uv के साथ स्थापित कर सकते हैं:
# pip
pip3 install gixy-next
# uv
uv pip install gixy-next
फिर आप इसे चला सकते हैं:
# gixy defaults to reading /etc/nginx/nginx.conf
gixy
# But you can also specify a path to the configuration
gixy /opt/nginx.conf
आप अपने NGINX कॉन्फ़िगरेशन को एकल डंप फ़ाइल में भी निर्यात कर सकते हैं (देखें nginx -T लाइव कॉन्फ़िगरेशन डंप):
# 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 -
वेब-आधारित स्कैनर
Gixy-Next को स्थानीय रूप से डाउनलोड करके चलाने के बजाय, आप इस वेबपेज का उपयोग कर सकते हैं और अपने वेब ब्राउज़र से एक कॉन्फ़िगरेशन स्कैन कर सकते हैं (स्थानीय रूप से, WebAssembly का उपयोग करके)।
Docker के साथ स्कैन करें
Gixy-Next Docker Hub या GitHub Registry से Docker इमेज के रूप में उपलब्ध है।
किसी स्थानीय कॉन्फ़िग फ़ाइल को कंटेनर में माउंट करके स्कैन करें:
# 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
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
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 nginx.conf और शामिल कॉन्फ़िगरेशन फ़ाइलों में NGINX सुरक्षा और प्रदर्शन से संबंधित गलत कॉन्फ़िगरेशन की एक विस्तृत श्रृंखला का पता लगा सकता है। निम्नलिखित प्लगइन्स समर्थित हैं:
- [add_header_content_type] add_header के माध्यम से Content-Type सेट करना
- [add_header_multiline] बहु-पंक्ति प्रतिक्रिया हेडर
- [add_header_redefinition] "add_header" निर्देश द्वारा प्रतिक्रिया हेडर की पुनर्परिभाषा
- [alias_traversal] गलत कॉन्फ़िगर किए गए alias के माध्यम से पथ ट्रैवर्सल
- [allow_without_deny] deny के बिना allow निर्दिष्ट करना
- [default_server_flag] default_server फ़्लैग का अभाव
- [error_log_off]
error_logकोoffपर सेट करना - [hash_without_default] hash ब्लॉक में default का अभाव
- [host_spoofing] अनुरोध के Host हेडर की जालसाज़ी
- [http2_misdirected_request] HTTP/2 misdirected-request सुरक्षा उपाय का अभाव
- [http_splitting] HTTP प्रतिक्रिया विभाजन (Response Splitting)
- [if_is_evil] location संदर्भ में उपयोग किए जाने पर if हानिकारक है
- [invalid_regex] अमान्य regex कैप्चर समूह
- [low_keepalive_requests] कम
keepalive_requests - [missing_worker_processes]
worker_processesका अभाव - [mixed_case_variable] मिश्रित-केस चर संदर्भ
- [origins] referer/origin हेडर सत्यापन में समस्याएँ
- [overlapping_captures] rewrite redirect/args संदर्भ में अतिव्यापी कैप्चर
- [proxy_buffering_off]
proxy_bufferingको अक्षम करना - [proxy_pass_normalized]
proxy_passपथ सामान्यीकरण समस्याएँ - [quic_bpf_reuseport] reload के बाद QUIC कनेक्शन चुपचाप छोड़ दिए जाते हैं
- [regex_redos] रेगुलर एक्सप्रेशन सेवा-अस्वीकरण (ReDoS)
- [resolver_external] बाहरी DNS नेमसर्वर का उपयोग करना
- [return_bypasses_allow_deny] Return निर्देश allow/deny प्रतिबंधों को दरकिनार करता है
- [ssl_stapling_without_resolver] resolver के बिना OCSP stapling चुपचाप विफल हो जाता है
- [ssrf] सर्वर साइड रिक्वेस्ट फोर्जरी (Server Side Request Forgery)
- [stale_dns_cache] proxy_pass में उपयोग किए गए पुराने/अप्रचलित कैश्ड DNS रिकॉर्ड
- [status_page_exposed] यह सुनिश्चित करता है कि status_page सार्वजनिक रूप से उजागर न हो
- [try_files_is_evil_too] open_file_cache के बिना
try_filesनिर्देश हानिकारक है - [unanchored_regex] अनएंकर रेगुलर एक्सप्रेशन
- [unnamed_groups] rewrite क्वेरी स्ट्रिंग में अनाम कैप्चर समूह
- [valid_referers] valid_referers में none/blocked
- [version_disclosure] server_tokens के लिए असुरक्षित मानों का उपयोग
- [worker_rlimit_nofile_vs_connections]
worker_rlimit_nofileकम से कमworker_connectionsका दोगुना होना चाहिए
कुछ पता नहीं चला? कृपया GitHub पर issue खोलें और बताएँ कि क्या कमी है!
उपयोग (फ़्लैग्स)
gixy डिफ़ॉल्ट रूप से /etc/nginx/nginx.conf से सिस्टम का NGINX कॉन्फ़िगरेशन पढ़ता है। आप इसे gixy को पास करके स्थान भी निर्दिष्ट कर सकते हैं:
# Analyze the configuration in /opt/nginx.conf
gixy /opt/nginx.conf
आप --tests के साथ चेकों का एक केंद्रित उपसमुच्चय चला सकते हैं:
# Only run these checks
gixy --tests http_splitting,ssrf,version_disclosure
या --skips के साथ कुछ शोर-भरे चेकों को छोड़ें:
# Run everything except these checks
gixy --skips low_keepalive_requests,worker_rlimit_nofile_vs_connections
केवल एक निश्चित गंभीरता या उससे अधिक की समस्याओं की रिपोर्ट करने के लिए, संयोजन -l फ़्लैग का उपयोग करें:
# -l for LOW severity issues and higher, -ll for MEDIUM and higher, and -lll for only HIGH severity issues
gixy -ll
डिफ़ॉल्ट रूप से, gixy का आउटपुट ANSI-रंगीन होता है; इसे संगत टर्मिनल में देखना सर्वोत्तम है। बिना रंग वाला आउटपुट पाने के लिए आप text मान के साथ --format (-f) फ़्लैग का उपयोग कर सकते हैं:
$ 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
आप एक प्रतिलिपि-योग्य, मशीन-पठनीय JSON आउटपुट पाने के लिए भी -f json का उपयोग कर सकते हैं:
$ 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."}]
आप GitHub कोड स्कैनिंग में अपलोड करने के लिए, उदाहरण के लिए, SARIF 2.1.0 लॉग प्राप्त करने हेतु भी -f sarif का उपयोग कर सकते हैं:
# Write a SARIF report to a file, e.g. for `github/codeql-action/upload-sarif`
gixy -f sarif -o gixy-results.sarif
उपयोग के लिए अधिक फ़्लैग gixy को --help पास करके देखे जा सकते हैं। आप उपयोग गाइड में भी अधिक जानकारी पा सकते हैं।
कॉन्फ़िगरेशन और प्लगइन विकल्प
कुछ प्लगइन्स ऐसे विकल्प प्रदान करते हैं जिन्हें आप CLI फ़्लैग्स या कॉन्फ़िगरेशन फ़ाइल के माध्यम से सेट कर सकते हैं। आप कॉन्फ़िगरेशन गाइड में उनके बारे में अधिक पढ़ सकते हैं।
NGINX सुरक्षा और अनुपालन के लिए Gixy-Next
nginx -t चलाने के विपरीत, जो केवल सिंटैक्स की जाँच करता है, Gixy-Next वास्तव में आपके कॉन्फ़िगरेशन का विश्लेषण करता है और बिना हार्डनिंग वाले उदाहरणों और कमजोरियों का पता लगाता है।
Gixy-Next के साथ, आप एक स्वचालित NGINX कॉन्फ़िगरेशन सुरक्षा समीक्षा कर सकते हैं जो प्रत्येक बदलाव पर स्थानीय रूप से चल सकती है, चाहे वह ऑडिटिंग, अनुपालन, या सामान्य परीक्षण के लिए हो, जिससे कार्रवाई-योग्य निष्कर्ष प्राप्त करने में मदद मिलती है जो अस्थिर/धीमे NGINX सर्वरों को रोकने और असुरक्षित निर्देशों तथा असुरक्षित डिफ़ॉल्टों से जोखिम कम करने में सहायता करते हैं।
योगदान
Gixy-Next का अनुरक्षण Joshua Rogers द्वारा किया जाता है, लेकिन योगदान का हमेशा स्वागत है! आप हमारी विभिन्न तरीकों से मदद कर सकते हैं, जैसे:
- बगों की रिपोर्ट करना।
- पहचान के लिए नए प्लगइन्स सुझाना।
- दस्तावेज़ीकरण में सुधार करना।
- बग ठीक करना, रीफैक्टर करना, सुधार करना और नया कोड लिखना।
पुल रिक्वेस्ट में कोई भी बदलाव जमा करने से पहले, कृपया योगदान दिशानिर्देश दस्तावेज़, Gixy-Next में योगदान पढ़ें।
Gixy-Next का आधिकारिक होमपेज https://gixy.io/ है। Gixy-Next के दस्तावेज़ीकरण में किए गए कोई भी बदलाव स्वचालित रूप से उस वेबसाइट पर प्रतिबिंबित होंगे।
सोर्स कोड https://github.com/MegaManSec/Gixy-Next पर पाया जा सकता है।
Gixy क्या है? (पृष्ठभूमि)
Gixy एक NGINX कॉन्फ़िगरेशन विश्लेषक है जिसे मूल रूप से Yandex के Andrew Krasichkov द्वारा विकसित किया गया था। इसे पहली बार 2017 में जारी किया गया था और तब से यह अनुरक्षण-रहित हो गया है। यह Python के आधुनिक संस्करणों का समर्थन नहीं करता, इसमें कई बग हैं, और इसकी कार्यक्षमता तथा कमजोर NGINX कॉन्फ़िगरेशन का पता लगाने की क्षमता सीमित है। आधुनिक सिस्टम पर आज मूल Gixy चलाने पर निम्नलिखित त्रुटि उत्पन्न होगी:
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 एक फ़ोर्क है जो आधुनिक सिस्टमों के लिए समर्थन, नई जाँचें, प्रदर्शन सुधार, हार्डनिंग सुझाव, और आधुनिक Python तथा NGINX संस्करणों के लिए समर्थन जोड़ता है।
gixy-ng क्यों नहीं?
Gixy-Next वास्तव में gixy-ng का एक फ़ोर्क है, जो स्वयं मूल gixy का एक फ़ोर्क था। Gixy-Next उस समय बनाया गया था जब gixy-ng के अनुरक्षक ने बड़ी मात्रा में AI-सहायता प्राप्त परिवर्तन और स्वतः-जनित कोड बनाना शुरू कर दिया था जो समीक्षा-अयोग्य रूप से बड़े और साथ ही टूटे हुए थे।
कुछ समय बाद, gixy-ng के अनुरक्षक ने कोडबेस में AI-जनित परिवर्तन कमिट करने शुरू कर दिए, जिन्होंने स्पष्ट प्रतिगमन (regressions) पेश किए, टूल के महत्वपूर्ण व्यवहार को तोड़ दिया (जिसे टूल का उपयोग करने वाला कोई भी व्यक्ति पकड़ लेता), यादृच्छिक AI-टूलिंग कलाकृतियाँ जोड़ीं, और ऐसा कोड पेश किया जो बस वह नहीं करता था जो उसे करना चाहिए था। सबसे महत्वपूर्ण बात, अनुरक्षक ने gixy-ng के सभी दस्तावेज़ों, सभी आउटपुट, और सभी सोर्स कोड में अपने व्यवसाय के लिए मार्केटिंग भी जोड़ दी।
दूसरे शब्दों में, gixy-ng अनुरक्षक ने मूल gixy को लिया, AI से परिवर्तन करवाए, ढेर सारे बग (और अन्य AI कूड़ा-करकट) पेश किए, और फिर कोड में विज्ञापन जोड़ दिया। उन्होंने मर्ज रिक्वेस्ट के रूप में योगदान भी स्वीकार किए, लेकिन लेखक की जानकारी हटा दी (देखें यह पोस्ट और यह पोस्ट)।
Gixy-Next गुणवत्ता बहाल करने पर केंद्रित है, और लगभग 100,000-पंक्ति-लंबे NGINX कॉन्फ़िगरेशनों पर युद्ध-परीक्षणित किया गया है। यह gixy-ng में पेश किए गए परिवर्तनों से उत्पन्न बगों और गलत पहचान को ठीक करता है, AI टूल कलाकृतियों/कचरे को हटाता है, और कोडबेस को समीक्षा-योग्य और अनुरक्षण-योग्य बनाए रखने का प्रयास करता है। यह फ़ोर्क उन लोगों के लिए है जो स्वच्छ कोड और दीर्घकालिक अनुरक्षण-क्षमता में रुचि रखते हैं।
