DoS 공격이라고 불리는 일련의 공격 패턴들은 전자상거래나 각종 컨텐츠와 같은 인터넷상의 귀중한 자원들을 위협하고 있다. DoS 공격은 직접적으로 사용자 계정 또는 시스템의 데이터를 장악하기 위한 방법이라기 보다는 계획적으로 컴퓨터 자원들을 다운시키거나 ICMP, UDP, TCP의 데이터 패킷들을 사용해 서버에 많은 양의 네트워크 트래픽을 전송함으로서, 사용자들이 사이트에 접근하지 못하도록 자원을 고갈시키는 유형에서부터 non-RFC-Compliant 패킷을 이용해 운영 시스템의 동작을 멈춰버리게 하는 유형까지 다양한 방법이 존재한다.
|
|
(1) SYN Flood 공격
기본적으로 서버와 클라이언트 사이에 통신은 아래 그림과 같은 구조로 이루어져 있다.
▲ 3-Way Handshake 구조
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로그를 확인하도록 한다.
자세한 사항은 아래 주소를 참고한다.
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으로 송·수신되는 트래픽을 인증하도록 설정해야한다.
또한 호스트 레벨에서 다음과 같은 레지스트리 값을 설정한다.
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서비스의 취약성관련 내용은 아래 페이지를 참고하기 바란다.
