leopit's blog

성공적인 공공 웹 사이트가 되려면 사이트로의 액세스를 장려하는 동시에 바람직하지 못한 또는 치명적인 트래픽을 제거하고 사이트의 성능이나 확장성을 제한하지 않으면서 필요한 수준의 보안을 충분히 제공해야 합니다.

DoS(denial-of-service) 공격으로 인한 서비스 중단은 포털, 전자 상거래 사이트 등 웹 중심의 기업에게는 그야말로 "죽음의 키스(kiss of death)"입니다. 1999년 실시한 컴퓨터 범죄 및 보안 상태 조사(Computer Crime and Security Survey)에 의하면 외부인에 의한 침입을 보고한 응답자의 비율이 30%로, 외부인에 의한 시스템 침입이 3년 연속 증가한 것으로 나타났습니다. 인터넷 연결을 빈번한 공격 지점으로 보고한 사람들의 비율은 1996년 전체 응답자의 37%에서 1999년 57%로 3년간 줄곧 상승세를 보였습니다.

대부분의 웹 사이트의 경우 DoS 공격을 방지하는 것이 중요합니다. 특히 이러한 공격은 정상적인 웹 트래픽처럼 보이도록 하는 방법을 이용하여 웹 사이트 작동을 중단시키기 때문에 이미 손을 쓸 수 없는 상황에서야 이를 알게 됩니다. 웹 사이트 관리자는 기본적으로 IP 라우터에서 패킷 필터링 기능을 사용하여 액세스를 제어해 왔지만, 이 경우 라우터 성능이 지나칠 정도로 저하될 수 있으며 일반적인 유형의 많은 DoS 공격을 제거하지 못합니다.

기존의 방화벽은 NAT(Network Address Translation)를 사용하고, 특정 TCP 포트를 사용하는 트래픽을 제한하여 DoS를 방지하고, 특정 네트워크 주소로부터 수신되는 트래픽을 제한하거나 트래픽을 스캐닝하여 바이러스나 바람직하지 않은 애플리케이션이 있는지 확인하는 등 IP 주소의 경계 역할을 할 수 있습니다. 그러나 이런 솔루션은 시스템에 대한 액세스 방지라는, 오늘날의 웹에는 맞지 않는 개념을 바탕으로 설계되었습니다. 뿐만 아니라 기존의 방화벽은 트래픽 용량이 극도로 증가하는 오늘날의 웹 환경에 맞게 확장할 수 없습니다.

Cisco CSS 11000 시리즈 컨텐트 서비스 스위치는 확장성이나 성능을 손상시키지 않으면서 적절한 수준의 보안을 제공하도록 설계된 광범위한 웹 사이트 및 백엔드 시스템 보안 기능을 제공합니다. 여기에는 다음과 같은 보안 기능이 포함됩니다(그림 1 참조).

사이트 수준 보안

방화벽 로드 밸런싱 - 인터넷 경로에서 또는 핵심적인 백엔드 시스템이나 네트워크를 보호하기 위해 완벽한 방화벽 보안이 필요한 경우 Cisco CSS 11000 시리즈 스위치는 병목현상을 방지할 수 있으며, 여러 개의 로드 밸런싱된 방화벽 간에 트래픽을 분산하여 단일 장애 지점을 제거할 수 있습니다. 

그림 1: 웹 사이트 보안 DoS 공격

 

우회 규칙을 사용하여 특정 컨텐트에 대한 모든 요청에 대해 캐시를 우회하고 그 밖의 요청은 캐시로 전달할 수 있습니다. 기술적, 법적, 철학적 이유로 트래픽을 캐싱하는 고객들이 있는데, 이 기능을 사용하면 특정 고객의 컨텐트 중 일부 또는 전부가 캐시로 전달되지 않도록 세밀하게 제어할 수 있습니다. 

방화벽 로드 밸런싱

Cisco CSS 11000 시리즈 스위치는 여러 개의 방화벽 간에 트래픽을 로드 밸런싱하여 성능 병목현상과 단일 장애점을 없애 웹 사이트, 백엔드 데이터베이스, 네트워크 또는 기타 자원에 대한 보안을 유지합니다.
Cisco CSS 11000 시리즈 스위치는 로드 밸런싱이 이루어지고 있는 방화벽 앞, 뒤에 설치할 수 있습니다. 그림 2에서와 같이 방화벽 로드 밸런싱에 사용되지 않는 각 스위치에서 포트를 다른 용도로 구성할 수는 있지만 실제로 고유 스위치는 방화벽 양쪽에 설치됩니다.

그림 2: 엔터프라이즈 방화벽 로드 밸런싱 예



시스코 방화벽 로드 밸런싱은 고유 IP 주소를 갖고 있는 상태 저장(stateful) 방화벽 간에 트래픽을 분산하도록 설계되었습니다.

그림 3: 로드 밸런싱된 방화벽 구성

 

Cisco CSS 11000 시리즈 스위치는 한 쌍의 IP 주소 사이의 특정 웹 플로우에 대한 모든 트래픽이 어느 방향으로든 동일한 방화벽을 통과하도록 보장합니다. 그림 3에서와 같이 인접 방화벽 포트의 IP 주소(A), 원격 방화벽 포트의 IP 주소(B), 원격 웹 스위치 포트의 IP 주소(C)를 사용하여 각 스위치에서 정적 IP 경로를 구성하면 됩니다. 또한 로드 밸런싱된 방화벽 양쪽의 모든 포트는 서로 다른 IP 서브넷 주소를 활용하고 있습니다. 이 구성에서는 NAT를 수행하도록 방화벽을 구성할 수 없습니다. 모든 NAT 처리는 방화벽의 사설 네트워크 측에 있는 웹 스위치에서 수행됩니다.

Cisco CSS 11000 시리즈 웹 스위치는 각각 상태 검사를 사용하여 경로의 각 단계가 응답하고 있는지 확인함으로써 방화벽을 통해 인접 방화벽 포트, 원격 방화벽 포트, 원격 웹 스위치 포트 등 경로를 보안합니다. 일부 경로를 사용할 수 없는 경우, 웹 스위치는 생존 경로를 통해 모든 트래픽을 다시 라우팅합니다. 경보를 전송하거나 이벤트를 기록하여 시스템 관리자에게 장애를 알리도록 Cisco CSS 11000 시리즈 스위치를 구성할 수 있습니다. 세션 상태 정보를 공유하고 실제로 서로 연결되도록 방화벽이 구성되어 있으면 경로나 방화벽에 장애가 발생한 경우에도 사용자 세션이 중단되지 않습니다.

리던던시를 추가로 제공하기 위해 활성/비활성 구성으로 로드 밸런싱이 이루어지고 있는 방화벽 양쪽에 Cisco CSS 11000 시리즈 스위치를 여러 개 설치할 수 있습니다. 이렇게 하면 그림 4에서와 같이 방화벽과 웹 스위치 모두의 단일 장애점이 제거됩니다. 이 구성에서 비활성 웹 스위치는 활성 Cisco CSS 11000 시리즈 스위치의 상태를 모니터링하고 스위치나 업링크 장애를 감지함과 동시에 VRRP(Virtual Router Redundancy Protocol)를 사용하여 비활성 스위치 쌍으로 제어를 전송합니다.

그림 4: 완벽한 이중 방화벽 로드 밸런싱 예

 

결론

Cisco CSS 11000 시리즈 스위치는 성능이나 확장성을 손상시키지 않고 모든 측면의 웹 사이트 보안을 위한 포괄적인 솔루션을 제공하도록 설계되었습니다. Cisco CSS 11000 시리즈 스위치는 정교한 DoS 공격을 제거할 수 있도록 내재된 지능을 각 웹 사이트별로 고객 보안 정책을 구성할 수 있는 유연성과 결합하여 실제 고객과 정당한 사용자가 사이트를 항상 사용할 수 있도록 보장합니다.

// www.cisco.com/global/KR/products/pc/cnd/c11000/cswsc_wi.shtml

ping 을 이용한 DOS 공격 막는 방법을 적어 보자. kernel 에서 ping의
응답 즉, ICMP ECHO 를 on을 시키느냐 off 를 시키느냐에 따라 ping이
되느냐 안 되느냐이다. 보통 ping 을 막는 방법으로 많이 나오는 방법
은 kernel의 icmp_echo_ignore_all 값을 1로 만들어 주는 방법이 주로
알려져 있다.

하지만 kernel document 에 들어 있는 문서를 자세히 보면 ping 을 이
용한 dos 공격은 broadcast와 multicast service 의 패킷을 넘치게 하
는 공격인 것이다.

즉 ping을 다 막을 필요는 없고 broadcast 와 multicast 쪽의 ping 만
막으면 되는 것이다. 아래는 kernel 문서의 원문이다.

icmp_echo_ignore_all and icmp_echo_ignore_broadcasts

Turn on (1) or off (0), if the kernel should ignore all ICMP ECHO
requests, or just those to broadcast and multicast addresses.
Please note that if you accept ICMP echo requests with a
broadcast/multicast destination address your network may be used
as an exploder for denial of service packet flooding attacks to
other hosts.

만약 모든 ICMP ECHO 요청을 커널이 무시하게 하거나, ICMP ECHO 요청
중 broadcast 와 multicast 주소에만 무시하게 할때 1의 값은 무시, 0
의 값은 return 을 하게 된다. 만약 boardcast/multicast 주소의 ICMP
ECHO 요청을 수용하게 한다면, network 가 다른 호스트로 denial of
service(DOS) packet flooding 공격을 하는데 이용이 될수가 있다.

즉 icmp_echo_ignore_all 의 모든 값을 1로 할 필요는 없다는 것이다.
즉 ping 이라는 것은 내가 외부에서 나의 host 가 살아 있는지의 판단
여부도 되기 때문이다. 그러므로

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

을 이용하는 것 보다는

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

를 이용하는 것이 더욱 낳다. 부팅시 마다 적용을 시키고 싶다면
rc.local 에 위의 내용을 넣어 주도록 한다.

RedHat 6.2 버젼 이상의 사용자들은 sysctl 을 kernel 값을 관리 할수
있다. 일단 /etc/sysctl.conf 에 다음의 값을 넣는다.

net.ipv4.icmp_echo_ignore_broadcasts = 1

파일을 저장한 후에 sysctl -w 명령을 실행하고 나서

sysctl -a | grep ignore_boradcasts

명령을 실행하면 값이 변경이 되었는지 확인을 할수가 있다. 다음 부터
는 부팅시 /etc/sysctl.conf 의 값이 적용이 된다.

R.U.D.Y DDoS

RUDY(R-U-DEAD-YET) 는 Post 메소드를 전송하여 서비스를 거부시기키는 DDoS 공격이다.
Content-Length를 매우 크게 설정하여 서버의 지연을 유발한다.

서버는 클라이언트의 HTTP Header에 Content-Length를 보고 그 길이만큼의 Content가 올 때까지 대기하고 있다. 이 점을 이용하여 초기에 길이를 크게 설정해놓고, Content는 일정한 간격으로 1byte씩 전송한다. 결국, 서버는 한 세션당 [Content-Length * Interval Seconds] 만큼의 지연시간이 발생한다.

아래는 실제 공격 패킷이다. Content-Length 가 매우 길게 설정되어 있고 연속된 A 문자를 찍고 있다.
이를 일정한 간격으로 1byte씩 보낸다고 생각해보자
서버는 표기된 전체 byte를 수신할때까지 계속 대기하게 된다.

:: 대응 방안

현재까지 알려진 차단 방법은 크게 두가지다.

- Content-Length 임계치를 두어 차단
- User-Agent 기준으로 차단 (특이값이 있을 경우)

SlowLoris

GET 방식의 메소드는 헤더의 데이터 구분을 CRLF을 이용한다. 0D 0A 가 두번 들어가면 헤더의 끝을 나타내는데..
의도적으로 한번만 넣어서 헤더의 끝을 맺지 않음으로 서버는 헤더가 끝날때까지 지속적으로 기다리게 만든다.
익히 알려진 slowloris 공격 툴은 헤더에 X-a: b 를 전송하고 Content-Length가 42byte 라는 특징이 있다.

:: 공격에 취약한 서버
- Apache 1.x, 2.x, squid

:: 공격에 취약하지 않은 서버
- lighttpd, IIS6.0, IIS7.0, nginx, varnishd, J5K.

공격툴로 테스트를 해보면 아래와 같이 펜더가 나온다.

공격 진행중 패킷을 보면 CRLF(0d 0a) 를 한번만 보내 헤더의 끝을 맺지 않음을 알 수 있다.

slowloris의 특징인 Content_Length: 42 와 X-a: b 도 보인다.

이와 같이 공격을 수행하면 "X-a: b\r\n"의 불완전 헤더를 지속적으로 보내어 SYN->SYNACK를 반복하고 서버 측에서 FIN 패킷을 보내지 않아 계속 패킷을 기다리는 상태가 되어 결국 서비스 거부상태가 된다. 

apache의 경우 실제 공격시에는 로그가 남지 않으며 공격을 멈추면 아래와 같이 로그가 남는다.

# error_log

[error] server reached MaxClients setting, consider raising the MaxClients setting
failed: error reading the headers
failed: error reading the headers
failed: error reading the headers
failed: error reading the headers

# access_log

"GET / HTTP/1.1" 400 308
"GET / HTTP/1.1" 400 308
"GET / HTTP/1.1" 400 308
"GET / HTTP/1.1" 400 308 

:: 대응방안

-.  Timeout 설정 변경(가장 현실적인 방법)
     httpd.conf 에서  Timeout 300  ==> 5 이하로 변경 (5초동안 연속된 패킷이 오지 않을 경우 timeout시킴)

-. iptables의 connection limit(커넥션 제한) 설정
   # iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 30 -j DROP