test

Sun Java System Messaging Server 6 2005Q4 관리 설명서

POP, IMAP 및 HTTP 서비스에 대한 클라이언트 액세스 구성

이 절에는 다음과 같은 하위 절이 포함됩니다.

Messaging Server는 서버에 액세스할 수 있는 클라이언트를 광범위하고 세부적으로 제어할 수 있도록 IMAP, POP 및 HTTP 서비스에 대한 정교한 서비스별 액세스 제어를 지원합니다.

대기업이나 인터넷 서비스 공급자에 대한 메시징 서비스를 관리하는 중이면 이러한 기능은 시스템에서 스팸 발송자 및 DNS 스푸퍼를 차단하고 네트워크의 일반 보안을 향상시키는 데 도움을 줄 수 있습니다. 특히 원하지 않은 대량 전자 메일을 제어하는 방법은 17 장, 메일 필터링 및 액세스 제어를 참조하십시오.

주 –

IP 주소별로 액세스를 제어하는 것이 기업의 중요한 문제가 아닐 경우 이 절에 설명된 필터를 만들 필요가 없습니다. 단지 최소한의 액세스 제어만 필요한 경우에는 대부분 허용에서 이를 설정하는 방법에 대한 지침을 참조하십시오.

클라이언트 액세스 필터의 작동 방법

Messaging Server 액세스 제어 기능은 서비스되는 TCP 데몬과 동일한 포트에서 수신하는 프로그램입니다. 즉, 이 기능은 액세스 필터를 사용하여 클라이언트 신원을 확인하며 클라이언트가 필터링 프로세스를 통과할 경우 데몬에 대한 액세스 권한을 클라이언트에게 제공합니다.

Messaging Server TCP 클라이언트 액세스 제어 시스템은 필요한 경우 처리 과정의 일부로서 소켓 종점 주소에 대한 다음 분석을 수행합니다.

시스템은 필터라고 부르는 액세스 제어문에 대해 이 정보를 비교하여 액세스를 허가 또는 거부할지 여부를 결정합니다. 각 서비스에 대해 별도의 허용 필터 및 거부 필터 집합이 액세스를 제어합니다. 허용 필터는 액세스를 명시적으로 허가하며 거부 필터는 액세스를 명시적으로 금지합니다.

클라이언트가 서비스에 대한 액세스를 요청하면 액세스 제어 시스템은 다음 조건을 사용하여 각 서비스의 필터에 대해 클라이언트의 주소 또는 이름 정보를 순서대로 비교합니다.

여기에서 설명된 필터 문은 간단한 방식으로 여러 다른 종류의 액세스 제어 정책을 구현할 수 있을 정도로 충분히 유연합니다. 거의 배타적인 허용 또는 거부를 사용하여 대부분의 정책을 구현할 수 있지만 허용 필터와 거부 필터를 둘 다 임의로 조합하여 사용할 수 있습니다.

다음 절에서는 필터 문을 자세하게 설명하고 사용 예를 제공합니다. 서비스에 대한 액세스 필터 만들기 절에서는 액세스 필터를 만들기 위한 절차에 대해 설명합니다.

필터 문

필터 문은 서비스 정보와 클라이언트 정보를 모두 포함합니다. 서비스 정보는 서비스 이름, 호스트 이름 및 호스트 주소를 포함할 수 있습니다. 클라이언트 정보는 호스트 이름, 호스트 주소 및 아이디를 포함할 수 있습니다. 서버 및 클라이언트 정보는 둘 다 와일드카드 이름이나 패턴을 포함할 수 있습니다.

가장 간단한 형식의 필터는 다음과 같습니다.

service: hostSpec

여기에서 service는 서비스 이름(예: smtp, pop, imap 또는 http)이고 hostSpec은 호스트 이름, IP 주소 또는 액세스를 요청하는 클라이언트는 나타내는 와일드카드 이름 또는 패턴입니다. 필터가 처리될 때 액세스를 요구하는 클라이언트가 client와 일치할 경우 service에 지정된 서비스에 대한 액세스가 해당 필터 유형에 따라 허용되거나 거부됩니다. 다음은 몇 가지 예입니다. 

imap: roberts.newyork.siroe.com
pop: ALL
http: ALL

이러한 필터가 허용 필터일 경우 첫 번째 필터는 IMAP 서비스에 대한 액세스를 roberts.newyork.siroe.com 호스트에 허가하고 두 번째 및 세 번째 필터는 각각 POP 및 HTTP 서비스에 대한 액세스를 모든 클라이언트에게 허가합니다. 이러한 필터가 거부 필터일 경우 이러한 클라이언트는 서비스에 대한 액세스가 거부됩니다. ALL과 같은 와일드카드 이름에 대한 자세한 내용은 와일드카드 이름을 참조하십시오.

필터가 더 일반적인 형식을 가질 경우 필터의 서버 또는 클라이언트 정보는 다음과 같이 다소 복잡할 수 있습니다.

serviceSpec: clientSpec

여기에서 serviceSpec은 service 또는 service@hostSpec이 될 수 있고 clientSpec은 hostSpec 또는 user@hostSpec이 될 수 있습니다. user는 액세스를 요구하는 클라이언트 호스트와 연관된 사용자 아이디 또는 와일드카드 이름입니다. 다음 두 개의 예를 가정해 봅니다.

pop@mailServer1.siroe.com: ALL
imap: srashad@xyz.europe.siroe.com

여기에서 이러한 필터가 거부 필터일 경우 첫 번째 필터는 mailServer1.siroe.com 호스트에서 SMTP 서비스에 대한 액세스를 모든 클라이언트에 대해 거부합니다. 두 번째 필터는 xyz.europe.siroe.com 호스트에서 사용자 srashad의 IMAP 서비스에 대한 액세스를 거부합니다. 이러한 확장된 서버 및 클라이언트 지정을 사용하는 시기에 대한 자세한 내용은 서버 호스트 지정 및 클라이언트 사용자 아이디 지정을 참조하십시오.

마지막으로 가장 일반적인 형식의 필터는 다음과 같습니다.

serviceList: clientList

여기에서 serviceList는 하나 이상의 serviceSpec 항목으로 구성되며 clientList는 하나 이상의 clientSpec 항목으로 구성됩니다. serviceList 및 clientList 내의 개별 항목은 공백 및/또는 쉼표로 구분됩니다.

여기에서는 필터가 처리될 때 액세스를 요구하는 클라이언트가 clientList의 clientSpec 항목 중 하나와 일치할 경우 serviceList에 지정된 모든 서비스에 대한 액세스가 해당 필터 유형에 따라 허용되거나 거부됩니다. 다음은 이에 대한 한 예입니다.

pop, imap, http: .europe.siroe.com .newyork.siroe.com

이 필터가 허용 필터일 경우 europe.siroe.com 또는 newyork.siroe.com 도메인에 있는 모든 클라이언트는 POP, IMAP 및 HTTP 서비스에 대한 액세스가 허가됩니다. 선행 점이나 다른 패턴을 사용하여 도메인 또는 서브넷을 지정하는 방법에 대한 자세한 내용은 와일드카드 패턴을 참조하십시오.

또한 다음 구문을 사용할 수도 있습니다.

“+” 또는 “-” serviceList:*$next_rule

+(허용 필터)는 클라이언트 목록에 대해 데몬 목록 서비스가 허가된다는 것을 의미합니다.

-(거부 필터)는 클라이언트 목록에 대해 서비스가 거부된다는 것을 의미합니다.

*(와일드카드 필터)는 모든 클라이언트가 이러한 서비스를 사용하도록 허용합니다.

$는 규칙을 구분합니다.

다음 예는 모든 클라이언트에서 여러 서비스를 사용 가능하게 합니다.

+imap,pop,http:*

다음 예는 여러 규칙을 표시하지만 각 규칙은 서비스 이름을 하나만 가지도록 단순화되며 클라이언트 목록에 와일드카드를 사용합니다. 이는 LDIF 파일에서 액세스 제어를 지정하기 위해 가장 일반적으로 사용되는 방법입니다.

+imap:ALL$+pop:ALL$+http:ALL

다음 예는 사용자에 대해 모든 서비스를 거부하는 방법을 보여 줍니다.

-imap:*$-pop:*$-http:*

와일드카드 이름

다음 와일드카드 이름을 사용하여 서비스 이름, 호스트 이름이나 주소, 또는 아이디를 나타낼 수 있습니다.

표 19–3 서비스 필터의 와일드카드 이름

와일드카드 이름 

설명 

ALL, *

범용 와일드카드입니다. 모든 이름과 일치합니다. 

LOCAL

모든 로컬 호스트(이름에 점 문자가 포함되지 않은 호스트)와 일치합니다. 그러나 설치가 정규 이름만 사용할 경우 로컬 호스트 이름은 점을 포함하므로 이 와일드카드와 일치하지 않습니다. 

UNKNOWN

이름이 알려지지 않은 모든 사용자나 이름이나 주소가 알려지지 않은 모든 호스트와 일치합니다. 

다음과 같이 이 와일드카드 이름을 신중하게 사용합니다. 

일시적인 DNS 서버 문제로 인해 호스트 이름을 사용하지 못할 수 있습니다. 이러한 경우 UNKNOWN을 사용하는 모든 필터는 모든 클라이언트 호스트와 일치합니다.

통신하는 네트워크 유형을 소프트웨어에서 식별할 수 없으면 네트워크 주소를 사용할 수 없습니다. 이러한 경우 UNKNOWN을 사용하는 모든 필터는 해당 네트워크의 모든 클라이언트 호스트와 일치합니다.

KNOWN

이름이 알려진 모든 사용자나 이름 및 주소가 알려진 모든 호스트와 일치합니다.

다음과 같이 이 와일드카드 이름을 신중하게 사용합니다. 

일시적인 DNS 서버 문제로 인해 호스트 이름을 사용하지 못할 수 있습니다. 이러한 경우 KNOWN을 사용하는 모든 필터를 모든 클라이언트 호스트에서 실패합니다.

통신하는 네트워크 유형을 소프트웨어에서 식별할 수 없으면 네트워크 주소를 사용할 수 없습니다. 이러한 경우 KNOWN을 사용하는 모든 필터는 해당 네트워크의 모든 클라이언트 호스트에서 실패합니다.

DNSSPOOFER

DNS 이름이 고유한 IP 주소와 일치하는 않는 모든 호스트와 일치합니다. 

와일드카드 패턴

다음 패턴을 서비스나 클라이언트 주소에서 사용할 수 있습니다.

EXCEPT 연산자

액세스 제어 시스템은 단일 연산자를 지원합니다. EXCEPT 연산자를 사용하면 serviceList 또는 clientList에 여러 항목이 있을 경우 일치하는 이름이나 패턴에 대한 예외를 만들 수 있습니다. 예를 들어, 다음 표현식은

list1 EXCEPT list2

list1과 일치하는 항목이 또한 list2와 일치하지 않을 경우에 일치한다는 것을 의미합니다.

다음은 이에 대한 한 예입니다.

ALL: ALL EXCEPT isserver.siroe.com

이 예는 거부 필터인 경우 isserver.siroe.com 호스트 시스템에 있는 것을 제외하고 모든 클라이언트에 대해 모든 서비스의 액세스를 거부합니다.

EXCEPT 절은 중복될 수 있습니다. 다음 표현식은

list1 EXCEPT list2 EXCEPT list3

다음과 같은 것으로 평가됩니다.

list1 EXCEPT (list2 EXCEPT list3)

서버 호스트 지정

서버 호스트 이름이나 주소 정보를 serviceSpec 항목에 포함하여 요청되는 특정 서비스를 필터에서 추가로 식별할 수 있습니다. 이러한 경우 항목의 형식은 다음과 같습니다.

service@hostSpec

Messaging Server 호스트 시스템이 다른 인터넷 호스트 이름을 가진 여러 인터넷 주소에 대해 설정된 경우 이 기능을 사용할 수 있습니다. 서비스 공급자인 경우에는 이 기능을 사용하여 다른 액세스 제어 규칙을 가진 여러 도메인을 단일 서버 인스턴스에서 호스트할 수 있습니다.

클라이언트 사용자 아이디 지정

RFC 1413에 설명된 대로 identd 서비스를 지원하는 클라이언트 호스트 시스템의 경우 클라이언트의 사용자 아이디를 필터의 clientSpec 항목에 포함하여 특정 클라이언트 요청 서비스를 추가로 식별할 수 있습니다. 이러한 경우 항목의 형식은 다음과 같습니다.

user@hostSpec

여기에서 user는 클라이언트의 identd 서비스(또는 와일드카드 이름)에 의해 반환되는 사용자 아이디입니다.

필터에서 클라이언트 아이디를 지정하는 것은 유용할 수 있지만 다음과 같은 사항에 주의해야 합니다.

경우에 따라 사용자 아이디 조회 기능은 클라이언트 호스트에서 권한 없는 사용자의 공격으로부터 보호하는 데 도움이 될 수 있습니다. 예를 들어, 일부 TCP/IP 구현에서는 rsh(원격 쉘 서비스)를 사용하는 침입자가 신뢰할 수 있는 클라이언트 호스트를 가장할 수 있습니다. 클라이언트 호스트가 ident 서비스를 지원할 경우 사용자 아이디 조회를 사용하여 이러한 공격을 감지할 수 있습니다.

필터 예

이 절의 예는 액세스 제어의 다양한 방법을 보여 줍니다. 이러한 예에서는 허용 필터가 거부 필터보다 먼저 처리되고 일치하는 항목이 발견될 때 검색이 종료하며 일치하는 항목이 전혀 없을 경우 액세스가 허가된다는 것에 주의합니다.

여기에 나열된 예는 IP 주소가 아니라 호스트 및 도메인 이름을 사용합니다. 주소와 넷마스크 정보를 필터에 포함하여 이름 서비스 실패를 대비한 안정성을 향상시킬 수 있다는 것에 주의합니다.

대부분 거부

이 경우에는 액세스가 기본적으로 거부됩니다. 명시적으로 허가된 호스트만 액세스가 허용됩니다.

기본 정책(액세스 없음)은 다음과 같은 평범하고 단순한 거부 파일을 통해 구현됩니다. 

ALL: ALL

이 필터는 허용 필터에 의해 액세스가 명시적으로 허가되지 않은 모든 클라이언트에 대한 모든 서비스를 거부합니다. 그런 다음 허용 필터는 다음과 같을 수 있습니다.

ALL: LOCAL @netgroup1

ALL: .siroe.com EXCEPT externalserver.siroe.com

첫 번째 규칙은 로컬 도메인(즉, 호스트 이름에 점이 없는 모든 호스트)의 모든 호스트와 netgroup1 그룹의 구성원에 대해 액세스를 허가합니다. 두 번째 규칙은 선행 점 와일드카드 패턴을 사용하여 externalserver.siroe.com 호스트를 제외하고 siroe.com 도메인에 있는 모든 호스트의 액세스를 허가합니다.

대부분 허용

이 경우에는 액세스가 기본적으로 허가됩니다. 명시적으로 지정된 호스트만 액세스가 거부됩니다.

기본 정책(액세스 허가)은 허용 필터를 불필요하게 만듭니다. 원하지 않는 클라이언트는 다음과 같이 거부 필터에 명시적으로 나열됩니다.

ALL: externalserver.siroe1.com, .siroe.asia.com
ALL EXCEPT pop: contractor.siroe1.com, .siroe.com

첫 번째 필터는 특정 호스트와 특정 도메인에 대해 모든 서비스를 거부합니다. 두 번째 필터는 특정 호스트와 특정 도메인의 POP 액세스만 허가합니다.

스푸핑된 도메인에 대한 액세스 거부

필터에서 DNSSPOOFER 와일드카드 이름을 사용하여 호스트 이름 스푸핑을 감지할 수 있습니다. DNSSPOOFER을 지정하면 액세스 제어 시스템은 정방향 또는 역방향 DNS 조회를 수행하여 클라이언트가 제공한 호스트 이름이 실제 IP 주소와 일치하는지 확인합니다. 다음은 거부 필터의 예입니다.

ALL: DNSSPOOFER

이 필터는 IP 주소가 해당 DNS 호스트 이름과 일치하지 않는 모든 원격 호스트에 대한 모든 서비스를 거부합니다.

가상 도메인에 대한 액세스 제어

단일 서버 인스턴스가 여러 IP 주소 및 도메인 이름과 연관된 가상 도메인을 메시징 설치에서 사용할 경우 허용 및 거부 필터를 조합하여 각 가상 도메인에 대한 액세스를 제어할 수 있습니다. 예를 들어, 다음 허용 필터를

ALL@msgServer.siroe1.com: @.siroe1.com
ALL@msgServer.siroe2.com: @.siroe2.com
...

다음 거부 필터와 결합하여 사용할 수 있습니다.

ALL: ALL

각 허용 필터는 domainN 내의 호스트만 IP 주소가 msgServer.siroeN .com에 해당하는 서비스에 연결되도록 허용합니다. 다른 모든 연결은 거부됩니다.

서비스에 대한 액세스 필터 만들기

IMAP, POP 또는 HTTP 서비스에 대한 허용 및 거부 필터를 만들 수 있습니다. 또한 이러한 필터를 SMTP 서비스에 대해 만들 수 있지만 인증된 SMTP 세션에만 적용된다는 점에서 이것은 거의 가치가 없습니다. 17 장, 메일 필터링 및 액세스 제어를 참조하십시오.

Procedure필터를 만드는 방법

단계

  1. 콘솔에서 액세스 필터를 만들려는 Messaging Server를 엽니다.

  2. 구성 탭을 누릅니다.

  3. 왼쪽 표시 영역에서 서비스 폴더를 열고 서비스 폴더 아래에서 IMAP, POP 또는 HTTP를 선택합니다.

  4. 오른쪽 표시 영역에서 액세스 탭을 누릅니다.

    이 탭의 허용 및 표시 필드에는 해당 서비스에 대한 기존의 허용 및 거부 필터가 표시됩니다. 필드의 각 행은 하나의 필터를 나타냅니다. 이러한 필드 중 하나에서 다음 작업을 지정할 수 있습니다.

    1. 추가를 눌러 새 필터를 만듭니다필터 허용 또는 필터 거부 창이 열리면 새 필터의 텍스트를 창에 입력하고 확인을 누릅니다.

    2. 필터를 선택하고 편집을 눌러 필터를 수정합니다. 필터 허용 또는 필터 거부 창이 열리면 창에 표시된 필터의 텍스트를 편집하고 확인을 누릅니다.

    3. 필터를 선택하고 삭제를 눌러 필터를 제거합니다.

      필요한 경우 일련의 삭제 및 추가 작업을 수행하여 허용 또는 거부 필터의 순서를 재정렬할 수 있다는 것에 주의합니다.

      필터 문 지정과 다양한 예는 필터 문 및 필터 예를 참조하십시오.

      명령줄

      다음과 같이 명령줄에서 액세스 및 거부 필터를 지정할 수도 있습니다.

      서비스에 대한 액세스 필터를 작성 또는 편집하려면 다음을 수행합니다.


      configutil -o service.service.domainallowed -v filter

      여기에서 service는 pop, imap 또는 http이고 filter는 필터 문에 설명된 구문 규칙을 따릅니다.

      서비스에 대한 거부 필터를 작성 또는 편집하려면 다음을 수행합니다.


      configutil -o service.service.domainnotallowed -v filter

      여기에서 service는 pop, imap 또는 http이고 filter는 필터 문에 설명된 구문 규칙을 따릅니다.

HTTP 프록시 인증에 대한 액세스 필터 만들기

모든 저장소 관리자는 모든 서비스에 대해 프록시 인증을 수행할 수 있습니다. 저장소 관리자에 대한 자세한 내용은 저장소에 대한 관리자 액세스 지정을 참조하십시오. 모든 사용자는 해당 클라이언트 호스트가 프록시 인증 액세스 필터를 통해 액세스가 허가된 경우 HTTP 서비스에 한하여 프록시 인증을 수행할 수 있습니다.

프록시 인증을 사용하면 포털 사이트 등의 다른 서비스에서 사용자를 인증하고 인증서를 HTTP 로그인 서비스로 전달할 수 있습니다. 예를 들어, 포털 사이트가 여러 서비스를 제공하며 그 중 하나가 Messenger Express 웹 기반 전자 메일이라고 가정해 봅니다. 이 경우 최종 사용자는 HTTP 프록시 인증 기능을 사용하여 포털 서비스에 한 번만 인증되면 됩니다. 즉, 전자 메일을 액세스하기 위해 다시 인증될 필요가 없습니다. 포털 사이트는 클라이언트와 서비스 간의 인터페이스로 작동하는 로그인 서버를 구성해야 합니다. Messenger Express 인증을 위한 로그인 서버의 구성을 돕기 위해 Sun Java System은 Messenger Express용 인증 SDK를 제공합니다.

이 절에서는 IP 주소별로 HTTP 프록시 인증을 허용하기 위해 허용 필터를 만드는 방법에 대해 설명합니다. 로그인 서버를 설정하는 방법이나 Messenger Express 인증 SDK를 사용하는 방법은 이 절에서 설명하지 않습니다. Messenger Express에 맞게 로그인 서버를 설정하고 인증 SDK를 사용하는 방법에 대한 자세한 내용은 Sun Java System 담당자에게 문의하십시오.

ProcedureHTTP 프록시 인증에 대한 액세스 필터 만들기

단계

  1. 콘솔에서 액세스 필터를 만들려는 Messaging Server를 엽니다.

  2. 구성 탭을 누릅니다.

  3. 왼쪽 표시 영역에서 서비스 폴더를 열고 서비스 폴더 아래에서 HTTP를 선택합니다.

  4. 오른쪽 표시 영역에서 프록시 탭을 누릅니다.

    이 탭의 허용 필드에는 프록시 인증에 대한 기존의 허용 필터가 표시됩니다.

  5. 새 필터를 만들려면 추가를 누릅니다.

    허용 필터 창이 열리면새 필터의 텍스트를 창에 입력하고 확인을 누릅니다.

  6. 기존 필터를 편집하려면 필터를 선택하고 편집을 누릅니다.

    허용 필터 창이 열리면창에 표시된 필터의 텍스트를 편집하고 확인을 누릅니다.

  7. 기존 필터를 삭제하려면 허용 필드에서 필드를 선택하고 삭제를 누릅니다.

  8. 프록시 탭에 대한 변경이 끝나면 저장을 누릅니다.

    허용 필터 문에 대한 자세한 내용은 필터 문을 참조하십시오.

    명령줄

    다음과 같이 명령줄에서 HTTP 서비스에 대한 프록시 인증을 위한 액세스 필터를 지정할 수도 있습니다.


    configutil -o service.service.proxydomainallowed -v filter

    여기에서 filter는 필터 문에 설명된 구문 규칙을 따릅니다.