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

SMTP 릴레이 차단 구성

액세스 제어 매핑을 사용하여 다른 사용자가 Messaging Server 시스템을 통해 SMTP 메일을 릴레이하지 못하도록 할 수 있습니다. 예를 들어, 다른 사용자가 메일 시스템을 사용하여 대량 전자 메일을 수백 수천의 인터넷 메일함으로 릴레이하지 못하도록 할 수 있습니다.

기본적으로 Messaging Server는 로컬 POP 및 IMAP 사용자에 의한 릴레이를 포함하여 모든 SMTP 릴레이 작업을 차단합니다.

적합한 로컬 사용자에게 릴레이를 허용하면서 인증되지 않은 릴레이를 차단하려면 Messaging Server에서 이 두 클래스의 사용자를 서로 구분할 수 있도록 구성해야 합니다. 예를 들어, POP나 IMAP를 사용하는 로컬 사용자의 경우 Messaging Server가 SMTP 릴레이 역할을 수행합니다.

SMTP 릴레이를 차단하려면 다음이 가능해야 합니다.

내부 메일과 외부 메일 구분
인증된 사용자의 메일 구분
메일 릴레이 금지

내부 호스트 및 클라이언트에서 SMTP 릴레이를 사용하려면 “내부” IP 주소나 서브넷을 INTERNAL_IP 매핑 테이블에 추가해야 합니다.

MTA의 내부 메일과 외부 메일 구분 방법

메일 릴레이 작업을 차단하려면 MTA는 먼저 사용자 사이트에서 전송된 내부 메일과 외부 인터넷에서 전송되어 사용자 시스템을 경유하여 다시 인터넷으로 나가는 외부 메일을 구분할 수 있어야 합니다. 내부 메일은 허용하고 외부 메일은 차단하려 합니다. 인바운드 SMTP 채널(일반적으로 tcp_local 채널이며 기본적으로 설정됨)에서 switchchannel 키워드를 사용하여 구분할 수 있습니다.

switchchannel 키워드를 사용하여 SMTP 서버가 들어오는 SMTP 연결에 연관된 실제 IP 주소를 조사합니다. Messaging Server는 이 IP 주소와 다시 쓰기 규칙을 결합하여 도메인 내에서 보낸 SMTP와 도메인 외부로부터의 연결을 구분합니다. 그런 다음 이 정보는 내부 메일 트래픽과 외부 메일 트래픽을 분리하는 데 사용될 수 있습니다.

아래 설명된 MTA 구성은 기본적으로 서버가 내부 메일 트래픽과 외부 메일 트래픽을 구분할 수 있도록 설정됩니다.

구성 파일에서 로컬 채널 바로 앞에 noswitchchannel 키워드가 지정된 defaults 채널이 옵니다.
! final rewrite rules defaults noswitchchannel ! Local store ims-ms ...
받는 TCP/IP 채널은 switchchannel과 remotehost 키워드를 지정하며, 예를 들면 다음과 같습니다.
tcp_local smtp single_sys mx switchchannel remotehost TCP-DAEMON
받는 TCP/IP 채널 정의 뒷부분은 이름은 다르지만 비슷한 채널입니다. 예를 들면 다음과 같습니다.
tcp_intranet smtp single_sys mx allowswitchchannel routelocal tcp_intranet-daemon
routelocal 채널 키워드는 채널에 주소를 다시 쓸 때 MTA가 해당 주소의 모든 명시적 라우팅을 이 채널을 통해 “단락”하도록 하여 명시적으로 소스 라우팅된 주소를 통해 내부 SMTP 호스트를 거친 루핑 방식으로 릴레이 시도를 차단합니다.

위 구성 설정으로 도메인 내에서 생성된 SMTP 메일은 tcp_intranet 채널을 통해 들어옵니다. 다른 모든 SMTP 메일은 tcp_local 채널을 통해 들어옵니다. 이렇게 해당 메일이 들어오는 채널을 기준으로 내부 메일과 외부 메일이 구분됩니다.

이 작업의 작동 방식에 대해 알아보겠습니다. 여기서 핵심은 switchchannel 키워드이며,tcp_local 채널에 적용됩니다. 서버는 메일이 SMTP 서버에 들어오면 키워드를 통해 받는 연결과 연관된 소스 IP 주소를 검사합니다. 서버는 받는 연결의 리터럴 IP 주소에 대해 역방향 지정 봉투 다시 쓰기를 시도하여 연관된 채널을 찾습니다. 소스 IP 주소가 INTERNAL_IP 매핑 테이블 내의 IP 주소나 서브넷과 일치하는 경우 해당 매핑 테이블을 호출하는 다시 쓰기 규칙을 통해 해당 주소가 tcp_intranet 채널로 다시 쓰여집니다.

tcp_intranet 채널은 allowswitchchannel 키워드로 표시되기 때문에 메일은 tcp_intranet 채널로 전환되어 해당 채널로 들어갑니다. 메일이 INTERNAL_IP 매핑 테이블에 없는 IP 주소의 시스템에서 들어오는 경우 역방향 지정 봉투 다시 쓰기로 tcp_local 또는 다른 채널로 다시 씁니다. 하지만 tcp_intranet 채널로는 다시 쓰지 않으며 다른 모든 채널은 기본적으로 noswitchchannel로 표시되어 있으므로 메일은 다른 채널로 전환되지 않고 tcp_local 채널로 남아 있게 됩니다.

주 –

“tcp_local” 문자열을 사용하는 모든 매핑 테이블이나 변환 파일 항목은 사용법에 따라 “tcp_*” 또는 “tcp_intranet”으로 변경해야 할 수 있습니다.

인증된 사용자의 메일 구분

사이트에는 물리적 네트워크의 일부가 아닌 “로컬” 클라이언트 사용자가 있을 수 있습니다. 이러한 사용자가 메일을 전송하면 외부 IP 주소(예: 임의의 인터넷 서비스 제공자)로부터 메일이 전송됩니다. 사용자가 SASL 인증을 수행할 수 있는 메일 클라이언트를 사용하는 경우 이러한 인증된 연결을 다른 외부 연결과 구분할 수 있습니다. 따라서 인증되지 않은 릴레이 전송 시도는 거부되는 반면 인증된 전송은 허용됩니다. 인바운드 SMTP 채널(일반적으로 tcp_local 채널)에 saslswitchchannel 키워드를 사용하여 인증된 연결과 인증되지 않은 연결을 구분할 수 있습니다.

saslswitchchannel 키워드는 전환할 채널을 지정하는 인수를 취합니다. SMTP 보낸 사람이 인증에 성공하면 해당 전송 메일은 지정된 전환 대상 채널에서 오는 것으로 간주됩니다.

인증된 전송 구분을 추가하는 방법

단계

구성 파일에 고유 이름을 가진 새 TCP/IP 채널 정의를 추가합니다. 예를 들면 다음과 같습니다.

tcp_auth smtp single_sys mx mustsaslserver noswitchchannel TCP-INTERNAL

이 채널은 정규 채널 전환을 허용하지 않아야 합니다(즉, 이전 기본 행에서 명시적 또는 암시적으로 noswitchchannel이 있어야 함). 이 채널에는 mustsaslserver가 있어야 합니다.

다음 예에 표시된 대로 maysaslserver 및 saslswitchchannel tcp_auth를 추가하여 tcp_local 채널을 수정합니다.
tcp_local smtp mx single_sys maysaslserver saslswitchchannel \ tcp_auth switchchannel |TCP-DAEMON
이 구성을 사용하면 로컬 비밀번호로 인증할 수 있는 사용자가 보낸 SMTP 메일이 tcp_auth 채널에 들어갈 수 있습니다. 내부 호스트에서 보낸 인증되지 않은 SMTP 메일은 여전히 tcp_internal 채널로 들어옵니다. 다른 모든 SMTP 메일은 tcp_local로 들어옵니다.

메일 릴레이 금지

이 예에서는인증되지 않은 사용자가 시스템을 통해 SMTP 메일을 릴레이하지 못하도록 하는 것을 설명합니다. 우선 로컬 사용자는 SMTP 메일을 릴레이할 수 있어야 합니다. 예를 들어, POP 및 IMAP 사용자는 Messaging Server를 사용하여 메일을 보냅니다. 로컬 사용자는 물리적으로 메일이 내부 IP 주소에서 들어오는 로컬이거나, 물리적으로는 원격이지만 로컬 사용자로 인증이 가능한 사용자일 수 있습니다.

인터넷 상에 있는 임의의 사용자가 해당 서버를 릴레이로 사용하지 못하게 하려 합니다. 다음 절에서 설명하는 구성을 사용하면 이러한 사용자 클래스를 구분하고 올바른 클래스를 차단할 수 있습니다. 특히 tcp_local 채널을 통해 들어오고 같은 채널을 통해 나가는 메일을 차단하려 합니다. 이를 위해 ORIG_SEND_ACCESS 매핑 테이블이 사용됩니다.

ORIG_SEND_ACCESS 매핑 테이블을 사용하여 소스 채널과 대상 채널을 기반으로 트래픽을 차단할 수 있습니다. 이 경우 tcp_local 채널을 통해 송수신되는 트래픽을 차단해야 합니다. 이 기능은 다음 ORIG_SEND_ACCESS 매핑 테이블로 구현됩니다.

ORIG_SEND_ACCESS

   tcp_local|*|tcp_local|*        $NRelaying$ not$ permitted

이 예에서 해당 항목은 메일이 tcp_local 채널에 들어가서 바로 해당 채널로 다시 나올 수 없도록 지정합니다. 즉, 이 항목은 외부 메일이 SMTP 서버로 들어와서 곧바로 인터넷으로 릴레이되는 것을 방지합니다.

ims-ms 채널과 일치하는 주소(하지만 별칭이나 메일링 목록 정의를 통해 다시 외부 주소로 확장될 수 있는 주소)를 차단할 수 있도록 SEND_ACCESS 매핑 테이블 대신 ORIG_SEND_ACCESS 매핑 테이블이 사용됩니다. SEND_ACCESS 매핑 테이블을 사용할 때는 외부 사용자가 다시 외부 사용자로 확장되는 메일링 목록을 보내거나 메일을 다시 외부 주소로 전달하는 사용자에게 보낼 수 있도록 하려면 길이를 늘여야 합니다.

SMTP 릴레이 차단에 RBL 검사를 포함한 DNS 조회 사용

Messaging Server에는 유효한 DNS 이름을 가진 주소에서 전송된 메일만 전달되도록 하는 여러 방법이 있습니다. 가장 간단한 방법은 tcp_local 채널에 mailfromdnsverify 채널 키워드를 지정하는 것입니다.

Messaging Server는 ORIG_MAIL_ACCESS에서 다음 규칙을 사용하여 유효한 DNS 이름을 가진 주소에서 전송된 메일만 전달되도록 하는 dns_verify 프로그램도 제공합니다.

ORIG_MAIL_ACCESS

  TCP|*|*|*|*|SMTP|MAIL|*|*@*|*|*  \
$[msg_svr_base/lib/dns_verify.so,  \
dns_verify,$6|$$y|$$NInvalid$ host:$ $$6$ -$ %e]

위 예에서 줄 바꿈은 이러한 매핑 항목에서 구문적으로 매우 중요합니다. 다음 행으로 진행하려면 백슬래시 문자를 사용해야 합니다.

또한 dns_verify 이미지를 사용하여 받는 연결을 RBL(Realtime Blackhole List), MAPS(Mail Abuse Prevention System, DUL(Dial-up User List) 또는 ORBS(Open Relay Behavior-modification System) 목록 등에 대해 검사하여 UBE로부터 보호할 수 있습니다. 새 mailfromdnsverify 키워드와 마찬가지로 dns_verify 콜아웃을 수행하는 대신 “보다 간단한 구성” 방법으로 이러한 검사를 수행할 수도 있습니다. 보다 간단한 방법은 dispatcher.cnf 파일에 DNS_VERIFY_DOMAIN 옵션을 사용하는 것입니다. 예를 들어, [SERVICE=SMTP] 섹션에서 검사하려는 다양한 목록에 대한 옵션의 인스턴스를 설정합니다.

[SERVICE=SMTP]
PORT=25
! ...rest of normal options...
DNS_VERIFY_DOMAIN=rbl.maps.vix.com
DNS_VERIFY_DOMAIN=dul.maps.vix.com!
...etc...

이 경우 메일은 SMTP 수준에서 거부됩니다. 즉 메일은 SMTP 대화 도중 거부되므로 MTA로 전송되지 않습니다. 이 방법의 단점은 내부 사용자가 보낸 메일을 포함하여 모든 받는 SMTP 메일을 검사한다는 것입니다. 따라서 효율성이 떨어지며 인터넷 연결이 중지되면 문제가 발생할 수 있습니다. 그 대안은 PORT_ACCESS 매핑 테이블 또는 ORIG_MAIL_ACCESS 매핑 테이블로부터 dns_verify를 호출하는 것입니다. PORT_ACCESS 매핑 테이블에는 로컬 내부 IP 주소나 메일 전송자를 검사하지 않는 초기 항목과 다른 모든 사용자에 대해 원하는 검사를 수행하는 후기 항목을 지정할 수 있습니다. 또는 ORIG_MAIL_ACCESS 매핑 테이블에서 tcp_local 채널로 받는 메일에만 검사를 적용하려는 경우에는 내부 시스템/클라이언트로부터 받는 메일에 대해 해당 검사를 건너뛸 수 있습니다. dns_verify를 가리키는 항목을 사용하는 예는 다음과 같습니다.

PORT_ACCESS

! Allow internal connections in unconditionally 
  *|*|*|*|*  $C$|INTERNAL_IP;$3|$Y$E
! Check other connections against RBL list
   TCP|*|25|*|*  \
$C$[msg_svr_base/lib/dns_verify.so,\
dns_verify_domain_port,$1,rbl.maps.vix.com.]EXTERNAL$E


ORIG_MAIL_ACCESS 

  TCP|*|25|*|*|SMTP|*|tcp_local|*@*|*|*  \
$C$[msg_svr_base/lib/dns_verify.so,\
dns_verify_domain,$1,rbl.maps.vix.com.]$E

DNS 기반 데이터베이스 지원

dns_verify 프로그램은 원치 않는 대량 전자 메일을 보낼 수 있는 받는 SMTP 연결을 확인하는 데 사용되는 DNS 기반 데이터베이스를 지원합니다. 공개적으로 사용 가능한 DNS 데이터베이스 중 일부는 일반적으로 이러한 용도로 사용되는 TXT 레코드를 포함하지 않을 수 있습니다. 대신 A 레코드만 포함합니다.

일반 설정에서 특정 IP 주소에 대한 DNS의 TXT 레코드에는 메일을 거부할 때 SMTP 클라이언트로 반환하기에 적합한 오류 메시지가 포함되어 있습니다. 하지만 TXT 레코드가 없고 A 레코드가 있는 경우 Messaging Server 5.2 이전의 dns_verify 버전에서는 “No error text available이라는 메시지를 반환했습니다. ”

이제 dns_verify에서는 사용 가능한 TXT 레코드가 없는 경우에 사용되는 기본 텍스트를 지정하는 옵션을 제공합니다. 예를 들어, 다음 PORT_ACCESS 매핑 테이블에서는 이 옵션을 사용하는 방법을 보여 줍니다.

PORT_ACCESS 

   *|*|*|*|* $C$|INTERNAL_IP;$3|$Y$E  \
   TCP|*|25|*|*   \
$C$[<msg_svr_base/lib/dns_verify.so \
,dns_verify_domain_port,$1,dnsblock.siroe.com,Your$ host$ ($1)$ \
found$ on$ dnsblock$ list]$E 
    * $YEXTERNAL

이 예에서 원격 시스템이 dnsblock.siroe.com 도메인의 쿼리에 있지만 TXT 레코드를 사용할 수 없는 경우에는 “Your host a.b.c.d found on dnsblock list.”