nginx 보안 구멍 처리

nginx 에 안전 구멍 이 있다 는 것 을 알 고 마음 에 두 지 않 았 습 니 다. 오늘 시간 을 내 서 테스트 를 했 습 니 다. 정말 위험 합 니 다. nginx 로 서버 를 구축 하 는 친 구 는 반드시 조심 하 세 요. 예방 조 치 를 취하 지 않 으 면 심각 한 안전 위험 을 초래 할 수 있 습 니 다.
2010 년 5 월 23 일 14: 00 전에 본 고 를 읽 은 친 구 는 현재 v 1.1 버 전의 최신 설정 에 따라 설정 하 십시오.
어제 80Sec 에서 Nginx 가 심각 한 0day 구멍 이 발생 했 습 니 다. 상세 한 내용 은 'Nginx 파일 형식 오류 분석 구멍' 을 참조 하 십시오.사용자 가 이미지 업로드 권한 을 가 진 Nginx + PHP 서버 만 있 으 면 * * 에 의 해 가능 합 니 다.사실 이 구멍 은 Nginx 의 구멍 이 아니 라 PHP PATH 입 니 다.INFO 의 허점 은 다음 과 같 습 니 다.http://bugs.php.net/bug.php?id=50852&edit=1 예 를 들 어 사용자 가 사진 을 올 렸 는데 방문 주 소 는?http://www.domain.com/p_w_picpaths / test. jpg, test. jpg 파일 의 내용 이 실제 PHP 코드 일 때 통과http://www.domain.com/p_w_picpaths / test. jpg / abc. php 는 이 파일 의 PHP 코드 를 실행 할 수 있 습 니 다.
장 옌 의 블 로그 에는 적어도 네 가지 방안 이 언급 되 어 있 는데 다음 과 같이 나열 되 어 있다.
방법 ① 、 php. ini 수정, cgi. fix 설정pathinfo = 0;그리고 php - cgi 를 다시 시작 합 니 다.이 변경 사항 은 PATH 사용 에 영향 을 줍 니 다.INFO 의사 정적 응용, 예 를 들 어 내 가 예전 에 블 로그 의 URL:http://blog.s135.com/read.php/348.htm 방문 할 수 없습니다.방법 ②, nginx 설정 파일 에 다음 내용 을 추가 한 후 다시 시작 합 니 다: if ($fastcgi script name ~ \.. * \ /. php) {return 403;}.이 매 칭 은 유사 한 영향 을 줍 니 다.http://www.domain.com/software/5.0/test.php(5.0 은 디 렉 터 리),http://www.domain.com/goto.php/phpwind 라 는 URL 로 접근 했다.방법 ③ 그림 을 저장 하 는 location {...} 또는 가상 호스트 server {...} 에 대해 서 는 순수 정적 접근 만 허용 하고 PHP 접근 은 설정 되 지 않 습 니 다.
방법 4: 장 연 은 ngix. conf 프로필 을 수정 하 는 임시 해결 방법 을 제공 합 니 다. 호 환 "http://blog.s135.com/demo/0day/phpinfo.php/test"의 PATHINFO 거짓 정적, 거부 "http://blog.s135.com/demo/0day/phpinfo.jpg/test.php"의 빈틈 * *:
location ~* .*\.php($|/)
{
if ($request_filename ~* (.*)\.php) {
set $php_url $1;
}
if (!-e $php_url.php) {
return 403;
}
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fcgi.conf;
}
다음 내용 을 fcgi. conf 파일 에 써 서 여러 가상 호스트 가 참조 할 수 있 습 니 다.
if ($request_filename ~* (.*)\.php) {
set $php_url $1;
}
if (!-e $php_url.php) {
return 403;
}
fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $uri;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;
# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param REDIRECT_STATUS 200;
잘 읽 지 못 했 습 니 다. 여기 기록 을 하나 만들어 서 참고 하여 찾 아 보 세 요.
저 는 세 번 째 방안 을 사 용 했 습 니 다. 즉, 그림 을 올 릴 수 있 는 디 렉 터 리 에서 처리 하고 phop 프로그램 을 실행 하지 못 하 게 합 니 다. 코드 는 다음 과 같 습 니 다.
location ^~ /uploadfile/{ 

            location ~ "\.php.*$"{ 

                    return 403; 

        } 

테스트 를 통 해 가능 합 니 다. 정규 가 잘 배우 지 못 해서 웃음거리 가 되 었 습 니 다!
위의 이 말 은 아직도 문제 가 있 습 니 다. 사용 한 후에 모든 그림 이 보이 지 않 고 장 연 의 방법 도 시도 해 보 았 습 니 다. 왠 지 효과 가 없 었 습 니 다.
최종 적 으로 방안 2: if ($fastcgi script name ~ \.. * \ /. php) {return 403;} 을 사용 합 니 다.
매우 효과 적 인 것 은 몇 가지 실행 구멍 을 테스트 하 는 방식 도 소 용이 없다.
이 정칙 을 자세히 생각해 보 았 다.
\. 점 을 대표 합 니 다............................................................................................
. jpg (임의의 문자) / (임의의 문자) php (임의의 문자)
예 를 들 어. jpg / xxx. php;. jpg /? xccc / 1. php;. jpg / ccc. php? x = 8; (한 마디 로 통 살)
 
다음으로 전송:https://blog.51cto.com/webteam/735695