Gixy-Next v0.7.1
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 응답 분할
- [if_is_evil] location 컨텍스트에서 사용될 때 if는 악마
- [invalid_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경로 정규화 문제 - [proxy_set_header_redefinition] "proxy_set_header" 지시문에 의한 프록시 요청 헤더 재정의
- [quic_bpf_reuseport] 리로드 후 QUIC 연결이 조용히 끊김
- [regex_redos] 정규식 서비스 거부 (ReDoS)
- [resolver_external] 외부 DNS 네임서버 사용
- [return_bypasses_allow_deny] return 지시문이 allow/deny 제한을 우회함
- [ssl_ecdh_curve] 포스트 양자 그룹이 구형 OpenSSL에서 NGINX 시작을 막음
- [ssl_stapling_letsencrypt] Let's Encrypt 인증서에 대해 OCSP 스테이플링이 아무 효과 없음
- [ssl_stapling_without_resolver] resolver 없이 OCSP 스테이플링이 조용히 실패함
- [ssrf] 서버 측 요청 위조
- [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에 이슈를 열어주세요!
사용법 (플래그)
gixy는 기본적으로 시스템의 NGINX 구성을 /etc/nginx/nginx.conf에서 읽습니다. 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 색상이 적용되며, 호환되는 터미널에서 가장 잘 보입니다. --format (-f) 플래그에 text 값을 사용하면 색상 없는 출력을 얻을 수 있습니다:
$ 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
-f json을 사용하면 재현 가능한 기계 판독 가능 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."}]
-f sarif를 사용하면 SARIF 2.1.0 로그를 얻을 수도 있습니다. 예를 들어 GitHub 코드 스캐닝에 업로드할 수 있습니다:
# 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가 유지보수하고 있지만, 기여는 언제나 환영합니다! 다음과 같은 다양한 방법으로 도움을 줄 수 있습니다:
- 버그 보고.
- 탐지를 위한 새 플러그인 제안.
- 문서 개선.
- 코드 수정, 리팩터링, 개선 및 새로운 코드 작성.
풀 리퀘스트로 변경 사항을 제출하기 전에 기여 가이드 문서인 Contributing to Gixy-Next를 읽어주세요.
Gixy-Next의 공식 홈페이지는 https://gixy.io/입니다. Gixy-Next의 문서 변경 사항은 해당 웹사이트에 자동으로 반영됩니다.
소스 코드는 https://github.com/MegaManSec/Gixy-Next에서 확인할 수 있습니다.
Gixy란 무엇인가? (배경)
_Gixy_는 Yandex의 Andrew Krasichkov가 원래 개발한 NGINX 구성 분석기입니다. 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-ng 자체는 원래 gixy의 포크였습니다. Gixy-Next는 gixy-ng의 유지보수자가 검토하기 어려울 정도로 방대하고 망가진 AI 지원 변경 사항과 자동 생성 코드를 대량으로 만들어내기 시작한 후에 만들어졌습니다.
얼마 후, gixy-ng의 유지보수자는 명백한 회귀를 도입하고, 도구의 핵심 동작을 망가뜨리고(도구를 사용하는 사람이라면 누구나 알아차렸을 문제), 무작위 AI 도구 아티팩트를 추가하고, 단순히 해야 할 일을 하지 않는 코드를 도입한 AI 생성 변경 사항을 코드베이스에 커밋하기 시작했습니다. 가장 중요한 것은, 유지보수자가 gixy-ng의 모든 문서, 모든 출력, 모든 소스 코드에 자신의 비즈니스 마케팅을 추가했다는 점입니다.
다시 말해, gixy-ng 유지보수자는 원래 gixy를 가져다가 AI에게 변경을 요청하고, 여러 버그(및 기타 AI 쓰레기)를 도입한 다음, 코드에 광고를 추가했습니다. 또한 머지 리퀘스트 형태의 기여를 받아들이면서도 작성자의 정보를 삭제했습니다(이 글과 이 글 참조).
Gixy-Next는 품질 회복에 중점을 두고 있으며, 거의 100,000줄에 달하는 NGINX 구성에서 실전 검증되었습니다. gixy-ng에서 도입된 변경으로 인한 버그와 오탐을 수정하고, AI 도구 아티팩트/쓰레기를 제거하며, 코드베이스를 검토 가능하고 유지보수 가능하게 유지하려고 노력합니다. 이 포크는 깔끔한 코드와 장기적인 유지보수성에 관심이 있는 사람들을 위한 것입니다.