나무모에 미러 (일반/어두운 화면)
최근 수정 시각 : 2024-10-24 22:46:42

분산 반사 서비스 거부 공격

DRDos에서 넘어옴

파일:나무위키+유도.png  
DRDos은(는) 여기로 연결됩니다.
운영체제에 대한 내용은 DR-DOS 문서
번 문단을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
참고하십시오.
1. 개요2. 상세3. 특징
3.1. 더 향상된 은닉3.2. 증폭 공격의 구현
4. 현황

1. 개요

DRDoS (Distributed Reflection Denial of Service Attack, 분산 반사 서비스 거부 공격)

IP Spoofing을 이용한 서비스 거부 공격 중의 하나이다. DDoS와 거의 동일하지만 좀비들을 중점으로 사용하는 대신 Internet Protocol의 약점과 서버들의 응답성을 악용해 공격을 수행한다. DDoS와 거의 비슷한 2000년대 극초반에 발견된 생각보다 매우 오래된 유형의 공격이다.

2. 상세

IP 헤더에 들어가는 송신자 IP 주소를 피해자의 IP로 조작하여, 정상적인 서비스를 하는 서버들에게 서비스를 요청한다.[1] 그렇게 하면 일반적으로 서버들은 패킷의 송신자 IP를 보고 그 IP로 응답을 하는데 이로 인해 서비스를 요구하지도 않은 피해자에게 이에 대한 모든 응답이 되돌아가게 된다. 이를 이용해 피해자에게 대량의 트래픽을 유발, DDoS 공격의 형태로 만든 것이 바로 DRDoS이다. 여기서 IP가 위조된 패킷을 받아 피해자에게 의도치 않게 공격을 가하게 되는 서버들을 반사체나 반사자(Reflector), 또는 반사 서버(Reflection Server) 라고 하며, 인터넷 상에 연결 되어 외부의 요청에 대한 응답을 하는 어떠한 컴퓨터라도 반사체로 악용 될 가능성이 있다. 물론 여러분의 PC도 반사체가 될 수 있다.

일반적으로 UDP 기반 프로토콜들이 악용된다. TCP 기반 프로토콜들은 일반적인 조건에선 TCP의 특성으로 인해 DRDoS 공격을 구현하는 것이 거의 불가능하고[2] 그 외의 프로토콜들은 로컬 네트워크에서만 구현되거나 가용할 반사체 자체를 찾기 어렵다. TCP 자체만으로는 첫 연결 시도 시 상대가 최대 3회 응답을 시도하는 동작을 악용할 수 있으나 2000년도 중반 이후로는 전문적인 DoS 방어 서비스 및 네트워크 규모의 폭발적인 성장으로 현재 시점에선 유의미한 공격력을 내기 힘들다.

인터넷 품질이 과거에 비해 충분히 안정적이고 DRDoS 등의 프로토콜 취약점 악용 사례가 잘 알려져있으므로 현재 사용되는 대부분의 상용 프로토콜들은 TCP를 기반으로 하며, UDP를 기반으로 할 경우에도 소프트웨어 수준에서 연결 검증 동작을 하도록 설계 되어 프로토콜이 취약하지 않도록 하고 있다.

3. 특징

DRDoS가 일반적인 DDoS와 차별되는 특징은 크게 두가지가 있다.

3.1. 더 향상된 은닉

IP Spoofing만 되어 있어도 귀찮아지는데 중간자 역할을 하는 반사체까지 끼어 있어서 DDoS에 비해 공격 근원지를 찾아내기가 훨씬 까다롭다. 실제로도 직접적인 공격을 가하는 시스템은 반사체인데 이들은 공격자에 대한 정보를 전혀 가지고 있지 않을 뿐더러, 공격자가 발생시키는 공격 트래픽이 피해자에게 직접 전달 되지도 않기 때문에 공격이 끝나고 피해 서버에 남아있는 로그로 추적해보려고 해도 공격자에 대한 정보를 찾을 방법이 없다. 그러다보니 어떻게든 공격이 끝나도 추적이니 뭐니 하면서 후처리가 가능한 DDoS와는 달리 DRDoS는 일단 공격이 끊기면 단기적인 공격은 사후처리가 사실상 불가능하다는 특징이 있다.

당연히 공격자가 무조건 안전한 것은 아니다. 다른 이유로 인해 공격자가 노출될 수도 있고 어차피 트래픽은 ISP 업체의 라우터를 통해 흘러다닐 수밖에 없기 때문에 공격 트래픽이 모니터링 될 가능성도 있다. DDoS에 비해서 더 많은 대비와 신속한 대응을 필요로 하지만 어찌됐든 공권력으로 쥐잡듯이 뒤져보면 다 찾을 수는 있기 때문에 장기적인 공격을 계획하는 공격자 입장에서는 이 특징이 크게 의미가 없다.

또한 보통 수천개의 반사체들을 루프를 돌리면서 공격을 하게 되는데 라우터에 문제를 일으키는 경우도 종종 있으며 그 흔적이 명백하게 남아 ISP가 일단 하겠다고 마음 먹으면 에이전트들의 위치를 특정하기가 쉽다는 문제도 있다.

3.2. 증폭 공격의 구현

반사체의 응답 트래픽이 방어자에게 돌아간다는 원리를 응용하여 실제 공격시에 반사체로부터 가능한한 큰 응답을 끌어내 공격 규모를 극적으로 향상시킬 수 있다. 즉, 공격자가 시도한 공격 규모에 비해서 피해자가 실제로 받는 공격 규모가 커진다. 문제는 이게 단순히 2배 3배 수준이 아니라 적어도 수십배, 많으면 수백배씩 말도 안되게 상상도 못할 수준으로 공격 규모가 커질 수 있으며,[3] PPS[4] 증폭까지 덤으로 발생한다는 것이다. 이로 인해서 실제 공격자가 단독으로 공격을 전개하더라도 어지간한 DDoS 이상의 공격 규모가 구현되고 좀비PC까지 동원해서 구현되기라도 하면 수백Gbps~수Tbps급의 국제적 규모가 되어버려 매우 심각한 문제를 일으키고 있으며, 이정도가 되면 방어 설정을 할 수 있고 없고가 문제가 아니라 공격 크기 자체가 문제가 된다.[5]

4. 현황

위에 서술한대로 보자면 뭔가 엄청난 기술같지만 생각보다 전망이 좋지는 않다. DDoS보다 동작 조건을 만족시키기 어렵고 성능에 영향을 주는 변수가 많다보니 오히려 일정 이상의 공격 규모부터는 역효과가 나기 쉽기 때문이다. 특히 증폭을 통해 공격력이 뻥튀기 되는 만큼 에이전트로 쓸 수 있는 시스템도 이에 반비례해서 적다보니 절대적인 규모도 DDoS에 비해 그다지 이득을 보기 어렵고 반사체들은 시간이 지날수록 약점이 보완되는데다 증폭 특성을 만드는 각종 프로토콜의 결함들도 시간이 지남에 따라 보완이 이루어진다. 이렇게 되면 절대적인 반사체들의 쪽수가 확 줄어들기 때문에 한번 노출된 방법으로는 테라비트 단위의 대규모 공격을 만들기가 상당히 힘들다.[6] 원리 자체가 다른 시스템을 간접적으로 이용하는 것이고 인터넷 서비스는 변화가 굉장히 빠르기 때문에 어줍잖은 지식으로는 제대로 된 공격을 성립시키기 어려워서 변화에 적응할 능력이 없는 툴키디들이 범접하기 힘든 영역이다.[7]

더불어 DRDoS 공격은 IP Spoofing이 가능함을 전제로 하는데 Windows는 이미 2002년 XP 서비스팩 2부터 이를 차단하고 있으므로 일반적인 방법으로는 애플리케이션 수준에서 IP Spoofing을 구현하는 것이 불가능하다. 물론 이는 운영체제의 제약이므로 네트워크 드라이버를 로드하여 IP Header를 위변조함으로써 우회할 수 있지만 드라이버의 로드는 관리자 권한을 요구할뿐더러 설령 권한이 있더라도 서명되지 않은 드라이버는 차단되고 때로는 재부팅이 요구되기도 한다. 이 때문에 억지로라도 좀비 PC들로 DRDoS를 구현하기 위해서는 보통 상용 드라이버들을 악용하는 수밖에 없는데 당연히 구현이 매우 까다로울 뿐더러 백신에 의해 얼마든지 손쉽게 드라이버가 언로드 될 수 있고 공격자가 통제할 수 없는 요인으로 인해 좀비 PC가 무력화 되기 쉽다는 문제가 있다.[8]

또한 설령 힘들게 드라이버를 올려서 IP Spoofing을 구현하더라도 한국의 가정집들에 어지간해선 달려있는 공유기와 모뎀을 통과하지 못하거나 문제가 발생하는 경우도 많고,[9] 이것까지 돌파하더라도 네트워크 장비들이 발달함에 따라 ISP의 종단 라우터가 이를 필터링 해버리는 경우도 많다. 라우터 단에서의 IP Spoofing 차단은 무슨 짓을 해도 회피할 수 없으므로 이 경우엔 IP Spoofing은 물리적으로 구현할 수 없다고 보면 된다.[10] 이처럼 기본 전제조건인 IP Spoofing이 가능한 시스템은 매우 희귀하여 이를 만족할 수 있는 시스템을 구하는것 조차 큰 어려움이 있다.

DRDoS는 상용 프로토콜의 취약점을 악용한다는 특성상 공격 트래픽을 정상 트래픽으로 위장시키는 것이 불가능하고 능동적으로 패킷을 생산할 수 없다. 따라서 탐지가 매우 쉽기 때문에 대부분의 방어장비에 의해 사실상 확정적으로 막히게 되며, 이로 인해 공격 규모가 충분히 크지 않으면 일반적인 DDoS보다도 효과적이지 않을 수 있다. 또한 보통 반사체의 물리적 위치가 지역적이지 않고 전세계에 걸쳐 퍼져있기 때문에 분산 방어에도 굉장히 약해서 국제적인 DDoS 방어 서비스[11]에는 아무리 공격 규모가 커도 타격을 주기 어렵다. 실제로도 2018년 2월 28일에 GitHub가 받았던 1.35Tbps급 공격도 규모만으로는 인터넷 역사에서 손에 꼽았지만 간헐적인 서버 장애를 일으키는 수준의 피해 밖에 주지 못했다.

2015년 이후부터는 DRDoS 공격에 자주 악용되던 프로토콜들이 보완됨에 따라 평균 공격 빈도와 규모가 점점 감소하는 추세이며 2024년도 이후부터는 사실상 주류에선 밀려났다. 위에서 언급했듯이 정말 꾸준한 관리를 해야 되는데다가 어떤 식으로든 좀비 PC를 위시한 봇넷이 있어야 대규모 공격이 가능한데 DRDoS를 활용할 수 있는 좀비 PC를 대량으로 만들고 유지하기가 무척 골치아프기 때문이다. 특히 사물 인터넷이 발달함에 따라 PC뿐만이 아니라 여러 솔루션의 시스템을 DDoS 공격에 참여시켜 압도적인 쪽수로 밀어버리는 방법이 유행하고 있다. 그러나 DRDoS는 일단 세팅만 적당히 되면 써먹기가 편리한 점 때문인지 쉽게 사라지지는 않는 상황이며, 증폭 가능한 취약점이 발견되면 어마어마한 증폭배율로 막대한 트래픽을 생성하기에 최고 공격 규모 역시 대부분 DRDoS 공격이 갱신하고 있다.


[1] 쉽게 설명하기 위해 뭔가를 요청한다는 뉘앙스로 썼지만 어찌됐든 서버에게서 뭔가 응답을 받을수만 있으면 된다.[2] TCP는 통신하는 과정에서 SYN, ACK Number라는 무작위 값을 주고 받으며 올바른 수신이 이루어졌는지를 검증하는데 IP Spoofing 된 패킷은 송신자 측에서 수신자의 응답을 기대할 수 없으므로 제대로 된 반사 동작을 성립시킬 수가 없다.[3] DNS 기반일 경우 최고 57배, NTP는 964배의 증폭 공격이 가능하다. 즉, 100Mbps의 일반 가정집 회선으로도 NTP 기반 DRDoS 공격을 전개하면 이론상으로는 컴퓨터 단 1대로 약 100Gbps 규모의 DDoS 공격을 발생시킬 수 있다는 것이다.[4] Packet per Second, 초당 패킷 수[5] 방어장비는 화살을 막는 방패마냥 무조건 공격을 막아주는게 아니라 들어오는 쓰레기 트래픽을 필터링하여 하위망의 가용성을 지키는, 일종의 거름망 같은 기능을 하는 장비다. 방어장비 상단의 회선 용량마저 초과할 수준으로 큰 공격이 들어와버리면 방어장비고 뭐고 다 무용지물이다.[6] 프로토콜에 따라 다르지만 대부분 악용되는 반사 서버들의 세팅을 약간 조정해줌으로써 손쉽게 무력화 된다. Memcached 기반 공격의 경우, 취약한 Memcached 서버의 캐시를 무효화하는 방법으로 아예 방어자가 증폭 공격 자체를 원천 차단할 수 있다.[7] 최근 깃허브 등지에 DRDoS 공격을 수행하는 스크립트등이 올라와 툴키디들이 이를 어설프게 사용하는 경우가 있으나 상술했다시피 정말 전문적인 지식과 까다로운 조건이 요구되므로 유의미하게 사용하기가 매우 어렵다.[8] 예를들어 드라이버 제조사가 서명을 갱신하기라도 하면 해당 드라이버는 로드할 수 없게 된다.[9] 가정집 수준의 장비들은 CPU 사양과 메모리가 충분하지 않아 수천 수만개에 달하는 커넥션 자체를 감당을 못한다. 때문에 공격을 시작하는 순간 해당 장비들이 다운되면서 인터넷이 단절되기도 한다.[10] IP Spoofing 자체는 대단한 기술 같은게 아니고 단순히 IP Header의 Source IP만 바꿔주는 것일 뿐이다. 그렇게 Source IP가 변조된 패킷을 외부로 내보낼 수 있느냐가 문제이기에 IP Spoofing은 강제한다는 개념이 논리적으로 있을 수 없으며 그냥 온갖 장비들을 무사히 통과하기를 기도하는 것 말고는 공격자가 할 수 있는 일이 없다.[11] OVH, AWS 등등