IIS7에서 요청 필터링 사용 방법
URLScan 은 이전 버전의 IIS 에 애드-온 형태로 제공되던 보안 도구로 관리자들은 이 도구를 사용하여 웹 서버에 엄격한 보안 정책을 적용할 수 있었습니다. IIS 7.0 에서는 URLScan 의 모든 핵심적인 기능들이 요청 필터링이라는 모듈에 병합되었으며 숨겨진 네임스페이스라는 기능이 추가되었습니다. 본문에서는 요청 필터링이 제공하는 각각의 기능들에 대해서 알아보고 여러분들이 접하고 있는 환경에 적용이 가능하도록 실제 상황에서의 예제를 살펴보겠습니다.
이중 인코딩 요청 필터링
기능 개요
이 기능은 이중 인코딩된 요청을 이용한 공격을 방지합니다. 이 시나리오는 공격자가 주의 깊게 만들어진 이중으로 인코딩된 교묘한 요청을 IIS 로 전송하는 경우에 적용됩니다. 이와 같은 공격이 발생한다면 IIS 는 요청이 유효한 경우에만 허용하고 그렇지 않다면 거부할 것입니다. 이 기능이 활성화되면 IIS 는 해당 URL 을 두 번 디코딩하는데, 만약 첫 번째 디코딩 결과와 두 번째 디코딩 결과가 다르다면 요청은 거부되어질 것입니다. 이 기능에 의해서 요청이 거부되면 404.11 오류 코드가 로그에 기록됩니다.
URLScan 의 동일한 기능
이 기능은 URLScan 의 VerifyNormalization 옵션의 기능과 동일합니다.
실제 예제
이 예제에서는 서버 관리자가 서버로 전송되는 이중으로 인코딩된 요청을 결코 허용하지 않기를 원한다고 가정합니다. 이 시나리오를 반영하기 위해 다음과 같은 구성설정을 사용할 수 있습니다.
<system.webServer>
<security>
<requestFiltering allowDoubleEscaping="false"></requestFiltering>
</security>
</system.webServer>
</configuration>
최상위 비트 설정 문자 필터링
기능 개요
이 기능은 IIS 로 전달되는 비 ASCII 문자가 포함된 모든 요청들을 허용할지 또는 거부할지를 결정합니다. 이 기능에 의해서 요청이 거부되면 404.12 오류 코드가 로그에 기록됩니다.
URLScan 의 동일한 기능
이 기능은 URLScan 의 AllowHighBitCharacters 옵션의 기능과 동일합니다.
실제 예제
이 예제에서는 서버 관리자가 전체 서버에 전송되는 최상위 비트가 설정된 문자들을 허용하지 않기를 바라지만, 오직 하나의 응용 프로그램에서는 이를 허용하기 원한다고 가정합니다. 이를 위해서 서버 관리자는 applicationHost.config 파일에는 allowHighBitCharacters=”false” 를 설정했지만, 비 ASCII 문자를 받아들이기 바라는 응용 프로그램의 루트 아래에는 web.config 파일을 생성했습니다. 다음의 구성설정이 바로 그 web.config 파일에 사용된 설정입니다.
<system.webServer>
<security>
<requestFiltering allowHighBitCharacters="true"></requestFiltering>
</security>
</system.webServer>
</configuration>
파일 확장자에 기반한 필터링
기능 개요
이 기능은 IIS 가 서비스 할 수 있는 파일 확장자들의 집합을 정의합니다. 이 기능에 의해서 요청이 거부되면 404.7 오류 코드가 로그에 기록됩니다.
URLScan 의 동일한 기능이 기능은 URLScan 의 AllowExtensions 옵션과 DenyExtensions 옵션의 기능과 동일합니다.
실제 예제이 예제에서는 서버 관리자가 ASP 파일은 서비스 되지 않지만 그 외의 모든 파일들은 서비스 되기를 원한다고 가정합니다. 이를 위해서 서버 관리자는 allowUnlisted 옵션을 “true” 로 설정하고, 명시적으로 서비스 되지 않기를 바라는 ASP 파일을 위해 다음과 같은 파일 확장자 항목을 정의합니다.
<system.webServer>
<security>
<requestFiltering>
<fileExtensions allowUnlisted="true" >
<add fileExtension=".asp" allowed="false" />
</fileExtensions>
</requestFiltering>
</security>
</system.webServer>
</configuration>
요청 제한에 기반한 필터링
기능 개요
이 기능은 다음 세 가지 기능들의 조합으로 이루어집니다.
- maxAllowedContentLength ? Content-Length 요청 헤더값의 최대 크기를 지정합니다.
- maxUrl ? 쿼리스트링을 제외한 URL 의 최대 길이를 지정합니다.
- maxQueryString ? 쿼리스트링의 최대 길이를 지정합니다.
이 기능에 의해서 요청이 거부되면 다음과 같은 오류 코드가 로그에 기록됩니다.
- 404.13 콘텐츠가 너무 큰 경우
- 404.14 URL 이 너무 긴 경우
- 404.15 쿼리스트링이 너무 긴 경우
이 각각의 기능들은 URLScan 의 다음 기능들과 동일합니다.
- maxAllowedContentLength
- maxUrl
- maxQueryString
이는 소스 코드에 접근할 수 없는 소프트웨어를 구매하는 기업들에게는 매우 일반적인 상황입니다. 코드에 내제된 취약성들이 발견되었을 때, 그 영향을 받는 코드를 갱신하는 것이 매우 어려울 수도 있습니다. 이러한 취약성들은 대부분 응용 프로그램으로 전송되는 URL 이나 쿼리스트링이 단지 ‘너무 커서’ 또는 ‘콘텐츠가 너무 많아서’ 발생하는 경우가 대부분입니다. 서버 관리자가 안전한 최대값을 결정할 수 있다면, 응용 프로그램의 이진 파일들을 수정하지 않고서도 아래와 같은 구성설정을 사용해서 그 제한값을 적용할 수 있습니다.
<system.webServer>
<security>
<requestFiltering>
<requestLimits
maxAllowedContentLength="30000000"
maxUrl="260"
maxQueryString="25" />
</requestFiltering>
</security>
</system.webServer>
</configuration>
HTTP 동사 필터링
기능 개요
이 기능은 IIS 가 요청으로 받아들일 동사들의 목록을 정의할 수 있게 해줍니다. 이 기능에 의해서 요청이 거부되면 404.6 오류 코드가 로그에 기록됩니다.
URLScan 의 동일한 기능이 기능은 URLScan 의 UseAllowVerbs 옵션, AllowVerbs 옵션, 그리고 DenyVerbs 옵션의 기능과 동일합니다.
실제 예제이 예제에서는 서버 관리자가 오직 하나의 동사, 즉 GET 동사만 허용하기를 원한다고 가정합니다. 이를 위해서 서버 관리자는 먼저 구성설정 파일에 allowUnlisted=”false” 옵션을 설정하여 명시적으로 지정하지 않은 모든 동사를 허용하지 않도록 설정합니다. 그리고, 그 다음에 허용하고자 하는 동사들의 목록을 명시적으로 지정합니다. 이 예제에서는 오직 GET 동사만을 허용합니다.
<system.webServer>
<security>
<requestFiltering>
<verbs allowUnlisted="false">
<add verb="GET" allowed="true" />
</verbs>
</requestFiltering>
</security>
</system.webServer>
</configuration>
URL 문자열 시퀀스에 기반한 필터링
기능 개요
이 기능은 IIS 가 거부할 문자열 시퀀스의 목록을 정의합니다. 이 기능에 의해서 요청이 거부되면 404.5 오류 코드가 로그에 기록됩니다.
URLScan 의 동일한 기능이 기능은 URLScan 의 DenyUrlSequences 옵션의 기능과 동일합니다.
실제 예제이 기능은 매우 강력합니다. 만약 IIS 에 의해 서비스 되지 않기를 바라는 어떤 문자열 시퀀스가 있다면, 그 문자열 시퀀스를 다음과 같이 구성설정에 추가할 수 있습니다.
<system.webServer>
<security>
<requestFiltering>
<denyUrlSequences>
<add sequence=".." />
</denyUrlSequences>
</requestFiltering>
</security>
</system.webServer>
</configuration>
이 예제에서는 ‘..’ 시퀀스를 거부합니다. 그러나, 보다 현실적인 시나리오는 여러분들이 이미 폐업한 판매자로부터 구매한 응용 프로그램을 갖고 있으며, 특수한 시퀀스의 문자열이 이 응용 프로그램으로 전송되었을 때 문제가 발생할 수 있다는 사실을 발견한 경우입니다. 여러분들은 이 기능을 사용하여 해당 응용 프로그램의 코드를 수정하지 않고서도 단순히 거부 목록에 URL 시퀀스를 추가하는 것만으로 응용 프로그램을 보호할 수 있습니다.
숨겨진 네임스페이스 필터링
기능 개요
이 기능은 ‘서비스 가능한’ 네임스페이스를 (또는 URL 구역) 정의할 수 있도록 해줍니다. 이 기능에 의해서 요청이 거부되면 404.8 오류 코드가 로그에 기록됩니다.
URLScan 의 동일한 기능이 기능은 IIS 7.0 에서 새롭게 제공되는 기능으로 URLScan 에는 존재하지 않습니다.
실제 예제이해를 돕기 위해서 서버에 다음과 같은 두 개의 URL 이 존재하는 경우의 예제를 생각해 보겠습니다.
- http://site.com/bin
- http://site.com/binary
우리들이 원하는 것은 binary 디렉터리의 콘텐츠들은 서비스를 허용하지만 bin 디렉터리의 콘텐츠들은 서비스를 허용되지 않는 것입니다. 그렇지만, 만약 URL 시퀀스 필터링 기능을 사용하여 “bin” 시퀀스를 거부하도록 설정한다면, 결국 두 개의 URL 이 모두 거부되고 말 것입니다. 다음과 같은 구성설정을 사용하여 오직 bin 디렉터리에 대한 접근만을 거부하고 binary 디렉터리 하위에 존재하는 콘텐츠에 대한 접근은 계속해서 허용하도록 지정할 수 있습니다.
<system.webServer>
<security>
<requestFiltering>
<hiddenNamespaces>
<add hiddenDirectory="BIN" />
</hiddenNamespaces>
</requestFiltering>
</security>
</system.webServer>
</configuration>
요약
이전 버전의 IIS 에서 관리자들은 URLScan 을 사용하여 전역적인 수준의 보안 정책을 정의하고 자신들이 관리하는 시스템에 이를 적용할 수 있었습니다. IIS 7.0 에서 관리자들은 전역적인 수준뿐만 아니라 각각의 URL 들을 대상으로 동일한 정책을 적용할 수 있게 되었으며, 새롭고 풍부한 기능의 대체 모델이 제공하는 이점들을 이용할 수도 있습니다.
본문을 통해서 우리들은 요청이 거부될 때 요청 필터링이 리턴하는 몇 가지 새로운 오류 코드를 살펴보았습니다. 다음은 모든 IIS 로그 오류 코드를 정리한 간단한 참조 목록입니다.
|
오류 |
상태 코드 |
|
요청된 포트에서 웹 사이트에 액세스할 수 없습니다. |
404.1 |
|
웹 서비스 확장 잠금 정책으로 인해 이 요청이 거부됩니다. |
404.2 |
|
MIME 맵 정책으로 인해 요청이 거부됩니다. |
404.3 |
|
핸들러가 존재하지 않습니다. |
404.4 |
|
요청 필터링: URL 시퀀스로 인해 요청이 거부됩니다. |
404.5 |
|
요청 필터링: HTTP 동사로 인해 요청이 거부됩니다. |
404.6 |
|
요청 필터링: 파일 확장자로 인해 요청이 거부됩니다. |
404.7 |
|
요청 필터링: 숨겨진 네밍스페이스로 인해 요청이 거부됩니다. |
404.8 |
|
숨겨진 파일 속성이 설정되어 요청이 거부됩니다. |
404.9 |
|
요청 필터링: 요청 헤더가 너무 길어서 요청이 거부됩니다. |
404.10 |
|
요청 필터링: 이중 인코딩된 URL 로 인해 요청이 거부됩니다. |
404.11 |
|
요청 필터링: 비 ASCII 문자로 인해 요청이 거부됩니다. |
404.12 |
|
요청 필터링: 콘텐츠 길이가 너무 커서 요청이 거부됩니다. |
404.13 |
|
요청 필터링: URL 이 너무 길어서 요청이 거부됩니다. |
404.14 |
|
요청 필터링: 쿼리스트링이 너무 길어서 요청이 거부됩니다. |
404.15 |