저는 Ubuntu 20.04 LEMP(Linux, Nginx, MariaDb, PHP) 웹 서버를 실행하고 있습니다. 또한 MacOS 클라이언트 시스템에서 일부 nmap 취약성 테스트를 수행하고 있습니다. MacOS에서는 다음을 사용하고 있습니다.오 마이 Zsh!플러그인이 활성화된 상태에서 nmap. MacOS 클라이언트 시스템에서 Ubuntu Server에 대한 일부 취약점 테스트를 수행하기 위해 다음 명령을 실행했습니다.
nmap_check_for_vulns my.server.ip.address
이는 에 대한 별칭 명령입니다.
nmap --script=vuln
내 서버의 IP 주소로 명령을 실행한 후 nmap은 다음을 보고했습니다.
| http-vuln-cve2011-3192:
| VULNERABLE:
| Apache byterange filter DoS
| State: VULNERABLE
| IDs: CVE:CVE-2011-3192 BID:49303
| The Apache web server is vulnerable to a denial of service attack when numerous
| overlapping byte ranges are requested.
| Disclosure date: 2011-08-19
| References:
| https://www.tenable.com/plugins/nessus/55976
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3192
| https://www.securityfocus.com/bid/49303
|_ https://seclists.org/fulldisclosure/2011/Aug/175
Ubuntu Server에서 출력은 다음과 ss -lnpt같습니다.
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 100 0.0.0.0:25 0.0.0.0:*
LISTEN 0 511 0.0.0.0:443 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:8125 0.0.0.0:*
LISTEN 0 100 0.0.0.0:4190 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:19999 0.0.0.0:*
LISTEN 0 100 0.0.0.0:993 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:10023 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:10024 0.0.0.0:*
LISTEN 0 100 127.0.0.1:10025 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:10026 0.0.0.0:*
LISTEN 0 80 127.0.0.1:3306 0.0.0.0:*
LISTEN 0 100 0.0.0.0:587 0.0.0.0:*
LISTEN 0 128 0.0.0.0:43211 0.0.0.0:*
LISTEN 0 511 127.0.0.1:6379 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:783 0.0.0.0:*
LISTEN 0 100 0.0.0.0:143 0.0.0.0:*
LISTEN 0 511 0.0.0.0:80 0.0.0.0:*
LISTEN 0 4096 0.0.0.0:10000 0.0.0.0:*
LISTEN 0 100 0.0.0.0:465 0.0.0.0:*
LISTEN 0 128 0.0.0.0:43219 0.0.0.0:*
LISTEN 0 256 0.0.0.0:53 0.0.0.0:*
서버에서 이 취약점을 해결하려고 하는데 서버에 Apache가 설치되어 있지 않아서 이 취약점이 나타나는 이유를 모르겠습니다!
내 질문은 취약한 프로그램을 어떻게 찾고 서버의 취약성을 어떻게 닫을 수 있느냐는 것입니다.
답변1
ss -lnpt포트 80 또는 443에서 수신 대기 중인 프로세스가 대상일 가능성이 가장 높은지 확인하세요 .
답변2
그만큼고대의 확인하다이는 apache2에만 국한되지 않고 apache2에서 이러한 DoS 표면을 완화하는 특정 접근 방식에만 해당됩니다. Nginx는 이를 사용하지 않습니다. 기본적으로 많은 수의 개별 범위에 대한 요청을 수행하지만 헤더 크기 제한이 적용됩니다. 이론적으로 이것은(또는 헤더를 있는 그대로 전달되는 모든 것) 이상한 요청에 대한 과도한 리소스 사용에 취약할 수 있습니다.
max_ranges number; Default: — Context: http, server, location이 지시문은 버전 1.1.2에 나타났습니다.
바이트 범위 요청에서 허용되는 최대 범위 수를 제한합니다. 제한을 초과하는 요청은 지정된 바이트 범위가 없는 것처럼 처리됩니다. 기본적으로 범위 수는 제한되지 않습니다. 0 값은 바이트 범위 지원을 완전히 비활성화합니다.
Apache 서버에 과부하를 주는 데 사용할 수 있는 특정 트릭만큼 큰 문제는 없습니다. nginx가 다른 곳에서 프록시를 사용하지 않는 한(또는 프록시 대신 캐시에서 대부분의 요청을 처리하는 것에 따라) 해당 설정을 사용하여 특별히 제한 사항을 추가하지 않더라도 아무 작업도 수행할 필요가 없습니다.
요즘 웹서버(2011년 이후 유지보수를 받은 서버)는 단순히무시크기 합계가 전체 콘텐츠 길이를 초과하는 범위에 대한 요청- 실제 적용이 거의 없으므로 제한하는 것보다 훨씬 더 나은 완화가 가능합니다.숫자범위.
어쨌든... 명령줄에서 그런 짜증나는 요청을 직접 작성할 수 있습니다. 전체 익스플로잇은 수백 개의 중첩 범위 등이 포함된 헤더가 포함된 요청을 보내는 것입니다 Range: bytes=1-1337,1-1338,1-1339. 응답(상태 206, 200개의 nginx가 헤더를 무시하고 모든 것을 반환한 경우)이 상당히 느린지 확인하면 확실하게 알 수 있습니다.