소스 정보
- 저장소
- CyberStrikeus/CyberStrike
- 최근 소스 활동
- 2026년 4월 22일 14:54
- 감지된 SKILL.md 언어
- 영어
- 스타
- 1,653
- 포크
- 254
설치 방법
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
소스 파일 검토
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
메뉴
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/CyberStrikeus/CyberStrike --skill cis-nginx-v300-5-1-2명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
macOS post-exploitation for credential harvesting, DTrace monitoring, TCC bypass, and stealth operations via native tools
Windows userland post-exploitation for credential harvesting, monitoring, AMSI/ETW bypass, and stealth operations
Kubernetes post-exploitation for container escape, secret extraction, RBAC abuse, and cluster persistence
SOC 직업 분류 기준
SKILL.md 표시 중
| name | cis-nginx-v300-5-1-2 |
| description | Ensure only approved HTTP methods are allowed (Manual) |
| category | cis-nginx |
| version | 3.0 |
| author | cyberstrike-official |
| tags | ["cis","nginx","web-server","reverse-proxy","access-control","request-filtering"] |
| cis_id | 5.1.2 |
| cis_benchmark | CIS NGINX Benchmark v3.0.0 |
| tech_stack | ["nginx","linux","web-server"] |
| cwe_ids | [] |
| chains_with | [] |
| prerequisites | [] |
| severity_boost | {} |
Following the principle of least functionality, an NGINX server should be configured to reject any HTTP methods that are not explicitly required by the application. While standard web browsing typically only needs GET, POST, and HEAD, modern RESTful APIs might require methods like PUT, PATCH, or DELETE. Any method not essential for the application's functionality should be blocked at the web server level.
Disabling unused HTTP methods mitigates the risk of unintended server interaction and can prevent certain classes of web application attacks. For example, if an attacker finds a way to bypass application-layer authentication, an enabled but unused PUT or DELETE method on the web server could potentially lead to unauthorized file modification or deletion. By explicitly denying such methods, NGINX ensures that requests never even reach the backend application and therefore significantly reducing the attack surface.
An overly restrictive filter can block legitimate application functionality. Before implementing these restrictions, it is crucial to coordinate with application developers to get a definitive list of all required HTTP methods for every application endpoint. Incorrectly blocking a required method (e.g., PUT for a file upload feature) will cause parts of the application to fail.
1. Configuration Inspection:
Run the following command to analyze the fully loaded NGINX configuration for any method-limiting directives:
nginx -T 2>/dev/null | grep -E '(\$request_method|limit_except)'
Review the configuration to ensure that either a limit_except block or an if ($request_method) block is correctly implemented for the relevant location.
2. Active Testing:
Send a request with a non-approved method (e.g., OPTIONS or DELETE) using curl and verify that the server responds with the correct status code, not a 200 OK or 404 Not Found.
curl -X OPTIONS -I https://example.loc/api.html
Expected Output: The server should return either HTTP/1.1 405 Not Allowed or HTTP/1.1 444 Connection Closed Without Response. Any other 2xx or 4xx code indicates a potential misconfiguration.
There are two recommended methods to restrict HTTP verbs.
Method 1 (Preferred): Using limit_except This directive is designed for this purpose and is considered the cleanest approach. It restricts all methods except for the ones listed.
location /api_login/ {
# Only allow GET, HEAD, and POST methods for this location.
limit_except GET HEAD POST {
deny all;
}
# ... other directives ...
}
Method 2 (Alternative): Using an if condition This method offers more flexibility, such as returning a non-standard status code like 444, which simply closes the connection without sending a response header.
location / {
# If the request method is NOT one of GET, HEAD, or POST
if ($request_method !~ ^(GET|HEAD|POST)$) {
# --> close the connection immediately.
return 444;
}
# ... other directives ...
}
All methods are allowed.
| Controls Version | Control | IG 1 | IG 2 | IG 3 |
|---|---|---|---|---|
| v8 | 16.10 Apply Secure Design Principles in Application Architectures | N | Y | Y |
| v7 | 9.2 Ensure Only Approved Ports, Protocols and Services Are Running | N | Y | Y |
| Tactic | Technique |
|---|---|
| Initial Access | T1190 - Exploit Public-Facing Application |
| Execution | T1059 - Command and Scripting Interpreter |