DoS 공격 이론 및 대처 방법(레지스트리 변경)

DoS는 일반인들에게는 생소한 개념이었지만 2000년 2월 amazon.com, eBay, Yahoo 그리고 그 밖이 다른 유명한 전자상거래 관련 사이트들이 2일 동안 지속적으로 DDoS라는 DoS의 변종공격을 받아 운영이 불가능한 사건이 발생하면서 DoS란 개념이 일반인들에게 점차 인식되기 시작하였다.

 

DoS는 대부분 외국의 유명사이트를 공격목표로 삼고 있지만, 초고속 인터넷 기술이 발달한 우리나라의 사이트들도 DoS 공격의 좋은 목표이며, 최근에는 국내 모 ISP업체의 해외망이 DoS 공격을 받아 가입자들이 피해를 입은 사례가 있었다.

그리고 전세계 인터넷 트래픽을 관장하는 미국 내 13개 루트 서버가 DDoS 공격을 받아 그 중 9대가 일시적으로 정상 작동이 불가능한 사례가 발생했으며, 공격의 진원지로 인터넷 사용자 수와 초고속 인터넷 보급율이 높은 우리나라와 미국이 제기되기도 했다.

위에서 잠깐 언급한 국내의 모 ISP 업체의 피해처럼 DoS 공격의 심각성은 비단 남의 일만은 아니다. 이에 기업들은 문제의 심각성을 깨닫고 자사의 네트워크를 보호하기 위해 IDS나 방화벽 같은 보안시스템을 도입하고 자체 CERT를 조직하여 운영하고 있지만 개인이 운영하는 웹서버는 상대적으로 DoS 공격에 대해 취약하다.

따라서 이번에는 Windows 2000을 기반으로 한 웹서버에서 어떻게 하면 DoS 공격으로부터 웹서버를 보호할 수 있는지 알아보자.


1. DoS/DDoS란 무엇인가?

DoS(Denial of Service)도 사용자들에게 피해를 준다는 점에서 크래킹의 한 종류라고 할 수 있지만, 요즘 인터넷으로 배포되는 공격 프로그램을 이용하면 전문 지식이 없어도 공격이 가능하기 때문에 그 방법이 비교적 간단하지만 그 피해 범위와 정도는 매우 광범위하다. DoS의 주요 공격 대상은 시각적인 서비스를 하는 웹서버나 라우터, 네트워크같은 기반 시설이다.

DoS는 한 사용자가 시스템의 리소스를 독점하거나 모두 사용, 또는 파괴함으로써 다른 사용자들이 이 시스템의 서비스를 올바르게 사용할 수 없도록 만드는 것을 말한다. 이런 의미에서 시스템의 정상적인 수행에 문제를 일으키는 모든 행위를 DoS라 할 수 있다.

그런데 이런 공격이 일어나는 방법은 매우 다양하다. 이 공격은 고의적으로 발생할 수 있지만 사용자의 의도와는 무관하게 발생할 수도 있으며, 공격자는 서비스 요구를 통해 서비스 중단을 초래할 수 있다. 예를 들어 공격자가 1초당 10개의 메일을 받을 수 있는 서버에 초당 20개의 메일을 보내면 공격 대상이 된 메일 서버는 메일을 제대로 전송하지 못할 것이며, 20개보다 훨씬 많은 메일을 보낼 경우엔 서버가 다운될 수도 있다.

▲ DoS 공격 구조

DDoS 공격은 DoS의 또 다른 형태로, 인터넷에 연결된 일련의 시스템들을 이용해 단일 사이트에 대한 플러드 공격을 시도하는 것이다. 해커들이 일단 취약한 인터넷 시스템에 대한 액세스에 성공하면 침입한 시스템에 소프트웨어를 설치하고 이를 실행시켜 원격에서 공격을 개시한다. 최근 DDoS 공격이 민간 기업이나 공공기관 시스템에서 실행되고 있지만, 해커들은 대학 네트워크의 개방적인 분산 속성 때문에 대학 네트워크를 실행 사이트로 자주 사용하는 경향이 있다.

▲ DDoS 공격 구조

 

 

 

2.DoS 공격 유형

 

DoS 공격이라고 불리는 일련의 공격 패턴들은 전자상거래나 각종 컨텐츠와 같은 인터넷상의 귀중한 자원들을 위협하고 있다. DoS 공격은 직접적으로 사용자 계정 또는 시스템의 데이터를 장악하기 위한 방법이라기 보다는 계획적으로 컴퓨터 자원들을 다운시키거나 ICMP, UDP, TCP의 데이터 패킷들을 사용해 서버에 많은 양의 네트워크 트래픽을 전송함으로서, 사용자들이 사이트에 접근하지 못하도록 자원을 고갈시키는 유형에서부터 non-RFC-Compliant 패킷을 이용해 운영 시스템의 동작을 멈춰버리게 하는 유형까지 다양한 방법이 존재한다.

(1) SYN Flood 공격

기본적으로 서버와 클라이언트 사이에 통신은 아래 그림과 같은 구조로 이루어져 있다.

▲ 3-Way Handshake 구조

1) 클라이언트는 일련번호와 패킷크기를 포함한 정보를 서버에 전송하여 연결을 시작한다.
2) 서버는 클라이언트가 보낸 세션 정보로 응답한다.
3) 클라이언트는 서버로부터 수신한 정보에 동의하고 승인한다.

서버에 수천 개의 TCP 접속(SYN) 요청 메시지를 보낸다. 이 때 이 패킷내부의 소스 IP 주소를 속이거나, 인터넷 상에서 사용하지 않는 IP 주소값으로 변형한다. 그러면 서버는 새로운 접속을 맺기 위해 실제로는 존재하지 않거나 동작하지 않는 IP 주소값으로 SYN/ACK로 응답을 한다.

서버는 SYN/ACK 응답을 보낸 클라이언트로부터 ACK가 올 때까지 기다리게 되는데, 서버는 ACK 메시지를 받지 못하게 된다. 이렇게 되면 서버는 ACK 받을 때까지 버퍼와 같은 자원을 계속 종료하지 않고 열어두게 되는데, 계속 누적될 경우 결국은 시스템이 다운되거나 서비스를 중단하는 사태가 발생하는 것이다.
Syn Flood에 대한 대응요령은 후반부에서 알아본다.

▲ DoS Syn Flood 공격에 사용되는 도구

▲ DDoS Flood공격에 사용되는 도구

(2) Smurfing 공격

Smurfing 공격은 그 광범위한 효과로 인하여 가장 무서운 DoS 방법 중에 하나이며, IP와 ICMP의 특징을 이용한다. 브로드캐스트 핑 요구는 네트워크 주소나 네트워크 브로드캐스트 주소에 직접 보내질 수 있다. 만약 192.168.0.0/24 범위를 가진 네트워크가 있다면, 네트워크 ID는 192.168.0.0될 것이고 브로드캐스트용 주소는 192.168.0.255가 될 것이다. 브로드캐스트는 전형적으로 지정된 범위 내에서 조정된 각각의 주소 없이 무엇이 활동하는지 진단할 목적으로 사용된다.

Smurfing 공격은 직접적인 브로드캐스트와 세 가지 구성요소인 공격자, 증폭 네트워크와 표적을 최대한 이용한다. 공격자는 증폭 네트워크의 브로드캐스트 주소로 공격 서버가 요구하는 것처럼 패킷들의 원본 주소를 위조하여 ICMP ECHO 패킷을 전송하고, ICMP ECHO 패킷을 수신한 증폭 네트워크 내의 모든 시스템은 공격 서버에 응답을 하게 된다. 만일 공격자가 브로드캐스트 핑에 응답할 100개의 시스템을 가진 증폭 네트워크에 하나의 ICMP 패킷을 보내게 되면, 공격자는 100만큼의 효과로 DoS 공격을 할 수 있다.

이 공격과 상이한 형태의 Fraggle 공격이라는 것이 있는데, Fraggle 공격은 방식은 Smurfing 공격과 비슷하지만 ICMP 대신 UDP를 사용한다는 것이 다른 점이다. 공격자들은 증폭 네트워크 내의 브로드캐스트 주소로 전형적인 포트 7(Echo)을 이용해 가짜 UDP 패킷을 전송한다. 에코가 가능한 네트워크 내의 각각의 시스템은 엄청난 트래픽을 생성하고 공격 서버로 응답을 보게 된다. 만약 증폭된 네트워크 내의 시스템에서 에코가 가능하지 않더라도 ICMP 도달 불능 메시지가 여전히 대역폭을 소모하게 될 것이다.

Smurfing 공격을 방어하기 위해서는 직접적인 브로드캐스트를 경계 라우터에서 사용할 수 없게 만들어야 한다.

(3) 응용 프로그램 서비스 DoS 공격

대부분의 공격들은 희생자의 서버에 있는 낮은 레벨의 자원에 초점을 맞추지만, 거의 모든 프로그램상의 버그는 DoS 취약점을 야기시킬 수 있다는 사실을 명심해야한다. IIS와 같은 응용프로그램 도구는 특히 이런 공격에 취약하다.

- WebDAV Propfind DoS

2001년 중반 IIS 5.0를 사용하는 시스템에서는 WebDAV의 잘못된 요청으로 인해 IIS가 DoS를 일으킬 수 있는 취약성이 Georgi Guninski에 의해 처음 발견되었다.

MS에서는 WebDAV Propfind DoS에 대한 패치를 마련하였지만, 기본적으로 WebDAV기능을 사용하지 않을 것을 권하고 있다. 물론 WebDAV를 사용하지 않도록 하면 다음과 같은 기능을 사용하지 못할 수 도 있다.

- 웹 폴더
- 오피스를 사용하여 웹사이트 발간
- Digital Dashboard를 이용하여 IIS 5.0 서버 모니터링

반드시 WebDAV가 필요하지 않다면 IIS의 모든 확장된 기능들을 사용하지 않도록 해야만 한다. 이런 한가지 예방법을 통해 현재 그리고 나중에 발생할 수도 있는 많은 보안 취약점들로부터 시스템을 보호할 것이다.

참고로 누군가 Propfind DoS를 사용하여 서버를 공격하고 있다는 사실을 알기 위해서는 PROFIND / -500 엔트리에 대한 IIS로그를 확인하도록 한다.

자세한 사항은 아래 주소를 참고한다.

MS01-016 : http://www.microsoft.com/korea/technet/security/bulletin/MS01-016.asp
Q241520 : How to Disable WebDAV for IIS 5.0

(4) LAN기반 DoS 공격

여러분이 네트워크를 운영하고 있다면 LAN기반의 DoS 공격의 위험성도 간과해서는 안 된다. 상당수의 시스템이 웹서비스를 하면서 불필요한 프로토콜 및 서비스를 설치해 놓은 경우가 많다. 이는 LAN 기반의 DoS 공격뿐만 아니라 프로토콜의 고질적인 문제로 인해 외부의 DoS 공격 및 내부 네트워크의 정보가 외부로 유출될 수 있는 위험성이 있다.

1) NetBios Name Release DoS

몇 가지 LAN 기반 Windows 2000 DoS 공격 중에서도, 대체로 윈도우 네트워킹의 핵심역할을 하는 NetBios 프로토콜을 사용한다. NetBios의 고질적인 문제점은 신뢰성이 없고, 인가되지 않는 서비스에 의존한다는 점이다.

예를 들어, NetBios Name Service(NBNS)는 NetBios 이름에 대한 IP주소를 찾아주지만 반대로 쉽게 속일 수 있기 때문에, NetBios 이름에 대한 등록을 요청하거나 특정 호스트에 name release 패킷을 보내 네트워크 상에서 적법한 클라이언트의 접속을 끊게 만들 수 있다. 다시 말해 이런 패킷을 수신한 클라이언트는 공유자원 접근, 도메인 인증 등을 포함하여 NetBios 네트워크에 참여할 수 있는 능력을 잃게 된다.

아래 그림은 NetBios Name Release DoS 공격을 받은 시스템의 NetBios name service 상태를 확인한 것이다.

대부분의 NetBios 관련 문제와 마찬가지로, 이런 공격을 막기 위해서는 계층상에서 방어체제를 마련하는 것이 좋다. 즉 웹서버의 성능이나 보안성을 고려했을 때 불필요한 프로토콜 및 서비스(특히 NetBios와 관련된)는 반드시 제거되어야 한다.

위 두 메뉴의 체크표시를 없애거나 제거하면 아래 그림과 같은 결과가 출력된다.

위와 같이 하면 NetBios의 고질적인 문제로 인한 보안상의 문제는 어느 정도 해결될 것이다. 그러나 꼭 NBNS/WINS 서비스를 사용해야 한다면 Windows 2000 IPSec 필터를 통해 UDP 137∼139으로 송·수신되는 트래픽을 인증하도록 설정해야한다.

또한 호스트 레벨에서 다음과 같은 레지스트리 값을 설정한다.

HKLM＼SYSTEM＼CurrentControlSet＼Services＼NetBT＼Parameters
NoNameReleaseOnDemand
Reg_DWORD = 1

2) Windows RPC Service DOS

RPC(Remote Procedure Call)란 한 프로그램이 네트워크 상의 다른 컴퓨터에 위치하고 있는 프로그램에 서비스를 요청하는데 사용되는 프로토콜로서, 이때 서비스를 요청하는 프로그램은 네트워크에 대한 상세 내용을 알 필요가 없다(절차 호출이란 때로 함수 또는 서브루틴 호출의 의미로도 사용된다). RPC는 클라이언트/서버 모델을 사용하는데, 서비스를 요청하는 프로그램이 클라이언트이고, 서비스를 제공하는 프로그램이 서버이다. 다른 정상적인 또는 자체적인 프로시저의 호출과 마찬가지로, RPC도 요청하는 프로그램이 원격 절차의 처리 결과가 반환될 때까지 일시 정지되어야 하는 동기 운영이다. 그러나, 가벼운 프로세스의 사용이나, 같은 주소공간을 공유하는 스레드 등은 여러 개의 RPC들을 동시에 수행될 수 있도록 허용한다.

RPC서버는 자신이 수신한 내용을 검증하지 않기 때문에 클라이언트로부터 잘못된 RPC 패킷을 수신할 경우, 정상적인 RPC 요청에 대해서는 응답할 수가 없으므로 서비스가 중단되는 문제가 발생한다.

RPC 서비스의 DoS 취약성은 패치를 하더라도 완전히 해결된 것이 아니다. 최근에 보고된 RPC 서비스의 DoS 취약성에 관한 내용을 보면 sp3를 적용한 윈도우 2000에서도 존재한다는 것을 알 수가 있다.

Windows 2000의 DCE-RPC 스택 내에 존재하는 RPC서비스의 DoS취약성은 공격자가 목표 시스템의 TCP 135번 포트를 통해 공격함으로써 RPC 서비스를 중지시킬 수 있게 한다. RPC 서비스가 중단된 시스템은 더 이상 새로운 RPC 요청에 대해서는 응답하지 못하며 거의 모든 기능이 중단될 수도 있다.

RPC 서비스의 DoS 취약성을 해결하기 위한 제일 좋은 방법은 "직접 RPC 서비스를 중지하면 해결되지 않을까"라고 생각할 수도 있겠지만, 직접 RPC 서비스를 중지하는 것은 좋은 방법이 아니다. 왜냐면 RPC 서비스도 운영체제의 일부이기 때문에 중지하게 되면 네트워크 서비스 및 제어판의 일부 기능을 사용할 수 없게 된다. 가장 좋은 방법은 방화벽을 사용해 TCP 135∼139, 445번 포트를 막아두는 것이다.

RPC서비스의 취약성관련 내용은 아래 페이지를 참고하기 바란다.