"Apache Killer" a DDoS using the Range HTTP Header

In 2007, a Google engineer, Michal Zalewski, published a memo detailing a potential vulnerability of both Apache and IIS Web Servers after investigating the HTTP/1.1 "Range" header implementation. He reported then:

it is my impression that a lone, short request can be used to trick the server into firing gigabytes of bogus data into the void, regardless of the server file size, connection count, or keep-alive request number limits implemented by the administrator. Whoops?

A proof of concept for the Apache DDoS tool was published as a Perl script on the August 19 ”Full Disclosure” security mailing list. On August 24, the Apache Security Team published a memo explaining:

It most commonly manifests itself when static content is made available with compression on the fly through mod_deflate - but other modules which buffer and/or generate content in-memory are likely to be affected as well. This is a very common (the default right!?) configuration.

The attack can be done remotely and with a modest number of requests leads to very significant memory and CPU usage.

Active use of this tools has been observed in the wild.

There is currently no patch/new version of apache which fixes this vulnerability. This advisory will be updated when a long term fix is available. A fix is expected in the next 96 hours.

On Friday, Apache published a second advisory in which they explain how Apache httpd and its so called internal 'bucket brigades' deal when a server processes a request to return multiple (overlapping) ranges; in the order requested. A single request can request a very large range (e.g. from byte 0- to the end) 100's of times in a single request. Currently this kind of requests internally explode into 100's of large fetches, all of which are kept in memory in an inefficient way.

This is being addressed in two ways. By making things more efficient. And by weeding out or simplifying requests deemed too unwieldy. There are several immediate options to mitigate this issue until a full fix is available.

Apache's mitigation strategies ranged from completely disallowing the Range header, to limiting the size of requests, to deploying a custom Range counting module. Lori MacVittie detailed how the mitigation strategies could be implemeted with Big-IP.

SYN Flooding 공격이란?

신플루딩공격이란 TCP세션이 연결될 때의 취약성을 이용한 서버공격이다.

먼저 TCP의 기본적인 연결단계는 아래와 같습니다.

1. A(소스서버)가 B(목적지서버)에게 접속을 요청하는 SYN패킷을 보낸다.
2. B는 요청을 수락한다는 SYN과 ACK패킷을 A에게 보낸다.
3. A가 B에게 ACK를 보내면 연결이 이루어지고 본격적이 데이터교환이 이루어진다.

위의 2번단계에서 목적지서버(B)는 소스서버(A)가 ACK패킷을 보내주기를 계속적으로 기다리는 것이 아니라
일정시간 후 요청이 오지 않으면 백로그큐(Backlog Queue)가 허용하는 공간에 연결정보(로그)를 보관하게 됩니다.
이러한 상태가 지속적으로 요청되어 연결정보(로그)가 쌓이게 되면 목적지서버(B)의 특정서비스가 마비될 수 있습니다. 이러한 공격을 DOS공격의 일종인 SYN Flooding 공격이라고 합니다.
Syn 로그 기록후 Timeout 까지의 대기시키는데 그 타임아웃 시점보다 짧게 Syn 요청을 해서 스택을 채워네트웍을 마비시키기도 하고 Invalid 한 값의 Syn으로 무차별적으로 이루어 지기도 한다.

SYN Flooding 공격탐지

1. SYN_RECV 가 있으면 공격에 노출되었다고 보면 된다.

   ~$ netstat -na | grep SYN
   tcp 0 0 61.250.171.252:28004 94.9.83.63:3072 SYN_RECV
   tcp 0 0 61.250.171.252:28004 3.7.244.2:3072 SYN_RECV
   tcp 0 0 61.250.171.252:28004 48.32.206.32:3072 SYN_RECV
   
   ~$ netstat -na |grep SYN | wc -l
   146
   
   정상적인 경우라면 거의 0이어야 함

2. SYN Cookies가 작동할 때 SYN Flooding공격이 있으면 messages 파일에 아래와 같은 내용이 출력된다.
   #Possible SYN flooding on port 80. Sending cookies.

SYN Flooding 공격막기

이러한 신플루딩 공격을 차단하기 위해서는 백로그큐의 사이즈를 늘려주는 방법과 tcp_syncookies값을 1로 설정하는 방법이 있습니다.

1. SYN backlog사이즈 증가
   cat /proc/sys/net/ipv4/tcp_max_syn_backlog 로 현재 서버의 백로그큐 값을 확인

   ~$ cat /proc/sys/net/ipv4/tcp_max_syn_backlog
   1024
   
   1024 보다 작으면 1024 이상으로 설정해줍니다.
   
   sysctl \-w net.ipv4.tcp_max_syn_backlog=1024

2. SYN Cookie설정
   위와 같이 백로그큐의 값을 늘려주더라도 이 방법은 임시적인 방법일 뿐, 지속적인 공격을 당하게 된다면 결국 로그값이 가득차게 된다. 그렇기 때문에 백로그큐의 값을 늘려주는 것과 함께 신쿠기 기능도 설정해줘야 합니다.
   cat /proc/sys/net/ipv4/tcp_syncookies 로 현재 서버의 신쿠키 값을 확인해서 0으로 되어 있다면
   sysctl -w net.ipv4.tcp_syncookies=1 ← 요렇게 값을 1로 바꿔줍니다.

   ~$ cat /proc/sys/net/ipv4/tcp_syncookies
   1
   ~$ sysctl \-w net.ipv4.tcp_syncookies=1
   error: permission denied on key 'net.ipv4.tcp_syncookies'
   ~$ sudo sysctl \-w net.ipv4.tcp_syncookies=1
   net.ipv4.tcp_syncookies = 1

   신쿠키는 백로그큐가 가득 찼을 경우에도 정상적인 접속요구를 계속 받아들일수 있도록 해주므로 신플루딩 공격에 대비한 가장 효과적인 방법중 하나입니다.

3. IP TABLES
   • IP직접막기

     ~$ iptables -A INPUT -s <Source IP> -j DROP

   • Rule추가

     ~$ iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
     ~$ iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
     ~$ iptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
     ~$ iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP
     ~$ service iptables save
     ~$ service iptables restart

4. sysctl.conf에 rule추가

   ~$ vi /etc/sysctl.conf
   
   # Enable TCP SYN cookie protection
   net.ipv4.tcp_syncookies = 1
   
   # Decrease the time default value for tcp_fin_timeout connection
   net.ipv4.tcp_fin_timeout = 30
   
   # Turn off the tcp_window_scaling
   net.ipv4.tcp_window_scaling = 0
   
   # Turn off the tcp_sack
   net.ipv4.tcp_sack = 0
   
   Then execute the command :-
   # /sbin/sysctl -p

5. iptables 조회 (block추가나 해재후에 확인 절차. 아래는 default iptables 조회시의 output)

 ~$ iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
 

공격툴

http://packetstormsecurity.nl/DoS/

0 comments | Add Comment

DDOS 대응방법

DDOS공격시 아파치웹상으로 대응하는 방법을 기술한다.

• DDOS탐지
  탐지는 보통 System팀에서 Report가 오게 되지만, 웹팀내에서도 확인이 필요합니다.
  • 아파치 로그상에서 IP별 request건수 측정

    tail -n 10000 access_log | cut -f1 -d' ' | sort | uniq -c | sort -nk 1

  • 특정 IP/Agent에 대한 request건수 측정

    grep 'A cat' access_log | cut -f1 -d' ' | sort | uniq -c

    아파치 로그파일의 위치는 /usr/local/apache/log/access

• IP Block
  해당 호스트의 아파치 VirtualHost셋팅내의 Directory 부분에 Deny From 추가

  <Directory "/usr/local/tomcat/webapps/ROOT">
      Options -Indexes FollowSymLinks MultiViews
      AllowOverride None
      Order allow,deny
      Allow from all
      Deny from xxx.xxx.xxx.xxx
      FileETag None
    </Directory>

• Agent Block
  해당 호스트의 아파치 VirtualHost셋팅내에 아래와 같이 Agent pattern을 deny from에 추가

  <Location ~ "/*">
      Order allow,deny
      Allow from all
      Deny from env=bad_req
    </Location>
  SetEnvIfNoCase User-Agent "^Mozilla/4.0.*MyIE 3.01" bad_req

• Syn Flooding