'멀티GET' 태그의 글 목록

728x90

AN090806_Attack_Notes_Valid_HTTP_Get_Request_Attack.pdf

RIOREY DDOS Solution의 Http Get & CC attack 에 대한 차단

RIOREY는 많은 다른 Application level공격들을 방어 할 수 있는 매우 효과적인 TCP SYN rate를 소개했습니다.

이러한 공격들은 다양한 HTTP attacks, CC attacks, P2P attacks 그리고 많은 것들은 포함합니다.

이 문서에서는 SYN RATE 엔진이 어떠한 방식으로 운영되는지, 그리고 최근에 HTTP 공격들을 대신해서

막아주는데 사용되는지를 설명합니다.

TCP SYN Rate 엔진은 매우 유연한 동작을 합니다, 이 엔진은 서버의 행동을 대신해서 클라이언트의 동작을 시험하기 때문에 서버의 운영 시간 동안에 거짓 경보를 울리는 일이 없게 됩니다.

우리는 HTTP GET attack 과 CC attack의 예와 함께 TCP SYN Rate가 어떤 방식으로 돌아가는지 설명을

할 것입니다.

HTTP Attack들은 보통 TCP session들을 열게 되어 있습니다. 그리고 그때 HTTP GET을 요청 합니다.

HTTP GET이 빨리 반복 되었을 때 그것은 HTTP Server의 과도한 응답을 요구하게 되는 요인이 되며 결

국 서버는 장애를 일으키게 됩니다.

HTTP GET 공격의 종류

HTTP 요청은 두 가지 주요 사항이 있습니다:

a) 첫 번째 HTTP 요청은 단일 TCP connection입니다.

이것은 HTTP 1.0 과 1.1 버전에 의해 제공되어 집니다.

b) 다중 요청들은 단일 TCP connection 안에 있습니다.

이것은 HTTP 1.1에 의해 제공 됩니다.

대부분의 HTTP공격은 다음의 기술을 사용합니다.

단일 HTTP Get 공격

a) 단일 TCP Connection 에서 한번의 HTTP 요청을 처리하는 경우.

이것은 또한 큰 규모의 랩실에서 소프트웨어 Generate 를 이용해서 HTTP 공격을 유발하는

경우입니다. 어쨌든 더욱 정교한 공격은 이 기술을 사용합니다.

b) 더 적은 공격 대역폭과 함께 Victim 에게 더욱 큰 손해를 입히는 원인입니다.

HTTP 공격 기술을 사용하여 실행하기 위한 조건.

a) 공격자들은 TCP SYN packet 의 Generating 에 의해 TCP connection 을 시작합니다.

b) 그때 ACK 를 보내고, 그리고 다음과 같이 GET 명령을 보냅니다:

GET /Gallerys/java/45/stat.php?id=1020880659&v=1.0 HTTP/1.1

c) 공격자들은 Victim 서버들을 끊임없이 응답하게 하기 위해서 반복적으로 GET request를 반복적으

로 보낼 것입니다.

공격 발생 일 때

공격의 한 형태로서 공격자들은 높은 비율의 공격 Packet을 Generate할 필요가 있습니다.

매번 HTTP GET이 Generate되기 전에 TCP SYN이 먼저 Generate 된 다는 것은 반듯이 명심해야 됩니다,

그렇기 때문에 종종 HTTP 공격이 이 기술을 사용하여 또한 같은 HTTP GET 요청비율의 TCP SYN RATE

flood의 원인이 됩니다.

RIOREY의 공격에 대한 대응

HTTP 요청이 매번 오기 전에 TCP SYN이 먼저 오기 때문에, RIOREY는 빠르게 SYN Rate 요청을 초과하는것을 탐지 합니다, 그리고 TCP connection을 거절 할 것입니다.

이것은 매우 효과 적인 방법이며, 그것은 뿐만 아니라 HTTP 공격도 처리하고 또한 많은 다양한 TCP

connection을 기반으로 하는 Application 공격을 차단할 것입니다.

CC Attack

CC 공격

예를 들어 많은 ISP는 공격 동안에 많은 Victim IP address들의 변경을 통해서 HTTP 공격을 방어하고 있

습니다.

정상적인 컴퓨터에서는 일단 URL을 찾아 보면 그것은 악의의 탐색을 피하기 위해 IP address를 은닉하게

될 것입니다.

ISP가 Victim IP를 변경 했을 때, 그것은 Cache의 시간이 만료될 때까지 약간의 교체 주기를 만들어 내게

될 것입니다.

예를 들어 공격의 추적기능을 지금 사용해 보면:

GET /Gallerys/java/45/stat.php?id=1020880659&v=1.0 HTTP/1.1

User-Agent: SickleBot

Host: gernhardts.com

Cache-Control: no-cache

HTTP/1.1 200 OK

Date: Sat, 14 Jan 2006 21:43:18 GMT

Server: Apache/1.3.33 (Unix) mod_log_bytes/0.3 FrontPage/5.0.2.2635 PHP/4.3.11 mod_ssl/2.8.22

OpenSSL/0.9.7c

X-Powered-By: PHP/4.3.11

Connection: close

Transfer-Encoding: chunked

Content-Type: text/html

eG1/ZwEGf2R4eHwBBn9/dWIBBn5keHh8LDUsYWVgYGVjYmhjYGBtfmRjYWl8bWtpIm9jYQEGfn91Yiw/LGFlYG

BlY2JoY2BgbX5kY2FpfG1raSJvY2EBBm==

위의 예와 같이 변동 추적을 사용하면, 공격자들은 Victim IP 변경을 지금 추적하고 공격을 방어한 ISP에

대해서 노력을 헛되이 만들어 버릴 수 있습니다.

이와 같이 위의 변동은 하나의 SYN 을 계속하고 있고 그렇기 때문에 RIOREY의 SYN RATE Limit는 Cache control의 상태를 알 필요가 없고 공격의 다양함을 대신해서 똑같이 효율적으로 공격을 막아 낼 수가 있습니다.

공격에 대한 SYN RATE를 이용한 대응

TCP SYN Rate를 적당히 사용하기 위해서는, SYN RATE Limit를 올바르게 사용해야 합니다. SYN RATE는

RX Box안에서 IP address의 쌍(서버-클라이언트) 사이에서 SYN Rate로 정의 됩니다.

그렇기 때문에 그것은 서버가 아닌 클라이언트의 행동을 주의 깊게 보게 됩니다.

또한 서버에 연결된 한 명의 클라이언트이든지 또는 서버에 연결된 1000명의 클라이언트이든지, RIOREY SYN RATE는 각각의 클라이언트에 독립적으로 동작하게 될 것이며 이러한 방법을 사용하면 Application 의 형태는 SYN RATE에 의해 정의 될 수 있습니다. 그것은 서버에 연결된 수많은 클라이언트가 아닙니다.

예를 들어, 정상적인 웹 접속에서, 한 클라이언트 IP에 대한 SYN RATE는 10보다는 크게 될 것이며 이것

은 분당 SYN입니다. 다른 Application은 한 클라이언트들에 다른 SYN 비율을 갖게 될 것입니다.

SYN RATE levels을 정하면, 정상 작동 상태에서 네트워크를 관찰해야 합니다. RX는 당신의 네트워크에 분 당 SYN RATE를 권고 해 줄 것입니다. 당신은 당신의 Application에 대한 IP들의 주위에서 정상적인 SYN RATE의 집단을 보게 될 것 입니다.

Per IP SYN Rate Limit" 는 대략 정상적인 SYN RATE의 집단의 상위 10% 또는 최저 10 ppm 에서 정하고, 그리고 그때 "Max SYN Rate" 는 "Per IP SYN Rate Limit" 위의 대략 10% 또는 최저 10ppm 에서 정해질 것이다.