➽ 대응 방안 ① 출발지가 조작된 IP 차단 ② 패킷의 임계치 설정 ③ 미사용 protocol, port 차단(80번 port를 사용하는 UDP는 존재하지 않음)
ICMP Flooding
icmp 프로토콜을 이용하여 네트워크 대역폭을 고갈시키는 공격이다.
➽ 대응 방안 ① 출발지가 조작된 IP 차단 ② icmp request 응답 차단
DNS Reflection
DNS 서버에 응답 값이 큰 특정 명령어를 지속 요청하여 해당 네트워크의 불필요한 트래픽을 유발시킨다. DNS query 시 ANY 명령은 해당 DNS가 줄 수있는 모든 정보를 요청하게 된다.
저 패킷에서의 특징은 DNS 응답에 ip가 존재하지 않았으며
DNS는 UDP 프로토콜을 사용하는데 3WAY를 한다는 점이였다. 그 이유는
DNS에 불필요한 데이터를 채워서 512Byte를 넘김으로 Tcp 프로토콜로 재질의가 됐기 때문이다.
(DNS 데이터가 512Byte를 넘기면 tcp 프로토콜을 사용한다.)
Reflector=반사라고 불리는 이유는 자신이 공격을 수행하지 않고 Reflector(DNS Server)를 사용하여 공격하기 때문이다. 다수의 DNS 서버를 이용하면 DNS Amplification(증폭) DDoS Attacks 라고 한다.
아래 패킷은 DNS Reflection 유형 두 번째다. 아까와는 달리 DNS가 512byte 이상인데 UDP로 전송되었다.
그 이유는 세 번째 패킷의 플래그셋을 봤을 때
Truncated: Message is not truncated 부분이 0으로 설정되어있기 때문이다.
➽ 대응 방안 ① DNS record는 반드시 접근 통제 절차를 통해서 허용
NTP Reflection
네트워크상에서 시간 동기화를 위한 network time protocol의 취약점을 이용하여 불필요한 트래픽을 발생시킨다. 특정 명령어(get monlist – NTP 서버에 접속한 IP 정보를 모두 요청) 실행시 요청대비 과도한 응답이 발생하는 취약점을 이용한다.
NTP 서버는 주로 사내 스위치에 연결되고 NTP 서버는 GPS를 달아서 정확한 시간을 가져온다.
➽ 대응 방안 ① 불필요한 명령어 차단 및 필요시 접근 통제 절차 후 사용
Smurf attack
스머프 공격은 라우터를 통해 다른 네트워크로broadcast 패킷을 전송하는
directed broadcast 기능을 악용한다.대상 서버에게 다량의 icmp reply 응답을 받게 함으로써
트래픽을 유발한다. 공격자는 출발지를 공격대상 서버 ip로 바꾸고 목적지를 공격대상 서버가 포함된 broadcast 주소로 설정한다(*.*.*.255)
➽ 대응 방안 ① 라우터에서 directed broadcast 기능을 차단 시중에 파는 라우터는 해당 기능이 default로 막혀있는데 필요하다면 접근 제한을 주어 사용할 수 있다.
자원 고갈
SYN Flooding
TCP 3 way handshaking의 취약점을 이용하여 서버의 backlog queue를 가득 채워서 정상 사용자의 접속을 방해하는 공격이다. 공격자는 출발지 IP를 조작하여 SYN 패킷을 공격대상 서버로 보낸다. SYN 패킷을 받은 서버는 조작한 IP로 SYN-ACK패킷을 보내고 backlog queue에 연결을 준비한다. 하지만 조작된 IP로 SYN-ACK를 받은 서버는 ACK 응답을 보내주지 않으므로 backlog queue가 가득찬 상태를 유지한다.
➽ 대응 방안 ① syncookie 설정 SYN 패킷에 cookie를 삽입하여 인증기능을 구현한다.
② First SYN Drop 첫번째 SYN 패킷은 무조건 DROP 한다. 정상적인 서버라면 SYN패킷을 재전송 하기 때문에 악성 행위자의 접속 시도를 막을 수 있다.
SYN-ACK Flooding
tcp 연결을 위해서는 최초 동기화(SYN) 패킷부터 전송해야 한다. 하지만 SYN 대신 SYN-ACK 패킷을 지속적으로 전송하여 불필요한 RST 패킷을 생성하게 만들어서 서버의 부하 증대를 유도하는 공격이다. 원래 방화벽에서 차단해야 하는데 굳이 대응해주는 경우 문제가 발생한다.
➽ 대응 방안 ① Anti DDoS 장비 설치 ② 조작된 패킷 차단
TCP Connection Flooding
3-way handshaking 후 아무것도 하지 않고 연결상태를 유지하여 정상 사용자의 접속을 방해한다. 정상 연결 후 어떤 행위도 하지 않기 때문에 악성 행위에 대한 판단이 어렵다.
연결된 세션들은 어떠한 접속도 없었고 I/O Graph 확인 결과 특정 시점에 tcp 연결이 과도하게 이루어 진 것으로 보인다.
➽ 대응 방안 ① 연결을 대신 유지해주는 캐시서버 구축 ② 연결 지속 time을 짧게 설정하여 불필요한 연결유지 방지 ③ 임계치 기반 차단
TCP Data Flooding
정상적인 3 way handshaking 후 의미없는 데이터를 모두 채워서(MTU) 전송한다.
※ PSH 플래그란?
채팅 프로그램은 실시간 응답 처리가 중요한데 이 때 받은 데이터를 차근차근 위 계층을 거치지않고 즉시 목적지인 응용 계층으로 전송하도록 하는 플래그다.
정상적인 연결이 성립된 후이기 때문에 악성 행위 여부를 판단하기 어렵다. 데이터 전송간 연결 성립/차단을 반복하고 있으므로 서버의 CPU/RAM 사용률이 증대된다.
➽ 대응 방안 ① 캐시서버 활용 ② 임계치 기반 차단
응용 계층 고갈
DNS Query Flooding
DNS Query를 다량으로 요청하여 대상 DNS 또는 관련된 보조 DNS까지 정상적인 서비스를 방해하는 공격이다. 공격자는 의도적으로 없는 DNS를 요청하여 대상 DNS에서 해당 주소를 찾느라 DNS 자원을 낭비하게 된다.
➽ 대응 방안 ① IP당 Query 요청에 대한 임계치 설정
GET Flooding
정상적인 3 way handshaking 후 특정 페이지를 짧은 시간안에 지속적으로 접속 요청한다.
➽ 대응 방안 ① 캐시서버 활용 ② 임계치 기반 차단
Slow HTTP Header DoS(Slowloris)
HTTP 요청을 비정상적으로 조작하여 서버가 요청을 받아 들이기를 무한히 기다리게 만든다. 서버는 불완전한 요청을 무한히 기다리게 되고, 이런 대기를 여러개 만들어서 정상적인 사용자의 접속을 방해한다.
이 공격을 이해하려면 HTTP의 구조를 알아야 한다.
HTTP에는 헤더와 바디가 있는데 헤더와 바디를 구분하기 위해서 개행문자(0d 0a)를 사용한다.
정상적인 구분자라면 위 패킷처럼 요청의 헤더 끝이 [0d 0a 0d 0a]가 나와야 한다.
그런데 슬로우리스 공격은 아래 패킷처럼 0d 0a가 하나 밖에 없으므로
요청 패킷에 대한 응답을 하지 못하게 된다.
HTTP 헤더와 바디를 개행으로 구분하는데 요청 헤더를 끝내지 않았으므로
서버는 요청을 계속 기다리는 상태가 되어 웹 서버의 자원을 소모하게 된다.
➽ 대응 방안 ① 출발지의 time-out 대기 시간을 조정 무한정 기다리지 않고 연결을 끊으면 정상 사용자인 경우 다시 접속 요청을 할 것이다.
Slow HTTP Read DoS Window Size는 수신 가능한 데이터 크기를 지정하는 플래그이다. 위 공격은 정상적인 3 way handshaking 후 데이터를 보낼 수 있는 window 사이즈를 매우 작게 만들어서 데이터의 전송시간을 아주 길게 만든다. 짧은 데이터 송수신에도 많은 시간이 소요되기 때문에 정상적인 사용자의 접속을 방해한다.
TCP Zero Window 패킷을 계속 보내는 이유는 라우터에서 자동으로 윈도 사이즈가 정상으로 설정되기 때문이다.
➽ 대응 방안 ① 출발지의 time-out 대기시간 조정 ② 연결 시간이 과도한 세션 시간 조정
Slow HTTP POST DoS - RUDY(R-U-DEAD-YET?)
RUDY는 HTTP 패킷의 Content-Length를 매우 큰 값으로 설정하여 서버의 부하를
유발시키는 공격 기법이다.
웹 서버는 Content-Length를 보고 이 크기 만큼의 Content를 받을 때까지대기 중인데
이를 악용하여 길이를 크게 설정하고 매우 소량의 Content를 일정 시간마다 보내어 딜레이를 준다.
위 패킷의 경우 공격자가 Content-Length를 100000바이트까지 설정하여 웹 서버로 보냈는데
웹 서버가 공격자로부터 받은 데이터는 그에 비하여 매우 적으므로
한 세션 당 대기 시간이 매우 길어진다.
RUDY의 공격 타겟은 HTTP Post 방식을 이용하는 웹 페이지를 대상으로 한다.
➽ 대응 방안 ① Session time-out 시간 조정 ②MAX Content-Length 값 조절
