태터툴즈 최근 버전에 관한 내용이 갱신되었기 때문에 글의 수정이 필요합니다.
Mono와 상관은 없습니다만 PHP Setup for IIS를 이용해서 Windows
기반의 PHP 웹 사이트를 운영하고자 하시는 분들에게는 분명히 도움이 되리라 생각하고
글을 씁니다. PHP Setup for IIS는
http://okstart.pe.kr 에서 받으실 수 있으며 Windows NT
4.x Server Family, 2000 Server Family, Server
2003 Family에서 사용할 수 있습니다. (Windows 9x 및 Windows
NT 4.x, Windows 2000 Professional의 Personal Web
Server와는 호환되지 않습니다.)
rkttu.com은 현재 Windows Server 2003의 IIS 6.0을 서버로
사용하며 PHP Setup for IIS를 사용하여 PHP에 관한 지원을
추가하였습니다.
하지만 실제로 몇몇 PHP 웹 어플리케이션들은 호환성 문제로 인하여 전혀 예상하지
못하거나 기대하지 않았던 불편을 초래하기도 합니다. 이 글을 통하여 조금이나마 도움이
되시기를 바라며 글을 올립니다.
1. 흔히 발생하는 퍼미션 문제
기존의 유닉스나 리눅스 계열 운영 체제에서는 세 자리의 숫자로 퍼미션에 관한 모든
설정을 제어할 수 있습니다. 하지만 Windows NT의 보안 체계는 이보다 훨씬
복잡한 구조를 나타냅니다. 따라서, 기존에 널리 사용되넌 chmod 명령어나 FTP를
통한 퍼미션 조정은 불가합니다.
Windows NT 계열의 운영 체제에서는 접근의 주체가 사용자라는 단위에 의하여
발생됩니다. 따라서, IIS도 합당한 사용자 계정을 획득한 상황에서 파일을 읽거나 쓰는
작업을 처리하게 되어있습니다. 이러한 계정은 시스템 계정으로, [IUSR_컴퓨터이름]과
같은 형태로 미리 만들어집니다.
특별히 IIS의 관리 콘솔을 이용하여 디렉터리에 접근하는 사용자의 권한을 다른 계정으로
주지 않았다면 [IUSR_컴퓨터이름] 계정에 대한 권한 할당을 해주는 것이 퍼미션 할당
작업에 해당됩니다.
퍼미션 할당 작업은 컨텐츠가 저장된 디렉터리를 탐색기로 열고, 해당 개체를 오른쪽
버튼으로 클릭하고 "속성" 또는 "등록 정보" 메뉴를 선택하면 나타나는 세부 사항 대화
상자의 "보안" 탭을 통해 조절할 수 있습니다.
2. PHP.INI에 설정된 임시 디렉터리에 관하여.
PHP.INI 파일에 파일 업로드 및 세션 처리를 위한 임시 디렉터리 관련 설정이
있습니다. 여기에 명시된 디렉터리는 반드시 Everyone (그룹)에 대해 모든 권한
할당을 해주어야 합니다.
3. IIS 6.0의 웹 서비스 확장에 대하여.
IIS 5.0과 6.0의 보안상의 차이점 중 가장 눈에 띄는 것은 ISAPI 및
CGI에 대한 보안 설정이 구체화되었다는 점입니다. 즉, IIS 6.0에서는 사용하려는
ISAPI DLL이나 CGI EXE는 반드시 웹 서비스 확장 섹션에 등록되어야 한다는
의미입니다. 여기에 등록하지 않고 웹 사이트 또는 특정 디렉터리의 응용프로그램 풀
구성에만 등록할 경우 동작하지 않게 됩니다.
4. PHP 기반 응용프로그램들은 항상 별도의 응용프로그램으로 독립시켜줄것.
PHP 기반 응용프로그램이 저장된 디렉터리 개체의 등록 정보를 IIS 관리자에서
살펴보면 디렉터리 탭이 있는데 그곳의 응용프로그램 설정 섹션을 살펴보면 기본값은
만들어져 있지 않은 것으로 되어있습니다. 좌측의 만들기 버튼을 눌러서 별도로 분리를
시키고, 반드시 실행 권한에는 "스크립트 전용"을 선택해 주셔야 합니다. 그리고 당연한
이야기이지만 "구성" 버튼을 눌러서 php 확장자에 대하여 php-cgi.exe 엔진을
연결시켜주어야 합니다.
5. 필요한 곳에서만 PHP 해석기 엔진을 사용하기
위의 4번과 같이 PHP 응용프로그램들을 따로 독립시켜두면 필요한 곳에서만 PHP
엔진을 호출하도록 구분할 수 있습니다. 이렇게 하여 성능을 최대한 발휘할 수 있도록
하는 것도 가능합니다.
6. 기본 문서에 유의할 것
IIS는 Apache와 달리 Default 라는 단어의 페이지가 미리 지정되어있습니다.
그래서 기본 문서에 index.html과 index.php 파일을 추가해 주는 것을
잊지 말아야 하겠습니다. 또한, 우선 순위를 높게 잡아주어 빨리 찾도록 해주는 것도
중요합니다.
7. 제로보드와 태터툴즈의 로그인 문제
제로보드와 태터툴즈만의 문제는 아닐 것입니다. 비슷하게 활용할 수 있는 곳이 적지 않을
것이라 보고 공통의 코드 두 줄을 알려드립니다. 이 코드 두 줄을 필요한 곳에 적절히
배치하는 것이 중요하리라 생각됩니다. 태터툴즈 구버전 (0.x) 사용자 계서는 7.2
섹션을 꼭 참고하십시오.
7.1. 제로보드의 로그인 문제 해결
제로보드의 로그인 문제를 해결하기 위해서는 lib.php 파일에서 다음의 섹션을
찾으셔야 합니다.
/*******************************************************************************
* 에러 리포팅 설정과 register_globals_on일때 변수 재 정의
******************************************************************************/
@error_reporting(E_ALL ^ E_NOTICE);
@extract($HTTP_GET_VARS);
@extract($HTTP_POST_VARS);
@extract($HTTP_SERVER_VARS);
@extract($HTTP_ENV_VARS);
위와 같은 섹션의 바로 밑 부분에 아래의 코드를 집어넣어 주십시오.
$_QU = ($QUERY_STRING) ? "?" : "" ;
$REQUEST_URI =
"$PHP_SELF"."$_QU"."$QUERY_STRING";
7.2. 태터툴즈의 로그인 문제 해결
태터툴즈의 최신 버전은 이런 사항을 해결하였습니다. 따라서 이 내용을 적용할 필요는
없습니다. 하지만 아직 구 버전을 사용하고 계실 경우 아래의 지시 사항대로 따라하여
주십시오.
태터툴즈의 로그인 문제를 해결하시기 위해서는 inc_function.php 파일을 열고
다음의 섹션을 찾아주십시오.
reset($HTTP_SERVER_VARS);
while (list($key, $val) =
each($HTTP_SERVER_VARS)) {
$$key = $val;
}
바로 밑에 두 줄의 코드를 집어넣습니다.
$_QU = ($QUERY_STRING) ? "?" : "" ;
$REQUEST_URI =
"$PHP_SELF"."$_QU"."$QUERY_STRING";
두 곳 모두 같은 코드를 집어넣었습니다. 로그인 문제가 발생하는 PHP 프로그램에는
위와 같은 방법을 사용하여 해결이 가능할 것이라 봅니다.
8. 일부 Perl 프로그램들의 파일 입/출력 문제
IIS에서는 Active Perl을 사용하여 Perl 웹 프로그램들을 구동할 수
있습니다. 하지만 문제점이 있는데, 유닉스나 리눅스와는 달리 Windows NT는
심볼릭 링크의 개념이 없습니다. 그에 따라서 파일 액세스를 하기 위하여 파일 핸들을
열어놓으면 다른 프로세스가 접근할 수 없게 됩니다. 즉, 다중 사용자 접속에 취약하게
됩니다.
이 점을 고치기 위하여 직접 Win32 API를 핸들링하여 Shared Mode로
열도록 고쳐도 되겠습니다만 많은 노력이 필요할 것입니다. 이 점에 대한 마땅한 해결책은
아직까지 없는듯 합니다.
9. MBSA (Microsoft Baseline Security Analyzer)의
검진 보고서에서 조심해야 할 것
최근에 경험한 사실 한 가지가 있습니다. MBSA 라는 유틸리티는 Microsoft사가
Technet을 통하여 무료로 배포하는 보안 점검 유틸리티입니다. 군더더기 없는 정확한
핫픽스만을 설치할 수 있어서 자주 애용하고 있는 유틸리티이기도 합니다. 최근에 저는 이
유틸리티를 사용하면서 한 가지 실수를 저질렀습니다. 그것은 다름이 아니라 IIS와
연관성이 있는(?) World Wide Web Publishing Service 라는
이름의 서비스에 대한 보고서였습니다. MBSA는 이것을 그닥 필요없는 서비스이기 때문에
꺼도 좋다고 이야기를 하고 있습니다만 이대로 시행하였다가 낭패를 봤습니다. CGI
기반으로 연결된 PHP 해석기가 동작하지 않기 시작하였습니다. 하는 수 없이 원래대로
복구를 하고 IIS를 재시작하니 그제서야 제자리를 찾았습니다. 이 점에 대해서 다른
의견이 있으시면 듣고 싶습니다. ^^
서버 관리자 여러분들께서는 많은 도움이 되셨기를 바랍니다.
남정현(junghyun0816)
http://rkttu.com
|
