nginx 버전이 노출되어 있으면 위험할 수 있다구?

nginx 의 버전을 외부 사용자가 확인할 수 있게 노출시켜두면 위험하다!
nginx 버전이 노출되는 대표적인 페이지로는 오류 페이지가 있다
nginx 에서 오류를 응답할때 기본적으로 반환하는 페이지에 버전 정보가 나오게 된다

1. 왜 위험한가

nginx 의 특정 버전의 취약점이 발견되면 이를 이용한 공격이 너무 쉬워진다.
최소한 내 서버의 nginx 버전이라도 모르게 해야한다.

2. 어떻게 대응해야 하는가

nginx 의 기본 오류 페이지가 반환되지 않도록 하거나,
위 기본 오류 페이지에서 버전 정보가 나가지 않도록 조치를 해야 한다

#nginx.conf
http{
 ...
 server_tokens off;
 ...
}

위와 같이 옵션을 추가해주면, 아래와 같이 버전정보 없이 오류페이지를 반환한다

3. 요정도 대응이면 충분한가?

이번에 nginx 버전 제거 작업을 하면서, 
이 외에도 보안적인 관점에서 더 조치해 두어야하는 부분들은 없는지 확인해 보게 되었다

그렇게 알게된 nginx 보안을 위한 조치 사항은 다음과 같다

Step 1. 미사용 nginx module들 비활성화 시키기

nginx 를 설치하면, 자동적으로 기본 모듈들을 포함시켜서 설치하게 되는데,
불필요한 모듈들이 많아지면 많아질수록 보안에는 취약해 질것이니..
설치 중에 필요한 모듈들 외에는 disable 하도록 설정하기

# ./configure --without-http_autoindex_module
# make
# make install

Step 2. server_tokens off

server_tokens off 를 설정하지 않아서 nginx 버전이 노출되게 두어서 받을 수 있는 공격들을,
information disclousure attack~ 이라고 부른다고 하는군..

Step 3. 리소스 제한

Dos 공격을 받지 않기 위해서, 리소스 관련 용량 제한등을 해둘 필요성이 있다.
이전에 서버 api 체크 하다가 큰 파일 전송 안되어서 뭬얏! 한 적이 있었는데,
역시 nginx.. 다 계획이 있었구나

- client_body_buffer_size
- client_header_buffer_size
- client_max_body_size
- large_client_header_buffers

Step 4. 안쓰는 HTTP 메소드 제한

생각해보면 이 방법이 정말 간단하고 보안 효과도 좋을 것 같은데 꼭 도입하는게 좋을 것 같다

#nginx.conf
location / {
limit_except GET HEAD POST { deny all; }
}

Step 5. 더 많은데 이제 어렵다. Reference에..

4. Reference

- nginx server_tokens doc : http://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens
- hardening nginx : https://www.acunetix.com/blog/web-security-zone/hardening-nginx/