섹션 설정

가능한 언어: en | + fr | + ja | + ko | + tr

이 문서는 최신판 번역이 아닙니다. + 최근에 변경된 내용은 영어 문서를 참고하세요.

설정파일에 있는 +지시어는 서버 전체에 적용되거나, 특정 디렉토리, 파일, 호스트, +URL에만 적용될 수 있다. 이 문서는 다른 지시어의 적용범위를 +제한하기위해 설정 섹션이나 .htaccess 파일을 +사용하는 방법을 설명한다.

설정 섹션의 종류
파일시스템과 웹공간
가상호스트
프록시
안에 어떤 지시어를 사용할 수 +있나?
섹션들이 결합하는 방법

참고

Comments

설정 섹션의 종류

관련된 모듈	관련된 지시어
`core` `mod_proxy`	`<Directory>` `<DirectoryMatch>` `<Files>` `<FilesMatch>` `<IfDefine>` `<IfModule>` `<Location>` `<LocationMatch>` `<Proxy>` `<ProxyMatch>` `<VirtualHost>`

+ + + +

섹션에는 두가지 종류가 있다. 대부분은 매요청마다 처리된다. +해당하는 요청에만 안에 포함한 지시어를 적용한다. 반대로, <IfDefine>과 <IfModule>은 서버가 +시작할때와 꺼질때만 처리한다. 시작할때 상태가 참이면 안에 있는 +지시어가 모든 요청에 적용된다. 참이 아니면 안에 있는 지시어는 +무시한다.

+ +

<IfDefine> +지시어는 httpd 명령행에 적절한 파라미터가 있는 +경우에만 안에 포함한 지시어를 적용한다. 다음 설정을 예로 들면, +서버를 httpd -DClosedForNow로 시작할 경우에만 +모든 요청이 다른 사이트로 리다이렉션된다:

+ +

+<IfDefine ClosedForNow> +Redirect / http://otherserver.example.com/ +</IfDefine> +

+ +

<IfModule> +지시어도 특정 모듈이 서버에 포함된 경우에만 안에 든 지시어를 +적용한다는 점을 제외하고는 매우 비슷하다. 모듈을 서버에 정적으로 +컴파일하거나 동적으로 컴파일한후 설정파일 앞에 LoadModule 줄이 있어야 한다. 이 +지시어는 특정 모듈의 설치유무에 따라 설정파일이 다를 필요가 +있을때만 사용해야 한다. 모듈이 없는 경우 유용한 오류문이 나오지않을 +수 있기 때문에 언제나 사용하길 원하는 지시어를 안에 두면 안된다.

+ +

다음 예에서 mod_mime_magic이 있을때만 MimeMagicFiles 지시어를 +처리한다.

+ +

+<IfModule mod_mime_magic.c> +MimeMagicFile conf/magic +</IfModule> +

+ +

<IfDefine>과 +<IfModule>의 +검사 앞에 "!"을 붙여 조건을 역으로 할 수 있다. 또, 여러 섹션들을 +겹쳐서 사용하여 더 복잡한 효과를 얻을 수 있다.

파일시스템과 웹공간

+ +

가장 자주 사용되는 설정 섹션은 파일시스템과 웹공간(webspace)의 +특정 장소에 대한 설정을 변경하는 것들이다. 먼저 이 둘의 차이를 +이해하는 것이 중요하다. 파일시스템은 운영체제 입장에서 디스크를 +보는 관점이다. 예를 들어, 기본값으로 아파치를 설치를 하면 유닉스 +파일시스템의 경우 /usr/local/apache2, 윈도우즈 +파일시스템의 경우 "c:/Program Files/Apache +Group/Apache2"에 설치된다. (아파치는 윈도우즈에서 조차 +항상, 역슬래쉬가 아닌, 슬래쉬를 사용함을 주의하라.) 반대로 +웹공간은 웹서버가 제공하고 클라이언트가 보게될 사이트의 관점이다. +그래서 유닉스에서 기본 아파치 설치를 한 경우 웹경로의 경로 +/dir/은 파일시스템 경로 +/usr/local/apache2/htdocs/dir/에 해당한다. 웹공간은 +데이타베이스 등에서 동적으로 생성될 수 있기때문에 반드시 +파일시스템에 직접 대응될 필요는 없다.

+ +

파일시스템 섹션

+ +

<Directory>와 +<Files> 지시어와 +정규표현식을 사용하는 지시어는 파일시스템의 특정 부분에 지시어를 +적용한다. <Directory> 지시어에 포함된 지시어들은 +지정한 파일시스템 디렉토리와 그 하위 디렉토리에 적용된다. .htaccess 파일을 사용해도 결과는 +같다. 다음 설정을 예로 들면, 디렉토리 목록(index)이 +/var/web/dir1 이하 디렉토리에서 디렉토리 목록(index)이 +가능하다.

+ +

+<Directory /var/web/dir1> +Options +Indexes +</Directory> +

+ +

<Files> 섹션에 포함된 지시어들은 어떤 +디렉토리에 있는지 관계없이 지정한 이름을 가진 파일에 적용된다. +설정파일의 주설정부분에 있는 다음 설정을 예로 들면, 장소와 +관계없이 private.html이란 이름을 한 파일의 접근을 +거부한다.

+ +

+<Files private.html> +Order allow,deny +Deny from all +</Files> +

+ +

파일시스템의 특정 부분에 있는 파일을 지칭하기위해 <Files>와 <Directory> 섹션을 같이 +사용한다. 다음 설정을 예로 들면, +/var/web/dir1/private.html, +/var/web/dir1/subdir2/private.html, +/var/web/dir1/subdir3/private.html 같이 +/var/web/dir1/ 디렉토리 아래에 있는 이름이 +private.html인 파일의 접근을 거부한다.

+ +

+<Directory /var/web/dir1> +<Files private.html> +Order allow,deny +Deny from all +</Files> +</Directory> +

+ + +

웹공간 섹션

+ +

<Location> +지시어와 이에 해당하는 정규표현식을 사용하는 지시어는 반대로 +특정 웹공간의 설정을 바꾼다. 다음 설정을 예로 들면, /private으로 +시작하는 URL-경로의 접근이 거부된다. 여기에는 +http://yoursite.example.com/private, +http://yoursite.example.com/private123, +http://yoursite.example.com/private/dir/file.html +같이 /private 문자열로 시작하는 요청이 해당된다.

+ +

+<Location /private> +Order Allow,Deny +Deny from all +</Location> +

+ +

<Location> +지시어는 파일시스템에 대응할 필요가 없다. 다음 예는 어떻게 특정 +URL을 mod_status가 제공하는 아파치 내부 핸들러로 +대응시키는지를 보여준다. 파일시스템에 server-status라는 +파일은 필요없다.

+ +

+<Location /server-status> +SetHandler server-status +</Location> +

+ + +

와일드카드와 정규표현식

+ +

<Directory>, +<Files>, +<Location> +지시어에서 C 표준 파이브러리의 fnmatch와 같은 +쉘에서 사용하는 와일드카드 문자를 사용할 수 있다. +"*" 문자는 어떤 문자열이라도 나타내고, "?" 문자는 어떤 문자 한개를 +나타내며, "[seq]"는 seq 중에 한 문자를 나타낸다. +어떤 와일드카드도 "/" 문자를 나타내지는 못한다. 그래서 이 문자는 +직접 사용해야 한다.

+ +

더 유연한 설정이 필요하면 perl호환 정규표현식을 사용하는 <DirectoryMatch>, <FilesMatch>, <LocationMatch>를 사용할 +수 있다. 그러나 아래 설정의 결합에 관한 절에서 정규표현식 섹션을 +사용하면 지시어가 적용되는 방법이 어떻게 변하는지 살펴봐라.

+ +

모든 사용자 디렉토리 설정을 변경하는 비정규표현식 와일드카드 +섹션은 다음과 같다:

+ +

+<Directory /home/*/public_html> +Options Indexes +</Directory> +

+ +

정규표현식 섹션을 사용하여 한번에 여러 종류의 그림파일에 +대한 접근을 거부할 수 있다:

+<FilesMatch \.(?i:gif|jpe?g|png)$> +Order allow,deny +Deny from all +</FilesMatch> +

+ + + +

무엇을 사용하나

+ +

파일시스템 섹션과 웹공간 섹션 중 하나를 선택하는 것은 실제로 +매우 쉽다. 파일시스템에 있는 객체에 지시어를 적용할때는 항상 +<Directory>나 +<Files>를 +사용한다. (데이타베이스에서 생성한 웹페이지와 같이) 파일시스템에 +있지 않는 객체에 지시어를 적용할때는 <Location>을 사용한다.

+ +

파일시스템에 있는 객체의 접근을 제한하기위해 <Location>을 사용하면 +절대 안된다. 여러 다른 웹공간 장소(URL)가 같은 파일시스템 장소에 +대응될 수 있으므로, 걸어둔 제한을 우회할 수 있기 때문이다. 다음 +설정의 예를 살펴보자:

+ +

+<Location /dir/> +Order allow,deny +Deny from all +</Location> +

+ +

이 설정은 http://yoursite.example.com/dir/을 +요청한다면 잘 작동한다. 그러나 대소문자를 구별하지않는 파일시스템을 +사용한다면 어떻게되나? +http://yoursite.example.com/DIR/을 요청하여 쉽게 +제한을 우회할 수 있다. 반대로 <Directory> 지시어는 어떻게 요청하였는지 +관계없이 그 장소에서 서비스되는 내용에 적용된다. (예외는 파일시스템 +링크를 사용하는 경우다. 심볼링크를 사용하여 한 디렉토리를 +파일시스템의 여러 장소에 둘 수 있다. <Directory> 지시어는 심볼링크를 따라간다. +그러므로 높은 수준의 보안을 위해서는 적절한 Options 지시어를 사용하여 심볼링크를 +무시해야 한다.)

+ +

아마도 당신은 대소문자를 구별하는 파일시스템을 사용하므로 +이런 일이 일어나지 않는다고 생각할지도 모른다. 그러나 다른 +방법으로도 여러 웹공간 위치가 한 파일시스템 위치에 대응될 수 +있음을 기억하라. 그래서 가능하면 항상 파일시스템 섹션을 사용해야 +한다. 그러나 이 규칙에 예외가 하나 있다. 설정 제한을 +<Location /> 섹션에 두면 이 섹션이 특정 +URL이 아닌 모든 요청에 적용되므로 완벽하게 안전하다.

+ + +

가상호스트

+ +

<VirtualHost> +섹션은 특정 호스트에 적용되는 지시어들을 포함한다. 이는 한 +컴퓨터에서 각각 다른 설정을 사용한 여러 호스트를 서비스할때 +유용하다. 더 자세한 정보는 가상호스트 문서를 +참고하라.

프록시

+ +

<Proxy>와 +<ProxyMatch> +섹션은 지정한 URL에 대해 mod_proxy 프록시 서버를 +거쳐 접근하는 경우에만 적용된다. 다음 설정을 예로 들면, 프록시 +서버를 통해 cnn.com 웹사이트에 접근할 수 없다.

+ +

+<Proxy http://cnn.com/*> +Order allow,deny +Deny from all +</Proxy> +

안에 어떤 지시어를 사용할 수 +있나?

+ +

어떤 설정 섹션안에 사용할 수 있는 지시어를 알려면 지시어의 +사용장소를 확인하라. +<Directory>에서 +사용가능한 지시어는 <DirectoryMatch>, <Files>, <FilesMatch>, <Location>, <LocationMatch>, <Proxy>, <ProxyMatch> 섹션에서도 사용가능하다. +그러나, 예외가 있다:

+ +

AllowOverride 지시어는 +<Directory> +섹션에서만 사용할 수 있다.
FollowSymLinks, SymLinksIfOwnerMatch, +Options는 <Directory> 섹션이나 +.htaccess 파일에서만 사용할 수 있다.
Options 지시어는 +<Files>과 +<FilesMatch> +섹션에서 사용할 수 없다.

섹션들이 결합하는 방법

+ +

설정 섹션은 매우 특별한 방법으로 적용된다. 이 순서가 설정 +지시어를 해석하는 방법에 중요한 영향을 주기때문에 이 방법을 +이해하는 것이 중요하다.

+ +

결합하는 순서는:

+ +

(정규표현식을 사용하지않는) <Directory>와 .htaccess는 + 동시에 일어난다 (경우에 따라 .htaccess이 + <Directory>를 + 무시하도록 설정할 수 있다)
<DirectoryMatch> (그리고 + <Directory ~>)
<Files>와 <FilesMatch>는 동시에 일어난다
<Location>과 <LocationMatch>는 동시에 일어난다

+ +

<Directory>를 제외하고 각 섹션들을 + 설정파일에 나온 순서대로 처리된다. (위의 순서 1) <Directory>는 디렉토리 + 내용이 가장 짧은 것에서 긴쪽으로 처리된다. 그래서 예를 들어, + <Directory /var/web/dir>을 + <Directory /var/web/dir/subdir> 이전에 + 처리한다. 같은 디렉토리를 지칭하는 여러 <Directory> 섹션이 + 있다면 이들을 설정파일 순서대로 처리한다. Include 지시어로 포함한 설정은 + Include 지시어 위치에 + 포함한 파일 내용이 있는 것처럼 처리한다.

+ +

<VirtualHost> 섹션 안에 포함된 섹션은 + 가상호스트 정의 밖에 있는 해당 섹션 이후에 적용된다. + 그래서 가상호스트 안에서 주서버의 설정사항을 수정할 수 있다.

+ +

mod_proxy가 요청 서비스할때, <Proxy> 섹션의 + 처리순서는 <Directory> 섹션과 같다.

+ +

다음에 나오는 섹션은 이전 섹션의 결과를 수정한다.

+ +

기술적 주의

+ 실제로 + <Location>/<LocationMatch>는 + (Aliases와 DocumentRoot를 사용하여 + URL을 파일명으로 변환하는) 이름번역 단계 이전에 처리된다. + 변역이 끝난 이후에는 완전히 무시한다. +

+ +

예제

+ +

다음은 겹합하는 순서를 설명하는 예다. 이들 모두 요청에 +적용된다고 가정하면 지시어는 A > B > C > D > E +순서로 처리된다.

+ +

+<Location /> +E +</Location> + +<Files f.html> +D +</Files> + +<VirtualHost *> +<Directory /a/b> +B +</Directory> +</VirtualHost> + +<DirectoryMatch "^.*b$"> +C +</DirectoryMatch> + +<Directory /a/b> +A +</Directory> + +

+ +

더 현실적인 예는 다음과 같다. <Location> 섹션을 나중에 처리하므로 +<Directory> +섹션에 있는 접근제한과 관계없이 서버에 무제한 접근을 가능하다. +즉, 결합하는 순서는 중요하므로 주의하라!

+ +

+<Location /> +Order deny,allow +Allow from all +</Location> + +# 악! 이 <Directory> 섹션은 아무런 효과가 없다 +<Directory /> +Order allow,deny +Allow from all +Deny from badguy.example.com +</Directory> +

+ + + +