이 기사를 통해 현재 수 많은 웹서버들의 취약점을 찾아 공격하고 있는 악의적 유저들을 막아내는 방법에 대해서 기초적인 지식을 얻을 수 있다.
일반적인 유저 인증 프로세스와 Apache서버와 리눅스에서 지원하는 인증 프로세스를 이해하고 이를 통한 효과적인 전략수립과 설정방법등에 대해서 정보를 얻을 수 있다.
기나긴 강좌의 진행에 앞서 이 기사에서는 다음의 전제조건을 갖고 출발함을 알린다.
- Apache 의 소스 트리가 . /apache-1. 3/ 부터 시작되는 것
- Apache 의 ServerRoot 이 /usr/local/web/apache 인 것
- Apache 의 DocumentRoot 가 /usr/local/web/htdocs 인 것
- Apache 가 실행될 때의 유저명 (httpd.conf 파일의 User 지시자의 값)이 nobody 인 것
기사에서 언급하는 부분은 위의 디렉토리를 참조하게 된다.
강제/임의 액세스 제어
액세스 제어에는 2개의 기본적인 방법이 있다. 하나는 유저가 자신있게 자신을 검증하는것과 유저가 누구인지 믿을 만한 누군가가 검증하는 것이다.
기본적인 검증법에는 다음을 조사한다.
- 유저가 가지고 있는 것
- 유저가 알고 있는 것
- 유저가 누구인가
혹은, 이것들을 조합하는 것이다. 조금 이 이야기를 일반적인 이야기로 옮겨보자면
'유저가 가지고 있는 것' 이란 '문을 열기 위한 작은 자물쇠의 열쇠'라고 할 수 있다. 문을 열고 들어갈 수 있는 자물쇠의 올바른 열쇠를 가지고 있으면 들어갈 수 있게 하는 것이다.
'유저가 알고 있는 것'이란, 은행계좌를 본인밖에 사용할 수 없게 해주는 비밀번호 같은 것이다. 이 비밀번호가 알려지지 않는 한 문제가 발생하지는 않는다.
'유저가 누구인가'라는 것은 DNA패턴이 증거로 인정되듯이, 본인임을 인정해 보안을 강화하는 것이다.
고도의 보안이 요구되는 시스템에서는, 이러한 인증 방법들이 조합되어 사용하는 것이 보통이다. 예를 들어 은행의 ATM 머신은 위의 2개의 방법을 활용하고 있댜. 현금을 인출하기 위해 ATM 카드를 가진 사람만이 접근할 수 있고, 카드의 비밀번호를 아는 사람만이 접근하게 하는 방식이다.
그런데 '임의와 강제'라는 말은 무엇을 뜻하는 것인가? 간단하게 말하면 임의 엑세스 제어(DAC)에서는, 유저가 자유롭게 취급할 수 있는 증명 정보의 정당성을 조사해 인증하는 방법이고, 강제 엑세스 제어 (MAC)에서는, 유저가 자유롭게 취급할 수 없는 것을 조사한다.
예를 들어, 누군가 다른 사람으로부터 유저명과 패스워드를 받으면, 유저는 시스템에 엑세스 할 수 있지만, 이 때 사용되는 유저명과 패스워드는 사용자의 권한하에 있어,
시스템에서는 실제로 엑세스 한 유저가 실질적인 소유주인지는 모른다. 이러한 시스템을 임의 엑세스 제어 시스템이라고 한다.
한편, DNA 정보는 변경할 수가 없다. 유저의 DNA 패턴에 의해 엑세스를 허가하는 시스템이 있다면 그 유저 이외에 아무도 엑세스 할 수 없게 되고, 유저가 타인으로 엑세스 되는 것을 막을 수 있다. 이러한 시스템을 강제(비임의) 액세스 제어 시스템 이라고 한다.
Web의 분야, 특히 Apache에서는, 임의 제어를 통한 접근 제한은 유저명과 패스워드를 통한 방법이고, 강제 제어는 클라이언트의 IP 주소와 같은 정보를 통한 제어이다.
임의 제어와 비임의 제어를 분명히 구별하는 방법으로 엑세스 실패시 처리 방법을 생각해 보면 쉽다. 예를 들어 패스워드를 잘못입력해서 임의 제어로 엑세스에 실패했을 경우에는 재차 시도의 기회가 주어진다.
하지만, 강제 제어의 엑세스에 실패하면, '금지'에러가 된다.
인증과 승인
인증이라는 것은, 증명 정보가 올바른지 어떤지를 확인하는 프로세스다. 즉, 유저명은 미리 시스템의 데이터베이스에 존재하고, 입력된 패스워드가 유저명에 대해서 올바른지 어떤지를 조사할 수 있다.
한편, 승인이라는 것은 정당한 클라이언트가 특정한 자원에의 엑세스를 허가하고 있는지 어떤지를 확인하는 프로세스다.
예를 들어, 철수는 올바를 유저명과 패스워드를 가지고 있지만, 제한된 파일을 엑세스 할 수 없다. 왜냐하면 철수는 엑세스 승인 리스트에 존재하지 않기 때문이다.
Apache에서는, 거의 모든 보안 관련 모듈로 위의 모두의 프로세스를 행한다. 각 모듈을 구별하는 주된 특징은 인증의 방식이다. 대부분의 모듈에서는 유효한 증명 정보를 특정의 포맷으로 보존해 둘 필요가 있다.
예를 들어 mod_auth 모듈에서는, 유저명과 패스워드 정보를 일반적인 텍스트 파일에 담아 두며, mod_auth_dbm 에서는 DBM 데이터베이스에 담아 둔다. 승인의 방식에서는 이 모듈들에서는 본질적으로 같은 방법이 사용되고 있다.
보안 모듈에는 AuthUserFile 이나 AuthDBMGroupFile 와 같은 지시자를 통해, 인증 데이터베이스의 정보를 건네받는다. 보호되는 자원은, 설정 파일내에서 지시자를 사용해 지정한다.
AuthName "Foo for Thought"
AuthType Basic
AuthUserFile /home/johnson/foo.htpasswd
Require valid-user
이 예에서는, 보호되는 자원은 /home/johnson/public_html 디렉토리 및 그 아래 층에 있는 「foo.bar 라는 이름의 파일」이다. 또, foo.bar 에 엑세스가 승인되고 있는 증명 정보를 식별할 방법이 지시자에 의해 설정되어 있다.
이 경우, /home/johnson/foo.htpasswd 에 담겨져 있는 유효한 증명 정보를 가지는 유저는 보호된 자원에 엑세스 할 수 있다.
▶ 계속: Apache의 보안처리
Apache에서의 보안처리 부분은 아래의 3개의 보안 모듈 부분을 통과함으로써 진행된다. 대부분 엑세스를 위해서는 아래의 1개 또는 2개모듈을 통과하게 된다.
Apache에서는 보안 인증 부분을 3개 부분으로 나누어 처리하는데 다음과 같은 순서로 진행된다.
- access_checker
이 부분에서는 강제 액세스의 체크가 적용된다. 예를 들어, mod_access에 의해, 클라이언트의 IP 주소가 문서에 액세스를 허가 받았는지 체크된다.
- check_user_id
이것은 인증 부분이다. mod_auth와 같은 DAC 모듈에 의해, 유저의 증명 정보가 데이타베이스중에 있어 그것이 유효한지를 체크한다.
- auth_checker
- 이 부분에서는 승인을 한다. mod_auth등의 모듈에 의해, 위의 부분으로 인증된 유저에게 문서에의 액세스가 허가 되었는지 체크한다.
임의 액세스를 체크하는 부분은 보통 2부분에 걸쳐 진행된다.
기본 인증과 다이제스트 인증
현재, 사용자의 증명 정보를 주고 받는 방법에는 인증과 다이제스트 인증이라는 2개의 방법이 있다. 다이제스트 방법은 매우 보안적인 방법이어서 실질적으로 많이 사용되지 않고 있다.
웹상에서의 대부분의 인증은 보다 낮은 보안 방법인 기본인증 메커니즘을 사용하고 있다.
기본 인증에서는, 사용자명과 패스워드를 base64 encode 한 것을 서버에 송신하고 있는 것에 지나지 않는다. 통신을 방해하거나 가로챈다면 사용자명과 패스워드를 알 수 있다는 것이다. 물론 그러한 정보가 올바르게 인증에 성공하지 않으면 의미가 없지만 말이다. 한편, 다이제스트 인증에서는, 증명 정보는 타인에 의해 쉽게 디코드할 수 없는 방식으로 송신한다.
사용자명과 패스워드는 기본 인증의 메카니즘에서는 거의 보호되고 있지 않고, 복수의 보호 영역에서, 사용자 정보를 인증 데이타베이스 같은 것이 사용된다. 다이제스트 인증 메카니즘에서는, 증명 정보가 유효한 보호 영역의 이름이 encode 되므로, 다이제스트법을 사용한 보호 영역에서는, 각각 개별의 인증 데이타베이스를 가질 필요가 있다.
Apache의 구성시에 임의 제어를 설정하려면 AuthType 지시자가 필요하다. 설정은 보다 상위의 디렉토리로부터 계승되지만 계승되는 값을 따로 설정할 필요가 있다. 기본값은 아무것도 설정되어 있지 않다.
강제 및 임의 제어의 편성 Satisfy 지시자
임의 및 비임의 액세스 제어를 편성해 사용하고 싶은 경우도 있을 것이다. 예를 들어, 로컬 네트워크에 있는 사용자는 자유롭게 문서에 액세스 할 수 있지만, 그 이외는 사용자명과 패스워드를 입력할 필요가 있다라고 하는 설정을 하고 싶다면 다음과 같은 경우이다.
이러한 설정을 하기에는 Satisfy 지시자를 사용한다. 이것은 다음과 같은 키워드를 이용한다.
- All
Satisfy All 지시자가 적용되는 문서에 엑세스 하려는 모든 클라이언트는 비임의 체크와 임의 체크를 통과해야 한다.
- Any
Satisfy Any 지시자가 적용되는 문서에 액세스 하려는 클라이언트는 비임의 체크 또는 임의 체크 어딘가를 패스하면 된다.
예를 들어 다음의 설정에서는, 로컬 네트워크 (IP 주소가 10. *. *. *)에 있는 클라이언트는, foo.html 페이지로 자유롭게 액세스 할 수 있지만, 그 이외의 사람에게는 모두, 사용자명과 패스워드를 요구하게 된다.
- Order Deny, Allow
- Deny from All
- Allow from 10.0. 0.0/255. 0.0. 0
- AuthName "Insiders Only"
- AuthType Basic
- AuthUserFile /usr/local/web/apache/.htpasswd-foo
- Require valid-user
- Satisfy Any
IP 주소는, 클라이언트/서버형태의 HTTP통신을 위한 중요한 요소이다. 송신중에 변경할 수 없고 위장하기도 어렵기 때문에 제어를 위해 필요한 정보이다.
Apache의 배포버전에는 이러한 IP를 통한 엑세스 제한 모듈이 포함되어 있다.
Apache의 mod_access모듈을 이용하면 엑세스 허가/거절을 도메인이나 IP주소에 지정할 수 있다. 허가와 거절을 위해서 Allow 와 Deny 지시자의 기본적인 구문을 나타내면 다음과 같다.
Allow from host-or-network
host-or-network 로 지정할 수 있는 것은 다음과 같다.
- 호스트 또는 도메인명 (www.foo.com)
- IP 주소 (10.0.72.3)
- IP 주소와 subnet mask (10.0. 0.0/255. 0.0. 0)
- IP 주소와 CIDR 마스크 사이즈 (10.73. 128.0/18)
가능한 제어를 이용하려면 도메인명보다는 IP 주소를 사용하는 편이 좋다. 도메인명을 사용하면, Apache 에서는 클라이언트의 IP 주소로 변환하기 위한 불필요한 변환 작업이 필요하다. 변환이 이뤄진 후 호스트/도메인명이 일치하지 않으면 접근을 제어할 수 있다.
이 밖에도 Allow 및 Deny 지시자를 사용한 지정 방법이 있다. 「 from env=[! ]envariable-name」를 사용하면, 환경 변수의 유뮤를 통해 가능/불가의 결정을 할 수 있다. 환경 변수는 서버 전체의 환경에 대해서 설정하는 것도 할 수 있고, mod_setenvif 의 모듈을 사용하면, 각 요구에 대해서 설정하는 것도 할 수 있다.
Order 지시자는, IP제어를 통해 Allow 및 Deny 목록에 수록된 리스트의 해석방법을 제어한다. 순서가 Allow, Deny의 경우, 초기 상태는 Deny from All 와 같은 상태이고, Allow의 조건 리스트가 처리된 후,Deny 의 조건 리스트가 처리된다. Order Deny, Allow 는 그 역으로, 초기 상태에서는 「모두 허가」이고, Deny의 조건 리스트가 처리된 후, Allow의 조건 리스트가 처리된다.
기억하는 쉬운 방법은 허가와 거부의 조건은 마지막 키워드와 일치한 다고 생각하면 된다. 즉, Deny, Allow는 「허가」로, Allow, Deny는 「거부」라고 이해하면 된다.
사용자 인증에 의한 제한
특정 페이지를 사용자 아이디와 패스워드를 통해 접근을 가능하게 하는 제한을 하려면 mod_auth 모듈을 이용해야 한다. 이것은, 임의 제어 모듈 중에서, 가장 간단하게 사용할 있다.
액세스 제어를 설정하는데 중요한 지시자는 인증 데이타베이스의 장소의 정의와 승인된 유저의 확인에 관한 것이다. mod_auth 모듈에서 지시자는 AuthUserFile과 Require 이다. 다른 모듈에도 같은 역할을 가지는 지시자가 있다.
AuthUserFile 지시자는, 풀 패스로 지정한 파일명을 잡는다 (예: /home/foo/.htpasswd-foo). 이것은, 현재의 보호 영역에서 모듈이 사용하는 텍스트 형식의 인증후 장소를 지정하는 것이다. 패스의 생략형태나 상대 패스에 의한 파일 지정은 허가되어 있지 않다.
Require 지시자의 자세한 정보는 http://httpd.apache.org/docs/mod/core.html#require 를 참조하기 바란다. Require에 대해서는 다음 기사에서 좀 더 논해보도록 하자.
레벨과 계승
각각의 장소에 대해서 유효한 다른 인증 파일을 사용하면, 같은 보호 영역에 있는 URL을 다른 방법으로 제어하는 것을 할 수 있다. 복수의 접근제어를 사용하도록 설정하면 보안에 강화되는 부분이 있지만 반복 인증제어를 통과해야 하기 때문에 사용자가 불편할 수 있다.
- AuthName Finance
- AuthType Basic
- AuthUserFile /usr/local/web/apache/auth/.htpasswd-finance
- Require valid-user
위의 예는 finance 서브 디렉토리와 모든 파일, 그리고 하위의 서브 디렉토리가 보호되게 설정한 예이다. products와 같은 다른 디렉토리에는 영향을 주지 않는다.
계승
다른 대부분의 Apache 구성과 같이, 특정 문서나 디렉토리에 적용된 보안 지시자는, 부모 레벨로부터 또는 트리 구조의 것보다 상위의 레벨로부터도 계승된다. 그 때문에, 각 레벨로 다른 지시자만을 설정 하면 되는 것이 된다. 다음의 두가지 예는 같은 설정을 나타낸다.
- AuthName "Finance Department"
- AuthType Basic
- AuthUserFile /usr/local/web/apache/auth/.htpasswd-finance
- Require valid-user
- AuthName "Finance Department"
- AuthType Basic
- AuthUserFile /usr/local/web/apache/auth/.htpasswd-finance
- Require user susan bob
- AuthName "Finance Department"
- AuthType Basic
- AuthUserFile /usr/local/web/apache/auth/.htpasswd-finance
- Require valid-user
두가지의 예에서는, 부모 디렉토리로부터의 값의 계승을 잘 이용하고 있고, 서브 디렉토리에서는 액세스 리스트를 Bob 와 Susan 에 제한하는 지정만으로 끝나고 있다.
일반적으로, 보안의 문제를 취급할 때에 가정을 너무 세우는 것은 좋은 방법은 아니다. 계승을 이용해 보안을 설정하기 때문에 상위의 디렉토리에 한 번만 제어를 하면 계승된다고 행복해 하면 큰 낭패를 만날지도 모른다. 상위듸 디렉토리 설정 하나의 잘못으로 부적절한 계승이 이뤄질 수 있음을 잊지 말자.
특정 사용자명의 요구
AuthUserFile나 동종의 지시자(Require) 설정을 통해 특정 사용자의 엑세스만을 요구하는 제어를 할 수 있다.
다음의 경우를 생각해 보자.
- AuthUserFile /home/foo/.htpasswd-foo
- Require user foo
- Require user bar
이 예에서는, 사용자명이 foo 또는 bar를 요구한다.
Require 지시자는 어느 모듈에서도 공통에 사용할 수 있고 그 구문도 어렵지 않다. 사용되는 구문에 제한또한 없다.
대부분의 임의 제어 모듈에서는, 유저의 그룹화를 서포트하고 있어, 개인 대신에 그룹에 접근 허가를 줄 수가 있다. 이 기능은 (mod_auth 에서는) AuthGroupFile 지시자를 사용해 설정한다. 유저 파일과 같게, 그룹 파일에는, 각 행에 그룹명, 구두점, 그리고 콤마로 단락지어진 사용자명으로부터 되는 텍스트 정보만이 포함되어 있다. 액세스 요구의 증명 정보로부터 사용자명을 받는다.
모듈은 그룹 파일을 검색해, 그 유저가 어느 그룹에 속하고 있는지를 조사한다. 다음은 설정의 예이다.
- board:annette, bill, james, gwynyth
- finance:susan, steve, phoebe, zoe, bill_s
- engineering:geekboy, lisa, melanie, george, j_johnson
그룹에 의한 액세스를 허가하기에는,Require 지시자를 다음과 같이 변경하는 것만으로 좋다.
통상의 UNIX 유저와 같이 하나의 사용자명은 복수의 그룹에 속하는 것이 가능하다.
* 따삼님에 의해서 게시물 이동되었습니다 (2007-05-29 13:57) | 
