지난 시간에는 IIS 웹 서버의 취약점과 대응책을 개괄적으로 알아보았다. 이번 호부터는 IIS 웹 서버를 보호하기
위한 보다 구체적인 방법을 살펴보도록 하겠다.
1. 필요한 구성요소만 설치한다.
1.1 IIS의 구성요소
IIS 웹 서버는 5.0버전부터 Windows 운영체제의 구성요소로 포함되어 배포되고 있다. IIS를 설치하면
다음과 같은 서비스나 웹 사이트, 폴더, 계정이 기본적으로 설치 또는 구성되는데 이 중에서 필요한 구성요소만
설치하는 것이 최우선 과제이다.
항목 |
설명 |
서비스 |
웹과 FTP 관리를 위한 IIS 관리 서비스
World Wide Web 서버 서비스
FTP 서비스
메일 발송을 위한 SMTP(Simple Mail Transport Protocol) 서비스
뉴스그룹을 위한 NNTP(Network News Transport Protocol) 서비스 |
계정 및
그룹 |
IUSR_MACHINE (인터넷으로 접근하는 익명 계정)
IWAM_MACHINE (out-of-process로 실행되는 웹 애플리케이션이 실행되는
계정) |
폴더 |
%windir%\\system32\\inetsrv (IIS
프로그램)
%windir%\\system32\\inetsrv\\iisadmin (IIS 관리 프로그램)
%windir%\\help\\iishelp (IIS 도움말 파일)
%systemdrive%\\inetpub (웹, FTP, SMTP 루트 폴더) |
웹 사이트 |
기본 웹 사이트(80번 포트) :
%systemdrive%\\inetpub\\wwwroot
관리 웹 사이트(3693번 포트) :
%systemdrive%\\system32\\inetsrv\\iisadmin |
[표 1] IIS의 설치 항목
[제어판] - [프로그램 추가/제거] - [Windows 구성요소 추가/제거]에서 인터넷 정보 서비스(IIS)
항목을 보면 기본적으로 다음과 같은 구성요소가 설치된 것을 확인할 수 있다. 대다수의 악의적인 공격은 초기 기본
설정으로 IIS 서버가 구성되어 있다고 가정하고 취약점을 노리는 경우가 많으므로 FTP나 NNTP, SMTP,
Server Extensions 등의 서비스들은 사용하지 않는 경우에는 설치하지 않는 것이 보안 및 관리적인
측면에서 좋다.
[그림 1] IIS의 구성 요소
1.2 웹 사이트의 구성
IIS를 설치한 후에 [관리도구] - [인터넷 서비스 관리자]를 실행하여 확인해 보면 다음과 같이 '기본 웹
사이트'와 그 하위에 IISHelp, MSADC, Printers, Script-xs와 같은 가상 디렉토리가 기본적으로
구성되어 있음을 알 수 있다. 그러나 이러한 기본 구성 또한 악의적인 공격의 대상이 된다. 예를 들면 ADSI
스크립트를 이용해서 기본 웹 사이트에 대한 설정을 변경한다든지 MSADC 가상 디렉토리를 통한 서버 자원 접근 등이
가능하다.
[그림 2] 기본 웹 사이트에 추가되어 있는 가상 디렉토리들
물론 이러한 문제점들은 최신 서비스 팩과 보안 패치를 설치함으로써 해결이 되지만, 필자의 경우에는 '기본 웹
사이트'를 중지 또는 제거하고 초기 웹 서버의 루트 경로인 '%system
drive%\\inetpub\\wwwroot'가 아닌 다른 위치에 웹 서버를 위한 루트 폴더를 만들어 사용한다. (위
[그림 2]를 보면 '기본 웹 사이트'가 중지되어 있고 'noenemy'라는 새로운 웹 사이트를 만들어 운영하고
있음을 알 수 있다.)
2. 최신 패치와 업데이트를 항상 유지한다.
운영체제의 서비스 팩과 보안 패치를 최신 버전으로 유지하는 것은 보안 사고를 예방하기 위한 기본적인 과제이다. 과거
큰 피해를 입었던 보안 사고들은 주기적인 보안 패치를 통해서 미연에 막을 수 있는 것이 대부분이었다는 점을
기억하자. 이러한 권장 패치에 대한 알림과 자동 업데이트 기능이 운영체제 차원에서 제공되므로 패치 적용에 대한
관리적인 이슈가 많이 감소되었다.
또한 마이크로소프트에서 제공하고 있는 MBSA(Microsoft Baseline Security
Analyzer)라는 툴을 이용하면 중요한 보안 패치의 적용 여부 뿐만 아니라 운영체제나 인터넷 익스플로어, SQL
서버, MDAC 등의 구성요소를 분석하여 보안상 취약한 부분을 손쉽게 확인할 수 있다.
[그림 3] MBSA를 이용한 취약점 분석 결과
[관련 사이트]
- Windows Update 사이트 :
http://windowsupdate.microsoft.com
- MBSA 사이트 :
http://www.microsoft.com/technet/security/tools/mbsahome.mspx
3. IIS Lockdown 툴을 사용한다.
3.1 IIS Lockdown 설치 및 구성
앞서 IIS를 설치할 때에 필요한 구성요소만 설치하라고 언급했었는데 IIS Lockdown 툴은 사용 목적에 따라
권장되는 IIS 웹 서버의 설정으로 구성해주는 도구이다. 즉, 사용 목적에 따라 필요한 구성요소만 활성화 시키고
그외의 구성요소는 비활성 상태로 만든다. IIS Lockdown 툴은
여기에서 다운로드 받을 수 있다.
잠깐! |
IIS Lockdown 툴은 실행과
동시에 IIS 웹 서버의 하위 서비스나 그 환경설정 내용이 변경되어 적용되므로 주의가 필요하다. 적용
후에 일부 서비스가 정상 동작하지 않을 수 있으며 이를 수정하는 과정이 필요할 수 있기 때문이다.
따라서 실제 사용중인 웹 서버에 바로 적용하기 전에 테스트 서버로 동일한 환경을 구성한 뒤에
정상적으로 서비스가 되는지 테스트한 후에 사용하는 것이 좋다. |
IIS Lockdown 툴은 설치 프로그램이 아니라 단독 실행파일이다. 다운로드 한 후에 실행해보면 다음과 같은
템플릿 선택 화면을 볼 수 있다. 웹 서버가 사용되는 목적에 따라 활성화되는 구성요소와 IIS의 메타베이스 정보가
다르게 설정되므로 올바른 템플릿을 선택하는 것이 중요하다. 각 템플릿 별 세부 설정사항에 대한 내용은
여기 를 참고하기 바란다.
[그림 4] IIS Lockdown - 템플릿 선택 화면
다음으로 진행하면 URLScan 필터를 설치할 것인가를 물어보는 화면이 나타난다. URLScan은 ISAPI
필터로서 특정 HTTP 요청을 블록킹함으로써 서버를 보호하는데 사용된다. URLScan에 대해서는 다음 절에 다시
설명하겠다.
[그림 5] URLScan 필터의 설치 여부 선택
다음으로 진행하면 선택한 템플릿에 따라 IIS 웹 서버의 보안 설정이 구성된다. 만약 원래의 구성으로 되돌리고
싶으면 IIS Lockdown 툴을 재실행하고 이전 설정 정보로 롤백하면 된다.
3.2 URLScan ISAPI 필터
URLScan은 ISAPI 필터로 특정 HTTP 요청을 블록킹함으로써 IIS 서버를 보호하는 역할을 담당한다. 명령
프롬프트에서 'iislockd.exe /q /c'라고 입력함으로써 IISLockdown을 실행하지 않고
URLScan 필터만 설치할 수도 있다. 설치된 URLScan을 삭제하려면 [제어판] - [프로그램 추가/제거]에서
IIS UrlScan Tool을 찾아 삭제하면 된다.
URLScan 필터는 '%windows directory%\\system32\\inetsrv\\urlscan'에
설치된다. 이 디렉토리에는 URLScan의 실행에 필요한 바이너리 파일과 환경설정 파일이 있으며 로그파일이
저장된다. 이 디렉토리에서 urlscan.ini 파일이 있는데 바로 URLScan 필터의 동작을 설정하는 환경설정
파일이다.
[그림 6] UrlScan.ini 설정 파일
UrlScan.ini 파일에는 필터링 하는데 사용되는 여러 섹션과 설정 항목이 존재한다. 각 항목에 대하여 자세한
설명이 있어 직관적으로 구성할 수 있게 되어 있다.
어떠한 메소드를 허용하고 거부할 것인가는 AllowVerbs와 DenyVerbs를 이용하면 되고, 어떠한 확장자를
허용하고 거부할 것인가는 AllowExtensions와 DenyExtensions 섹션을 이용하면 된다. 서버의
경로 탐색에 대한 거부는 DenyUrlSequences 섹션을, 그리고 전반적인 설정에 사용되는 options
섹션이 있다.
ISAPI 필터는 IIS 웹 서버가 요청을 받기 전에 해당 요청을 가로채서 먼저 처리하므로 UrlScan 필터에
의해서 거부된 요청은 IIS 웹 서버로 전달되지 않는다. 초기 설정 후에는 로그 파일을 잘 분석하여 어떠한 요청이
거부되는지, 만약 정상적인 요청이 거부되고 있다면 UrlScan.ini 설정파일을 수정하는 과정이 필요하다.
[출처] 안철수연구소
[저자] 김순근 연구원 |
|