NGINX 보안을 강화해보자

NGINX에 대한 보안을 강화하는 방법 Nginx security hardening guide을 참고해보자.

1. NGINX를 숨겨라

현재는 NGINX로 요청을 보내면 응답 헤더에 NGINX 버전이 명시된다. 이를 숨기는 게 좋다고 한다.

이 설정을 추가해주면 된다.

이제 응답에 버전이 명시되지 않는다.

proxy_pass_header Server;

이걸 추가해주면 NGINX 서버도 가릴 수 있다.

이제 헤더에 NGINX 정보가 뜨지 않는다.

2. HTTP1.0은 거절해라

if ($server_protocol = HTTP/1.0) {
                add_header Upgrade "HTTP/2.0";
                add_header Connection "Upgrade";
                return 426 "Upgrade Required: Upgrade your client to support more modern HTTP protocol";
                break;
            }
            

이렇게 넣어주면 된다.

3. url을 분석해서 악의적인 접근을 막아라

현재 악의적인 접근에 대한 url을 로깅으로 확인하고 있다.
이를 map으로 담아서, 여기에 해당하면 444응답을 반환하고 바로 종료하고 있다.

엔진엑스 access.log를 보면 위처럼 응답하는 것을 확인할 수 있다.

그 이외의 것은 HTTPS 용이라서 HTTPS를 적용하고 추가할 계획이다.

4. IP에서 연결할 수 있는 커넥션 수를 제한하라

DDos를 비롯한 비정상적인 연결의 경우 ip당 연결할 수 있는 커넥션 수를 제한하는 게 좋다고 한다.

limit_conn_zone $binary_remote_addr zone=addr:10m;

server {
    location /download/ {
        limit_conn addr 1; //연결가능한 커넥션 수
    }

5. Slow Connection을 없애라

    client_body_timeout 10s;
    client_header_timeout 10s;

client_body_timeout는 클라이언트 요청 후 응답의 바디 보내기까지 기다리는 시간

client_header_timeout는 클라이언트 요청 후 응답의 헤더를 보내기까지 기다리는 시간이다.

데이터를 작성하는 데 시간이 너무 오래 걸린다면, 연결을 가능한 오래 열어두려는 시도일 수 있다고 한다. 그래서 이를 제한하는 것.

6. NGINX의 보안 취약점을 보완해라

Nginx 보안 취약점

여길 보면 보안 취약점에 대한 내용들이 있다.

(1)DocumentRoot 영역 분리

nginx 설치 시 /usr/share/nginx/html를 DocumentRoot로 쓰는데, 해당 html 디렉터리는 공격받기 쉬운 문서들 및 공격에 이용될 수 있는 시스템 관련 정보도 포함되어 있기 때문에 변경해야 한다.

# 새 디렉토리 만들기
sudo mkdir -p 경로

# 여기에 필요한 파일만 새로 만들기
sudo touch 경로/html/index.html

server {
    root 경로/html;
}

이렇게 변경해주면 된다.

(2)Symbolic Link 사용 제한
심볼릭 링크라고 해서 파일의 바로가기를 만들었을 때, 이를 링크/파일 이렇게 해서 웹에서 볼 수도 있다고 한다. 일반 이용자가 이를 하지 못하도록 막으려면 disable시켜줘야 한다.

(3)Directory Listing 제거

웹서버의 특정 경로에 있는 파일들을 디렉토리 형태로 볼 수 있게 해준다.

이런 느낌이라고 한다.

autoindex off; //location 블록

이렇게 해주면 차단된다!

해킹 방지를 위한 Nginx 설정

    add_header X-Frame-Options SAMEORIGIN;  #(2)
    add_header X-Content-Type-Options nosniff;  #(3)
    add_header X-XSS-Protection "1; mode=block";  #(4)

이 세가지를 추가해주는 게 좋다고 한다.

(2)는 클릭재킹 공격을 방지하기 위한 헤더다. 이 헤더가 설정되면, 같은 출처의 페이지에서만 이 페이지를 iframe으로 포함할 수 있다.

클릭재킹(Clickjacking)은 웹사이트 사용자를 속여 자신도 모르게 악성 링크를 클릭하도록 하는 인터페이스 기반 공격입니다. 클릭재킹을 통해, 공격자는 악성 링크를 웹사이트의 버튼이나 합법적인 페이지에 삽입합니다. 감염된 사이트에서 사용자가 합법적인 링크를 클릭할 때마다, 공격자는 해당 사용자의 기밀 정보를 얻게 되고, 궁극적으로 인터넷에서 사용자의 개인 정보를 손상시킵니다. 출처=클릭재킹 (Clickjacking)

(3)MIME 스니핑 공격을 방지하는데 사용된다.

(4)크로스 사이트 스크립팅 (XSS) 공격을 방지하는데 사용된다.XSS 공격은 공격자가 웹 사이트에 악의적인 스크립트를 삽입하여 사용자의 정보를 탈취하는 공격이다.

(4)*trace, track 메서드는 차단해라

if ($request_method ~ ^(TRACE|TRACK)$) {
    return 405;
}

(5)버퍼 사이즈를 조절해라

client_body_buffer_size 128k;    # POST 데이터를 위한 버퍼
client_header_buffer_size 1k;    # 대부분의 헤더에 충분
client_max_body_size 10m;        # 전체 요청 크기 제한
large_client_header_buffers 4 4k; # 큰 헤더를 위한 버퍼

요청을 매우 크게 보내서 메모리를 고갈시키는 공격도 있다고 한다.
이런 경우 NGINX에서 먼저 걸러낼 수 있다.

(6)Range 공격을 막자

if ($http_range ~ "\d{9,}") {
    return 444;  # 연결 즉시 종료
}

일반적으로 공격 시도 전에 웹서버의 취약점에 대한 사전 정찰이 실행 된다. 이런 정찰 트레픽을 통해서 공격의 한 가지 방법인 Range버퍼 오버플로를 일으킬 수있는 매우 큰 값을 전송하는 경우가 있다.

공격자들은 주로 범위 기반 공격 전에 매우 큰 범위 요청이있는 HTTP 요청을 전송하여 취약한 시스템을 찾으려고하는 것으로 알려져 있다.

보통 파일 다운로드할 때 중간에 끊기면 이어받기를 위해 Range 헤더를 쓰는데, 공격자가 이 Range 값을 엄청 크게 (예: 18446744073709551615) 보내서 서버에 부담을 주는 공격이라고 한다.