[꿀팁]고성능 Nginx를위한 보안(7)-DoS, DDoS 공격 방어 설정

#Nginx설치 #Nginx-install #웹서버 설정 #Nginx웹서버설치 #웹서버튜닝#Nginx웹서버 설정 #Nginx웹서버설치 #웹서버튜닝 #Nginx웹서버 설정 #Nginx웹서버설치 #웹서버튜닝 #high performancen nginx #system performance tunning #웹서버 튜닝 #성능개선 #시스템튜닝 #파일시스템 튜닝 #대용량 웹서버 튜닝 #웹서버 유량제어

 

1. 디스크의 I/O 병목 줄이기
2. 프로세스 처리량 늘리기 (Process)
3. TCP 관련 처리량 늘리기
4. 메모리 및 CPU 튜닝하기 (Processor)
5. 마이크로캐싱
6. 로그 부하 줄이기
7. Dos, DDos 방어 설정

 

 

[꿀팁]고성능 Nginx를위한 보안(7)-DoS, DDoS 공격 방어 설정

 

DDos, Dos 등 또는 특정 트래픽의 부하 발생시 제한을 하는 방법으로 Nginx의 기능을 활용하는 방법들을 정리하여 보았습니다.  

대형 싸이트에서 이벤트 또는 선착순의 서비스 처리를 하는 경우도 있지만 특정 싸이트의 개인정보를 해킹하기 위한 시도에서 활용이 가능한 방법 입니다.

 

주로 이러한 룰은 대용량 메일 처리를 해본 경험이 있는분은  Spam 어세씬이라는 응용 프로그램을 생각 하면 더 좋은 방안을 찾을 수 있을 것이라고 봅니다.

저의 경험으로는 종종 이러한 공격 시즌에 들어오는 IP의 수가 1만~10만개가 한꺼번에 들어오기 때문에 아래와 같은 방법으로는 해킹인지 아닌지 구분이 쉽지 않고 방어하기 어렵다고 말씀드립니다.
다만 Nginx를 이용하면 최소한의 대비책은 될것이고 쉽게 적용 가능하기 때문에 비용 효과적인 방법이라고 봅니다.

 

DDOS 상황은 아래 방안들로 쉽게 해결 할 상황이 아닙니다. WAF나 DDos탐지 시스템이 없는 상태에서 이러한 상황 대처하는 최소한의 방어 대책이라고 보여집니다. 그리고 문제를 해결하는 방안을 세우기 위해 해야 할 일은

이와 유사한 상황이 발생하면 어떤 서비스에 영향을 주지 않고 할 것인지, 일부 서비스에 영향을 주지만 핵심 부분은 어떻게 방어를 할 것인지를 결정하고 수행을 해야 합니다.

 

Nginx에서  서비스 방어와 유량제어 방법

1.Request 요청 비율 제한 ( limit_req )
2.연결 수 제한  ( limit_con )
3.느린 연결 닫기
4.특정 IP 주소 거부
5.백엔드 서버에 대한 연결 수 제한
6. 정찰 트레픽 식별과 처리 (범위 기반 공격 - CVE-2015-1635)
7. 고부하 처리 정리

 

 

1. Request 요청 비율 제한 ( limit_req )

악의적으로 서버에 request를 매우 빠르게 지속적으로 넣게되면 서버가 응답이 불가능한 상황이 됩니다.
이럴때는 시간 당 request 개수를 제한하고, 해당 제한 개수를 초과하게 되면 그 request는 deny 하는 설정을 해주면됩니다. 

limit_req_zone $binary_remote_addr zone=zone_one:10m rate=30r/m;
server {
        # ...
        location /login.html {
             limit_req zone=zone_one;
             # ...
        }
 }

 

이 limit_req_zone 지시문은 지정된 키 (이 경우 클라이언트 IP 주소 ( ))에 대한 요청 상태를 저장하기 위해 zone_one 이라는 공유 메모리 영역을 구성합니다.  location블록의 지시문은 /login.html 에 대하여$binary_remote_addr의  limit_req 에 대한 공유 메모리 영역을 참조합니다.

nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req_zone   
nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req

 

 

2. 연결 수 제한  ( limit_con )

사용자의 단일 클라이언트 IP 주소로 열 수있는 연결 수를 적합한 값으로 제한 할 수 있습니다.

limit_conn_zone $binary_remote_addr zone=zone_addr:10m;
server {
        # ... 
        location /store/ {
             limit_con zone_addr  10;
             # ... 
        }
 }

이 limit_conn_zone 지시문은 zone_addr 라는 공유 메모리 영역을 구성합니다. 이 경우 (이전 예제에서와 같이) 클라이언트 IP 주소 $binary_remote_addr을 키로 저장을 합니다.  location 블록의 /store에 대한 limit_conn지시문은 공유 메모리 영역을 참조하고 각 클라이언트 IP 주소에 대하여 최대 10 개 까지의 동시 연결을 허용하도록 합니다.

nginx.org/en/docs/http/ngx_http_limit_conn_module.html#limit_conn_zone  
nginx.org/en/docs/http/ngx_http_limit_conn_module.html#limit_conn

 

 

3. 느린 연결 닫기

데이터를 빠르게 응답하지 않는 연결을 닫을 수 있습니다. 이것은 연결을 가능한 오래 열어 두려는 공격시도로서 느린 접속으로 서버의 새 연결에 사용 할 리소스를 소진하여 기능을 감소시키기 때문입니다.

느린 접속 공격 유형 :  Slow HTTP Header DoS ( Slowloris 공격) 

• HTTP Header 정보를 비정상적으로 조작하여 웹서버가 온전한 Header정보가 올때 까지 기다리도록 합니다.
• 서버가 연결 상태를 유지할 수 있는 가용자원은 한계가 있으므로 임계치를 넘어가면 다른 정상적인 접근을 거부하게 됩니다.

Slowloris는 이러한 유형의 공격의 예입니다. client_body_timeout지시어를 이용하여 client가 body를 쓰게 하는 대기시간을 제한 하고  client_header_timeout 으로 클라이언트와 헤더를 쓰는 시간을 제한 합니다. ( 두 지시문의 기본 값은 60초 입니다.)

예시를 들면 헤더 또는 본문에 대해 클라이언트에서 쓰는 시간을 5 초 이상 기다리지 않도록 NGINX를 구성합니다.

server {
       client_body_timeout 5s;
       client_header_timeout 5s;
        # ...
}

 

 

4. 특정 IP 주소 거부

Nginx는 공격에 사용되는 클라이언트가 하나 이상의 특정 클라이언트 IP 주소 집합 또는 IP주소 범위에 대하여 허용되는 IP 주소를 식별 할 수 있는 경우, 
"deny" 지시문을 사용하여 해당 연결이나 요청을 수락하지 않도록  해당 IP 주소를 거부 할 수 있습니다. 

예를 들면  
*  특정 주소 대역 범위(123.123.123.1 ~ 16 )를 접근 제한 합니다.
*  특정 주소를 명시적으로 나열하여 123.123.123.3, 123.123.123.5 및 123.123.123.7 등을 제한 합니다.
* allow와 deny 지시문을 함께 사용하여 특정 주소에 대한 접근을 허용하거나 제한 합니다. 

location /range {
      deny 123.123.123.0/28;
      # ... 클라이언트의 IP 대역을 제한
}


location /list {
    deny 123.123.123.3;
    deny 123.123.123.5;
    deny 123.123.123.7;
    # ... 특정 IP 목록에 대한 제한
}

location /admin {
   allow 192.168.1.0/24;
   deny all;
   # ... 일부만 허용
}

 

 

5. 백엔드 서버에 대한 연결 수 제한

NGINX 또는 NGINX Plus 인스턴스는 일반적으로 부하 분산중인 백엔드 서버보다 더 많은 동시 연결을 처리 할 수 ​​있습니다. Nginx로 유입된 특정 호출이백엔드 서버까지 유입되지 않도록 일정 수의 접속을 유지할 필요가 있습니다.  이때 NGINX 와 백엔드 서버 간의 연결 수를 제한 할 수 있습니다. 

예를 들어 웹 사이트  업스트림 그룹 에있는 두 백엔드 서버 각각에  200 개 이하로 연결하도록 제한할 수 있습니다.

upstream website_up {
    server 192.168.100.1:80 max_conns=200;
    server 192.168.100.2:80 max_conns=200;
    queue 10 timeout=30s;
}

백엔드 각 서버마다 max_conns 으로 최대 연결 개수를 지정하고,  queue 지시문으로 업스트림 그룹의 모든 서버가 연결 제한에 도달했을 때 대기중인 요청 수를 제한하고,  timeout매개 변수는 요청을 대기열에 보관할 기간을 지정합니다.

nginx.org/en/docs/http/ngx_http_upstream_module.html#max_conns

 

 

6. 정찰 트레픽 식별과 처리 (범위 기반 공격 - CVE-2015-1635)

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

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

CVE-2015-1635는 일종의 overflow공격으로 시스템들이 가진 버퍼들에 대한 취약점을 찾아 공격하는 기법입니다.
이 공격은 윈도우 시스템의 경우 HTTP.sys를 사용하면 원격 공격자가 "HTTP.sys 원격 코드 실행 취약성"이라고하는 제작 된 HTTP 요청을 통해 임의 코드를 실행 할 가능성이 있습니다.
(Microsoft Windows 7 SP1, Windows Server 2008 R2 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold 및 R2등 : 2015년 4월 14일에 공개된 보안 업데이트 패치로 해결)

범위 기반 공격 (CVE-2015-1635) 는  헤더의 Range 바이트 범위가 큰 HTTP 요청 이 충돌을 유발 한다고보고했습니다 .

GET / HTTP/1.1  \rn
Host: stuff \rn
Range: bytes=0-18446744073709551615 \rn
\rn

Nginx는 이러한 유형의 특정 http request의 파라미터 들을 판단하여 방어를 할수 있습니다.

1) 범위 기반 공격을 식별 하기 위해서 http_range 값이 10자리 이상의 값일 경우 값을 삭제 하는 것입니다.

map $http_range $saferange {
    "~d{10,}" "";   # if it matches a string of 10 or more integers, remove it
    default $http_range;
}

server {
     listen 80;
     location / {  
          proxy_set_header Range $saferange;
         proxy_pass http://some_url:80;
     }
}

 

2) HTTP 444코드를 이용 Range 값이 큰 정수와 비슷할 때 HTTP 444코드를 반환 하여 즉시 클라이언트 연결을 닫도록 할 수 있습니다 

server { 
     listen 80; 
     if ($http_range ~ "d{9,}") {
         return 444;
     }

     location / {  
          proxy_set_header Range $saferange;
         proxy_pass http://some_url:80;
     } 
}

 

 

7. 고부하 처리 정리

DDoS 공격은 일반적으로 높은 트래픽 부하를 초래합니다. 각 시스템이 더 높은 부하를 처리 하도록 운영 체제 및 각 시스템의 성능을 높여야 합니다. ( 별도의 공격 탐지 시스템을 이용하여 네트웍의 전반적인 모니터링 환경을 구성하는 것도 중요 합니다.) 또한 blackhole 처럼 특정 트레픽의 유입이 들어오면 block을 할수 있는 대피소도 만들 필요가 있습니다. 그리고 네트웍 차원의 DDos, WAF등으로 모니터링과 방어체계를 갖추어야 합니다.

최근 클라우드가 보편화 되면서 클라우드에서 이러한 환경을 제공하기도 하지만 실제 관리측면의 모니터링 환경도 중요하다고 보여 집니다.  특히 클라우드 환경에서 유입되는 트레픽은 다수의 IP 또는 국내.외를 불문한 접속이 유입되기 때문에 시스템을 보호하는 차원에서 회피와 거부에 대한 정책도 함께 강구 되면 좋겠습니다.

 

[기타 참고]

* www.nginx.com/blog/nginx-protect-cve-2015-1635/

* www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/

 

[웹서비스 튜닝 목차]

1. 디스크의 I/O 병목 줄이기
2. 프로세스 처리량 늘리기 (Process)
3. TCP 관련 처리량 늘리기
4. 메모리 및 CPU 튜닝하기 (Processor)
5. 마이크로캐싱
6. 로그 부하 줄이기
7. Dos, DDos 방어 설정