Hacking 당했다. 이제 어떻게 할 것인가?

네트워크 공격 탐지, 무력화 그리고 공격으로부터의 회복

저자 : Alan Sugano

 마침내 금요일이다. 3일이라는 이 기나긴 주말에 그 동안 준비해 왔던 혼자만의 휴가를 실행에 옮겨볼 참이다. 그런데 사무실을 떠나기 직전에 어느 직원이 네트워크가 갑자기 느려졌다고 불평한다. 특히 인터넷을 이용하려고 할 때 이러한 증세가 나타난다는 것이다. 몇 군데 점검해 보니 정말로 네트워크와 서버가 믿을 수 없을 만큼 느려진 상태이다. 방화벽의 트래픽 통계를 점검해 보니 인터넷 트래픽이 비정상적임을 알 수 있었다. 서버에서 Netstat 명령을 실행하여 인증을 우회해 인터넷으로부터 온듯한 몇 개의 연결을 찾아 내었다. 서버의 레지스트리를 점검해보니 역시 몇 개의 이상한 프로그램이 자동적으로 로드 되도록 설정되어 있다. 그 동안 준비해왔던 휴가 계획은 또다시 취소되고 그 대신 산더미 같은 일감이 쌓여있는 주말이 눈에 보인다. 방금 해킹 당한 것이다.

 공격의 특징상 지금까지 쭉 해킹 당해 왔는지 혹은 그렇지 않은지 알아내기란 쉽지는 않다. 그러나 반대로 어디를 뒤져봐야 하는지 그리고 무엇을 살펴봐야 하는지 안다면 해킹을 찾아내기도 쉬울 것이며 또 다른 손해를 입기 전에 대책을 강구하기도 쉬울 것이다. 이제 여러분의 시스템을 망가트리는 악의적인 프로그램을 찾는 방법을 제시하고 해킹에 대한 복구 계획을 세우는 지침에 대해서 살펴보자. 필자는 이 모든 것을 세 개의 사례 소개를 통해 함께 제시할 것이며 이를 통하여 네트워크 해킹을 발견하고 해킹으로부터 피해를 복구하며 또한 향후에 발생할지 모를 또 다른 해킹으로부터 조직을 안전하게 보호할 수 있는 방안에 대하여 도움을 주고자 한다.

무엇을 살펴볼 것인가

분명히 뚜렷한 징후가 나타나기 전에 해킹을 찾아내어 중단 시키고 피해를 복구해야 할 것이다. 어디서부터 시작할 것인가? 모든 해킹은 참으로 독특하다. 그러나 항상 최우선으로 살펴보아야 할 곳은 있다. 다음은 첫 번째로 검사해 볼만한 핵심 요소들이다. 레지스트리 서브키. 만약 특정 시스템이 해킹 당했다고 의심되면 그 시스템의 레지스트리의 Run 서브키를 우선 살펴보아야 한다. 예상치 못한 프로그램이 이곳에서 로드 되고 있는지 찾아보아야 한다. 물론 해커들만이 악성 프로그램의 시작점으로 Run 서브키를 애용하는 것은 아니며 그 밖의 침입자 역시 이러한 서브키로부터 바이러스가 시작되도록 설정하는 경우가 있다. 이 서브키를 갖고 있는 운영체제는 윈도우 서버 2003, 윈도우 XP, 윈도우 2000, 윈도우 NT, 윈도우 Me 그리고 윈도우 9x이며 점검해야 할 서브키는 다음과 같다.

*HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run *HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce *HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices *HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServicesOnce
*HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run *HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce *HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices *HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce

만약 윈도우 2003, XP, Win2K 또는 NT 시스템을 운영하고 있다면 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows\CurrentVersion\Policies\Explorer\Run 서브키도 역시 점검해 보아야 한다. 숨어있는 대부분의 프로그램은 잠재적인 해킹 프로그램이라고 할 수 있다. 구글이나 그 밖의 다른 검색엔진을 사용하여 프로그램 이름을 인터넷에서 검색해 보면 그 프로그램이 적상적인 것인지 아닌지를 쉽게 알 수 있다. C 드라이브의 루트, C:\windows 그리고 C:\windows\system32에서 실행된 프로그램이 있다면 특별히 조심해야 한다. 앞의 레지스트리는 습관적으로 자주 점검할 것을 필자는 강력하게 권한다. 그래야 시스템에서 자동으로 로드 되는 모든 프로그램에 친숙해 질 수 있다.

다음 서브키는 비교적 해킹 프로그램에서 드물게 사용하는 곳이다. 그러나 이곳도 역시 점검해야 한다. 이들 서브키는 모든 Windows 운영체제에 존재한다. 만약 기본 레지스트리 키가 "%1" %*이 아닌 다른 값을 포함한다면 그것은 대부분 해킹 프로그램일 것이다.

* HKEY_CLASSES_ROOT\batfile\shell\open\command
* HKEY_CLASSES_ROOT\comfile\shell\open\command
* HKEY_CLASSES_ROOT\exefile\shell\open\command
* HKEY_CLASSES_ROOT\htafile\shell\open\command
* HKEY_CLASSES_ROOT\piffile\shell\open\command
* HKEY_LOCAL_MACHINE\SOFTWARE\Classes\batfile\shell\open\command
* HKEY_LOCAL_MACHINE\SOFTWARE\Classes\comfile\shell\open\command
* HKEY_LOCAL_MACHINE\SOFTWARE\Classes\exefile\shell\open\command
* HKEY_LOCAL_MACHINE\SOFTWARE\Classes\htafila\shell\open\command
* HKEY_LOCAL_MACHINE\SOFTWARE\Classes\piffile\shell\open\command

서비스. 모든 윈도우 운영체제의 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services 레지스트리 서브키를 점검해 보라. 이 서브키 하부의 내용은 컴퓨터에 설정된 서비스의 목록이다. 필자는 Windows의 Service GUI를 사용하지 말고 레지스트리의 이 부분을 직접 살펴볼 것을 권한다. 왜냐하면 어떠한 서비스(예를 들어 Type 1 서비스와 같은)는 Service GUI에는 나타나지 않기 때문이다. 여기에 또다시 낯선 프로그램이 있는지 점검해 보아야 한다. 가능하다면 서비스 서브키의 항목 그리고 그 값과 해킹으로부터 안전한 시스템의 그것과 비교해 보고 차이가 있는지 검토해 보는 것이 좋다.

시작프로그램 폴더. C:\Documents and Settings\All Users\Start Menu\Programs\Startup 폴더와 C:\Documents and Settings\user_name>\Start Menu\Programs\Startup 폴더를 점검하여 이상한 프로그램이나 숨김 속성을 갖는 파일이 있는지 살펴야 한다. 현재 폴더와 그 하위 폴더의 숨김 파일들을 보려면 명령 프롬프트에서 다음을 실행하면 된다. dir /a h /s

표1: XP 컴퓨터에 일반적으로 열려있는 포트

프로토콜	포트	설명
TCP	135/epmap	End Point Mapper Microsoft DCE Locator service
TCP	139/netbios-ssn	NetBIOS over TCP/IP
TCP	445/Microsoft-ds	Server Message Block (SMB)
TCP	1025	RPC
TCP	1566	Corel Video
TCP	3389	Windows Terminal Services
TCP	4520	Windows Update
TCP	5000	Microsoft Plug and Play (PnP)
UDP	445/Microsoft-ds	SMB
UDP	1026	Calendar Access Protocol
UDP	1027	Calendar Access Protocol
UDP	1029	Calendar Access Protocol
UDP	UDP	Unassigned
UDP	2967	SSC-Agent
UDP	123/NTP	Network Time Protocol
UDP	1900	Windows Messenger Broadcasts
UDP	137/Netbios-ns	NetBIOS Name Service
UDP	139/Netbios-dgm	NetBIOS Datagram Service

예약된 작업. C:\windows\tasks 폴더에 이상한 작업이 있는지 점검해야 한다. 여러분이 알지 못하는 어떠한 작업이 있는지 꼼꼼히 살펴야 한다. Win.ini. 악의적인 사용자는 C:\windows\win.ini 파일을 통해 해킹 프로그램이 자동으로 로드 되도록 설정해 놓기도 한다. Win.ini 파일의 다음 부분을 보면 된다.

[windows]Run=Load=

Run= 또는 Load= 뒤에 나열된 모든 프로그램은 Windows가 시작될 때 자동으로 로드 되는 것들이다.

System.ini. 해커들은 침입자들은 C:\windows\system.ini 파일 안에 프로그램을 로드 하기 위한 쉘 명령어를 삽입하기도 한다. System.ini 파일의 다음 부분을 살펴보자.

[boot]shell=explorer.exe <program name >

explorer.exe 뒤에 나타난 모든 프로그램은 Windows가 시작될 때 자동으로 시작된다. 해커들은 물론 그 밖의 다른 위치에서도 프로그램이 자동으로 실행되도록 하기도 한다. Sysinternals의 Autoruns 프리웨어 유틸리티를 사용하면 NT 이상의 운영체제에서 어떠한 프로그램이 운영체제가 시작될 때 자동으로 로드 되는지 알 수 있다. 이 유틸리티는 http://www.sysinternals.com/ntw2k/freeware/autoruns.shtml에서 다운로드 할 수 있다.

열린 포트와 인증 받지 않은 사용자들

해킹 활동이 있는지 검사하기 위하여 키와 그 위치를 모두 점검해 본 다음에는 예상치 못한 포트가 열려 있는지 또는 의심스러운 포트가 있는지 점검해 보아야 한다. 루트킷(Root kits)은 스텔스 프로그램으로써 운영체제 수준에서 실행되며 포트를 열어 침입자가 원격지에서 감염된 시스템을 조종할 수 있게 해 주는 프로그램이다. 루트킷이란 본래 유닉스 운영체제에서 널리 알려진 프로그램 형태인데 Windows 버전으로 만드는 해커들이 점점 늘고 있다. Windows 기반의 운영체제에서 연결되어 있거나 대기 상태의 포트를 보려면 명령 프롬프트를 열고 다음 명령을 실행하면 된다.

Netstat -a

[표 1]은 윈도우 XP 기반의 컴퓨터에서 일반적으로 볼 수 있는 열린 포트의 목록이다. 특정한 워크스테이션 또는 서버에 더 많은 포트가 열린 것을 발견해도 그다지 놀랄 필요는 없다. 포트란 본래 서비스의 종류에 따라 동적으로 더 많이 열리기도 하기 때문이다. 예를 들면 원격 프로시저 호출(RPC)은 원격지에서 DHCP 또는WINS 서버들을 관리할 때 포트를 동적으로 사용한다. 마이크로소프트의 웹사이트 http://support.microsoft.com/?kbid=15459에 소개된 기사 "How To Configure RPC Dynamic Port Allocation to Work with Firewall"을 참고하면 더 많은 정보를 얻을 수 있다. Netstat를 실행한 뒤에는 다음과 같은 사항에 주의하여 결과를 검토해 보면 된다.

* 많은 수(10개 혹은 환경에 따라 그 이상)의 연결이 이루어져 있는가. 특별히 회사 외부의 IP범위로부터라면 더더욱 의심해 보아야 한다.

* 예상치 못했던 열린 포트가 있는가. 특별히 높은 포트(예를 들어 1024 이상의)라면 의심해 볼만 하다. 해킹 프로그램과 루트킷은 원격 연결을 위하여 높은 번호의 포트를 자주 사용한다.

* SYN Flood 공격이 있을 때 흔히 나타나는 현상으로써 많은 수의 보류(Pending) 상태의 연결 시도가 있는가.

* 낯선 배치파일. 어떤 루트킷은 C:\, C:\winnt\, C:\windows\, C:\winnt\system32 그리고 C:\windows\system32 폴더에 배치파일을 만든다. 루트킷 또는 해킹 프로그램 가운데 어떤 것들은 휴지통(Recycle Bin)에 파일과 폴더를 만드는 것도 있다. 따라서 휴지통 안의 숨김 폴더 또는 이상한 폴더 역시 의심해 보아야 한다. 휴지통의 기본 위치는 C:\recycler 폴더이다. 휴지통을 비운 다음에도 남아 있는 파일과 폴더는 반드시 의심해 보아야 한다.

어떤 해킹 툴은 Netstat 명령어를 통해 볼 때 조차 열린 포트가 나타나지 않도록 하는 것도 있다. 만약 Netstat 명령어의 결과에는 나타나지 않지만 그래도 무언가 있다고 느껴진다면 Network Mapper(nmanp)와 같은 포트스캐너 툴을 사용해 보는 것도 바람직하다. Network Mapper는 오픈 소스 유틸리티로써

http://www.insecure.org/nmap에서 다운로드 받을 수 있으며 원격으로 원하는 컴퓨터에 열려 있는 포트를 볼 수 있게 해 준다. AD에 존재하는 악의적인 사용자. 해커가 시스템을 해킹할 때 보통 액티브 디렉터리에 악의적인 목적으로 하나 또는 다수의 사용자를 만들어 놓는다. 이러한 사용자는 설명(Description)이 입력되어 있지 않은 경우가 있으므로 이 경우 액티브 디렉터리에 만드는 모든 사용자에는 일정한 규칙을 갖는 설명을 철저히 입력 해 두는 것이 효과적인 방법일 수 있다. 그러면 단순히 설명 칼럼을 소트해 보는 것 만으로도 의심이 가는 사용자를 쉽게 구분해 낼 수 있게 된다.

관리그룹 안에 포함되어 있는 이상한 사용자. 해킹의 중요한 목표 중 하나는 권한을 상승시키는 것이다. Active Directory에 존재하는 관리그룹(예를 들어 Administrators, Domain Admins, Enterprise Admins, Server Operators) 안에 이상한 사용자가 포함되어 있는지 검사해야 한다. 이러한 그룹의 멤버쉽을 제한한다면 이상한 사용자를 더욱 잘 식별해 낼 수 있다.

피해는 이제 그만: 해킹으로부터 복구 계획 만들기

어떤 시스템이 해킹 당한 것을 발견했다면 우선 침착할 필요가 있다. 냉정을 유지하고 논리적으로 대응하면 된다. 그리고 다음과 같은 대응 계획을 미리 만들어 두면 피해를 최소화 할 수 있다.

1. 네트워크 연결 끊기. 인터넷, VPN, WAN 그리고 다이얼 업 연결과 같이 외부와 연결된 모든 인터페이스를 차단한다. 라우터와 무선 AP(Access Point)로부터 연결된 모든 라인을 끊고 외부와 우리 네트워크를 연결하는 모든 장치를 찾아내어 분리시킨다. 이렇게 하면 해커의 공격을 막을 수 있으며 다른 시스템을 감염시키는 것을 막을 수 있다.

2. 무선 검색 수행. Airscanner Mobile Sniffer 또는 NetStumbler.com의 NetStumbler와 같은 무선 스니퍼를 사용하여 이상한 AP가 있는지 찾아본다. 이러한 스니퍼는 현재의 모든 무선 표준(예를 들어 802.11a, 802.11b 그리고 802.11g)을 지원하는 카드에 설치해야 함을 명심해야 한다.

3. 다른 해킹된 시스템 점검. 여기에 소개된 방법을 참고하여 또 다른 해킹된 시스템이 있는지 조사해야 한다.

4. 방화벽 구성 점검. 이상한 규칙(Rule)이나 외부로 향한 포트가 열려 있는지 또는 구성한 적이 없는 NAT 규칙이 있는지 점검해야 한다. 방화벽의 로그를 검사하여 의심이 가는 내용이 있는지 알아보아야 한다. 외부로 나가는 트래픽은 반드시 정해진 외부 포트를 통과하도록 제한해야 하고 지정된 시스템만이 방화벽을 통해 외부로 메일을 전송할 수 있도록 해야 한다.

5. Active Directory 검사. 이상한 사용자 계정이 만들어져 있는지Active Directory를 검사해 보고 발견하는 즉시 비활성화 시켜 사용하지 못하도록 해야 한다.

6. 네트워크의 모든 계정의 암호를 바꾸기. 특히 권한이 상승된 사용자에 대해서는 적어도 15자 이상의 암호를 지정해야 한다. 이 길이의 암호는 크랙 하기 쉽지 않은데 그 이유는 14자를 넘어가는 암호의 경우 LAN Manager의 암호 해쉬 알고리즘상 더욱 안전해지기 때문이다.

7. 해킹 당한 컴퓨터의 하드디스크 교체. 디스크를 교체하면 해킹 활동을 고립화 하여 시스템을 보호할 수 있다. 교체된 하드디스크에 담긴 정보를 분석하여 해킹에 대한 중요한 정보를 얻을 수도 있다.

8. 취약점 알아내기. 해커가 어떻게 네트워크에 접속 할 수 있었는지 알아내야 한다. 어렵게 보이지만 실제로는 쉬울 수 있다. 그러나 만약 취약점을 알아내지 못했다면 도움을 줄만한 컨설턴트를 고용해 보는 것도 좋은 방법이다.

9. 해킹 당한 컴퓨터 재설치. 해킹된 컴퓨터를 완전히 복구하는 것은 거의 불가능하다. 만약 하나 또는 다수의 해킹 툴이 시스템에 남아있다면 해커는 시스템에 다시 침투할 수 있다. 시스템을 확실히 새것처럼 만드는 방법은 하드디스크를 포맷하고 이전의 해킹 툴이 다시 복원되지 않도록 주의하면서 시스템을 다시 구성하는 것이다. 모든 프로그램을 CD-ROM으로부터 다시 설치해야 하며 데이터 파일만을 복원해야 한다. 테이프로부터 레지스트리, 운영체제 또는 프로그램을 복원해서는 안 된다.

10. 모든 시스템에서 전체 바이러스 스캔 실행. 그러나 때때로 안티바이러스 소프트웨어는 해킹 툴을 정상적인 프로그램으로 간주하는 일이 있다는 것을 알아야 한다. 만약 시스템이 안전하지만 그래도 해킹 당하고 있다고 의심된다면 주저 없이 시스템을 재설치 하는 것이 바람직하다.

11. WAN 라인 다시 연결. WAN 라인을 다시 연결하고 네트워크의 취약점이 해결되었는지 판단하기 위하여 주의 깊게 모니터링 해야 한다. 네트워크의 대역폭이 많이 사용되고 있는지 지켜보아야 하며 방화벽의 로그를 살펴보고 모든 서버의 보안 감사를 활성화 해야 한다.

12. 해킹 당한 하드디스크 철저 검토. 해킹 당한 하드디스크를 독립된 컴퓨터에 설치하고 해킹에 대한 좀 더 많은 정보를 알아내야 한다. 때때로 해커들이 IP 주소를 위장하기도 하지만 대부분의 경우 IP 주소가 해커의 흔적을 추적하는데 가장 좋은 출발점이 된다. IP 주소 할당 정보는 인터넷 할당 번호 관리 기관(Internet Assigned Numbers Authority : IANA)의 웹사이트인 http://www.iana.org 에서 얻을 수 있다.

13. 관련 기관에 통보. FBI는 인터넷 사기 불만 센터(Internet Fraud Complaint Center : IFCC -- http://www.ifccfbi.gov/index.asp)를 운영하여 인터넷의 의심스러운 활동에 대한 정보를 제공하고 있으며, 대부분의 FBI 사무소는 사이버 활동 팀(Cyber Action Teams : CATs)을 두고 있다. 어느 누구도 해킹 당했음을 인정하고 싶어하지 않는다. 그러나 적당한 기관에 알림으로써 더 큰 피해를 막을 수 있다는 사실을 알아야 한다. 각 지역의 FBI 사무소에 연락하고자 한다면 http://www.fbi.gov/contact/fo/fo.htm를 참고하면 된다. 지금까지 소개한 절차를 잘 활용한다면 제대로 된 해킹 복구 계획을 설계하는데 큰 도움이 될 것이다. 이것을 각자의 조직에 맞게 적당히 다듬고 전사적인 재해 복구 계획에 통합한다면 더욱 좋을 것이다.

 

사례를 통해 배우기

필자는 컨설팅 활동을 통해 네트워크가 해킹 당한 경험이 있는 수 많은 조직의 여러 가지 사례를 접할 수 있었다. 도중에 다른 회사의 경험을 이용한다면 각자의 조직이 갖고 있는 네트워크 또는 시스템 관련 취약점들을 좀 더 쉽게 알아낼 수 있다. 이제 몇 가지의 실제 해킹 시나리오를 검토해 보도록 하자.

DMZ에 위치한 IIS 공격

필자의 고객 가운데 하나가 전화를 통해 사용자들이 Win2k 서버 시스템의 특정 폴더에 접근할 수 없다고 알려왔다. 필자는 폴더의 모든 권한이 제거되어 있는 것을 발견하였고 누군가 시스템을 망가뜨린 것으로 판단하였다.

해킹 확인. 필자는 우선 액티브 디렉터리 사용자 및 컴퓨터 MMC를 열고 사용자 계정을 살펴보았다. 곧바로 누군가 불법 사용자 계정 하나를 만들어 Administrators 그룹에 넣어둔 것을 발견하였다. 이것은 누군가 네트워크를 해킹하여 침입한 것이므로 모든 외부 연결을 끊고 해킹 당한 컴퓨터를 조사하기 시작하였다. 그것은 별로 오래 걸리지 않았다. 필자의 고객은 DMZ에 두 대의 웹 서버를 두고 있었는데 그 중 하나는 회사의 웹 페이지를 운영하고 있었으며 다른 하나는 시간 재는 소프트웨어를 실행하고 있었다. 필자는 두 서버의 레지스트리의 Run 서브키를 열고 의심스러운 배치파일이 C 드라이브에 있는지 조사하였다. 그 결과 시간 재는 소프트웨어를 실행하는 시스템이 크게 손상되어 FTP와 SMTP를 통해 여러 루트킷이 실행되고 있는 것을 알 수 있었다. 이 서버는 내부 LAN에 존재하는 마이크로소프트의 SQL 서버와 연결되어 있었으며 오직 SQL 서버의 트래픽 만이 DMZ를 통하여 LAN으로 들어오도록 되어 있었다. 운영체제는 서비스 팩2가 설치된 Win2K이었으나 매우 중요한 업데이트 여러 개가 누락된 상태였다.

피해 복구. 필자는 시스템을 다시 구성한 다음 방화벽의LAN 쪽으로 옮겨 외부에서 접근하지 못하도록 하였다. 그리고 외부 라인을 다시 연결하여 의심스러운 활동이 없는지 조사하였다.

교훈. 외부에서 접근하는 서버를 DMZ에 둘 경우에는 서버에서 실행하는 모든 프로그램이 외부로부터의 접근에 안전한지 소프트웨어의 제조사와 함께 검토해야 한다. DMZ에 있는 서버뿐만 아니라 모든 서버들에 최신의 서비스 팩과 중요한 보안 패치를 해야 한다. SQL에 연결하는 모든 프로그램이 SQL 서버에 통합된 보안 연결을 사용하여야 하며 코드 내에서 별도의 연결 문자열을 통해 SQL에 접근하지 못하도록 해야 한다. 연결 문자를 웹 서버 코드에 삽입해 놓으면 해커에게 즉시 유효한 사용자 이름과 암호를 알려주는 셈이 된다. 웹 서버에서 SQL 서버로 연결하는데 관하여 더 자세한 정보는 마이크로소프트 웹 사이트 http://support.microsoft.com/?kbid=258939의 기사 "Recommendations for Connecting to Databases Through Internet Information Services"를 참고하면 된다. IIS 서버가 SQL서버의 데이터에 접근할 때에는 반드시 저장 프로시저를 사용하도록 해야 하며 SQL 문장을 사용하지 못하도록 해야 한다. 그렇게 함으로써 인증 받은 사용자만이 특정 저장 프로시저를 실행할 수 있는 권한을 갖도록 제어 할 수 있기 때문이다. 즉, 사용자들이 SQL 서버를 통해 어떠한 SELECT 문장도 실행하지 못하도록 제한 할 수 있게 된다.

VPN 클라이언트 공격

또 다른 고객의 경우 익스체인지 2000 서버 시스템에 백업 문제가 있으며 메일을 주고 받는 성능이 매우 저하되어 있었다. 필자는 시스템을 보고 나서 단순히 백업 실패 또는 성능 저하 이상의 심각한 문제가 있음을 알 수 있었다. 서버에 심한 디스크 동작이 일어나고 있으며 CPU 이용률이 매우 높은 상태였다. 윈도우의 작업 관리자를 열고 프로세스 탭을 선택하여 CPU 이용률 칼럼으로 정렬해 보았더니 Store.exe 프로세스가 CPU의 대부분의 사이클을 사용하고 있었다. 그런데 고객의 회사에는 메일을 많이 사용하는 사람이 없으며 고작 15명의 사용자만이 메일 서버에 연결 할 뿐이었다. 그 정도의 사용자라면 익스체인지 서버가 그렇게 많은 자원을 사용할 필요가 없는 것이었다. 필자는 메일 저장소가 해킹 당했다고 생각하였다.

해킹 확인. 우선 Exchange System Manager (ESM)을 열고 Administrative Groups, Admin_Group_Name, Servers, Server_Name, Protocols, Smtp, Default SMTP Virtual Server, Current Sessions 등을 점검해 보았다. 거기서 필자는 6개의 세션이 SMTP 가상 서버에 5분 이상 연결되어 있는 것을 발견하였는데 이것은 무언가 매우 잘못되어 있다는 명백한 단서였다. 대개 Exchange 서버의 세션은 보내거나 받는 메시지가 아주 큰 첨부 파일을 가지고 있지 않은 한 불과 몇 초 지속될 뿐이다. Default SMTP Virtual Server의 큐를 조사해본 결과 50 큐 이상이 여러 상태로 메일을 보내거나 회신을 기다리고 있는 것을 볼 수 있었으며 이것은 누군가 메일 서버를 릴레이 형태로 사용하고 있는 것이다. 그러나 어떻게 할 수 있었을까? Exchange 서버는 최신 서비스 팩을 설치한 Win2k 운영체제를 기반으로 하고 Exchange 2000의 서비스 팩3까지 설치된 상태였다. 중요한 업데이트 역시 모두 되어 있었다. 필자는 릴레이가 완료되는 것을 확인하기 위하여 http://www.ordb.org의 Open Relay Database's (ORDB's) 테스트를 수행하였다. 이것은 오픈 릴레이를 발생시킨 시스템을 점검하는 테스트이다.

 그런데 기본 SMTP 가상 서버의 연결을 제거하려고 할 때 마다 비슷한 IP범위로부터 발생되지만 도메인 이름은 다른 연결이 다시 나타나는 것이었다. 필자가 IANA 자료를 이용하여 IP주소를 추적한 결과 해당 IP 주소 블록은 중국의 어느 ISP에 할당된 것임을 알 수 있었다. 서버가 오픈 릴레이가 아님을 확인 한 다음 필자는 누군가 서버에 인증하여 메일을 보낸 것으로 결론지었다. 백업은 스팸 메일을 보내는 사람이 보내려고 시도한 모든 메일을 백업하고자 했기 때문에 실패한 것이었다. 필자는 Active Directory 사용자 및 컴퓨터 MMC를 열고 수상한 모든 사용자를 제거하였으며 Administrators 그룹 안에 포함되어 있던 수상한 사용자들의 계정 역시 제거하였다. 그 다음 레지스트리를 점검하여 Run 서브키 안에서 로드 되는 해킹 프로그램이 없는 것을 확인하였고 또한 바이러스 스캔 프로그램을 실행하여 서버가 깨끗한 것을 확인하였다.

 또다시 스팸 메일을 보내고자 하는 스패머가 메시지를 보내지 못하도록 하기 위하여 방화벽을 인터넷으로부터 차단하고 현재 활성 상태인 Exchange 서버의 모든 세션을 삭제한 다음 필자는 ESM을 통해 메일 큐로부터 메시지 삭제를 시도하였다. 그러나 너무 오래 시간이 소요되었다. 그래서 모든 Exchange 서비스를 중단 시키고 D:\exchsrvr\mailroot\vsi 1\queue 안에 있는 모든 메시지를 삭제하기 위하여 명령 프롬프트를 열어 Del 명령어를 사용하였다. 그런데 Exchange 서비스를 중단시키자 마자 서버의 성능이 극적으로 개선되는 것이었다. 10,000개의 메시지 큐를 삭제하는 데에는 1시간 정도, D:\exchsrvr\mailroot\vsi 1\badmail 안에 있는 bad-mail 디렉터리의 모든 메시지를 삭제하는 데에는 대력 8시간 정도 더 소요되었다. 최종적으로 네트워크의 모든 사용자의 암호를 바꾸고 스팸 메일이 시작된 IP 주소 범위로부터 오는 트래픽을 거부하도록 방화벽에 규칙을 새로 만들었다. 이 모든 것이 끝난 뒤에 필자는 방화벽을 인터넷에 연결하고 서버를 모니터링 하였다. 스팸 연결은 더 이상 나타나지 않았다.

 이 특이한 네트워크는 VPN 터널을 통하는 몇 개의 원격 사이트로 이루어져 있었는데 그 중 한 사이트에서 필자는 해킹 프로그램 Bat.Mumu.A.Worm, Hacktool, W32.Valla.2048, W32.HLLW.Lovgate.J@mm, Bat.Boohoo.Worm 그리고 MSBlast를 포함하는 원격 시스템을 찾을 수 있었다. 고객의 말에 의하면 이 컴퓨터는 VPN 터널이 활성화 된 상태로 항상 실행되는 상태였다고 한다. 그렇다면 해커가 시스템을 해킹하는 것은 단지 시간문제였을 것이다. 필자는 항상 원격 클라이언트는 방화벽 뒤에 둘 것을 권장한다. 특히 그것이 브로드밴드 연결을 사용한다면 더더욱 그래야 한다. 만약 다이얼 업 또는 무선 연결을 기반으로 Windows XP를 운영하고 있다면 시스템을 보호하기 위하여 Windows XP의 방화벽(예전의 인터넷 연결 방화벽)을 반드시 사용해야 한다.

피해 복구. 필자는 워크스테이션을 다시 설치 한 다음 SonicWALL의 TELE3 방화벽 안쪽에 두었다. 그 다음 방화벽이 회사의 사무실로 연결되도록 구성하였다. 다행히 이 클라이언트의 경우 단순히 해커가 스팸 메일을 보내기 위해서만 사용 하였으므로 더 큰 손실은 입지 않았다.

교훈. 이번 해킹으로 인하여 고객의 회사는 클라이언트가 방화벽 없이 브로드밴드의 모바일 VPN 연결을 하지 못하도록 금지하였다. 만약 여러분의 회사가 VPN 터널을 통한 원격 사이트를 가지고 있고 브로드밴드 연결이라면 방화벽을 설치해야 할 것이다. 그렇지 않다면 적어도 직원들이 컴퓨터를 사용하지 않을 때에는 컴퓨터를 끄도록 교육해야 한다. 또한 모든 직원들이 사용하지 않을 때에는 VPN 터널을 비활성화 시키는 방법을 반드시 알고 있어야 한다.

익스체인지 서버에 대한 SMTP AUTH 공격

세 번째 고객의 경우 인터넷 트래픽이 과도하여 인터넷 연결이 느려진 상태였다. 우선 모든 클라이언트에게 인터넷 연결을 끊도록 요청하였으나 그 뒤에도 인터넷 트래픽이 여전히 많았다. Exchange 2000의 외부로 나가는 큐를 살펴보니 100 이상이었으며 각 큐마다 상당량의 메시지들이 가득 차 있었다. ESM을 사용하여 우선 임의로 몇 개의 큐 안에 있는 메시지를 조사해 보았다. 여기서 필자는 수신자 또는 발신자가 로컬 도메인이 아닌 메시지들을 발견하였다. 이것은 메일 서버가 메일 릴레이에 사용되고 있다는 의미이다. 기본적으로 Exchange 2000 및 그 이후의 시스템은 메일의 발신자가 성공적으로 인증된 경우에는 메일을 릴레이 하도록 되어 있다.

해킹 확인. 해커들은 유효한 사용자 이름과 암호를 알아내기 위하여 몇 가지 다른 방법을 사용하였다. 그들은 성공할 때까지 지속적으로 게스트 또는 사용자의 암호를 추측하여 단순히 사용자 이름과 암호를 얻었거나 또는 유효한 사용자 이름과 암호를 알아내기 위하여 본격적인 해킹을 했을 수 있다. 스팸 메일을 보내는 스패머가 메일을 릴레이 하기 위해서는 오직 하나의 유효한 사용자 이름과 암호만 있으면 된다. 스패머가 어떤 계정을 사용하였는지 알기 위하여 필자는 ESM을 사용하였는데 Organization, Administrative Groups, Organizational Unit, Servers를 차례로 클릭하였으며 그 다음에는 서버 이름을 마우스 오른쪽 클릭하여 속성을 열고. Diagnostics Logging 탭을 살펴 보았다. 서비스 창에서 MSExchangeTransport를 클릭 한 다음 카테고리 창에서 Routing Engine, Categorizer, Connection Manager, Queuing Engine, Exchange Store Driver, SMTP protocol 그리고 NTFS store driver 항목에 대한 로깅 수준을 최대로 하였다. 그리고 이벤트 로그를 점검하여 외부 또는 모르는 메일 서버로부터 오는 인증 요청을 찾아보았다. 실패한 로그온 요청은 이벤트 번호 680과 함께 보안 로그에 나타나게 된다. 필자는 여기서 해커가 메일 서버에 로그온 하기 위하여 로컬 Exchange 서버에 존재하지 않는 사용자 계정을 사용하고 있음을 알 수 있었다.

피해 복구. 인증 계정을 알아낸 뒤 Exchange 서버의 보안을 강화하기 위하여 다음과 같은 조치를 취하였다.

14. 우선 스패머가 사용하는 계정의 암호를 바꾸었다. 만약 비슷한 상황이라면 스패머가 하나 이상의 유효한 사용자 계정과 암호를 알고 있을 수도 있으며 네트워크의 모든 사용자의 암호를 바꿔야 한다. 그 뒤 Guest 계정을 비활성화 시키고 서버의 서비스를 시작시키는 데 사용할 전용 계정을 설정 하였다. 서비스를 시작시키는데 Administrator 계정을 사용하면 안 된다. 만약 시스템이 해킹 당할 경우 서비스를 시작시키는데 사용되는 계정마저 노출될 우려가 있다.

15. Exchange 서버의 바깥쪽에 대한 인증을 중지시켰다. 이렇게 하기 위하여 ESM을 열고 Organization, Administrative Groups, Organizational Unit, Servers, ServerName, Protocols, SMTP를 클릭 한 다음 Default SMTP Virtual Server를 마우스 오른쪽 버튼으로 클릭하였다. 속성을 선택 한 다음 액세스 탭에서 인증을 선택하였다. 여기서 Anonymous access는 활성화 된 상태로 두었으나 Basic authentication과 Integrated Windows Authentication 체크 박스는 해제 하였다. 이렇게 함으로써 실제로는 SMTP 서버의 Auth 명령을 중지시킨 것이다.

16. 필자는 내부의 다른 Exchange 서버의 경우에는 외부와 접해 있는 Exchange 서버에 메일을 보낼 수 있도록 릴레이를 활성화 시켰다. ESM을 열고 Default SMTP Virtual Server를 마우스 오른쪽 버튼으로 클릭 한 다음 속성을 선택 하였다. 액세스 탭에서 릴레이를 클릭 하고 Only the List Below를 클릭 한 다음 외부와 접해 있는 서버에 메일을 릴레이 하도록 설정되어 있는 내부의 메일 서버를 선택하였다.

17. 이렇게 조치를 취한 다음 필자는 그 구성을 완전히 테스트 하였다. 메일의 흐름을 테스트 하였으며 인터넷에서 주고 받는 메일 그리고 모든 메일 서버에서 주고 받는 메일을 테스트 하였다. 조치 내용이 서버들 사이의 메일 흐름을 방해할 가능성이 있기 때문에 주말까지 기다렸다가 조치를 취하는 것도 괜찮을 것이다. 그리고 실제 환경에 구현하기 전에 먼저 실험 환경에서 테스트 해 보는 것이 좋다.

18. 이 경우에서 필자는 심각하게 훼손된 시스템을 발견하였고, 그래서 완전히 새로 설치하다시피 하였다. 따라서 여러분도 이러한 상황을 만나게 된다면 훼손된 모든 시스템을 파악하여 철저히 수리하거나 새로 설치해야 한다.

19. 필자는 고객의 메일 서버가 오픈 릴레이로 인하여 블랙리스트에 올라있는지 확인하기 위하여 ORDB를 점검하고 다행히도 고객의 메일 서버가 블랙리스트에 올라가기 전에 해킹 당한 시스템을 찾아내어 수리할 수 있었다. 메일 서버는 오픈 릴레이를 하고 있거나 대량의 스팸 메일 발송에 사용되는 경우 블랙리스트에 올라갈 수 있다. 수 많은 오픈 릴레이 데이터베이스가 존재하는데 이 데이터베이스의 목록을 보려면 http://dmoz.org/computers/internet/abuse/spam/blacklists를 참고하면 된다. 만약 여러분의 메일 서버가 블랙리스트에 올라가 있다면 그 목록에서 삭제해 줄 것을 요청하거나 또는 메일 서버의 외부 IP 주소를 변경하는 방법을 사용할 수 있다. 만약 메일 서버의 IP 주소를 변경한 경우라면 메일 서버를 가리키는 DNS의 Mail Exchanger(MX) 레코드를 함께 수정해야 한다. 그렇지 않으면 메일을 받지 못하게 된다. 교훈. Exchange 서버의 SMTP AUTH 공격을 방어하거나 또는 미리 대비하려고 한다면 필자가 위에서 소개한 방법들을 강력히 추천하는 바이다. 만약 침입자가 유효한 사용자 계정을 손에 넣어 메일을 릴레이 할 수 있다면 여러분의 메일 서버는 여러 메일 서버 블랙리스트에 올라가게 될 것이다. 아마도 이러한 공격으로부터 메일 서버를 잘 보호하는 것이 메일 전달로 생긴 문제점을 해결하는 것보다, 메일 서버를 블랙리스트에서 제거하는 것보다 그리고 취약점을 고쳐나가는 것보다 훨씬 쉬울 것이다.

당황하지 말고 미리 준비하라

공격 복구 계획은 제대로 된 IT 구조를 만들어 나가기 위한 모든 행동에 반드시 포함되는 중요한 일부분이다. 아마도 그것은 여러분이 위급할 때 당황하지 않고 오히려 제대로 대처할 수 있게끔 해 줄 것이다. 침입자들이 사용하는 여러 가지 툴과 방법론에 대하여 익숙해야 하며 여러분의 네트워크를 해킹하려고 하는 침입자들을 적극적으로 막아나가야 한다. 필자는 이러한 주제에 대하여 플로리다의 올랜도에서 10월 24일부터 27일 까지 열리는 다음의 Windows Connection Conference에서 더욱 자세히 다루고자 한다. 그곳에서 여러분들을 만나기를 희망한다.

사이버 전쟁터에서 배운 것

Paula Sharick

지금은 오전 10시. 나는 고객의 이벤트 로그를 샅샅이 뒤지고 있다. 웹 서버의 보안 이벤트 로그에 Administrator, Guest그리고 외부인의 사용자 이름에 대한 엄청난 로그온 실패 목록이 기록되어 있다. 요 며칠간 일어난 일인데 유독 밤 10시에서 새벽 5시 사이에 집중되어 있다. 어제의 마이크로소프트의 IIS 5.5 서버 로그를 살펴 보니 cmd.exe를 실행하려 했던 몇 번의 시도가 있었던 것을 알 수 있다. 무언가 잘못된 것이다. 웹 서버의 네트워크 아이콘은 변함없이 활성화 되어 있는데 이것은 시스템이 평소보다 더 바쁘게 움직이고 있다는 신호이다. 네트워크 모니터를 실행해 보니 FTP 패킷 들이 나타난다. 이상한 일이다. 벌써 1년 전에 이 웹 서버에서 FTP를 제거했는데 말이다. IIS 서버가 해킹 당했다고 의심이 든다. 그러고 보니 이 시스템은 그다지 보안적인 측면에서 보호받지 못하고 있었지 않은가. 웹 서버의 제조사가 보안 핫픽스를 설치하지 않았거나 또는 IIS를 IIS 락다운 툴로 보호하지 않았다는 것을 발견하였다.

웹 서버의 인터넷 접속을 차단하고 Inetpub 디렉터리를 꼼꼼히 살펴보니 침입자가 FTP를 설치할 때 만들어진 설치 로그가 남아 있다. 거기에는 FTP 서버에 필요한 파일과 폴더가 나열되어 있다. 로그를 보니 서버가 요 며칠 동안 수 많은 대용량 파일들을 다운로드 하고 업로드 했음이 나타나 있다. 추측해 보니 익스플로잇의 목적이 서버를 하이재킹 하여 다른 목적지를 찾는 동안 임시로 파일을 보관해 두기 위한 것 같다. 나는 일부러 FTP를 설치 한 다음 FTP의 로그 파일을 안내 삼아 중요한 파일들을 우선 안전한 곳으로 옮겼다. 그 다음 설치 로그에 나타난 파일과 폴더를 삭제하고 Inetpub 루트에 포함되지 않는 파일들을 모두 제거한 다음 FTP 서버에 관계된 모든 레지스트리를 청소하였다. 다시 부팅 해 보니 시스템이 정상으로 돌아왔고 FTP 해킹의 흔적은 보이지 않았다.

다중 익스플로잇

시스템을 해킹한 침입자가 시스템의 다른 곳에 더 은밀한 악성의 코드를 숨겨두고 있을 수도 있다는 생각이 들어 인터넷을 통해 현재의 FTP 익스플로잇에 대한 정보를 검색하여 보니 그 중 한군데에 내가 경험한 해킹과 똑같은 사례가 소개되어 있었다. 그것을 다운 받아 첨부된 스캔용 프로그램을 실행하였다. 그 프로그램은 해킹 툴과 트로이 목마 프로그램을 찾는 기능을 갖고 있었는데 실행 결과 시스템이 정상임을 알 수 있었다.

웹 서버의 보안에도 신경 쓸 차례이다. Microsoft Baseline Security Analyzer (MBSA)를 실행하여 필요한 서비스 팩과 핫픽스를 조사하고 설치한 다음 IIS 락다운 툴을 실행 하였다. 불필요한 시스템 서비스를 비활성화 한 다음 암호를 알아내어 침입하려는 해커에 대비하여 로그온에 두 번 실패한 경우 계정이 잠기도록 설정하였다. 웹 서버의 고정 IP 주소를 바꾸고 기본 포트를 83번으로 수정한 다음 라우팅 및 원격 액세스 서비스를 구성하여 외부의 요청을 새로 변경된 웹 서버의 IP 주소와 포트로 전달하도록 설정하였다. 맙소사, 다음날 이벤트와 방화벽의 로그를 검사했더니 웹 서버의 이벤트 로그에 또다시 밤 11시에서 새벽 5시 사이에 발생한 실패한 로그온 시도가 여러 번 나타나 있었다. IIS의 로그는 IIS의 URL 스캔 기능이 내부 사용자들의 시도를 포함하여 여러 번의 액세스 시도를 막았음을 보여주고 있었다.

매우 이른 새벽 시간에 직원들이 웹 사이트를 액세스 하였다는 사실은 그다지 신빙성이 없어 보였다. 분명히 이것은 인터넷으로부터 온 침입자의 소행일 것이라고 생각되었다. 그런데 침입자들이 IP 주소가 바뀌어 있는 웹 서버 내부에 침투할 수 있었다는 사실이 잘 이해가 되질 않았다. HTTP 요청은 표준이 아닌 포트로 매핑 되고 있고 내부의 사용자들만이 새로 바뀐 주소를 알고 있는데 말이다. 저녁 10시에 사무실로 돌아와 다시 한 번 침입자를 찾기 시작했다. 나의 고객의 써드파티 방화벽은 Windows 2000 서버 운영체제를 사용하며 두 개의 랜카드를 가진 시스템에서 실행되고 있었다. 우선 나는 방화벽을 구성하여 몇 개의 TCP와 UDP 포트가 액세스를 허용하도록 하였다. 방화벽은 내부의 사용자의 인터넷 요청과 방화벽으로부터 오는 신호가 나타나도록 라우팅 및 원격 액세스 서비스(RRAS)를 NAT가 설정된 라우터 전용 모드로 실행하고 있었다.

정교한 네트워크 모니터링 툴이 없었기 때문에 침입자를 실시간으로 알아 낼 수 있는 가장 손쉬운 방법은 RRAS NAT키가 빛나도록 하는 것 이었다. 인터넷에 연결된 랜카드를 마우스 오른쪽 버튼으로 클릭 한 다음 드롭 다운 메뉴에서 Show Mappings를 선택하여 현재의 모든 활동중인 NAT 연결이 표시되도록 하였다. 정상적인 사용자와 침입자가 인 바운드 연결로 나타났으며 내부의 사용자는 아웃바운드 연결로 나타났다. 같은 원본 TCP/IP 주소로부터 두 개의 인 바운드 세션이 있는 것을 보자마자 나는 즉시 RRAS를 재 시작 시켜 모든 세션을 종료하였다. 잠시 후에 NetBIOS 포트로 새로운 인 바운드 세션이 만들어 진 다음 곧바로 웹 서버로의 인 바운드 연결이 만들어지는 것을 볼 수 있었다. 이 연결의 IP 주소를 기록한 다음 한 시간 정도 더 지켜보았다. 그랬더니 각각 다른 세 침입자를 확인 할 수 있었다. 그 연결을 모두 종료하기 위하여 나는 RRAS를 서너 번 재 시작 하였다. 마침내 나는 인터넷 연결을 불가능하게 만들었던 주소를 모두 제거할 수 있었다.

전투에서 이겼지만 ...

이렇듯 쫓고 쫓기는 추격전이 일주일 가량 계속되었다. 그 동안 나는 두 가지 중요한 사실을 알아내었다. 첫 번째는 NAT 주소 매핑을 다시 구성해야 하며 Special Ports 탭을 통해 특정한 고정 IP 주소와 포트(83)으로 들어오는 연결을 제한해야 한다는 것이다. 이렇게 함으로써 액세스 시도를 완전히 없애지는 못했지만 어느 정도 줄일 수 있었다.

두 번째는 NAT에서 인터넷 접속을 활성화 할 때 마다 침입자들이 재빠르게 돌아온다는 사실이다. 나는 침입자들이 방화벽 안에 트로이목마를 가지고 있다가 인터넷 연결이 가능해 지면 즉시 침입자에게 패킷을 보내도록 해 두었다는 것을 알아냈다. 이러한 침투방식은 앞서 FTP 서버의 해킹보다 더욱 발견하기 어려웠다. 네트워크 모니터를 통해 추적하고, 활성화된 NAT 연결을 조사하고, Active Ports 프리웨어 유틸리티를 통해 열려 있는 TCP/IP와 UDP 포트를 모니터링 하여 나는 트로이 목마를 찾을 수 있었다. 인터넷 연결을 시작하자 마자 활동을 시작한 NAT 연결을 표시해 두었더니 매번 같은 IP 주소로 즉시 아웃바운드 연결이 만들어지는 것을 볼 수 있었다. 인터넷 연결을 시작하기 전에 네트워크 모니터를 시작한 경우에는 추적 목록에서 같은 TCP/IP 주소를 볼 수 있었다. 방화벽에 이 주소로 나가는 패킷을 막도록 규칙을 추가하였더니 침입자들이 다시 돌아오지 않았다.

... 전쟁에는 졌다

침입자를 제대로 퇴치했는지 확인하기 위하여 방화벽과 로그를 한 번 더 점검해 보다가 나는 매우 놀라고 말았다. 방화벽이 다운된 것이었다. 방화벽을 재 시작 해 보았으나 로그온 화면에서 마우스와 키보드가 동작하지 않았다. 다시 한 번 재시작 했더니 서버의 전원표시등이 노란색으로 계속 남아 있었다. 서버가 영원히 망가진 것이었다.