달력

42024  이전 다음

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30

제어판-관리도구-로컬보안정책-로컬정책-보안옵션-계정:administrator-사용
어드민계정 활성화됩니다

어드민계정만사용하실경우
제부팅-제어판-사용자계정-다른계정관리 -안쓰는것 삭제


ㅇ UAC 끄는 방법

시작 - 실행에서 msconfig를 칩니다.


시스템구성 - 도구를 보시면 UAC사용안함을 더블클릭 하시면 됩니다.


리부팅하시면 귀찮은 메세지 안나옵니다.

Posted by tornado
|

jsp 에서 이미지 표현하는 태그는 전부다 <c:url .../> 로 해놧더니 rewrite 되어서

이미지 파일 뒤에 *.jpg;jsessionid=.... 이 전부 붙어서 로그를 걸러내지 못한다.

해서리... 앞에 포스트인 [펌] Apache access_log 로그 관련 내용및 관리법 를 응용하여

httpd.conf 에 아래와 같이 설정하였다.

SetEnvIfNoCase Request_URI "/.(gif|jpg|png|css|js|java)$;jsessionid=.*" do_not_log

로그파일이 깨끗해짐 ^^

Posted by tornado
|
퍼온곳 : http://blog.naver.com/tripsketch?Redirect=Log&logNo=3703720

























=======================================================================
출처 : http://www.ricky.co.kr/jsboard/read.php?table=system&no=17&page=1
=======================================================================
[제목] 아파치 로그 파일 - 특이한 녀석들은 따로 담거나 없애기

* 제목이 좀 이상하네요........^.^

작성자 : 김칠봉 <san2(at)linuxchannel.net>
작성일 : 2001. 04. 30
대상자 : 초보

- 힌트 URL : 임은재님이 쓴 글을 보고 나서
   http://kltp.kldp.org/stories.php?story=00/10/22/9724184

- 관련 문서 : 아파치 제공 문서
   http://httpd.apache.org/docs/mod/mod_log_config.html
   http://httpd.apache.org/docs/mod/mod_setenvif.html


목차

1. 배경

2. 기초지식
  2-1. 로그포맷과 CustomLog 지시자
  2-2. 아파치 환경변수 설정

3. 예제
  3-1. 특정 IP 주소만 환경변수로 설정하기
  3-2. 특정 타입의 파일만 환경변수로 설정하기
  3-3. 특정 User-Agent 만 환경변수로 설정하기
  3-4.  종합예제 : 사오정(?) 로그 분석 피하기

------------------------------------------

1. 배경

몇 달 전부터 Webalizer 라는 로그 분석기로 제가(이하 '필자') 운영하는 싸이트의
로그를 대충 분석(?)해 봤는데 사오정(?) 분석이 되어 버렸더군요.
결정적으로 필자가 운영하는 싸이트의 대부분은 php로 구성되어 있는데, 이는 실제로

 - 방문자 외에 localhost에서 php가 실행하는 로그 기록
 - 로봇들의 접근 기록
 - 운영자(필자)가 접근한 로그 기록

 등등이 함께 기록되어 있어 순수 방문자 통계에 약간 덜(?) 정확한 통계가 나오더군요.
 따라서 이런 유형들의 로그는 없애거나 따로 로그기록하는 것이 낫을 것 같더군요.

 위의 내용이 이하 다루는 내용입니다.


2. 기초지식

2-1. 로그포맷과 CustomLog 지시자

Module mod_log_config 은 아파치 기본 모듈입니다.

    로그 포맷 스트링

    %a : 원격의 IP 주소
    %b : 헤더를 포함한 전송량(bytes)
    %{var}e : 환경 변수 "var"
    %f : 파일이름
    %h : 원격의 호스트
    %{hdr}i : 서버에 들어오는(요청) 헤더 값 "hdr"
    %l : 원격의 로그인 ID(지원한다면)
    %{label}n : 다른 모듈에서 "label" 구성
    %{hdr}o : 응답 헤더 값 "hdr"
    %p : 서버의 Canonical 포트 번호
    %P : 자식 프로세스 ID(PID)
    %r : 첫번째 요청 라인
    %s : 상태코드
    %t : 시간 포맷(CLF 포맷)
    %{format}t : "format"으로 구성된 시간 포맷
    %T : 서버에 요청하는 시간(초)
    %u : 원격의 유저이름(인증시)
    %U : 요청한 URL
    %v : 클라이언트 요청에 따른 Canonical 서버네임
    %V : UseCanonicalName 설정에 따른 서버네임

일반적으로 아파치를 설치하고 나면, 다음과 같이 기본설정되어 있을 겁니다.
(굳지 수정할 필요없음)

    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
    LogFormat "%h %l %u %t \"%r\" %>s %b" common
    LogFormat "%{Referer}i -> %U" referer
    LogFormat "%{User-agent}i" agent

    CustomLog /usr/local/apache/logs/access_log common

물론 이 정도는 다 알고 계시리라 믿습니다.

    로그 기록 지시자

    CookieLog
    CustomLog
    LogFormat
    TransferLog

CookieLogs는 제외하고 나머지 지시자에 대해서 알아봅시다.

LogFormat 지시자

Syntax: LogFormat format|nickname [nickname]
Default: LogFormat "%h %l %u %t \"%r\" %>s %b"
Context: server config, virtual host
Status: Base
Compatibility: Nickname only available in Apache 1.3 or later
Module: mod_log_config


CustomLog 지시자

Syntax: CustomLog file|pipe format|nickname [env=[!]environment-variable]
Context: server config, virtual host
Status: Base
Compatibility: Nickname only available in Apache 1.3 or later.
Conditional logging available in 1.3.5 or later.
Module: mod_log_config


TransferLog 지시자

Syntax: TransferLog file|pipe
Default: none
Context: server config, virtual host
Status: Base
Module: mod_log_config

LogFormat 지시자는 앞에서 예제가 있으므로 생략하고 비슷한 기능을 가진
CustomLog, TransferLog 지지자에 대해서 잠깐 알아봅시다.

둘다 file 에 로그를 기록한다는 면에서는 동일한 기능입니다.(pipe 기능도 동일)

    같은점

    1. 둘다 file에 로그를 기록한다.
    2. |pipe 에 설정한 외부 프로그램을 인자로 사용할 수 있다.
    3. 둘다 다중 로그를 사용할 수 있다.

    다른점

    1. CustomLog 지시자는 LogFormat 지시자에서 설정한 nickname이나 Log format을
        인자로 사용할 수 있다.
    2. CustomLog 지시자는 환경변수를 인자로 가질 수 있다.


따라서,
이하 다룰 내용은 환경변수를 설정하고 이 환경변수(env)와 동일(=)하거나 그렇지 않은(!=)
특정 유형에 대해서 로그에 기록해야하 하므로 당연히 CustomLog 지시자를 사용해야
합니다.

*주의)
환경변수를 인자로 사용할 경우 하나만 가능.

이해가 되셨는지 모르겠네요....


2-2. 아파치 환경변수 설정

아파치에서 환경변수를 설정하는 방법은 몇가지 있습니다.
예를 들어,

    - mod_env 모듈에 의한
       SetEnv
       지시자 이용

    - mod_setenvif 모듈에에 의한
       BrowserMatch
       BrowserMatchNoCase
       SetEnvIf
       SetEnvIfNoCase
       지시자 이용

등이 있습니다.
여기에서 주로 사용할 지시자는 BrowserMatch 지시자와 SetEnvIf 지시자입니다.

*참고)
xxxxNoCase 지시자는 대소문자를 구분하지 않겠다는 의미입니다.

이 두개의 지시자에 대한 사용법만 간단하게 알아봅시다.

BrowserMatch 지시자

Syntax: BrowserMatch regex envar[=value] [envar[=value]] ...
Default: none
Context: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Base
Module: mod_setenvif
Compatibility: Apache 1.2 and above (in Apache 1.2 this directive was found in the
now-obsolete mod_browser module); use in .htaccess files only supported with
1.3.13 and later


SetEnvIf 지시자

Syntax: SetEnvIf attribute regex envar[=value] [envar[=value]] ...
Default: none
Context: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Base
Module: mod_setenvif
Compatibility: Apache 1.3 and above; the Request_Protocol keyword and
environment-variable
matching are only available with 1.3.7 and later; use in .htaccess files only supported
with 1.3.13 and later

   환경변수 지정 및 값 지정 방법

   1.varname, or
   2.!varname, or
   3.varname=value

   예 :

   BrowserMatch ^Mozilla forms jpeg=yes browser=netscape
   BrowserMatch "^Mozilla/[2-3]" tables agif frames javascript
   BrowserMatch MSIE !javascript

   BrowserMatchNoCase Robot is_a_robot
   SetEnvIfNoCase User-Agent Robot is_a_robot

   BrowserMatchNoCase mac platform=macintosh
   BrowserMatchNoCase win platform=windows

   SetEnvIf Request_URI "\.gif$" object_is_image=gif
   SetEnvIf Request_URI "\.jpg$" object_is_image=jpg
   SetEnvIf Request_URI "\.xbm$" object_is_image=xbm
        :
   SetEnvIf Referer www\.mydomain\.com intra_site_referral
        :
   SetEnvIf object_is_image xbm XBIT_PROCESSING=1

   SetEnvIfNoCase Host Apache\.Org site=apache

   SetEnvIf 지자자에서 attribute 에 올 수 있는 것들 :

   Remote_Host - the hostname (if available) of the client making the request
   Remote_Addr - the IP address of the client making the request
   Remote_User - the authenticated username (if available)
   Request_Method - the name of the method being used (GET, POST, et cetera)
   Request_Protocol - the name and version of the protocol with which the request
                                    was made (e.g., "HTTP/0.9", "HTTP/1.1", etc.)
   Request_URI - the portion of the URL following the scheme and host portion
   그외
   Host, User-Agent, and Referer 가능

   see http://www.rfc-editor.org/rfc/rfc2616.txt

따라서,
BrowserMatch와 SetEnvIf User-Agent 는 서로 동일하다는 것을 알 수 있을 겁니다.

*중요)
CustomLog 지자자와 다르게 환경변수 인자에 여러 개를 설정할 수 있음.

여기까지 이해가 되셨다면 다음은 보지 않아도 될듯 하군요.......^.^


3. 예제

3-1. 특정 IP 주소만 환경변수로 설정하기

- 환경변수 이름 : do_not_log
- 목적 : 이 환경변수에 해당되는 특정 IP 주소는 access_log에 기록하지 않는다.

    SetEnvIf Remote_Addr "^127.0.0.1$" do_not_log
    SetEnvIf Remote_Addr "^211.35.159.12[89]$" do_not_log
    SetEnvIf Remote_Addr "^211.35.159.1[345][0-9]$" do_not_log

    위에서 설정한 특정 IP 주소는
    127.0.0.1 자기자신을 말하는 루프백 주소
    211.35.159.128, 211.35.159.129 두개의 IP 주소
    211.35.159.130 ~ 211.35.159.139 10개의 IP 주소
    211.35.159.140 ~ 211.35.159.149 10 개의 IP 주소
    211.35.159.150 ~ 211.35.159.159 10 개의 IP 주소

즉 원격의 IP 주소(Remote_Addr)가 위와 일치하면 do_not_log 환경변수에 지정하는 예임.

*참고)
^ 은 시작을 의미
$ 은 마지막을 의미
[0-9] 0~9까지의 숫자중 어느 하나


3-2. 특정 타입의 파일만 환경변수로 설정하기

    SetEnvIfNoCase Request_URI "\.(gif|jpg|png|css|js|java)$" do_not_log

    요청 URI(Request_URI) 파일이
    *.gif
    *.jpg
    *.png
    *.css
    *.js
    *.java

    로 끝난 파일인 경우(대소문자를 구별하지 않음) do_not_log 환경변수에 지정함


3-3. 특정 User-Agent 만 환경변수로 설정하기

- 환경변수 이름 : do_not_log 과 is_a_robot
- 목적 : 이 환경변수에 해당되는 특정 User-Agent는 access_log에 기록하지 않고,
             따로 로그(robot-log)에 기록하거나 기록하지 않기 위함.

    BrowserMatchNoCase "ru-robot" do_not_log is_a_robot
    BrowserMatchNoCase "Slurp/si" do_not_log is_a_robot
    BrowserMatchNoCase "Mercator" do_not_log is_a_robot
    BrowserMatchNoCase "Gulliver" do_not_log is_a_robot
    BrowserMatchNoCase "SyncIT/" do_not_log is_a_robot
    BrowserMatchNoCase "FAST-WebCrawler" do_not_log is_a_robot
    BrowserMatchNoCase "Lycos_Spider" do_not_log is_a_robot
    BrowserMatchNoCase "^ia_archive" do_not_log is_a_robot
    BrowserMatchNoCase "^tv" do_not_log is_a_robot
    BrowserMatchNoCase "Scooter" do_not_log is_a_robot
    BrowserMatchNoCase "ZyBorg/" do_not_log is_a_robot
    BrowserMatchNoCase "KIT-Fireball" do_not_log is_a_robot
    BrowserMatchNoCase "Googlebot/" do_not_log is_a_robot
    BrowserMatchNoCase "DIIbot/" do_not_log is_a_robot
    BrowserMatchNoCase "teoma_agent3" do_not_log is_a_robot
    BrowserMatchNoCase "empas_robot" do_not_log is_a_robot

모두 로봇으로 맞게 설정되었는지 모르겠네요...............T.T

각각의 정규표현식 조건에 맞는 User-Agent 인 경우, do_not_log 환경변수와
is_a_robot 이라는 두개의 환경변수에 설정한 예입니다.
is_a_robot 이라고 또 하나의 환경변수를 지정한 이유는 앞서 얘기했듯이
이 조건게 맞는 User-Agent가 접근할 경우 따로 로그에 기록하기 위함입니다.

이 BrowserMatchNoCase 지시자 대신에 SetEnvIfNoCase User-Agent 로 대신할 수 있는데
첫번째 부분을 다음과 같이 설정할 수 있습니다.(둘다 똑 같은 결과임)

    SetEnvIfNoCase User-Agent "ru-robot" do_not_log is_a_robot


3-4.  종합예제 : 사오정(?) 로그 분석 피하기

앞의 3개의 예제를 모두 적용하면 다음과 같습니다.

목적은 배경에서 설명했듯이 가능한 access_log 파일에

 - 방문자 외에 localhost에서 php가 실행하는 로그 기록은 기록하지 않는다.
 - 로봇들의 접근 기록은 따로 robot-log 파일에 기록한다.
 - 운영자가 주고 접근할 IP 주소는 로그에 기록하지 않는다.
 - *.gif, *.jpg, *.png, *.css, *.js, *.java 등과 같은 파일은 로그에 기록하지 않는다.

 이 정도의 조건이라면 가능한 어느 정도 수준으로 순수 방문자의 접근 기록만
 access_log 파일에 기록할 수 있습니다.

 -- httpd.conf(실제로 필자가 운영하는 아파치 설정 내용임) --------------------
##
## 중간 생략
##
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{User-Agent}i\"" use_robot
##
## 중간 생략
##

## 환경변수 do_not_log에 일치하지 않은 접근만 access_log 파일에 기록함.
##
CustomLog /usr/local/apache/logs/access_log combined env=!do_not_log

## 중간 생략

## 로봇들은 따로 robot_log 파일에 user_robot 포맷에 맞게 기록함
##
CustomLog /usr/local/apache/logs/robot_log use_robot env=is_a_robot

## 중간 생략

## 특정 IP 주소는 로그에 기록하지 않는다.
## 주로 서버 IP 주소와 운영자가 자주 접속하는 IP 주소들
##
SetEnvIf Remote_Addr "^127.0.0.1$" do_not_log
SetEnvIf Remote_Addr "^211.35.159.12[89]$" do_not_log
SetEnvIf Remote_Addr "^211.35.159.1[345][0-9]$" do_not_log

## 중간 생략

## 주로 이미지 파일을 요청했을 경우 로그에 기록하지 않는다.
##
SetEnvIfNoCase Request_URI "\.(gif|jpg|png|css|js|java)$" do_not_log

## 중간 생략

## 로봇들의 환경변수 지정
##
BrowserMatchNoCase "ru-robot" do_not_log is_a_robot
BrowserMatchNoCase "Slurp/si" do_not_log is_a_robot
BrowserMatchNoCase "Mercator" do_not_log is_a_robot
BrowserMatchNoCase "Gulliver" do_not_log is_a_robot
BrowserMatchNoCase "SyncIT/" do_not_log is_a_robot
BrowserMatchNoCase "FAST-WebCrawler" do_not_log is_a_robot
BrowserMatchNoCase "Lycos_Spider" do_not_log is_a_robot
BrowserMatchNoCase "^ia_archive" do_not_log is_a_robot
BrowserMatchNoCase "^tv" do_not_log is_a_robot
BrowserMatchNoCase "Scooter" do_not_log is_a_robot
BrowserMatchNoCase "ZyBorg/" do_not_log is_a_robot
BrowserMatchNoCase "KIT-Fireball" do_not_log is_a_robot
BrowserMatchNoCase "Googlebot/" do_not_log is_a_robot
BrowserMatchNoCase "DIIbot/" do_not_log is_a_robot
BrowserMatchNoCase "teoma_agent3" do_not_log is_a_robot
BrowserMatchNoCase "empas_robot" do_not_log is_a_robot

## 이하 생략
##
------------------------------------------------------

END
Posted by tornado
|
http://virtuawin.sourceforge.net/

무지 편리합니다.

VirtuaWin - The Virtual Desktop Manager

VirtuaWin is a virtual desktop manager for the Windows operating system (Win9x/ME/NT/Win2K/XP). A virtual desktop manager lets you organize applications over several virtual desktops (also called 'workspaces'). Virtual desktops are very common in Unix/Linux, and once you get accustomed to using them, they become an essential part of a productive workflow.

VirtuaWin is designed to be simple and elegant to use yet still be highly configurable and extensible.

Image of VirtuaWin Set-up - Desktop 1       Image of VirtuaWin Set-up - Desktop 2       Image of VirtuaWin Set-up - Desktop 3

Have as many as 9 virtual desktops on Windows with VirtuaWin!

VirtuaWin is a freely distributed program and is licensed under the GNU General Public License.

Copyright © 1999-2005 Johan Piculell
Copyright © 2006-2007 VirtuaWin ( VirtuaWin@home.se)

Posted by tornado
|

예전에 네이버 블로그에 적어놨던것 같은데... 찾기 귀찮아서 다시 올림.

qmail queue 에 쌓인 쓸데 없는 메일들을 지워주기도 하고,

queue 에 뭐가 어떻게 남았는지도 리스트로 뽑아볼 수도 있고 편리한 스크립트다.

qmail 정말 좋은 메일 서버임에 틀림없다.

Posted by tornado
|
JucyIPChanger.exe (90KB, DN:87)
아이피주소를 간단하게 바꾼다 - Jucy IP Changer  



Jucy IP Changer 는 미리 입력된 네트워크 정보를 통해 단순히 클릭만으로
IP, SubnetMask, DNS, Gateway를 한번에 바꿀 수 있습니다.
이동이 많은 노트북 사용자에게 편리한 유틸이며,
사용에 제한이 없는 프리웨어입니다.
Posted by tornado
|

마이크로소프트의 고객지원 페이지에 있는 해당 현상과 관련된 글입니다

 

수용할 수 있는 최대 개수의 연결이 이미 있으므로 지금 이 원격 시스템에 더 이상 연결을 작성할 수 없습니다.

 

-원인-

컴퓨터가 호스트할 수 있는 최대 개수의 인바운드 연결에 도달한 경우 이러한 문제가 발생합니다.

Windows XP Professional의 경우에는 네트워크를 통해 최대 10대까지 다른 컴퓨터에 동시에 연결할 수 있습니다. 이 제한에는 모든 전송 및 리소스 공유 프로토콜이 포함됩니다. Windows XP Home Edition의 경우에는 네트워크를 통해 최대 5대까지 다른 컴퓨터에 동시에 연결할 수 있습니다.


XP PRO버전의 경우 10대까지가 동시접속 제한숫자이군요.

이 제한을 풀수는 없다고 나왔구요


대신 이 문제를 다소나마 다른 방법으로 문제를 해결할 수 있도록 제시하고 있군요


원문은 이렇습니다

활동이 없는 모든 파일, 인쇄, 명명된 파이프(Named Pipe) 또는 메일 슬롯 세션은 AutoDisconnect 시간이 만료되면 자동으로 연결이 끊어집니다. AutoDisconnect 시간의 기본값은 15분입니다. 세션의 연결이 끊기면 10개의 연결 중 하나가 사용 가능한 상태가 되어 다른 사용자가 Windows XP 시스템에 연결할 수 있습니다. 따라서 AutoDisconnect 시간을 줄이면 서버 목적을 위해 많이 사용되지 않는 시스템에서 10개나 5개로 제한된 연결로 인해 사용자가 겪게 되는 문제를 줄이는 데 도움이 될 수 있습니다.

명령 프롬프트에서 다음 명령을 실행하여 AutoDisconnect 시간을 구성할 수 있습니다.

net config server /autodisconnect:time_before_autodisconnect

시간은 분 단위로 지정합니다.


그러니까 지금 10대의 컴퓨터가 서버에 연결되어 있다고 가정해보죠

연결된 10대의 컴퓨터가 쉬지 않고 계속해서 작업을 하고 있다면 10대의 연결은

계속적으로 유지됩니다


다른 컴퓨터들은  최대연결초과로 인해 서버에 접속할 수 없죠

그런데 위에 제시한 자동연결끊김 기능의 시간을 잘 활용하면 어느 정도 서버로의

유연한 연결이 가능해질 수  있게 되네여 .

기본시간이 15분이죠.  한 컴퓨터가 15분이상의 아무런 작업신호를 보내지 않으면

그컴퓨터는 자동으로 연결해제 되는 거죠


자 이 시간이 길면 길수록  어느 한 컴퓨터의 연결이 끊기는데 걸리는 시간이

최소한도  15분이 필요하죠

그러면 이 시간을 1분으로 하면 어떨까요.

연결된 컴퓨터들의 연결이 수시로 종료되겠죠.

컴퓨터 사용자들이 잠깐 화장실 갔다오기만 해도 연결이 종료되겠죠.

그러면 서버에 연결할수 있는 컴퓨터의 여유가 항상 어느정도 확보되겠죠.

수시로 서버컴에 연결하는 통로가 확보된다고 보면 되겠지요

연결이 끊긴다는 말이 크게 의미를 둘 필요는 없어요.

다시 작업을 시작한 순간  재연결되는 것이니까요


이 시간의 지정은 사용자께서 판단하시어 할 일이겠죠


실행창에서 cmd입력후 커맨드 창에서

ex) net config server /autodisconnect:1 ~5

 

시간은 1분이나 5분정도내에서 적당한 시간을 설정하시면 되겠네요

 

도움이 좀 되셨는지요.

내용출처 : 마이크로소프트의 고객지원센터
Posted by tornado
|

SELinux의 이해

OS/LINUX 2006. 7. 4. 11:53

Fedora Core4에 기본 포함된 Selinux에 대한 개념이해하는데 많은 도움이 될 수 있는 문서입니다.

 

 

1. SELinux의 이해

Q: SELinux란?
Q: SELinux 정책이란?
Q: SELinux 목표 정책(SELinux targeted policy)이란?
Q: 어떤 데몬이 목표 정책에 의해 보호받는가?
Q: 어느 데몬을 목표 정책에 추가할 것인가? Sendmail, Postfix, MySQL, 혹은 PostgreSQL?
Q: 염격한 정책은 어떤가? 이 정책 조차도 유효한가?(Does it even work?)
Q: 파일 문맥이란?
Q: 파일, 사용자, 프로세스의 보안 문맥을 확인하는 방법은?
Q: 영역과 유형은 어떻게 다른가?

 

2. SELinux 제어하기

Q: SELinux 설치 및 설치 안하는 방법은?
Q: 사용중인 정책을 교체하는 방법은?
Q: 목표 정책하에서 특정 데몬에 대하여 SELinux protection을 활성화/비활 성화 방법은?
Q: 부팅시 SELinux를 비활성화시키는 방법은?
Q: 부팅시 enforcing을 활성화/비활성화하는 방법은?
Q: 재부팅하지 않고 enforcing 모드를 임시로 비활성화시키는 방법은?
Q: 부팅시 시스템콜 auditing 키거나 끄는 방법은?
Q: 재부팅을 하지않고 시스템콜 auditing을 잠정적으로 끄는 방법은?
Q: SELinux 설치에 관한 상태 정보(status info)를 얻는 방법은?

 

3. 문제 해결하기

Q: 응용프로그램이 기대했던 데로 동작하지않고 avc: denied 란 메시지가 나타나면, 어떻게 이 문제를 해결하는 가?
Q: 기존 /home 파티션이 있는 시스템에 휘도라 코아를 설치하고 로그인을 할 수 없을 때 해결방법은?
Q: setfiles나 fixfiles를 사용하여 /home을 재명명한 후, 여전히 SELinux 비활성 시스템(non-SELinux-enabled system)으로 /home을 읽을 수 있을까?
Q: 휘도라 코아와 비SELinux 시스템간에 NFS를 사용하여 디렉토리를 공유하는 방법은?
Q: 적절한 문맥을 갖는 사용자 홈 디렉토리와 함께 새 리눅스 사용자 계정 을 만드는 방법은?
Q: 다른 모든 SELinux 문서는 su이 단지 리눅스 정체성만을 바꾸고 보안 역할(security role)은 아니라고 말한다.
Q: 특정 프로그램에 대한 로그를 채우는 avc 오류에 골치를 앓고 있다. 어떻게 하면 그것에 대한 접근을 감시하지(audit) 않도록 선택할 수 있는가?
Q: 비록 허가 모드에서 운행될 지라도(even running in permissive mode), 많은 수의 avc denied 메시지가 나타난다.
Q: 오직 SELinux가 enforcing 모드에 있을 때만 특정 허가 거부를 받지만, /var/log/messages에는 어떠한 감시 메시지를 볼 수가 없다. 이들 침묵의 거부(silent denials)의 원인을 밝혀낼(identify) 수 있는 방법은?
Q: 정책 패키지를 업그레이드할 때(예를 들어, yum을 사용하여), 기존 정책 에 어떤 일이 발생하는가; 자동으로 업데이트되는가?
Q: 만일 응용프로그램 패키지와 함께 보급되는 정책이 재명명이 필요한 방법으로 변경된다면, RPM은 패키지가 소유한 파일들을 재명명을 처리할 것인가?
Q: 정책과 정책 소스 패키지사이에 어떤 관계가 있는가?
Q: 왜 /etc/selinux/policyname/policy/policy.<version>과 /etc/selinux/policyname/src/policy/policy.<version> 파일은 다른 (크기, md5sums, 날짜)를 갖는가?
Q: 새로운 정책 패키지가 시스템을 비활성화시킬(disable) 것인가?
Q: 정책 작성에 도움을 줄 수 있는 방법은?
Q: 콘솔에 메시지가 넘쳐나고 있다. 어떻게 이것을 막아낼 수 있는가?
Q: 정책 소스를 설치하지 않고 기본 정책을 시험할 수 있는가?
Q: KDE 응용프로그램을 SELinux하에서 작동하는 데 문제가 있다.
Q: SELinux=disabled가 작용하지 않는 이유는?

 

4. SELinux 배치하기

Q: SELinux를 사용하기 위해 어떤 파일 시스템을 선택해야 하는가?
Q: SELinux는 시스템 성능에 어떠한 영향을 미치는가?
Q: SELinux를 효과를 제고하기위해(to leverage SELinx in) 첫째로 보아야 할 것은 어떤 유형의 배치/응용프로그램/시스템 등 인가(What types of deployments/applications/systems, etc.)?
Q: 어떻게 SELinux가 제삼 응용프로그램에 영향을 끼치는가?

 

문서출처 : KLDP

Posted by tornado
|

NTLDR is missing

Press any key to restart

 

NTLDR파일은 XP의 시스템파일중 하나 이다. 그렇기 때문에 손상되었거나 없으면

부팅이 않되면서 위와 같은 메세지가 나온다.

 

이런 메세지로 인해 부팅을 할 수 없을 경우에는 XP씨디에 있는 복구콘솔 프로그램을 이용하여

해결한다.

 

# 문제 원인

   NTLDR, BOOTFOT.BIN, NTDETDCT.COM, BOOT.INI 파일을 실수로 지웠을 경우

 

# 해결 방법 복구콘솔(XP 설치씨디에 있다)

1. COPY 명령으로 NTLDR 파일 복구

2. FIXBOOT 명령으로 BR 영역 보구

3. COPY 명령으로 BOOTFONT.BIN과 NTDETECT.COM파일 복구

 

# XP설치씨디를 이용하여 복구콘솔로 복구하는 방법

1. XP설치씨디를 씨디롬에 넣는다.

2. 컴퓨터를 재부팅한다.

3. 재부팅과 동시에 F2키나 DEL키를 계속 눌러서 CMOS SETUP으로 들어간다.

4. BOOT SEQUENCE로 들어가 부팅순서를 CDROM이 첫번째로 되게 설정한다. : BIOS에 따라 다름

5. F10키를 누른후 저장하고 재부팅

6. CD-ROM으로 부팅이 되면 R(복구콘솔)을 눌러 복구콘솔로 들어간다.

7. 키보드 선택시 첫번째 선택

8. 로그온할 WINDOWS 설치를 선택하십시오. 에서 1입력

9. 암호는 대부분 설정을 안하셨을텐 그냥 ENTER

10. C:WINDOWS

                여기 부터가  복구콘솔 명령을 실행할 수 있는 화면이다.

                띄어쓰기를 잘 해야 하는데 편의상 ^로 하겠다.(절대로 같이 표기하지 말것)

                씨디롬 드라이브가 D: 라고 가정한다.

11. CD ^

12. COPY^D:I386NTLDR^C:

13. FIXBOOT

14. COPY^D:I386BOOTFONT.BIN^C:

15. COPY^D:I386NTDETECT.COM^C:

16. EXIT

17. 자동으로 재부팅

Posted by tornado
|

분산파일 시스템

OS/WIndows 2006. 6. 21. 18:12

DFS(분산파일 시스템)

1. 개요
Windows 2000 Server 분산파일 시스템은 네트워크의 사용자들이 네트워크에서 파일을 찾고, 보고, 편집하는 것을 용이하게 한다. 이것은 DFS가 중앙 위치에서 네트워크의 어느 컴퓨터상의 파일에나 사용자가 액세스 하도록 하기때문이다.
DFS를 설치할 때는, DFS 루트-파일 및 파일

2. 분산파일 시스템이란?
Microsoft Distributed File System은 기업에 있는 여러 유형의 파일 시스템 리소스에 대해 하나의 이름 공간을 구현한다. Dfs는 물리적 리소스와는 독립된 하나의 논리적 트리 구조로 구성된다. Dfs 트리 토폴로지는 Directory 서비스에 자동으로 게시되어 Dfs 루트의 내결함성을 구현한다.
사용자가 Dfs 루트에 추가하는 볼륨은 공유 네트워크 디렉터리를 나타내는 리프 또는 분기 노드에 해당한다. 공유 리소스는 단일 트리나 복수의 Dfs 트리를 사용하여 분산될 수 있다. 그룹 액세스 권한과 같은 표준 Windows 2000 Server 보안 기능을 사용할 경우 Dfs 볼륨에 대한 액세스가 제한될 수 있다.
Dfs 트리는 하나의 DNS 이름 공간이다. 따라서 Dfs 볼륨에 대한 DNS 이름은 Dfs 루트의 호스트 서버를 확인해 준다. Active Directory는 하나의 Dfs 트리에 대한 여러 호스팅 서버 간의 볼륨 참조를 중재한다.
Dfs 트리는 사용자에게 적절한 네트워크 리소스에 대한 통일되고 가시적인 액세스 방법을 제공한다. 참조되는 리소스의 기존의 하위 디렉터리는 앞의 예에 나온 C++ 및 Java 하위 디렉터리의 경우처럼 상위 디렉터리와 함께 Dfs에 게시된다. Dfs 클라이언트 모듈은 Windows 2000 Server 및 Professional에 자동으로 설치되는 SMB(Server Message Block) 프로토콜에 기본적으로 제공된다.

3. DFS 요구 사항

플랫폼
호스트 DFS 클라이언트
호스트 DFS 루트
DOS, Windows3.x, Windows for Workgroup 및 NetWare 서버 아니오 아니오
Windows 95 예 - DFS 4.x 및 5.0용
클라이언트 다운로드
아니오
Windows 98 예 - DFS 4.x 및 5.0(독립형) 클라이언트 포함 및 DFS 5.0(도메인 기반)용 클라이언트 다운로드 아니오
Windows NT4.0 및
서비스 팩 3
예 - DFS 4.x 및 5.0(독립형) 클라이언트 포함 예 - 독립형 서버 전용
Windows 2000 DFS 5.0 클라이언트 포함 예 - 독립형 및 도메인 기반 서버 또는 도메인 컨트롤러

4. DFS 루트 만들기

1) 분산 파일 시스템을 시작한다. (시작-프로그램-관리도구-분산 파일 시스템)


2) 분산 파일 시스템에서 오른쪽 클릭후, 새 DFS 루트를 선택한다.


3) 새 DFS 루트 마법사가 나타나고, “다음”에 클릭한다.


4) 다음 스크린은 DFS 루트의 결함허용의 추가적인 옵션 사항이다. 이것은 액티브 디렉토리를 사용하여 정보를 저장한다. 그리고 액티브 디렉토리를 사용할 수 없을 때나 원하지않으면 DFS 루트 자체를 저장한다. “도메인 DFS 루트 만들기”를 선택한다. 그리고 다음을 클릭한다.


* 도메인 DFS 루트 만들기와 독립 실행형 DFS 루트 만들기와 차이점
도메인 기반 DFS 루트가 Active Directory를 사용하고 독립형은 그렇지 않은 것 이외에도 도메인 기반 루트는 도메인 멤버 서버에 설치해야 하며, 루트 디렉토리에 공유폴더를 가질 수 있고 여러 수중의 DFS 연결을 가질 수 있다. 독립형 루트는 제한된 연결 계층 구조를 가지며 루트 수준 공유 폴더를 가질 수 없다.

5) DFS 루트에 대한 호스트 도메인을 선택해야 한다. ( 결함허용일 때는 도메인 번호) 그리고, DFS 서비스를 실행해야 한다. 현재의 서버가 선택 되어질 것이나, 도메인 이름을 타이핑 하거나 브라우저를 클릭하여 바뀐다. 다음을 클릭한다.





6) 다음은 DFS 루트 볼륨을 위한 선택 사항이다. 크게 두개의 옵션이 있다.




7) 각각의 DFS 루트는 고유 이름이 필요하며, 이름을 바꾼다 할지라도 디폴트(default)로서 할당량의 이름이된다. 그리고, 새로운 DFS를 최근의 제어 테이블(console)에 추가할 수 있다. “다음”을 클릭 한다.


8) 도메인, 서버 그리고 할당의 이름이 요약 되어 있고, “마침”에 클릭한다.


9) 마침 후 화면 입니다.

Posted by tornado
|

휴지통까지 비웠을때,

shift + delete 로 파일 지웠을때,


복구 해야할때 유용함 ㅋㅋ

Posted by tornado
|
Posted by tornado
|

[qmail]queue-fix

OS/LINUX 2006. 5. 30. 15:41
김남일
손님





올리기올려짐: 2004년2월12일 2:19 pm    주제: queue-fix 설치는 어떻게 하나요. 인용과 함께 답변

스팸메일로 인하여 자꾸만 queue에 쌓이네요.
그래서 큐를 모두 지우고 다시 생성할려고 하는데
queue-fix.tar.gz를 다운로드 하였거든요.
그런데 어떻게 설치해야 될지 모르겠네요.
설치해 보신분 답변 부탁드립니다.
위로
'); // :badtag -->
 
김남일
손님





올리기올려짐: 2004년2월12일 3:17 pm    주제: Re: [자답] 해결했습니다. 인용과 함께 답변

자답입니다.
여기에 찾아보니까 있더군요.
해결했습니다

tar xzf queue-fix.tar.gz
cat ../queue-fix-1.4.diff | patch -p1
make
rm -rf /var/qmail/queue
./queue-fix -i /var/qmail/queue



김남일 wrote..
> 스팸메일로 인하여 자꾸만 queue에 쌓이네요.
> 그래서 큐를 모두 지우고 다시 생성할려고 하는데
> queue-fix.tar.gz를 다운로드 하였거든요.
> 그런데 어떻게 설치해야 될지 모르겠네요.
> 설치해 보신분 답변 부탁드립니다.
Posted by tornado
|

저번 주말엔 큐메일서버를 가지고 끙끙댔었습니다.


서핑중에 좋은 스크립트를 발견해서 올립니다.


큐메일 서버의 상태, 메일큐 제어 등을 할 수 있습니다.





'OS > LINUX' 카테고리의 다른 글

메일서버 릴레이 테스트  (0) 2006.06.16
[qmail]queue-fix  (0) 2006.05.30
qmail 설치후 queue 에 계속 쌓일 경우 .. 퍼미션 조절해주기..  (0) 2006.02.27
qmail+vpopmail 설치  (0) 2006.02.24
Apache James Setting  (0) 2006.02.23
Posted by tornado
|
[익스체인지 서버 2003, 바뀐 점은] ① 스팸메일 탈출 방법


구병국 (익스체인지 사용자 그룹 대표시샵) 21/06/2005
연재순서
1. 스팸 메일 수렁에서 벗어나기
2. 익스체인지 서버 2003 OWA 이용과 커스터마이제이션
3. 익스체인지 서버 2003과 ISA 서버 2004
스팸은 마치 노년기에 걸리는 당뇨병과 같다. 걸리지 않는 것이 가장 좋겠지만 일단 걸리면 세밀한 건강 검진과 식이요법, 운동 등으로 꾸준한 치료가 필수적이다. 스팸도 마찬가지다.

메시징 시스템이 제대로 돌아가는지 검사하고 제대로 설정한 뒤에 끊임없이 모니터링해야 안전한 상태로 유지할 수 있다. 관리자를 위한 익스체인지 서버 강좌, 그 첫번째 글은 스팸 필터링에서 시작한다.

인류 역사상 첫번째 스팸 메일은 지난 1978년 5월에 DEC가 새로운 제품에 대한 광고 메일을 600명의 사용자에게 보낸 것이 시초로 기록돼 있다. SMTP가 처음 고안될 때는 이것이 전화보다 더 널리 쓰이는 커뮤니케이션 수단으로 각광받을 줄은 상상하지 못했다.

한정된 대상, 한정된 공간에서만 사용하는 것을 고려했기 때문에 인증 없이도 보낼 수 있었고 받는 사람 역시 설마 보낸 사람 주소에 적힌 사람이 아닌 다른 사람이 메일을 보내리라곤 생각지 못했다.

하지만 역설적으로 말하면 그렇게 열린 공간에서 사용할 수 있었기에 오늘날 많은 경쟁자들을 물리치고 SMTP는 당당히 주요 메시징 프로토콜로 자리를 잡을 수 있었다. 물론 이후에 계속적으로 보안이 강화된 SMTP 프로토콜들이 발표됐지만 아직도 SMTP 자체로는 충분하지 못한 것이 현실이다.

오늘날 스팸에 관한 한 우리나라의 위치는 특별하다. 2004년 현재 전세계 스팸메일의 15.42%가 한국에서 발송됐다. 물론 여기에는 초고속 인터넷으로 연결된 많은 컴퓨터들이 스팸메일 발송 코드에 감염돼 봇(Bot)이라고 불리게 됨으로써 자신도 모르게 스팸을 보냈기 때문이다. 심한 경우 우리나라에서 발송되는 메일 전체를 스팸메일로 인식해 정상적인 메일마저 전달되지 않는 경우도 있었다.

MS는 지난 2003년부터 스팸에 대해 많은 관심을 보여 왔고, 그 결과 익스체인지 서버 2003에는 스팸에 대처할 수 있는 많은 기능들이 추가됐다. 여러가지 필터링 툴과 클라이언트인 아웃룩 2003과 함께 실행되도록 하는 기능 등이 대표적이다.

또한 지난해 8월에는 자체 개발하던 Caller-ID를 SPF(Sender Policy Framework)와 결합해 Sender-ID라는 명칭으로 인터넷국제표준화기구(IETF)에 표준으로 신청하기도 했다. 올해 새해 벽두에는 안티스파이웨어 베타 버전을 출시해 일반 사용자들의 컴퓨터에 있는 악성 코드와 응용 프로그램을 찾아 제거할 수 있는 툴을 선보였다.

최초의 스팸 필터링 기능 ‘보낸 사람 필터링’
익스체인지 2000이 시판됐을 때 처음 등장한 필터링 도구가 바로 보낸 사람 필터링(Sender Filtering)이다. 5.5 버전에서 지겹도록 큐에 쌓여졌던 @boss.com, @test.com, @test1.com 등의 메일 때문에 관리자들은 이 계정에서 보낸 메일에 대해 필터링을 하는 것이 필요하다고 입을 모았었다.

이것은 스패머가 릴레이 테스트, 메일 주소 추출, 사전식 메일 공격 등을 위해 해당 메일 서버로 뿌려졌던 메일에 대해 익스체인지 5.5의 Postmaster가 NDR(Non-Delivery-Report) 등을 보낸 사람에게 회신했기 때문이다. 여기에 응답하지 않기 때문에 큐에 쌓이고 이것들이 전체 서버의 성능을 떨어뜨리기 일쑤였다. 따라서 이를 원천적으로 막기 위해서는 아예 이런 도메인에서 오는 메시지들은 받지 않는 것이 좋겠다는 것이 관리자들의 의견이었다.

<화면 1> 보낸 사람 필터링

이렇게 탄생한 보낸 사람 필터링 탭이 바로 <화면 1>이다. 필요에 따라 도메인이나 특정 메일 주소를 등록할 수 있으며 여러 가지 옵션을 설정할 수도 있다. 먼저 [보낸 사람]은 필터링을 하고 싶은 도메인 앞에 @표시를 해서 입력하고, 주소 형태는 그대로 타이핑해 막을 수 있다. 약 850개까지 등록할 수 있으며 그 이상 입력하면 ‘LDAP Provider의 80072024’ 오류와 함께 먼저 입력한 것이 삭제된다.

이것은 [보낸 사람] 목록도 액티브 디렉토리(active directory) 데이터베이스 내에서 하나의 개체를 차지하게 되고 이것은 AD의 데이터베이스 단위인 8KB를 차지하는데, 이론적으로는 910개 정도(8*1024/9=910)가 들어가는 것이 정상이지만 이미 데이터베이스 내에 고정된 필드들이 존재하므로 이 50여개를 제외한 850여개로 제한되기 때문이다. [필터링한 메시지 보관]을 선택하게 되면 필터링한 것이 익스체인지가 설치된 하부 디렉토리의 Mailroot\vis 1\filter 폴더에 저장된다.

90년대 말과 2000년 초에는 스팸 메일을 보내는 기술도 그리 발달하지 못해 보낸 사람을 공란으로 해서 보내는 경우가 많았다. 그래서 나온 것이 [보낸 사람]이 비어 있는 메시지 필터링 기능이다. 하지만 요즘은 보내는 사람 란에 비어 있는 스팸 메시지는 거의 찾아볼 수 없다(일부 보이스 메일에서 보내는 메일의 경우 [보낸 사람] 란이 비어 있는 경우가 있다).

[주소와 필터가 일치하면 연결 끊기] 옵션을 선택하면 해당 주소가 보낸 메시지는 Mail From 명령 후에 곧바로 ‘554 5.1.0 Sender Denied’가 나타나고 연결이 종료된다. 이 옵션은 아예 연결 자체를 막아버리기 때문에 받는 서버의 부하에 전혀 영향을 미치지 않는다는 장점이 있지만, 보내는 사람이 필터링된 것을 알게 되므로 보낸 사람 란에 다른 주소를 입력하는 방식으로 악용될 가능성이 있다.

[보낸 사람에게 필터링한 것을 알리지 않고 수락] 옵션은 [주소와 필터가 일치하면 연결 끊기] 옵션을 선택하지 않았을 때 사용할 수 있다. 즉 보낸 사람에게는 정상적으로 메일을 보낸 것처럼 처리하지만 실제로는 필터링하도록 하는 것이다. 보내는 사람에게 메시지 필터링의 여부를 알지 못하게 하는 장점이 있지만 큰 메시지를 보내올 때 서버가 일단 받아들이기 때문에 대용량 부하가 발생할 수 있다.

메일 주소 수집을 피해라 ‘받는 사람 필터링’
받는 사람 필터링은 디렉토리에 존재하지 않는 주소 또는 차단 목록에 기록된 특정 주소로 들어오는 메시지에 대해서 SMTP 세션에서 막아버리는 방법이다. <화면 2>는 받는 사람 필터링을 설정하는 방법을 보여준다.

<화면 2> 받는 사람 필터링

게이트웨이 역할을 하는 익스체인지 서버는 RCPT TO 명령을 받으면 받은 메일 주소가 유효한지를 알아보기 위해서 글로벌 카탈로그 서버에 질의를 한다. 이때 [디렉토리에 없는 사람 필터링] 옵션을 선택하면 메일 주소가 있는 경우에만 이후 명령을 수행해 메시지 전체 내용을 받고, 주소가 없으면 ‘501 5.5.4 Invalid Address’ 오류 메시지를 내보낸다. 이 옵션은 익스체인지 2003의 큐를 말끔하게 정리할 수 있는 팁이다.

2000 버전에서 큐 안에 그렇게 많이 쌓여서 괴롭히던 메일 찌꺼기들이 2003이 되면서부터 자취를 감추게 된 것도 모두 이 기능 덕분이다(사실 이것은 익스체인지 5.5나 익스체인지 2000에서도 특정 메일이 도착하면 디렉토리에 LDAP(Lightweight Directory Access Protocol)으로 질의하도록 하는 스크립트를 작성해 SMTP 이벤트 싱크(Event Sink)에 추가해도 충분히 방비할 수 있었다).

익스체인지 2000에서는 공용 폴더에서 익명의 사용자에게 기고자 권한이 주어졌었다. 또 회의실과 같이 리소스 사서함을 가진 서버에서는 외부의 사용자도 해당 사서함에 메일을 보낼 수가 있었다. 회사 내에 있던 배포 그룹이 메일 주소를 가질 수도 있었다.

스팸 메일 발송자들은 해당 메일 주소가 공용폴더 주소인지 아니면 리소스 사서함인지를 모르며, 설사 알고 있더라도 상관하지 않고 메일을 보낼 것이다. 만일 [받는 사람]란에 이런 리소스 주소들을 등록해 놓는다면 공용 폴더를 아주 깨끗하게 유지할 수 있을 것이다. [받는 사람]란에 특정 주소를 입력하고 나서 해당 주소로 접속하면 ‘550 5.7.1 Requested Action not taken: mailbox not available’ 오류를 나타낸다.

메일을 사용할 수 있도록 한 그룹의 경우 여기서 메일 주소를 입력해도 되며 <화면 3>과 같이 해당 메일 그룹의 속성 대화상에 있는 익스체인지 일반정보 탭에 있는 메시지 제한에서 설정해도 된다.

<화면 3> 익스체인지 일반정보 탭

주의해야 할 것은 <화면 3>과 달리 기본적으로 그룹에게는 모든 사람으로부터 메일을 받을 수 있도록 설정돼 있다는 사실이다. 따라서 가능하면 그룹에 대해서는 [인증된 사람으로부터만] 옵션을 선택하고 그 외 세부 옵션을 선택하는 것이 좋다. 그래야만 외부에 있는 사용자가 함부로 내부에 있는 메일 그룹으로 메시지를 보낼 수 없도록 막을 수 있다. 이렇게 설정한 상태에서 외부에 있는 사용자가 내부에 있는 그룹으로 메일을 보내면 ‘550 5.1.1 User unknown’ 오류가 나타난다.

받는 사람 필터링을 구성하면 서버의 부하를 줄일 수 있지만 DHA(Directory Harvest Attack)의 가능성이 여전히 존재한다. DHA란 스팸 메일 발송자들이 메일 주소를 얻는 방법 가운데 하나로, DNS 내에서 메일 서버의 위치를 파악해 해당 메일 서버에 사전식으로 조합된 메일 주소를 보내서 NDR을 보내지 않는 메일에 대해서 메일 주소의 유효성을 확인하는 방법이다. 이밖에도 스팸 메일 발송자들은 성인사이트나 메일링 서비스 업체의 데이터베이스를 해킹하거나 다른 사람들에게 돈을 주고 메일 주소를 사기도 한다.

<그림 1> DHA의 개념도

<그림 1>은 DNS 내에 포함된 MX 레코드와 호스트 주소로 메일 서버의 주소를 알아내 사전식으로 조합된 메일 주소 목록을 이용, 해당 서버에 있는 유효한 메일 주소를 검색하는 DHA를 그림으로 나타낸 것이다.

이는 메일 주소를 수집하는 데 널리 사용되지만 사실 이렇게 해서 알아낸 메일 주소는 해킹을 통해서 얻은 주소 목록보다는 훨씬 가치가 떨어진다. 왜냐하면 특정 서버에 포함된 메일 주소는 해당 서버의 목적에 관심을 가진 사용자들의 주소지만 사전식으로 공격해서 얻은 메일 주소들은 해당 주소가 그것에 대해 관심이 있을지 여부를 알 수 없기 때문이다.

예를 들면 비아그라를 판매하려는 스팸 메일 발송자의 경우 일반 회사의 메일 서버에 사전식으로 공격하기 보다는 성인사이트를 운영하는 서버의 데이터베이스에 저장되어 있는 전자메일 주소 목록을 얻는 것이 비아그라를 훨씬 많이 판매할 수 있는 기회가 될 것이다.

아무리 메일 주소의 값어치가 떨어지더라도 잠재적인 고객확보 차원에서, 그리고 메일 주소를 다른 사람들에게 판매하기 위해서는 DHA를 수행하는데 이것을 방지하기 위해 널리 사용되는 기능이 타르피팅(Tarpiting) 기능(tar+pit의 합성어로 쥐를 잡을 때 사용하는 것처럼 타르로 된 끈끈이 덫을 의미한다)이다. SMTP 서버가 RCPT TO 명령을 통해 보낸 메일 주소가 디렉토리를 검색한 뒤 없다고 하면 늦게 응답하도록 해 스팸 발송자들이 해당 주소가 유효한지 여부를 알 수 없도록 하는 것이다.

타르피팅 기능은 윈도우 2003 환경에 SMTP 서비스의 버전(확인은 Windows\System32\inetsrv 디렉토리 안의 smtpsvc.dll이다)이 6.0.3790.175 이상 되어야 한다. 꾸준하게 보안 업데이트를 해 왔다면 문제가 없을 것이다. 지원 환경이 된다면 레지스트리를 변경해 줘야 한다. 레지스트리 HKEY_LOCAL_ MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSVC\ Parameters에서 새로 만들기 → DWORD → TarpitTime을 입력한 후 시간을 초단위로 입력하고 재부팅하면 된다. 만일 값을 5라고 설정하면 RCPT TO 명령은 5초 뒤에 응답하게 될 것이다. 보통 스팸 메일 발송자들은 RCPT TO에 대한 응답이 늦어지면 재시도를 하지 않는 것이 특징이다.

스팸 발송 서버를 막는 ‘연결 필터링’
익스체인지 2000까지는 실시간 차단 목록(RBL, Realtime Blocklist)을 이용할 수 있는 방법이 없었다. RBL이란 특정 단체나 회사에서 스팸 메일을 보내는 서버나, 전화 접속자(일반적으로 동적 IP를 사용하는 전화 접속자들이 자신도 모르게 스팸을 발송하게 되는 경우가 많다), 오픈 릴레이로 맞추어진 서버들의 IP 목록들을 말하며 우리가 일반적으로 알고 있는 ORDB(Open Relay DataBase, www.ordb.net), Spamhause(www.spamhaus.org), Mail-abuse(www.mail-abuse.org), SpmaCop(www.spamcop.net) 등이 바로 이 RBL을 제공해 주는 회사들이다.

연결 필터링이란 메시지가 들어오면 메시지를 보낸 서버의 IP 주소를 추출해 RBL 제공자에게 질의를 하고 해당 IP 주소가 목록에 있는지 여부를 확인, 해당 주소가 없다면 메시지를 받아들이고 주소가 존재한다면 거부하는 방법이다. 이 방법을 사용하면 약 40~50%의 스팸들을 걸러낼 수 있다고 한다.

사실 지난 2002년 MS의 조사에서도 익스체인지 서버를 게이트웨이로 쓰는 회사는 미국 내에서 거의 없었던 것으로 조사됐다. RBL을 이용할 수 없기 때문이었다. 거의 대부분의 회사들이 센드메일(Sendmail)을 SMTP 게이트웨이로 사용해 RBL 기능과 그 외 서비스를 이용해 왔다. MS는 이런 고객들의 요청을 받아들여 SMTP 게이트웨이로 센드메일을 사용하지 않고 바로 익스체인지를 사용할 수 있도록 RBL을 지원하게 됐다.

RBL들은 보통 DNS 쿼리를 이용해 질의를 한다. 즉 SMTP 가상 서버가 메시지를 받으면 <화면 4>와 같이 연결 필터링 탭의 [차단 목록 서비스]에 설정돼 있는 목록 중 가장 위쪽 서버에 질의를 한다. RBL에 질의를 하는 방법은 역방향 조회와 비슷한 모양을 가지고 있다.

<화면 4> 연결 필터링

역방향 조회 시에는 in-addr.arpa를 사용하지만 RBL의 경우 bl.spamcop.net이 같이 RBL 제공자의 도메인 이름을 사용한다는 것이 차이점이다. 예를 들면 123.12.12.3이라는 서버가 메시지를 보내 왔다면 3.12.12.123.bl.spamcop.net으로 질의를 한다. 그러면 해당 서버에서는 IP 주소가 있는지 확인해 이름이 있는지 여부를 결과로 보내 준다. nslookup 명령을 통해서 알아보면 어떻게 확인하는지 간단하게 확인할 수 있다.

>nslookup -q=a 3.12.12.123.bl.spamcop.net

server:ns.techmentor.co.kr

address:211.114.57.123

Name: 3.12.12.123.bl.spamcop.net

Address: 127.0.0.2

이를 네트워크 모니터를 이용해서 보면 다음과 같다.

DNS: 0x6c:Std Qry for 3.12.12.123.bl.spamcop.net of type Host Addr on Class INET addr

이때 해당 주소가 자신의 데이터베이스에 없으면 다음과 같은 메시지를 보여 준다.

DNS: 0x6c:Std Resp. Auth. Ns is spamcop.net. of type SOA on Class INET addr.: Name does not exist

데이터베이스에 존재한다면 다음과 같이 처리를 한다.

DNS: Answer section: 3.12.12.123.bl.spamcop.net of type SOA on class INET addr.
DNS: Resource Name: 3.12.12.123.bl.spamcop.net.
DNS: Resource Type= Host Address
DNS: Resource Class= Internet address class
DNS: Time To Live=2048(0x800)
DNS: Resource Data Length =4(0x4)
DNS: IP address=127.0.0.2

이렇게 되면 클라이언트에게는 기본적으로 550 5.7.1 123.12.12.3 has been blocked by Spamcop RBL list라는 응답을 보내 준다. 여기서 중요한 것이 바로 127.0.0.2라는 IP 주소다. 이것은 보통 반환상태 코드라고 부르는데, 해당 주소가 어떤 RBL에 포함돼 있는지를 나타내는 코드로 각 RBL 업체에 따라 약간의 차이가 있다. 그러므로 자신이 사용하는 RBL의 제공자 홈페이지에서 상태 반환 코드를 확인한 후 <화면 5>와 같이 필요한 코드만 적용할 수 있다. email-policy.com 웹사이트(www.email-policy.com/spam-black.lists.html)에 보면 각 RBL 제공회사별 반환 상태코드를 확인할 수 있다.

<화면 5> 연결 필터링의 상태반환 코드

메시지를 보낸 사용자에게 반환할 메시지의 내용도 지정할 수 있다. 기본적으로 [IP 주소 has been blocked by 규칙의 표시이름]으로 나타나는데 이것을 필요에 따라 바꿀 수 있다. 한글은 사용할 수 없으며, 다음과 같은 변수를 사용하면 적당하게 수정할 수 있다.

◆ %0: 보낸 메일 서버의 IP 주소
◆ %1: 연결 필터링의 규칙 표시 이름
◆ %2: RBL 서비스 제공회사 이름

예를 들어 ‘The IP address %0 was rejected by the Realtime Block List provider %2’라고 [반환할 사용자 지정 오류 메시지]에 입력하면 ‘The IP address 123.12.12.3 was rejected by the Realtime Block List provider bl.Spamcop.net’이라는 메시지를 받게 된다. 이때 특정 메일 주소에 대해 연결 필터링에 예외를 두기 원한다면 [예외]를 선택하고 SMTP 주소를 입력하면 해당 주소에 대해서는 연결 필터링의 결과에 상관없이 메시지를 받아 들인다.

만약 특정 주소가 아니라 특정 서버가 된다면 상황은 달라진다. 이때는 사용자가 원하는 작업이 무엇인지 먼저 결정해야 한다. 즉 특정 IP 주소에 대해서 거부할지 아니면 허용할지를 결정해야 한다. 특정 IP 주소에 대해서 거부한다는 말은 연결 필터링 결과에 상관없이 특정 IP 주소나 그 대역에 있는 컴퓨터 그룹들을 모두 거부한다는 의미이며, 반대로 허용한다는 것은 RBL의 질의 결과에 상관없이 해당 IP 주소에 대해서는 모두 허용한다는 뜻이다. 익스체인지 5.5의 경우 허용 목록에 해당 IP 주소를 입력해 바로 연결을 허용할 수 있다(이것을 보통 블랙 리스트의 반대 개념으로 화이트 리스트라고 한다).

차세대 안티 스팸 기능 ‘지능형 메시지 필터’
우리나라 사람들이 싫어하고 고통스러워하는 이야기가 바로 IMF이다. 처음 Intelligent Message Filter라고 했을 때는 좀 있어 보이더니 이것을 줄여서 IMF라고 하니 바로 인상이 구겨지는 것이 우리나라 사람들의 인지상정이다.

어쨌든 IMF가 첫선을 보인 것이 2004년 5월 미국에서 열린 TechED 2004이다. 이전까지만 해도 MS 익스체인지 컨퍼런스(MEC)가 따로 개최될 정도로 활기가 있었으나 2003년부터는 TechED에 통합돼 세션의 숫자도 줄어 들었다. 메시징의 중요성은 점점 강조되고 있지만 MS는 오히려 뒷걸음질치는 인상이다.

본래 IMF 개념이 처음 제기된 것이 지난 2003년 가을 컴덱스다. 빌 게이츠 회장이 자신도 하루에 수천통의 스팸을 받는다는 고백과 함께 앞으로 MS가 스팸과의 전쟁을 선포하고 그것을 위해 엄청난 돈을 투자하겠다고 밝혔다. 익스체인지 서버에 기계 학습(Machine Learning) 기술을 접목시킨 새로운 필터링 도구를 선보이겠다는 것이었다. 그리고 이 가운데 가장 먼저 제품화한 것이 바로 IMF였다.

익스체인지 2003이 출시될 때 이미 IMF에 대한 윤곽이 있었다. 왜냐하면 이전 버전에서 받는 사람 필터링, 연결 필터링 기능까지 구현했기 때문에 고객들의 컨텐츠 필터링에 대한 요구가 더욱 높아질 것으로 예상했기 때문이다. 실제로 익스체인지 2003이 출시될 당시 아웃룩 2003에 스팸 방지 기술을 추가했고, 이때 이미 SCL(Spam Confidence Level) 이야기도 함께 제기됐다. 이제 IMF의 내면 속으로 들어가 보자.

IFM의 기술 기반 ‘스마트스크린’
스마트스크린(SmartScreen) 기술은 MS에서 특허를 낸 기술로, 특정 메시지가 들어오면 이 메시지가 스팸인지 아닌지를 통계학으로 판단하는 기술이다. 이 기술의 근간에는 베이지언(Bayesian) 정리가 있다. 베이지언 정리는 우리가 고등학교 때 배운 조건부 확률을 기초로 하고 있는데 이 조건부 확률을 이해하는 것이 스마트스크린을 이해하는데 도움을 줄 것이다(박스 기사 참조).

스마트스크린은 이와 같은 통계학적 방법에 의해 미래의 정보에 점수를 매겨 스팸인지 아닌지를 평가한다. 그러므로 스마트스크린에 사용되는 확률 정보가 얼마나 정확한지에 따라 메시지 분류의 정확도가 결정된다. 필자는 여기서 변인을 하나만 두었다. 즉 특정 낱말이 들어간 경우에 스팸인지 여부를 결정하지만 스마트스크린에 적용되는 변인은 여러 가지이며 각 변인에 대한 가중치도 다르다. 그렇기 때문에 MS는 스마트스크린 전체 기술에 대해서 특허가 있으며 이 기술은 MSN, Hotmail, 아웃룩에서 사용되고 있다.

이 기술은 베이지언 정리를 스팸 부분에 적용하는데 권위자인 David Hekermann이 MS 연구소의 MLAS(Machine Learning and Applied Stastistics)와 ASI(Adaptive Systems annd Interactions) 그리고 시그널 프로세싱(Signal Processing) 그룹을 이끌고 완성시킨 것이다. MS는 스마트스크린 기술을 개발한 후 스팸 분류의 정확도를 높이기 위해 피드백 루프 프로그램을 이용, 고객들로부터 50만개 이상의 스팸 메일들을 받아 각각의 특징을 분석했다.

현재에는 MS의 스마트스크린 뿐만 아니라 스팸 어세신(Spam Assassin)이라는 스팸방지 공개 소프트웨어에도 베이지언 정리가 이용되고 있다. 미국의 대다수 컨텐츠 필터링을 이용한 스팸방지 솔루션도 마찬가지다. 이렇게 스마트스크린 기술을 통해서 얻어진 결과가 각 메시지별로 SCL로 표시된다. SCL 값은 모두 11단계의 값으로 구성돼 있으며 상세한 내용은 <표 1>과 같다.

<표 1> SCL 값과 그 의미

SCL 값설명-1익스체인지 서버 2003 내부에서 이동하는 메시지에 부여하는 값이다. 내부적으로 배달되는 메시지에 대해 위양성(False Positive: 스팸 메일이 아닌데 스팸 메일로 분류되는 경우)일 가능성은 전혀 없으므로 따로 구분하며 덮어쓰기도 불가능하다. 인증 받은 사용자로부터 받는 메일은 기본적으로 -1이 된다.0전혀 스팸이 아닐 때 쓰여진다.1~9스팸일 가능성을 나타내는데 1은 스팸이 아닐 가능성이 높고 숫자가 높아짐에 따라 스팸일 가능성이 높아진다. 9가 되면 스팸일 가능성이 99% 이상이 된다.

이렇게 각 메시지 별로 SCL이 정해지는데 IMF는 스팸 여부를 판단하는 임계값을 정한다. 임계값을 5로 정하면 5이상의 SCL 값을 부여받은 메일을 스팸으로 인식한다. 임계값을 낮게 설정하면 스팸 메일로 분류되는 메일이 많은 반면 위양성 메일도 증가하고, 임계점을 높게 설정하면 위양성 메일을 줄일 수 있지만 스팸 메일들의 덜 걸러질 가능성이 있다.

그럼 좀더 내부적으로 어떤 과정을 거쳐서 SCL이 완성되는지 알고리즘을 살펴 보자. SCL은 수신된 특정 메시지에 대해 보낸 시간과 받은 시간의 차이, 메시지가 HTML로 되어 있는지 여부, 단어들이 사전에 있는지 여부 등을 확인한다. 메시지에서 반복되는 단어들을 제외하며 메시지 제목에 있는 단어들과 메시지 본문에 대해서 가중치(weight)를 정하고 영어일 경우 메시지 헤더에 대문자 수와 메시지 헤더에 숫자가 얼마나 있는지, 특정 단어가 반복되는 횟수 등도 가중치에 반영한다.

이런 가중치들은 -10에서 +10까지의 값으로 정해지는데 (-)값을 가지게 되면 스팸이 아닌 것으로, (+)값을 가지면 스팸일 가능성이 높은 것으로 해석한다. 이런 가중치가 다시 정규화 과정을 거쳐 0에서 1사이의 값을 가지며 이런 정규화 값을 모두 더하면 SCL이 된다.

베이지언 정리  
조건부 확률은 과거의 A라는 사건의 발생해 W1이라는 것으로 분류됐다면 B라는 사건이 일어날 때 다시 W1으로 분류될 확률을 계산하는 것이다. 즉 메시지 내용에 비아그라라는 내용이 포함됐을 때 스팸 메일로 분류했다면, 다음 번 메시지의 내용에 비아그라가 나오면 W1으로 분류될 확률을 계산해 내는 것이다. 그러면 일단 A라는 사건이 일어날 확률을 P(A)라고 하고 W1에 속할 확률을 P(W1)이라고 하자.


P(W1)+P(W2)=1→스팸일 확률과 스팸이 아닐 확률을 더하면 1이다
P(W1|A)→비아그라라는 내용이 포함됐을 때 스팸으로 분류될 확률
P(A|W1)→스팸으로 분류됐을 때 비아그라라는 내용이 포함될 확률
P(A, B)가 동시에 일어날 확률

조건부 확률이론에 따르면 이것은 증명할 필요가 없는 공리로 P(W1|A)=P(W1, A)/P(W1)이며 P(A|W1)=P(A, W1)/P(A)가 될 수 있다. P(W1, A)와 P(A, W1)는 두 가지 사건이 동시에 일어날 확률이기 때문에 같은 의미이다. 그러므로 P(W1, A)와 P(A, W1)를 없애면 P(W1|A)=P(A|W1)P(W1)/P(A)가 된다. P(W1|A)는 A라는 성질이 있을 때 W1에 속할 확률이다. 즉 비아그라라는 성질이 있을 때 스팸에 속할 확률을 의미한다. 그러면 P(W1|A)+P(W2|A)=1이다. 즉 A라는 성질이 있으면 W1 그룹에 속할 확률과 W2 그룹에 속할 확률의 합은 1이 된다. 당연한 결과이다.

그러면 P(W1|A)<P(W2|A)라고 가정하자. 즉 A라는 특성 W2 그룹에 속할 확률이 높다고 가정하는 것이다. 그러면 P(W1|A)=P(A|W1)P(W1)/P(A)와 P(W2|A)=P(A|W2)P(w2)/P(A)가 된다. 가정한 P(W1|A)<P(W2|A)에 대입하면 P(A|W1)P(W1)/P(A)<P(A|W2)P(W2)/P(A)가 될 것이다. 여기서 P(A)를 제거하면 P(A|W1)P(W1)<P(A|W2)P(W2)가 된다. 좌우를 정리하면 P(A|W1)/P(A|W2)<P(W2)/P(W1)이 된다. 이것이 베이지언 정리이다.

사실 오른쪽 왼쪽 모두 이전의 데이터로 알아낼 수 있는 것이다. 왼쪽을 가능성비(likelihood ratio)라고 부르며, 오른쪽을 임계점(threshold)이라고 부른다. 예를 들어 현재 받는 메시지의 10%가 스팸 메일이라고 하자. 그러면 스팸 메일일 경우 W1, 스팸이 아닐 경우 W2라고 하자. 임계점은 0.9/0.1=9가 된다. 그럼 비아그라라는 내용이 포함된 메일을 받을 확률을 P(A)이라고 하면 P(A|W1)은 비아그라라는 내용이 포함된 메시지가 스팸 메일로 분류될 확률이고 P(A|W2)는 스팸이 아닐 확률일 것이다.

이전의 통계에 따르면 비아그라라는 글자가 포함된 메시지가 스팸으로 분류된 경우가 80%이고 스팸이 아니었을 경우가 20%라고 하면 P(A|W1)/P(A|W2)=0.8/0.2=4가 된다. 그러므로 베이지언 정리에 의하면 4<9가 되므로 참이 된다. 이것은 앞으로 비아그라라는 글자가 들어간 메시지가 배달되면 스팸으로 분류하게 된다는 것을 의미한다. 왼쪽과 오른쪽의 차이가 크면 클수록 그 정확도는 높아진다.

실전! 지능형 메시지 필터 사용하기
지능형 메시지 필터 기능을 사용하려면 SMTP 게이트웨이 역할을 하거나 브리지헤더 역할을 하는 서버에 설치해야 한다. IMF를 설치하면 전역 설정의 메시지 배달 특성에 <화면 6>과 같이 지능형 메시지 필터 탭이 추가된다. 이 값을 정하기 전에 [메시지 차단하는 경우]에서 기본으로 선택되어 있는 [작업없음]을 그대로 두고 성능 모니터에서 [Total Messages Assigned an SCL Rating of X] 카운터들을 이용해서 전체적인 메시지의 SCL 단계를 모니터링한 뒤 메시지 차단 임계점을 정해야 한다.

<화면 6> 지능형 메시지 필터 탭

지능형 메시지 필터에는 게이트웨이에서의 차단을 구성하거나 정보 저장소 단계에서 정크메일로 분류하도록 구성할 수 있는데 그 내용을 살펴보면 다음과 같다.

◆ 게이트웨이 차단 구성 : 메시지가 들어오게 되면 SCL을 부여 받고 이 SCL은 게이트웨이 차단 구성의 [SCL 등급이 다음보다 크거나 같은 메시지 차단]에서 설정한 임계값 보다 높은지 낮은지를 판단해, 낮으면 게이트웨이를 통과해 사서함이 위치해 있는 서버의 정보 저장소로 전달되고, 높으면 [메시지를 차단하는 경우]에서 설정한 옵션대로 처리한다.

① 거부 : 게이트웨이에서 메시지를 거부한다. 익스체인지는 SMTP 세션 동안 메시지를 거부하므로 연결하는 SMTP 서버가 보낸 사람에게 NDR을 발송해야 한다.

② 보관 : 등급이 지정한 임계값 이상인 UCE로 표시된 모든 메시지를 보관한다. 보관된 메시지는 보관 디렉토리에 저장된다. 이 디렉토리는 SMTP 가상 서버 속성의 메시지 탭에서 지정한 큐 디렉토리의 루트 디렉토리에 있다. 기본적으로 보관 디렉토리는 Exchsrvr\Mailroot\vsi n\UCEArchive이며 여기서 n은 SMTP 가상 서버 인스턴스 번호이다. 메모장으로 열거나 MS 아웃룩 익스프레스를 이용해 보관 디렉토리에 있는 메시지를 검토할 수 있다. 합법적인 전자 메일 메시지가 보관돼 있는 것을 발견하면 해당 메시지를 Exchsrvr\Mailroot\vsi n\pickup 디렉토리로 이동해 다시 전송할 수도 있다. 그러면 SMTP 서비스가 전자 메일 메시지를 해당 사서함으로 배달한다. HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\ContentFilter 레지스트리 밑에 새로 만들기, 문자열 값 그리고 ArchiveDir를 입력한 다음 보관할 위치를 D:\ArchiveDir 등과 같이 변경할 수 있다.

③ 삭제 : 등급이 지정한 임계값 이상인 UCE로 표시된 모든 메시지를 삭제한다. 해당 메시지는 익스체인지에서 받아 삭제한다. 보낸 사람과 받는 사람 모두 해당 메시지가 삭제됐는지 여부를 알 수 없다.

④ 작업 없음: 작업 없음을 선택하면 등급이 지정한 임계값 이상인 UCE로 표시된 메시지에 대해 어떤 작업도 수행하지 않는다. 이 UCE 등급은 다른 메시지 속성과 함께 저장되며 이러한 속성은 해당 메시지와 함께 다른 익스체인지 서버에 전송된다. 익스체인지 사서함 서버는 UCE 등급과 정보 저장소 정크 메일 구성에서 지정한 설정을 사용해 메시지를 사용자의 받은 편지함으로 배달할 것인지 정크 메일 폴더로 배달할 것인지 결정한다.

◆ 정보 저장소 정크 메일 구성 : 게이트웨이 차단 구성을 통과한 메일들은 실제 자신의 사서함이 있는 저장소에 저장될 때 각 사서함에 존재하는 정크 메일 폴더에 저장될지, 아니면 받은 편지함으로 이동할지 여부를 결정해야 하는데, 이때 [정보 저장소 정크 메일 구성]의 [SCL 등급보다 크거나 같은 메시지 이동]에서 설정한 SCL 값에 따르게 된다. 즉 여기서 설정한 SCL 값보다 크거나 같으면 해당 사서함 내의 정크 메일 폴더로 이동하고 작으면 받은 편지함으로 간다. 기억해 둘 것은 SCL 값은 정수가 아니라 소수점까지 포함된 유리수라는 것이다. 이 값은 당연히 게이트웨이에서 설정한 차단 구성의 SCL 값보다 같거나 작아야 한다.

IMF를 통과한 메시지들은 x-sender, x-receiver 속성이 추가되며 기본적으로 X-SCL 속성은 확장되지 않는다. 이를 확장하기 위해서는 HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\ContentFilter에서 새로 만들기 → DWORD → ArchiveSCL라고 입력하고 DWORD 편집에서 1이라 입력한다. 만일 0이나 이 값이 없으면 헤더 정보에 X-SCL이 남지 않는다. 다음은 IMF에서 확장된 헤더 특성에 대한 예이다.

x-sender: bkuk@korea.com
x-receiver: administrator@numi.ne.kr
X-SCL: 6 90.64%

아웃룩의 스팸 필터 기능
앞서 설명한 것처럼 아웃룩도 내부적으로 스마트스크린 기술이 적용된 제품이기 때문에 SCL 값을 이용해 스팸 여부를 결정할 수 있다. 그러나 아웃룩 2003이 출시될 당시에는 위양성이 많았다. 정상 메일을 스팸 메일로 분류할 가능성이 매우 높았던 것이다. 이것은 스마트스크린이란 알고리즘이 영어를 기반으로 하고 있기 때문에 한글이나 중국어, 일본어와 같은 2바이트를 사용하는 동아시아권 메일에 대해서는 위양성이 많았던 것이다.

하지만 아웃룩은 보안 업데이트에서 제공된 새로운 필터링 알고리즘을 이용해 점점 똑똑해지고 있다(2003년 12월, 2004년 3월 그리고 9월에 업데이트됐다. 업데이트 다운로드는 support.microsoft.com/default.aspx?scid=kb;ko;872976을 참고). 그리고 베이지언 정리의 특성상 과거의 판단기준을 통해 새로운 데이터가 들어왔을 때 확률을 추론하는 것이므로 데이터가 많이 쌓이면 쌓일수록 정확도는 높아진다.

<화면 7> 아웃룩의 정크메일 옵션

스마트스크린 알고리즘이 설정된 아웃룩의 정크메일 판단 옵션을 보면 <화면 7>과 같다. 여기에는 차단 수준을 다음과 같이 네 단계로 구성하고 있다.

◆ 자동 필터링 사용안함 : 수신거부 목록에 있는 것만 정크 메일로 보냄
◆ 낮음 : SCL이 7 이상 스팸으로 인식하게 된다.
◆ 높음 : SCL이 4 이상 스팸으로 인식하게 된다.
◆ 수신허용 목록만 : [수신 허용-보낸 사람] 목록이나 [수신 허용-받는 사람] 목록에 있는 정보로부터 받는 메시지만 받은 편지함에 저장한다.

아웃룩은 자체적으로 블랙 리스트인 수신 거부 목록을, 화이트 리스트로는 수신 허용 보낸 사람 목록과 수신-허용 받는 사람 목록을 가지고 있어 SCL 여부에 관계없이 메시지를 분류할 수 있다. 사용자가 만든 규칙들 중 수신 허용-보낸 사람 목록과 수신 거부 목록들의 최대 크기는 510KB로 약 2000개의 항목이 들어가는데 레지스트리를 변경해 크기를 조절할 수도 있다. 이 목록은 텍스트 파일로 저장하거나 불러들일 수 있어, 목록들을 네트워크 파일 서버에 두고 주기적으로 업데이트해 개별 사용자들이 아웃룩에 추가하도록 하면 더욱 효과적이다. MAPI(Messaging Application Programming Interface)를 사용하고 있다면 아웃룩 2003과 OWA(Outlook Web Access) 간에 서로 동기화도 할 수 있다. 단 OWA는 파일을 보내거나 가져올 수 없다.

작동방법과 순서
필터링 적용방법
전역설정에서 설정한 보낸 사람 필터링, 받는 사람 필터링, 그리고 연결 필터링은 아주 간단한 방법으로 각 SMTP 가상 서버별로 <화면 8>과 같이 속성 탭의 IP 주소에 있는 고급의 구분정보 란에서 사용할지 여부를 결정할 수 있다.

<화면 8> 필터링 사용 여부 결정하기

하지만 IMF는 <화면 9>와 같이 독립적으로 인터페이스가 따로 구성돼 있어서 원하는 가상 서버를 선택할 수 있도록 되어 있다. IMF는 인터넷 메일을 주고받는 게이트웨이나 브리지해드 서버에만 설정하면 되고 사서함이 저장된 서버에서는 따로 설치할 필요가 없다.

<화면 9> 지능형 메시지 필터링 속성


필터링 동작 순서
각 필터링이 어떤 순서를 거쳐서 분류되는지에 대해서는 <그림 2>에 나와 있다.

① SMTP 서버가 익스체인지에 연결해 SMTP 세션을 시작한다.

② SMTP 세션 중 익스체인지는 다음 기준에 따라 [연결 필터링]을 적용한다.
◆ 연결 필터링이 전체 수락 목록을 확인한다. IP 주소가 전체 수락 목록에 있으면 다른 연결, 받는 사람 또는 보낸 사람 필터링은 적용하지 않고 메시지를 수락한다.
◆ 연결 필터링이 전체 거부 목록을 확인한다. 보내는 서버의 IP 주소가 전체 거부 목록에 있으면 메시지를 자동으로 거부하고 다른 필터는 적용하지 않는다.
◆ 연결 필터링이 구성된 공급자의 실시간 차단 목록을 확인한다. 보내는 서버의 IP 주소가 차단 목록에 있으면 메시지는 거부하고 다른 필터는 적용하지 않는다.

③ 익스체인지는 [받는 사람 필터링]에 등록한 목록에 받는 사람이 있는지 확인한다. 받는 사람이 필터링하는 전자 메일 주소와 일치하면 익스체인지는 해당 메시지를 거부하고 다른 필터는 적용하지 않는다.

④ 받는 사람 필터링이 적용되면 익스체인지는 [보낸 사람 필터링]으로 구성된 보낸 사람 목록에서 확인된 보낸 사람 주소를 확인한다. 보낸 사람이 보낸 사람 목록에 있는 주소와 일치하면 구성된 옵션에 따라 필터링하고 다른 필터는 적용하지 않는다.

⑤ 메시지가 연결, 받는 사람 또는 보낸 사람 필터링 별로 필터링하지 않으면 지능형 메시지 필터가 적용되고 게이트웨이에서 다음 둘 중 하나가 발생한다.

◆ 지능형 메시지 필터가 메시지에 게이트웨이 임계값보다 높은 SCL 등급을 매기면 지능형 메시지 필터는 적절한 게이트웨이 작업을 수행한다.
◆ 지능형 메시지 필터가 메시지에 게이트웨이 임계값보다 낮거나 같은 SCL 등급을 매기면 메시지는 사용자의 사서함 저장소를 사용해 익스체인지 서버로 전달된다.

⑥ 사용자가 아웃룩 2003 또는 익스체인지 2003용 OWA를 사용하고 있는 경우, 사용자의 사서함 저장소가 메시지 SCL 등급과 사용자가 구성한 저장소 임계값을 비교하면 다음 중 하나가 실행된다.
◆ 메시지 등급이 저장소 임계값보다 낮거나 같으면 사서함 저장소는 아웃룩 또는 OWA에서 구성한 사용자의 차단할 보낸 사람 목록을 확인하고 다음 중 하나가 발생한다.
◆ 메시지를 보낸 사람이 아웃룩 또는 OWA에서 구성된 차단할 보낸 사람 목록에 없거나 차단할 보낸 사람 목록이 사용 가능하지 않거나 정의돼 있지 않으면 메시지는 받는 사람의 받은 편지함으로 배달된다.
◆ 보낸 사람이 아웃룩 또는 OWA에서 구성된 차단할 보낸 사람 목록에 있으면 메시지는 사용자의 정크 메일 폴더로 배달된다.

⑦ 메시지 등급이 저장소 임계값보다 높으면 사서함 저장소는 아웃룩 또는 OWA에서 구성된 사용자의 수신 허용-보낸 사람 목록을 확인하고 다음 중 하나가 발생한다.
◆ 보낸 사람이 수신 허용-보낸 사람 목록에 있으면 메시지는 받는 사람의 받은 편지함으로 배달된다.
◆ 보낸 사람이 수신 허용-보낸 사람 목록에 없거나 수신 허용-보낸 사람 목록을 사용할 수 없거나 정의돼 있지 않으면 메시지는 받는 사람의 정크 메일 폴더에 저장된다.


<그림 2> 필터링을 통한 메시지 흐름

스팸과 필터링 기술 ‘창과 방패’
MS는 현재 스팸메일 발송자에 대해 현재 엄청난 금액의 손해배상 소송을 제기한 상태다. 스팸왕이라고 불리는 Stanford Wallace도 소송 기간동안 스팸메일을 발송하지 않을 것이라고 선포했다. 그러나 이것은 진정한 해결책이 되지 못한다. 스팸 메일 발송자에게 엄청난 금액의 소송을 제기하는 것은 일종의 본보기 역할을 하는 것일 뿐이다. 현재 스팸메일의 54%가 미국에서 발송되며 그 중에서도 플로리다 지역이 가장 많다고 한다(아이러니하게도 2004년 여름 허리케인이 미국을 강타했을 때 전세계로 발송된 스팸 메일 양이 엄청나게 줄었다).

스팸 메일은 앞으로도 존재할 것이다. 스팸 메일과 정상 메일을 판단하는 기준은 모두 사용자에 달려있기 때문이다. 어디까지가 마케팅 메일이고 어디까지가 스팸 메일인지 기준도 모호하다. 어쩌면 우리가 교통경찰관에 딱지를 떼는 것과 마찬가지로 앞으로는 스팸 발송자들에 대해서 간단하게 벌금이 부과될지도 모른다. 하지만 진보된 기술은 이런 소모적인 과정을 크게 줄여줄 수 있다. 즉 사용자의 사서함에 도달하기 전에 스팸일 가능성이 높은 것은 제거하거나 정크 메일로 걸러내 혹시라도 있을 위양성을 줄여줄 수 있다.

실제로 MS에서는 익스체인지에 이런 기술을 추가했다. [보낸 사람], [받는 사람], [연결 필터링] 그리고 컨텐츠 필터링 기능인 IMF까지 추가했고, 클라이언트에서는 아웃룩의 정크 메일 옵션에서 다시 한번 판단할 수 있는 도구를 집어 넣었다. 올해에는 스팸 방지 기능을 강화하기 위해 IMF v2와 익스체인지 서비스팩 2 그리고 진정한 SMTP 게이트웨이로써 역할을 수행할 에지(Edge) 서비스가 출시될 예정이다. @

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.
Posted by tornado
|

구병국 (익스체인지 사용자 그룹 대표시샵) 27/06/2005
연재순서
1. 스팸 메일 수렁에서 벗어나기
2. 웹으로 옮겨 온 아웃룩, OWA
3. 익스체인지 서버 2003과 ISA 서버 2004
MS 제품군의 가장 큰 장점은 서로의 제품들이 서로 상호연동을 염두에 두고 개발된다는 점이다.

특히 익스체인지 서버와 ISA 서버는 보안과 편의성, 성능 등 개발단계부터 상호보완을 염두에 두고 개발된 기능들이 많다. 메시지 스크리너나 OWA 폼 로그인 기능 등은 ISA 서버 2004를 도입하는 것만으로도 이전 버전의 익스체인지에 기능을 추가하는 역할을 하기도 한다. 익스체인지에 날개를 달아주는 ISA, 서버 활용법을 살펴보자.

필자는 까만 교복을 입었던 마지막 세대이다. 요즘은 대형 마트나 학교 근처 교복점에서 기성복으로 입는 것이 보통이지만 80년대 초반만 해도 중학교, 고등학교 그리고 남자와 여자의 구분만 있을 뿐 맞춤 형식으로 치수를 재고 나서 며칠 기다리면 교복을 입을 수 있었다. 물론 가격대도 만만치 않았지만 내 몸에 맞게 만들어진 유일한 옷인 만큼 편하고 활동하기에 좋았다.

서버 중에도 이처럼 다른 어떤 서버를 특히 배려해서 만들어진 제품들이 있다. 예를 들어 액티브 디렉토리(Active Directory)는 익스체인지 5.5의 디렉터리 서비스를 발전시켜 개발한 제품으로, 익스체인지 2000이나 익스체인지 2003을 효과적으로 관리하기 위해 필수 불가결한 요소다. 실제로 액티브 디렉토리를 공부해 보면 얼마나 많은 것들이 익스체인지를 위해 미리 배려됐는지를 알 수 있다.

여기에 또 하나 익스체인지 서버를 배려한 제품이 있다. 바로 ISA(Internet Security and Acceleration) 서버 2004이다. 마치 그 옛날 맞춤 교복처럼 기업의 네트워크 자원을 안전하게 보호하는 제품으로 특히 익스체인지 서버를 위한 기능을 여기저기에서 찾을 수 있다. 이번 호에는 ISA 서버 2004의 특징을 살펴보고 익스체인지를 위한 기능 중 ISA 서버에 포함된 OWA 서버 게시 기능을 예로 들어 알아본다.

ISA 서버와 익스체인지의 궁합
ISA 서버는 본래 MS 프록시 서버 2.0 시절부터 국내에 알려지기 시작했다. 1990년대 말 출시된 이후 주로 국내에 상주한 해외 기업이나 합작사 등에서 간간이 볼 수 있었다. 이 때 인기있었던 기능이 크게 두세 가지인데, 공인 IP를 하나만 쓰고 사설 IP를 여러 개 사용할 수 있는 NAT(Network Address Translation) 기능과 한 번 들어간 웹 사이트의 정보를 캐시에 보관해 놓고 클라이언트가 다음 번에 동일한 사이트에 접속할 때 프록시 서버가 캐시에 저장된 정보를 이용해 액세스 속도를 향상시키는 캐시 기능 그리고 들고 나는 패킷들를 제어할 수 있는 패킷 필터링 기능 등이다.

당시 필자도 직장에서 프록시 서버를 도입해 사용했는데 이 때만 해도 NAT, 캐시, 패킷 필터링 기능을 하드웨어가 아닌 소프트웨어로 구현했다는데 많이 놀랐다. 2000년 이후 MS는 프록시라는 애매한 단어 대신 이 서버의 역할을 직관적으로 알 수 있는 ISA(Internet Acceleration and Security) 서버로 변경했다. 기본적인 개념에는 변화가 없지만 프록시라는 작은 의미 대신 누구나가 해당 제품이 어떤 용도로 쓰일지 한눈에 알 수 있게 한 것이다.

또한 프록시 서버 시절에는 익스체인지에 대한 배려를 찾아볼 수 없었지만 ISA 2000 버전부터 익스체인지를 위한 기능들이 하나둘씩 추가되기 시작했다. 예를 들면 OWA 게시 기능과 메시지 컨텐츠나 첨부물에 대한 필터링을 포함하는 메시지 스크리너(Message Screener) 등이 그것이다. 하지만 이것만으로 익스체인지를 위한 배려라고 하기에는 사실 좀 낯간지러운 것이 사실이다.

그러나 ISA 2004 버전부터 익스체인지에 대한 본격적인 배려가 시작됐다. 또한 많은 기능들을 마법사로 쓸 수 있도록 해 IT 방화벽 제품들이 마법사를 이용해 규칙을 정하는 추세를 따랐으며 설정한 기능들도 한눈에 볼 수 있도록 UI를 변경했다.

ISA 서버 2004는 보안 기능과 사용의 편리성, 그리고 거의 대부분의 네트워크 자원에 안전하게 액세스할 수 있는 기능을 제공한다. 특히 OWA(Outlook Web Access), IIS(Internet Information Server), SPS(SharePoint Portal Server), 라우팅 및 원격 액세스 서버, 액티브 디렉토리 등 MS 애플리케이션을 실행하는 네트워크에 안성맞춤으로 개발됐다.

ISA 서버 2004에는 내외부의 공격을 다양한 애플리케이션 계층에서 인식하는 방화벽이 들어 있어 HTTP와 같은 인터넷 프로토콜을 세밀히 검사해 기존 방화벽이 발견하지 못하는 많은 위협들을 찾아낸다. ISA 서버의 통합 방화벽과 VPN 아키텍처는 모든 VPN 트래픽을 필터링하고 검사하며, 윈도우 서버 2003 기반의 격리 솔루션에 적합한 VPN 클라이언트 검사 기능을 지원해, VPN 연결을 통해 들어오는 공격으로부터 네트워크를 보호한다.

그 외에도 새로운 사용자 인터페이스와 마법사, 템플릿, 다양한 관리 도구들은 관리자들이 일반적인 보안 구성 오류를 범하지 않도록 지원한다. ISA 서버 2004는 윈도우 서버 2000 버전과 2003 버전에 설치할 수 있으나 2003 버전에 최적화돼 있다.

ISA 서버 2004의 주요 특징
ISA 서버를 구성하는 이유는 내부에 있는 네트워크를 더 안전하게 보호하고 캐싱 기능을 이용해 인터넷 액세스 속도를 높이며, 운영을 편리하게 하기 위해서다. <그림 1>은 ISA 서버 2004와 익스체인지 서버를 구성하는 일반적인 방법을 나타낸 것이다.

다양한 종류의 클라이언트들이 인터넷 통해 ISA 서버에 액세스하는데, ISA 서버는 미리 설정한 방화벽 구성 정책에 따라 해당 패킷들을 분석해 내부 네트워크에 패킷들을 전달하고 그 결과를 ISA 서버를 통해 다시 해당 장치로 전달하는 역할을 한다. 내부 사용자들은 원하는 프로토콜을 이용해 ISA 서버 2004를 거치지 않고 접속할 수 있으며 메일 관련 다양한 프로토콜에 대한 패킷을 지원하는 것도 특징이다. ISA 서버 2004의 주요 기능을 자세하게 살펴보자.

<그림 1> ISA 서버 2004와 익스체인지 서버를 이용한 접속 방법

OWA의 폼 기반 인증
지난 호에서 OWA의 폼 기반 인증화면을 변경하는 방법을 다뤄봤다. 원격 사용자들이 웹 브라우저를 통해 익스체인지 서버 2003에 액세스할 때 네트워크 인증을 할 수도 있지만 국내 정서상 네트워크 인증보다는 폼 기반 인증이 더 선호된다. 이 때 OWA 서버(클라이언트가 OWA를 통해 접속하려고 하는 서버)는 사용자에게 폼 기반 로그온 페이지를 생성해 보여준다. 사용자가 해당 페이지에 로그온 정보를 입력하면 OWA는 사용자 인증 후 로그온을 허용한다.

문제는 인증 프로세스가 진행되는 동안 인증되지 않은 사용자들은 OWA 서버에 직접 연결되어 있는데 이를 통해 OWA 로그인 페이지를 보여주는 서버가 익스체인지라는 사실이 드러난다는 점이다. 이 때문에 설사 인증 요청이 거부되더라도 일부 서버와 웹 사이트 컨텐츠에 액세스할 수 있게 된다. 따라서 사용자 인증 전까지는 이들이 OWA 서버에 액세스하지 못하도록 해야 한다.

ISA 서버 2004는 자체적인 OWA 로그온 폼을 생성해 이 문제를 해결한다. 원격에 있는 사용자가 폼 로그인 페이지에 액세스하기 위해 OWA 서버에 접속하는 대신, ISA 서버 2004 방화벽이 로그인 페이지를 만들고 사용자 인증을 OWA 서버에 전달하는 방식이다. 이런 과정을 거쳐야만 ISA 서버 2004가 OWA 사이트에 대한 액세스 권한을 부여하므로 인증되지 않은 사용자들은 OWA 서버에 액세스할 수 없다.

또 다른 이점은 익스체인지 서버의 모든 버전이 폼 기반 인증을 사용할 수 있다는 점이다. 익스체인지 서버 버전 5.5와 2000 서버는 물론 이전 버전의 익스체인지 서버를 사용하는 기업들도 ISA 서버 2004를 통해 폼 기반 인증을 사용할 수 있다.

강력한 RPC 필터
MAPI(Messaging API)를 사용하면 익스체인지의 모든 기능을 이용할 수 있어 생산성이 크게 향상되지만 RPC를 통해 연결하기 때문에 높은 네트워크 속도가 필요하고 관련된 여러 포트를 열어야 하는 번거로움이 있다. 우리나라는 세계에서 유래를 찾아보기 힘들만큼 높은 대역폭을 자랑하고 있으면서도 상대적으로 보안에 취약해 집에서 아웃룩 클라이언트가 회사나 IDC에 있는 익스체인지 서버에 MAPI로 연결할 수 있었다.

하지만 2003년 여름에 맹위를 떨쳤던 블래스터 바이러스 사태 이후 IDC에서 RPC 관련 포트를 일정기간 폐쇄했다. 그 결과 이전에 MAPI를 사용하던 사용자들은 더 이상 집에서 접속할 수 없게 됐다. 아웃룩 MAPI 클라이언트로 원격지에서 모든 익스체인지 서버 서비스에 안전하게 연결할 수 있는 방법이 없었기 때문에 원격 사용자들은 다른 전자 메일 클라이언트를 사용해야 했고 익스체인지 서버에 대한 만족도도 떨어졌다.

ISA 서버 2004는 RPC 필터를 이용해 방화벽을 통과하는 RPC 연결에 대해 애플리케이션 계층 검사를 실시함으로써 이 문제를 해결했다. 방화벽은 적법한 RPC 연결만 익스체인지 서버에 전달하고 인터넷 웜에 의한 연결 등 다른 모든 RPC 연결들을 해제한다. 회사 외부에서 일하는 사용자들은 이 기능을 이용해 아웃룩으로 익스체인지 서버의 모든 서비스를 이용할 수 있으며 직원들이 사무실에 있건 다른 나라에 있건 상관없이 언제 어디서나 아무런 문제없이 아웃룩을 실행할 수 있다.

메일서비스 관련 게시 마법사
익스체인지 서버가 제공하는 메일 서비스(OWA, SMTP,POP3, IMAP4 등)를 인터넷에 게시하면 외부에서도 얼마든지 서비스를 사용할 수 있다. 하지만 이런 인터넷 서비스를 공격의 수단으로 삼을 가능성이 있으므로 철저한 보안을 통해 게시해야 한다.

문제는 익스체인지 서버 서비스를 인터넷 기반 사용자들에게 안전하게 게시하도록 방화벽을 구성하는 작업이 매우 복잡하고 또 게시 규칙을 제대로 구성하지 못할 경우 예기치 못한 결과를 초래할 수 있다는 점이다. 이 때문에 익스체인지 서버 2003을 처음 설치하면 POP3와 IMAP4 서비스는 사용하지 않도록 기본 설정돼 있었다.

ISA 서버 2004 버전은 익스체인지 서버 서비스를 인터넷에 게시하는 작업을 간단하게 진행하는 세 가지 마법사 - OWA 게시 마법사와 보안 SMTP/POP3/IMAP4 게시 마법사, 메일 서버간 게시 마법사 - 를 통해 이런 문제를 해결했다(<화면 1>). 이 마법사를 이용하면 익스체인지 서버 서비스 게시 작업이 간소화돼, 생성된 방화벽 액세스 정책을 구현하기 전에 검토하고 필요시 손쉽게 변경할 수 있다.

<화면 1> 메일서버 게시 마법사

SMTP 메시지 스크리너를 이용한 필터링
ISA 서버 2004에는 들어오는 전자 메일과 나가는 전자 메일들의 특징을 분석해 스팸을 차단하는 SMTP 메시지 스크리너(Message Screener) 구성 요소가 들어 있다. 스크리너는 메일이 어디로 향하는지(대상), 어디서 왔는지(원본), 제목이나 본문에 관리자가 정의한 키워드나 문자열이 포함되어 있는지, 첨부 파일의 이름, 파일 유형 및 크기 등을 기준으로 판단한다.

SMTP 메시지 스크리너에 설정한 스팸 패턴과 일치하는 메일이 ISA 서버에 도착하면 해당 메시지를 삭제 또는 관리자에게 전달하거나 ISA 서버내 특정 폴더에 저장하도록 설정할 수 있다. 또한 첨부 파일의 특성을 지정해 메시지 스크리너로 필터링해 바이러스나 악성 소프트웨어가 메일을 통해 네트워크로 유입되는 것을 막을 수 있다.

SMTP와 POP3 필터
인터넷 서비스를 기반으로 공격하는 사람들은 익스체인지 서버의 SMTP와 POP3 메일 서비스를 손상시키기 위해 버퍼 오버런 공격을 사용한다. ISA 서버 2004의 지능형 애플리케이션 계층 필터링(Intelligent Application Layer Filtering)은 이들 서비스에 대한 버퍼 오버런 공격을 차단해 인터넷 침입자가 SMTP와 POP3 서비스를 제어하거나 중단시키지 못하도록 방지한다. SMTP 및 POP3 애플리케이션 계층 필터는 들어오는 모든 SMTP와 POP3 통신을 검사해 서비스를 손상시킬 가능성이 있는 모든 명령 시퀀스를 차단한다.

ISA 서버 2004를 이용한 OWA 게시
원격 사용자들은 HTTP를 사용해 익스체인지 서버에 액세스할 수 있는데 그때 사용하는 것이 OWA이다. 익스체인지 2003의 OWA는 이전 버전보다 아웃룩 2003과 비슷해졌고 기능적인 측면에서도 큰 발전이 있었다(본지 3월호 참조). ISA는 OWA 폼 기반의 로그인 형식을 별도로 제공해 인증받지 않은 클라이언트가 OWA 사이트에 액세스하는 것을 막는다. OWA 게시 순서는 일반적으로 다음과 같다.

[1] OWA 웹 사이트에 대한 인증서를 발급받아 게시

[2] OWA 웹 사이트 인증서를 파일로 구성(사이트의 개인키 포함)

[3] OWA 사이트가 SSL 암호화와 기본 인증을 하도록 구성

[4] OWA 웹 사이트 인증서를 ISA 서버 2004 방화벽의 컴퓨터 인증 서비스로 가져온다

[5] OWA 퍼블리싱 마법사를 실행

여기서는 [1]~[3]을 제외한 과정에 대해 자세하게 살펴본다(더 자세한 것은 연재 마지막의 참고서적과 링크를 참고하기 바란다). 먼저 OWA 웹 사이트 인증서를 ISA 서버에 가져오려면 ISA 서버의 인증서 스냅인을 열어야 한다(스냅인 추가/제거에서 ‘인증서’를 선택한 뒤 ‘컴퓨터 계정’과 ‘로컬 컴퓨터’를 선택한 다음 ‘확인’을 클릭한다).

이제 콘솔에서 ‘개인’을 선택하고 가져오기를 실행해 인증서 파일이 있는 경로로 찾은 후 암호를 입력하고 가져오기를 한다. 이제 ISA 서버 2004 관리 콘솔에서 ‘Firewall Policy’를 선택하고 오른쪽에 있는 ‘Tasks’ 탭에서 ‘Publish a Mail Server’를 클릭해 환영 페이지가 나타나면 규칙이름 란에 ‘Publish OWA Site’와 같이 OWA 서비스 게시에 관련된 것으로 쉽게 알 수 있도록 이름을 정하고 ‘다음’을 클릭한다.

<화면 1>과 같이 ‘Select Access Type’ 페이지가 나타나면 Web Client Access(Outlook Web Access), Outlook Mobile Access, Exchange ActiveSync를 선택하고 다음을 클릭해 ‘Select Services’를 연다. ‘Outlook Web Access’를 선택하고 다음을 누르면 ‘Bridge Mode’ 페이지가 나타나는데 여기서 ‘Secure connection to clients and mail server’를 선택한다. 이 옵션은 클라이언트가 OWA 웹 사이트에 연결할 때 SSL을 사용하도록 웹 게시 규칙을 설정하는 것이다. 이렇게 함으로써 정보가 노출되지 않고 암호화돼 전달된다.

이제 다음을 누르면 ‘Specified the Web Mail Server’ 페이지가 나타나는데 Web mail server 대화상자에 내부 OWA 웹 사이트의 이름을 입력한다. 예를 들어 owa.culminis.co.kr이라면 이 이름은 내부 네트워크에 있는 익스체인지 서버 사이트에서 사용하는 것으로 OWA 웹 사이트의 인증서에 나타난 일반적인 이름을 사용해야 한다. IP 주소를 사용할 수도 있지만 ISA 서버 2004 방화벽의 내부 네트워크 인터페이스와 익스체인지 OWA 사이트 사이의 SSL 연결에 문제가 발생할 수 있다.

이제 ‘Public Name Detail’ 페이지의 ‘Accept request for’란에서 ‘This domain name(type below)’를 선택한다. 여기서는 외부 사용자들이 OWA 웹 사이트에 접속할 때 사용하는 이름을 설정할 수 있는데 일반적으로 내부의 이름과 같으므로 ‘Public Name’ 항목에 owa.numi.ne.kr과 같이 입력하고 다음을 클릭한다. 그러면 ‘Select Web Listener’ 페이지가 나타나는데 여기서는 ISA 서버가 들어오는 웹 요청에 대해 청취할 IP 주소와 포트번호를 지정할 수 있다. ‘New’를 클릭하면 ‘New Web Listener Wizard’가 시작되며 다음과 같은 순서로 설정할 수 있다.

[1] ‘Web Listener name’ 상자에 이름을 지정한다. OWA SSL Listener와 같이 이름만 봐도 쉽게 알 수 있도록 설정하는 것이 좋다. 다음을 누르면 ‘IP Addresses’ 페이지 나타나고 여기서 ‘External’ 선택상자를 누르고 ‘Address’ 버튼을 클릭해 ‘Specified IP Addresses on the ISA Server Computer in the select network’를 선택한다. OWA 사이트로 들어오는 요청에 청취할 ISA 서버 2004의 외부 공인 IP를 선택하고 ‘Add’를 클릭한 후 OK 버튼을 누른다.

[2] ‘Port Specification’ 대화상자에서 ‘Enable HTTP’ 선택상자를 해제하고 ‘Enable SSL’ 상자를 클릭해 ‘Certificate’란에서 ‘Select’를 선택하면 ISA 서버 2004 컴퓨터에 설치된 인증서를 가져올 수 있다.

[3] 이제 마침을 클릭해 ‘New Web Listener Wizard’를 끝내면 <화면 2>와 같이 마법사에서 설정한 내용을 확인할 수 있다.

<화면 2> Select Web Listener 페이지

이제 ‘Edit’를 눌러 나타나는 앞에서 설정한 Listener 속성 페이지에서 ‘Preference’ 탭 ‘Authentication’ 버튼을 클릭해 인증 종류를 결정한다. 기본으로 선택된 것이 ‘Integrated’이므로 이를 해제하고 <화면 3>과 같이 OWA Forms-Based를 선택한다. OWA-Forms-Based 인증 기능은 ISA 서버 2004가 OWA 사이트를 위해 보안을 향상시킨 것이다.

방화벽은 로그온 폼을 생성해 사용자 인증을 제공한 후 성공적으로 인증을 한 경우에만 연결 요청을 OWA 사이트로 보낸다. 이를 통해 인증받지 않은 사용자가 OWA 사이트에 액세스하는 것을 막는다. 한 가지 주의할 점은 만약 ISA 서버 2004 방화벽에서 폼 기반 인증을 사용했다면 익스체인지 서버 2003의 OWA 사이트에서는 폼 기반 인증을 사용하지 않아야 한다는 점이다(익스체인지 2000이나 5.5는 폼 기반 인증을 지원하지 않으므로 상관없다).

<화면 3> 폼 기반 인증을 위한 대화상자


<화면 3>에서 ‘Configure’를 누르면 <화면 4>와 같이 ‘OWA Forms-Based Authentication’ 대화상자가 나타난다. 접속한 클라이언트가 공용인지 개인용인지에 따라 세션 시간을 달리 설정할 수 있는데 공용여부는 클라이언트가 폼 기반의 OWA 인증 페이지에서 선택할 수 있다.

공용 컴퓨터나 개인용 컴퓨터에 따라 첨부물의 처리도 달리 할 수 있다. 왜냐하면 공항의 키오스크(kiosk)와 같은 공용 컴퓨터에서는 첨부물을 열면 기본적으로 임시 인터넷 폴터에 해당 파일이 저장되므로 보안에 매우 취약하다. 따라서 각 컴퓨터의 특징에 따라서 첨부물을 허용할지 여부를 ‘Clients on public machines’, ‘Clients on private machines’에서 결정한다. ‘Log off OWA when the user leaves OWA Sites’는 사용자가 OWA가 아닌 다른 페이지로 이동했을 때 자동으로 로그오프되는 기능이다.

<화면 4> OWA Forms-Based Authentication 대화상자

이제 OK를 두 번 눌러 대화상자를 모두 닫으면 ‘OWA SSL Listener’ 속성 페이지가 나타난다. ‘확인’을 누르면 <화면 2>와 같이 ‘Select Web Listener’ 페이지로 돌아온다. 다음을 클릭해 ‘Users Set’를 선택하고 기본적으로 선택된 All Users를 그대로 둔다.

All Users가 선택되어 있더라도 모든 사용자가 OWA 사이트에 액세스할 수 있는 것을 의미하지는 않는다. 성공적으로 인증을 끝낸 사용자만 실제 OWA 웹 사이트에 액세스할 수 있는 것이다. 인증은 익스체인지 OWA 웹 사이트가 담당하고 ISA 서버 2004는 오직 인증을 전달할 뿐이므로 All Users라는 말은 익스체인지 OWA에 인증을 받은 사용자를 의미한다.

마지막으로 다음을 눌러 메일 서버 게시 규칙만들기 마법사를 종료한다. 그러면 관리 콘솔의 중간에 방금 만든 Publish OWA Site라는 규칙이 올라온다. 마우스 오른쪽 버튼을 누르고 ‘Properties’를 선택해 등록정보 대화상자를 열고 <화면 5>와 같이 ‘To’ 탭에서 ‘Request appear to come from the original client’를 반드시 선택한다. 이 옵션은 OWA 웹 사이트가 외부 클라이언트의 실제 IP 주소를 받을 수 있도록 하는 옵션으로, 이렇게 해야 OWA 웹 사이트에서 분석 도구를 이용해 해당 IP별 분석 보고서를 작성할 수 있다.

‘확인’을 눌러 규칙 등록정보 페이지를 닫고 ‘Apply’를 클릭해 해당 규칙을 ISA 서버에 적용하면 본격적으로 이를 사용할 수 있다.

<화면 5> Publish OWA Site 등록정보의 To 탭

ISA 서버 2004는 영문판이므로 모든 메시지가 영어로 돼 있다. 이를 한글로 바꾸려면 \Program Files\Microsoft ISA Server\CookieAuthTemplates 폴더의 Strings.txt를 수정해야 한다. <화면 6>처럼 한글로 된 OWA를 만들 수 있으며 이 폴더에 여러 파일을 변경하면 로그온 UI를 필요에 따라 변경할 수 있다(가능하면 익스체인지의 폼 로그인 페이지를 참조해서 정하는 것이 좋다. UI 변경은 본지 3월호를 참조한다). 한 가지 주의할 사항은 변경 전에 반드시 해당 폴더를 백업 받아야 하며, 또한 ISA 서비스팩 1을 패치하면 삭제되므로 적용전에 미리 이 폴더의 내용을 백업해야 한다.

<화면 6> 한글로 변경된 OWA 화면

ISA 2004를 이용한 메시지 스크리너 구성
SMTP 메시지 스크리너는 ISA 2004를 표준 모드로 설치할 때는 추가되지 않고 필요에 따라 인스톨하는 기능이다. 만약 익스체인지 서버 2003의 ‘연결 필터링 및 받는 사람 필터링’을 사용하고 있다면 메시지 스크리너가 이 기능을 방해할 가능성이 있으니 주의해야 한다. 메시지 스크리너는 ISA 서버가 아닌 다른 서버에도 설치할 수 있는데 이 때는 IIS 6.0이나 5.0 버전이 설치돼 있어야 하고 SMTP 서비스도 사용하도록 설정해야 한다. 즉 메시지 스크리너에서 메시지를 받아 규칙에 맞게 필터링한 후 다시 익스체인지 서버 등으로 보내는 일종의 메일 릴레이 기능이 필수적이다.

<그림 2> 메시지 스크리너 기능

<그림 2>는 ISA 서버에 메시지 스크리너 기능을 사용한 예이다. 이렇게 구축하려면 먼저 ISA 서버에 SMTP 서비스를 설치하고 메일 릴레이 설정한다. 이후 ISA 서버에서 메일 서버를 게시하고 메시지 스크리너에 맞는 설정을 하면 필터링 기능이 작동되고, 필터링한 메시지만 내부 네트워크에 존재하는 익스체인지 서버에 배달된다. 메시지 스크리너를 설정하는 첫 단계는 ISA 서버 위에 SMTP 가상 서버를 설치하는 것이다. 여기서 SMTP 메시지 스크리너와 함께 들어오는 이메일 메시지에 대해 실제적인 필터링을 담당한다.

[1] 인터넷 정보 서비스(IIS) 스냅인을 시작해 기본 SMTP 가상서버로 이동한다.

[2] ‘도메인’ 폴더에서 마우스 오른쪽을 클릭하고 ‘새로 만들기’를 선택한 뒤 ‘원격’을 선택한다.

[3] 익스체인지 서버에서 사용하는 도메인 이름을 culminis.co.kr이라고 입력한다.

[4] 새롭게 만들어진 도메인에서 마우스 오른쪽을 클릭해 ‘속성’을 선택하면 해당 도메인 등록정보가 나타난다.

[5] ‘일반’ 탭에서 <화면 7>과 같이 ‘받는 메일을 이 도메인으로 릴레이할 수 있음’을 선택하고 ‘확인’을 누른다. 도메인 라우팅에서 ‘모든 메일을 스마트 호스트로 전달’을 선택하고 전달할 익스체인지 서버의 FQDN이나 IP 주소를 <화면 7>처럼 입력한다.

<화면 7> 원격 도메인 등록정보 대화상자

[1] SMTP 가상 서버에서 마우스 오른쪽을 클릭하고 속성을 선택해 대화상자를 연 뒤 ‘액세스’ 탭에서 ‘릴레이’를 선택한다.

[2] ‘릴레이 제한’ 대화상자에서 ‘추가’를 선택하면 ‘컴퓨터’ 대화상자가 나타나고 여기에 ‘단일 컴퓨터’를 클릭한 후 익스체인지 서버의 IP 주소를 입력한다. 이렇게 하면 나가는 메일에 대해서는 익스체인지 서버에서 배달한 메시지만 릴레이된다. 물론 나가는 메일도 ISA 서버를 통해 나가야 하므로 나중에 액세스 규칙을 만들어야 한다.

이제 ISA 설치 프로그램을 실행해서 ‘Program Maintenance’ 대화상자의 ‘Modify’를 클릭한다. <화면 8>과 같이 ‘Custom Setup’ 대화상자가 나타나면 ‘Mesage Screener’를 선택하고 마우스 오른쪽을 클릭한 후 ‘This feature will be installed on local hard disk’를 선택한다. 이제 메시지 스크리너 기능이 설치된다.

<화면 8> 메시지 스크리너 프로그램 설치 대화상자

메시지 스크리너는 SMTP 서버 게시 규칙을 통해 작동되므로 SMTP 서버 게시 규칙을 만들어야 한다(이것은 ISA 서버의 공인 IP에서 들어오는 SMTP 메시지를 듣는데 사용된다). ISA Server Management 콘솔에서 SMTP 서버를 게시한다. 먼저 콘솔에서 ‘Firewall Policy’를 선택하고 오른쪽에 있는 ‘Tasks’ 탭에서 ‘Create Server Publishing Rule’을 클릭한다.

환영 페이지에서 규칙이름을 정하는데 Inbound SMTP Relay와 같이 그 용도를 알 수 있도록 정하는 것이 좋다. 다음을 클릭하면 Select Server 페이지가 나타나는데 ISA 서버의 사설 IP 주소를 입력하고 다음을 클릭한다. Select Protocol 페이지의 ‘Selected Protocol’ 목록에서 ‘SMTP Server’를 선택하고 다음을 누른다. IP Address 페이지에서 ‘External’을 선택하고 ‘Address’ 버튼을 누른 후 <화면 9>와 같은 External Network Listener IP Selection 대화상자에서 ‘Specified IP Addresses on the ISA Server Computer in the selected network’를 선택하고 규칙에 사용할 외부 IP 주소를 선택한다. OK를 누른 뒤 다음을 클릭하고 마침을 누른다.

<화면 9> External Network Listener IP Selection 대화상자

이제는 메시지 스크리너가 특정 항목에 대해서 필터링하도록 구성하는 작업이 남았다. 이것은 ISA Server Management 콘솔에서 Configuration을 확장하고 Add-ins를 클릭해서 할 수 있다. 먼저 ‘Applications Filters’ 탭에서 SMTP Filter를 더블클릭해 ‘SMTP Filter’ 속성 대화상자를 열고 ‘General’ 탭에서 ‘Enable this filter’를 선택한다. Keywords, Users/Domains, Attachments 탭에서 필터링할 메시지의 특징을 설정한다.

예를 들어 Keyword 탭에서 ‘Add’를 선택하면 나타나는 ‘Mail Keyword Rule’에서는 <화면 10>과 같이 키워드를 입력하고 키워드가 위치할 곳이 메시지의 제목인지 본문인지 지정하고 이에 해당하는 메시지가 들어오면 필터링할 행동을 지정한다. 메시지를 삭제할지 보관할지 아니면 특정 사람에게 전달할 지를 정할 수 있다. 또한 ‘Hold Message’를 선택하면 필터링 된 메시지는 SMTP 루트 디렉터리의 Badmail 폴더에 저장된다.

<화면 10> Mail Keyword Rule 대화상자

Users/Domain 탭에서는 스팸을 보내는 사용자 또는 도메인을 등록해 해당 사용자나 도메인이 보내는 메시지를 받지 않도록 설정한다(익스체인지 2003의 ‘보낸 사람 필터링’과 같은 기능이다). Attachment 탭을 클릭해 ‘Add’를 선택하면 <화면 11>과 같이 ‘Add Attachment Rule’ 대화상자가 나타난다. 여기에서 첨부물의 이름 또는 확장자 종류, 첨부물의 크기별로 지정할 수 있다. 보통 바이러스 메일은 첨부물로 오기 때문에 여기서 필터링을 구성할 수 있으며 필터링 후에 어떻게 행동할지도 설정할 수 있다. 모든 규칙을 만들었으면 관리 도구에서 ‘Apply’를 눌러 실제 규칙을 적용한다.

<화면 11> Mail Attachment Rule 대화상자

SMTP 메시지 스크리너의 동작에 대한 로그는 ISA 2004 관리 콘솔의 왼편에 있는 모니터링을 클릭한다. ‘모니터링’ 노드에서 마지막에 있는 ‘Logging’ 탭을 선택한 후 오른편에 ‘Configure SMTP Message Screener Logging’을 선택하여 대화상자를 연다. <화면 12>와 같은 대화상자에서 ‘File’을 선택하고 ‘Format’ 목록에서는 ‘ISA Server File Format’을 선택한 다음 ‘Enable logging for this service’가 선택돼 있는지 확인한다.

<화면 12> SMTP Message Screener Logging 속성 대화상자

버릴 것이 없는 종합선물셋트
군대를 다녀왔거나 어린 시절을 기억하고 있는 사람이라면 ‘종합선물셋트’라는 것을 알 것이다. 다양한 먹거리가 있어 먹고 싶은 것부터 손이 가게 마련이다. MS의 제품들도 마찬가지다. 오피스 같은 개인용 소프트웨어에서 서버용 제품에 이르기까지 다양한 제품이 발매되고 있다.

일부에선 종합선물셋트란 일년동안 잘 팔리지 않는 것을 포장만 멋지게 해서 연말에 재고처리하는 방법이라고 하지만, MS 제품들은 겉은 종합선물셋트의 형태지만 제품들 하나하나가 상호연동된다는 강점을 갖고 있다.

이번 호에 살펴본 것은 ISA 서버와 익스체인지 서버에 대한 일부분에 불과하지만 세부적으로 보면 서로의 제품군에 대해 얼마나 크게 배려하고 있는지 알 수 있다. 메시지 스크리너나 OWA 폼 로그인 같은 것은 이전 버전의 익스체인지에서 지원하지 않는 기능인데 ISA 서버 2004를 도입하는 것만으로도 이런 기능을 추가할 수 있다. 상호연동하면서 겹쳐지지 않는 투자가 가능하다면 기업의 최고기술운영자(CTO)들도 관심을 가질만 하지 않을까.@

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.
Posted by tornado
|
구병국 (익스체인지 사용자 그룹 대표시샵) 24/06/2005
연재순서
1. 스팸 메일 수렁에서 벗어나기
2. 웹으로 옮겨 온 아웃룩, OWA
3. 익스체인지 서버 2003과 ISA 서버 2004
익스체인지 관리자들은 아웃룩의 문제를 호소하는 직원들의 요청을 종종 듣곤 한다. 이런 작업은 매우 단조롭고 반복적인 업무지만 최근 기업 환경이 언제 어디서든 메일을 사용해야 하는 상황이 되면서 더욱 체계적인 대안을 고민해 볼 시점이다.

그렇다면 과연 어떤 방법이 있을까. 웹으로 아웃룩과 거의 흡사한 기능과 인터페이스를 구현한 OWA는 가장 적합한 대안 가운데 하나다.

노련한 익스체인지 관리자라면 반복적이고 단조로운 업무는 가능한 한 줄이려고 할 것이다. 실제로 익스체인지 관리자들의 일상 업무 중 70~80%는 일반 클라이언트의 문의에 응대하는 것이라고 한다. 일반적으로 워드프로세서나 스프레드시트에 문제가 생기면 사용자 스스로 해결책을 찾는 경우가 많다.

하지만 아웃룩에 문제가 생긴다면? 십중팔구 익스체인지 관리자부터 찾는다. 때론 직접 찾아와 따지기도 한다. 이 때문에 익스체인지 관리자들은 시시콜콜한 물음부터 새로운 응용 프로그램을 개발하는 복잡한 문제까지 다양한 요구사항을 처리하는 데 많은 시간을 소비한다. 특히 국내에는 기술 지원부서를 따로 두고 이런 문제들을 해결하는 기업이 거의 없어 결국 익스체인지 관리자는 사용자들의 이용 문제를 해결하기 위해 정작 중요한 업무를 처리하지 못하는 상황에 직면해 있다.

그러나 최근의 기업 환경은 노트북을 들고 외근을 하거나 출장을 갔을 때도 항상 회사 메일을 열람할 수 있어야 한다. 긴 연휴에 외국으로 여행을 간 경우에도 메일을 확인해야 하는 경우가 많다. 앞서 언급한 일상 업무들은 익스체인지 관리자들에게 매우 반복적인 것이 분명하지만 이러한 기업 환경의 변화를 고려하면 익스체인지 관리자와 사용자 사이의 문제라기보다는 기업 환경이 변화하는 가운데 이 문제에 대한 근본적인 대안을 고민해야 하는 시기인 것이다. 그렇다면 과연 방법은 없을까.

이에 대한 한 가지 대안이, 전통적인 MAPI(Messaging API)로 사서함에 연결하는 대신 POP3, IMAP 4, HTTP 등을 이용해 익스체인지 사서함에 액세스하는 방법이다. 그러나 POP3는 받은 편지함에만 액세스할 수 있어 제한이 있고 IMAP4는 설정이나 메일을 받는 방법이 일반 사용자들에게 다소 낯설다.

그렇다면 만약 HTTP 프로토콜로 익스체인지 사서함에 엑세스할 수 있다면 어떨까. 이것이 가능하다면 인터넷에 연결된 곳이라면 언제 어디서든 웹 브라우저를 통해 사서함과 공용 폴더에 액세스해 메일을 보내고 일정을 관리하며 작업이나 연락처 등 여러 가지 일을 처리할 수 있을 것이다. 실제로 이를 지원하는 것이 바로 OWA(Outlook Web Access)이다. 이를 이용하면 회사내부와 거의 똑같은 기능과 사용자 인터페이스(UI)로 언제 어디서든 익스체인지 서버에 액세스할 수 있다.

물론 OWA에도 단점은 있다. 익스체인지 2003 버전 이전까지는 자체 인터페이스나 기능을 수정하기 매우 까다로웠고 설사 수정했다 해도 만족할 수 있는 수준의 성능이 나오지 않았다. 또한 인터페이스도 아웃룩과 달리 매우 투박해 메일을 열어보고 보내는 정도의 작업에만 적합했다. 이 때문에 대부분의 사용자들이 회사 내에서는 OWA 대신 아웃룩을 사용하곤 했다.

그러나 익스체인지 2003 버전이 발표되면서 많은 사항이 개선됐다. 인터페이스가 변한 것은 물론 기능적인 측면에서도 많은 사항이 추가됐고 다양한 커스터마이징 기능까지 지원한다. 이번 강좌에서는 익스체인지 2003 버전을 중심으로 관리자들이 참고할 수 있는 커스터마이징 기능에 대해 살펴보자.

시행착오의 시간들
OWA를 처음 선보인 것은 익스체인지 5.0 버전이지만 본격적으로 알려진 것은 5.5 버전부터다. 익스체인지 5.5는 ASP(Active Server Page)와 자바스크립트, CDO(Collaboration Data Objects)를 이용해 익스체인지 Information Store와 디렉토리 서비스에 MAPI로 연결하는 구조로 돼 있다. 즉 IIS와는 HTTP로 연결되지만 IIS에서 MAPI 세션을 이용해 익스체인지 서버에 액세스했다. 따라서 OWA를 실행하고 있는 단일 서버는 많아야 수백 개의 OWA 클라이언트에만 서비스할 수 있었으며, 제한된 숫자의 클라이언트만을 지원하는 ASP의 한계로 병목현상이 나타나곤 했다.

또한 IIS와 ASP 엔진의 메모리 누수를 비롯해 여러 가지 문제점을 안고 있었다. 운영체제를 윈도우 2000으로 업그레이드하고 서비스 팩을 설치하면 어느 정도 막을 수는 있지만 메모리의 문제점은 여전했다. UI에서도 사용자 편의보다는 웹 메일 기능 하나만을 지원하겠다는 생각으로 만든 인상이 컸다. 일부 기업들은 ASP를 수정해 사용하기도 했지만, ASP 파일을 수정해 OWA를 구성하면 성능에 문제가 생기는 경우가 많아 쉽게 손을 대지 못하고 로그온 페이지 정도만 수정해 사용했다.

이와 같은 OWA는 익스체인지 2000 버전에서 큰 변화를 맞는다. 여기에는 여러 가지 이유가 있었지만 무엇보다 사용자들이 점점 웹 환경에 익숙해지고 있는 추세를 반영한 측면이 가장 크다. 과거 클라이언트/서버 환경이 점차퇴조하고 웹 브라우저를 이용해 어디서든 로컬과 마찬가지로 메시지에 액세스할 수 있는 기능이 필요해진 것이다.

새롭게 발표된 익스체인지 2000은 이전에 핵심 전송 프로토콜로 사용하던 X.400에 기초한 MTA를 버리고 SMTP를 주요 프로토콜로 채택했다. 이것은 본격적으로 인터넷 프로토콜 환경으로 돌아섰음을 의미하는 매우 중요한 변화로, 이제 익스체인지는 IIS에서 MAPI로 익스체인지 서버에 액세스하는 이전 방식 대신 WebDAV를 사용하고 아키텍처에도 큰 폭의 변화를 주었다.

사용자들은 WebDAV를 이용해 문서관리, 파일 잠금, 문서 특성 액세스, 폴서 생성 등 다양한 기능을 사용할 수 있게 됐으며 XML과 DHTML을 지원해 클라이언트의 기능과 성능도 큰 폭으로 향상시켰다. 당시 MS는 익스체인지 2000 OWA를 개발하면서 다음과 같은 목표를 갖고 있었다.

[1] URL로 저장소에 있는 각 개체들에 접근할 수 있어야 한다
익스체인지 5.5는 각 개체들이 GUID(Globally Unique IDentifier)로 연결돼 있어 각 개체에 대한 액세스가 거의 불가능했다. 따라서 이를 URL로 쉽게 접근할 수 있도록 하는 것이 첫번째 목표였다. 익스체인지 2000 서버부터는 사서함 내에 있는 각 개체를 URL로 액세스를 할 수 있게 됐다(예를 들면 https://vpctemplate.numi.ne.kr/exchange/administrator/ 받은%20편지함/기초.eml/?cmd=open과 같다).

[2] 안정적으로 더 많은 클라이언트를 수용해야 한다
익스체인지 2000부터는 ASP에서 IIS 응용 프로그램에 의해 컴파일된 형태로 코드가 바뀌었다. 이제 브라우저는 WebDAV를 이용해서 익스체인지와 통신을 하게 되므로 훨씬 안정적으로 더 많은 사용자들이 사용할 수 있게 됐다. 또한 각자의 역할에 따라 프런트엔드 서버(FE)와 백엔드 서버(BE)로 구분했다.

이전 버전은 OWA가 IIS에서 접속한 후 MAPI를 통해 각자 사서함에 접속, 메일을 가져와 다시 HTTP로 전달하는 일종의 프록시로서의 역할을 했지만 FE와 BE의 환경이 되면서 모든 역할을 분산 처리하게 됐다. 프런트앤드 서버가 OWA 연결을 받고 그것을 다시 실제 사서함이 있는 백엔드 서버로 HTTP를 통해 연결하므로 더 많은 클라이언트를 수용할 수 있게 된 것이다.

[3] 인터페이스를 아웃룩과 유사하게 개선한다
당시에는 아웃룩 2000과 유사하게 만드는 것이 목표였다. 낮은 대역폭에서 접속해도 응답속도를 높일 수 있도록 하기 위해 필요없는 프레임이나 그래픽 요소들은 과감하게 삭제했으며, 사용자 인터페이스의 핵심적인 구성을 제공해 주는 폴더 목록과 같은 새로운 컨트롤들을 추가해 서버와의 불필요한 통신을 줄였다.

그리고 익스체인지 2003 OWA
한편 이후 버전인 익스체인지 2003에서는 한 단계 더 발전하게 된다. 당시 2003 OWA의 디자인을 오피스 아웃룩 팀과 긴밀한 협의를 통해 개발했다는 이야기도 있고 아예 디자인 자체를 맡겼다는 말도 있다. 실제로 OWA 2000과 2003을 비교해 보면 디자인 자체가 완전히 새롭게 변화됐으며 아웃룩 사용자에 대한 배려가 강화됐음을 알 수 있다.

즉 인터페이스에 있어서는 완전히 새로운 제품이 된 것이다(실제로 필자가 알고 있는 기업 가운데 OWA의 인터페이스 디자인을 보고 도입한 곳도 몇 군데 있다. 그들 대부분은 아웃룩 XP를 사용하고 있었으며 익스체인지를 도입하려고 준비하고 있었는데 RC 버전의 OWA를 보고 익스체인지 2003을 도입하기로 결정했다. 인터페이스의 중요성은 아무리 강조해도 지나치지 않다).

성능에 있어서도 큰 변화가 있었다. 이전에는 단지 웹상에서 메시지를 주고 받는 것에 머물렀다면 이제는 아웃룩에서 하는 대부분의 작업이 OWA에서도 가능하게 됐다.

하지만 실제 아키텍처를 보면 익스체인지 2003과 익스체인지 2000의 구조와 거의 비슷하다. <그림 1>은 익스체인지 OWA 2003의 구조를 나타낸 것이다. IIS 서버와 익스체인지 서버 간에 통신을 처리하는 ISAPI 필터로 exchfilt.dll 대신 DAVEx.dll을 사용한다. 물론 FE와 BE 구조를 가지고 있을 경우에는 FE에서 EXProx.dll이 요청을 받아 BE에 있는 DAVEx.dll로 전달한다.

DAVEx.dll은 GET과 POST 요청을 처리해 IIS와 익스체인지 IS 사이에 중간연결을 담당하는 ExIPC(Exchange Inter-Process Communication)로 전달하고, 그 후 ExOLEDB(Exchange Object Linking and Embedding Database)를 통해서 저장소 데이터로 전송된다.

<그림 1> OWA의 구조

익스체인지 2003에는 다음과 같은 새로운 기능들이 추가됐다.

◆ IE 5.01 이후 버전에는 훨씬 고급의 인터페이스를 채택해 언듯 보면 아웃룩 2003과 구별이 쉽지 않을 정도이다.
◆ 폼 로그인을 지원해 로그온 페이지를 쉽게 수정할 수 있다.
◆ S/MIME에 대한 컨트롤을 제공한다.
◆ 정크메일에 대한 방어 기능을 제공한다.
◆ 미리보기 기능을 제공한다.
◆ 찾기 기능이 향상됐다.
◆ 맞춤법 검사 기능이 추가됐다.

익스체인지 2003 가상 디렉토리의 구성  
기본적으로 익스체인지 2003을 설치하면 IIS의 기본 웹사이트에 몇 개의 가상 디렉토리가 만들어진다. 예를 보면 다음과 같다(여기서 도메인 이름은 numi.ne.kr로 한다).

◆ Exchange
이것은 \\.\BackOfficeStorage\numi.ne.kr\mbx로 맵핑돼 있으며 사서함에 액세스할 수 있도록 해준다. \\.\BackOfficeStorage는 Exchange를 하나의 드라이브로 보이도록 하는 ExIFS(Exchange Installable File System)의 일부로 표시되는 것이다.

◆ ExchWeb
\Exchsrvr\Exchweb 디렉토리에 연결되어 있는데 이 디렉토리에는 XML, 스타일 시트, 그래픽, 언어, 그리고 컨트롤들이 포함돼 있다. 사실 OWA를 커스터마이징을 한다는 것은 이 디렉토리에 있는 부분을 손댄다는 것을 의미한다고 해도 과언이 아닐 정도로 중요한 디렉토리인데 여기에는 다음과 같은 하위 디렉토리가 있다.

○ 6.5.6944.0 : 자바스크립트, CSS, Htc 등 OWA를 나타내기 위한 각종 컨트롤이 존재한다(서비스팩이 설치될 때마다 추가적으로 늘어날 수 있다).
○ bin : 각 클라이언트의 언어별로 로그인 및 로그오프 시에 나타낼 페이지가 저장돼 있다. 폼 로그인 페이지를 변경해야 할 경우 이 파일에 있는 언어별로 나누어진 디렉토리에 포함된 logon.asp 파일을 수정하면 된다.
○ help : 각 언어별 및 IE 버전별로 나타낼 도움말 내용을 저장하고 있다.
○ img : OWA를 구성하는 이미지들을 모은 디렉토리이다. 여기에 있는 모든 파일은 GIF 형식으로 돼 있으며 522개를 가진다.
○ theme : 각 테마 별로 각기 다른 색으로 OWA를 표시하기 위해 저장돼 있는 형태이다. 뒷부분의 테마 바꾸기를 참고하라.
○ view : OWA 데이터를 나타내기 위한 XML 스타일 파일을 저장하고 있다.

◆ Public
\\.\BackOfficeStorage\numi.ne.kr\Public Folder에 맵핑돼 있으며 기본 공용 폴더를 나타낸다. 이것도 또한 ExIFS를 통해서 접근할 수 있다.

◆ Exadmin
\\.\BackOfficeStorage로 맵핑돼 있으며 익스체인지 2003에서는 시스템 매니저에서 공용 폴더를 나타낼 때 사용된다.

◆ OMA
\Exchsrvr\OMA\Browse 폴더로 맵핑돼 있으며 OMA(Outlook Mobile Access) 클라이언트가 액세스할 때 사용된다.

◆ Microsoft-Server-ActiveSync
\exchsrvr\OMA\Sync 폴더에 맵핑돼 있으며 OMA 클라이언트가 Active Sync 기능을 사용할 때 이용된다.


OWA 세계로 들어가는 첫관문
OWA를 사용하려면 항상 http://서버이름/exchange나 http://서버이름/public과 같은 형태의 URL을 사용해야 한다. 하지만 일반적인 사용자가 현재 자신이 사용하고 있는 메시징 시스템이 익스체인지인지 아닌지 알 필요는 없다. 오히려 http://서버이름/mail처럼 기억하기 쉬운 이름을 사용하는 것이 편리하다.

공용 폴더도 마찬가지이다. 어떤 경우에는 루트 폴더부터 전체를 나타낼 필요가 있겠지만 익명의 사용자가 쓸 수 있는 게시판을 만들었을 경우(매우 극단적인 사례다) 공용 폴더의 전체 구조를 외부에 노출시킬 필요는 없다. 이럴 땐 하나의 공용 폴더만 떼어 내 OWA로 바로 접속하도록 하면 편리하다. 이를 위해서는 다음과 같이 작업하며 된다.

[1] 익스체인지 시스템 매니저를 열고 게시하기 원하는 서버로 간다. 프로토콜에서 ‘HTTP’를 선택한다.

[2] ‘Exchange 가상 서버’를 선택하고 마우스 오른쪽을 클릭해 ‘새로 만들기’와 ‘가상 디렉토리’를 선택한다.

[3] <화면 1>와 같이 가상 디렉토리 속성 대화상자가 나타나면 ‘이름’란에 원하는 디렉토리 이름을 부여할 수 있다. 만약 사서함에 액세스할 때 ‘/exchange’외에 다른 이름을 사용하고 싶다면 SMTP 도메인용 사서함을 선택하면 된다. 만일 다수의 도메인을 사용하고 있는 환경(미리 DNS와 받는 사람 정책에 설정해야 한다)이라면 ‘수정’을 선택해 다른 도메인 이름을 선택할 수 있다. 그러면 특정 도메인만 해당 가상 디렉토리를 이용하도록 설정할 수 있다. 기본 값을 사용하면 다른 도메인도 새롭게 만든 가상 디렉토리를 이용할 수 있다.

[4] 공용 폴더의 경우 게시하기 원하는 공용 폴더를 만들고 적당하게 클라이언트 권한을 부여한 다음 이와 같은 순서로 가상 디렉토리를 만든다. 이 때 익스체인지의 경로를 SMTP 도메인용 사서함 대신 공용 폴더로 선택하면 도메인 이름 대신 ‘공용 폴더’로 바뀌게 된다. 그러면 ‘수정’을 눌러서 원하는 공용 폴더를 선택할 수 있다.

이제 사서함에는 http://서버이름/mail로 접속할 수도 있고 /exchange로 할 수도 있으며 customer라고 하는 공용 폴더에는 http://서버이름/service로 접속할 수 있게 됐다.

<화면 1> OWA 가상 디렉토리 생성 대화상자

익스체인지 5.5의 OWA 이후 익스체인지 2000이 되면서 가장 절실하게 필요하던 것이 아마 폼 로그인일 것이다. 특히 우리나라의 경우 익스체인지 2000이 설치된 회사에서 OWA로 접속했을 때 나타나는 네트워크 로그인 창 때문에 사용자들의 반감은 매우 심했다. 대부분의 웹페이지에서 ID와 암호를 입력하는 폼 기반을 사용해 왔기 때문이다.


물론 익스체인지를 사용하는 큰 기업이나 인터넷 서비스 업체들은 자체적으로 폼 로그인을 만들어서 사용했지만 일반적인 중소회사에서는 쉽지 않았다. 이에 따라 MS는 익스체인지 2003 버전부터 폼 기반의 인증(또는 쿠키를 이용한다고 해서 ‘쿠키 기반의 인증’이라고도 한다)을 선택사항으로 채용했다. 단, 윈도우 서버 2003 위에 설치해 실행해야 한다.

폼 기반의 인증은 SSL(Secure Socket Layer)을 사용하므로 HTTP 가상 서버에 서버 인증서를 설치해야 한다. 그 이후에 익스체인지 시스템 매니저를 이용해 익스체인지 가상 서버에 접속한 다음 마우스 오른쪽을 클릭해 ‘속성’을 선택해 ‘Exchange 가상 서버 속성’ 대화상자를 연다. 여기서 ‘폼 기반 인증 사용’을 선택하면 ‘압축’ 정도를 선택할 수 있다.

그러면 익스체인지 서버 2003은 메시지와 사용자의 받은 편지함 목록과 같은 DHTML 코드뿐만 아니라 1KB 이상 되는 스타일 시트와 스크립트들을 압축해 전송한다. 이 알고리즘은 GZIP 압축방법을 사용하므로 IE 6.0 이후 버전부터 사용할 수 있다. 이제 ‘확인’을 누르면 IIS 서비스와 SSL을 설정하라는 메시지가 나타난다.

폼 기반 인증을 사용하도록 설정을 마쳤으면 <화면 2>와 같이 SSL을 이용해 https://서버이름/exchange의 형태로 접속할 수 있다(이것은 \exchsrvr\Exchweb\bin\auth\kor 디렉토리 안에 있는 logon.asp 파일로 나타난다).

<화면 2> OWA 폼 로그인 페이지

여기에서 사용자 이름은 도메인 이름\사용자 이름으로 넣을 수 있으며 UPN(User Principle Name)을 그대로 사용할 수도 있다. 도메인이 하나라면 <화면 3>과 같이 익스체인지 가상 디렉토리에서 기본 도메인을 설정해 일일이 도메인 이름을 입력하지 않도록 설정할 수 있다.

<화면 3> 기본 도메인 설정하기

이밖에도 클라이언트 란에는 기본 환경과 고급 환경 두 가지를 선택할 수 있는 옵션이 있다. 기본 환경을 선택하면 IE 5.01 이하 버전으로 접속한 것과 같은 페이지가 나타나는데 DHTML과 XML을 사용할 수 없는 기능상의 제약이 있다. 기본 옵션은 고급 환경이며 이것이 바로 우리가 일반적으로 OWA 2003이라고 부르는 화면이다. 보안 란에는 해당 컴퓨터가 개인 전용 PC인지 여부에 따라 자동으로 로그오프가 되는 시간을 정할 수 있다.

폼 로그인은 익스체인지를 설치하면서 기본적으로 설정되는 부분이 아니다. 따라서 기본으로 설치되는 http://서버이름/exchange 페이지에 액세스하면 자동으로 https://서버이름/exchange 페이지로 이동하도록 리다이렉션을 설정해야 한다. 이를 위해 먼저 http://서버이름/exchange 가상 디렉토리의 속성 페이지에서「디렉토리 보안|보안 통신|편집」을 선택하고 ‘보안채널 필요 SSL’과 ‘128비트 암호화 필요’를 선택한다. 그러나 이렇게 설정하고 http://서버이름/exchange로 액세스하면 <화면 3>과 같은 오류 페이지가 나타난다.

<화면 4> SSL 인증이 필요하도록 한 페이지에 HTTP로 액세스했을 때

이는 403.4 오류로 SSL 인증이 필요하다는 의미로, \Winnt\help\iishelp\Common\403-4.htm에 있는 페이지를 나타내도록 설정했기 때문이다(익스체인지 가상 디렉토리의 속성에서 ‘사용자 지정 오류’ 탭 참조). 따라서 다음과 같이 https//서버이름/exchange로 리다이렉션하도록 하는 HTML 문서를 만들어 redirect.html라는 파일명으로 Common 폴더에 저장하면 된다.

<html><head>
<meta http-equiv=“refresh" content="0; url=https://서버이름/exchange">
</head></html>

이제 다시 가상 디렉토리 속성의 ‘사용자 지정 오류’ 탭에서 403.4 오류에 대해서 redirect.html로 바꾸면 자동으로 https://서버이름/exchange로 변경된다.

내 맘대로 바꾸는 OWA 테마
OWA의 테마는 \exchsrvr\exchweb\theme 디렉토리에 0에서 4까지 다섯 가지 폴더에 저장돼 있으며 각 사용자들은 옵션의 ‘모양’ 탭에서 <화면 4>와 같이 선택할 수 있다. 각 테마 폴더 안에는 몇 가지 종류의 파일들이 존재하는데 그 내용을 보면 다음과 같다.

◆ logo2.gif : OWA 로고 이미지 파일이다. 임의의 형식으로 만들어 같은 이름으로 저장하면 로고를 바꿀 수 있다.
◆ nb-bkgd.gif : 바로가기 창의 배경색으로 크기는 1×26이다.
◆ nb-hide-ql.gif : 바로가기 창의 작은 점으로 나타나고 중간에 세모의 형태를 가지고 있다. 50×8의 크기를 가지고 있다.
◆ nb-show-ql.gif : 바로가기 창이 숨겨지면 나타나는 창이며 nb-hide-ql.gif와 크기, 형태가 유사하다.
◆ nb-ql-tgl.gif : 앞의 두 가지 이미지 뒤에 배경으로 나타나는 것이다.
◆ nb-sel-bkgd.gif : 바로가기 아이콘의 배경색이다.
◆ nb-bg.gif : 새로운 메일 도착 알림을 나타낼 때 배경색으로 들어가는데 보통 이 파일도 logo2.gif와 함께 많이 바꾸어 사용한다.
◆ tool-bkgd.gif : 각 도구 메뉴를 구분할 때 사용한다. 별로 바꿀 것이 없다.
◆ resize-dot.gif : 빈 이미지로 존재하며 약간의 빈틈을 매워줄 때 사용한다.
◆ OWAColors.css : 이것은 HTML의 CSS 형식의 파일로 각 색깔을 지정할 때 사용한다. 여기서 테마의 모든 배경색을 결정된다. 각 색깔들은 #RRGGBB 형태의 16진수로 표시되며 이를 수정해 원하는 색깔의 OWA를 만들 수 있다.

<화면 5> 테마의 종류

네트워크 로그인 페이지는 사용자 ID와 입력하는 형식이므로 바꿀 수 있는 것이 한정되어 있지만 폼 로그인의 경우 바꿀 수 있는 항목이 여러 가지 있다. 먼저 OWA에 사용되는 그림은 \Exchsrvr\exchweb\img 폴더에 들어 있으며 모두 GIF 형식이다. 픽셀 크기가 달라지면 그림이 깨지므로 바꾸고자 하는 파일의 크기를 잘 기억해야 한다. 일반적으로 가장 많이 바꾸는 부분이 Microsoft와 Outlook Web Access 로고를 자사에 맞게 바꾸는 것이다. <화면 5>는 폼 로그인 화면에서 사용되는 img 폴더내 그림 파일의 이름과 픽셀 크기를 나타낸 것이다.

<화면 6> 폼 로그인 페이지 내 그림 파일의 이름과 크기

여기서는 메일보기 페이지에서 좌측 상단에 있는 Outlook Web Access 로고를 변경해 보자. 이 파일은 179×36의 크기로 \Exchsrvr\exchweb\themes\0 폴더에 logo2.gif 형태로 존재하므로 <화면 6>과 같이 변경하면 기업에 맞게 활용할 수 있다. 이밖에도 도메인을 하나만 사용한다면 logon.asp 파일을 수정해 도메인\사용자 이름과 암호 칸도 익숙한 형태로 바꿀 수 있으며, IE 5.01 이후 버전을 사용한다고 가정하면 이런 형식과 보안 선택사항도 없앨 수 있다.

<화면 7> Outlook Web Access 로고를 변경한 전과 후

익스체인지 2000까지는 OWA 테마가 하나였다. 그러나 이후 버전부터는 여러 가지 배경색을 사용할 수 있도록 해 사용자의 기호에 따라 OWA를 바꿀 수 있다. 특히 익스체인지 2003은 자체적으로 새로운 테마를 만들어서 적용할 수도 있다. 먼저 특정 테마를 기본 테마로 사용하려면 레지스트리를 다음과 같이 수정해야 한다.

[1] 레지스트리의 HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\MSExchangeWeb\OWA 목록을 찾는다.
[2] 「편집|새로만들기|DWORD」값을 선택한다.
[3] 새값 #1에서 이름을 DefaultTheme으로 바꾼다.
[4] 이 항목에서 마우스 오른쪽을 클릭하고 수정을 선택한다.
[5] 자신이 원하는 테마 번호를 지정한다.

또한 새로운 테마를 만들 경우에는 레지스트리를 다른 방식으로 수정해야 하는데, 먼저 테마에 포함된 파일들을 모두 생성하고 OWAColor.css 파일을 원하는 색으로 지정해야 한다. 그 후 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\MSExchangeWeb\OWA 목록으로 내려가 다음과 같이 Themes 하위키를 만든다. 정리하면 id=100;title=EUG;bgcolor=#FFFFAA;path=5가 된다.

[1] 문자열 값으로 ‘새로만들기’를 한다. 테마 폴더이름과 동일한 이름을 부여하고 마우스 오른쪽을 눌러서 ‘편집’을 선택해 문자열 편집 대화상자를 연다.
[2] 테마의 ID를 부여한다. ID는 10진수 또는 16진수로 해야 하는데 여기서는 id=100으로 설정한다.
[3] OWA의 테마 목록에 나타날 테마 이름을 입력한다. 여기서는 title=EUG로 정한다.
[4] 배경색을 지정한다. 여기서는 bgcolor=#FFFFAA로 설정한다.
[5] 마지막으로 경로를 지정한다. 이것은 \exchsrvr\exchweb\theme 폴더 내에서 새롭게 만든 폴더의 경로를 입력한다. 여기서는 path=5로 설정한다.

이제 다시 OWA를 실행해 옵션의 모양을 선택해 보면 <화면 7>과 같이 추가된 것을 확인할 수 있다.
<화면 8> 추가된 OWA 테마

익스체인지 2003 OWA 세그먼트화
OWA를 사용하다 보면 필요에 따라 사용하지 않는 폴더가 생긴다. 예를 들어 받은 편지함에 있는 업무일지 폴더는 아웃룩과 달리 OWA에서는 그 기능이 매우 제한적이다. 이런 경우 아예 클라이언트에 보이지 않도록 설정할 수 있는데, 이처럼 특정 폴더나 기능을 나타낼 지를 결정하는 기능을 세그먼트화(segmentation)라고 한다. 세그먼트화는 익스체인지 2000 SP2에서 처음 소개됐으며 이후 OWA를 커스터마이징하는데 널리 사용되고 있다.

세그먼트화는 서버 단위의 세그먼트화와 사용자 단위의 세그먼트화 등 크게 두 가지 방식이 있다. 서버 단위에서 적용하기 위해서는 먼저 레지스트리를 변경해야 한다. 레지스트리를 변경하는 것은 매우 위험하므로 변경 전후에 항상 백업을 실시해야 한다.

[1] 레지스트리의 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\MSExchangeWeb\OWA 목록으로 내려간다.
[2] 「편집|새로만들기|DWORD」값을 선택한다.
[3] 새값 #1에서 이름을 DefaultMailboxFolderSet으로 바꾼다.
[4] 이 항목에서 마우스 오른쪽을 클릭하고 수정을 선택한다.
[5] 10진수 또는 16진수를 선택하고 자신이 원하는 값을 입력한다.

OWA 세그먼트화의 비트 값은 <표 1>과 같다. 여러 가지 기능 중에서 원하는 기능을 선택해 그 합을 비트값으로 표현하면 된다. 예를 들면 고급 사용자 환경에서 메일과 일정 그리고 약속 미리 알림과 메일도착 알림 기능만 사용하고 싶다면 ‘1+2+128+256+512=899’이므로 DefaultMailboxFolderSet에 899를 입력하면 된다.

<표 1> OWA 세그먼트 비트값

한편 MS의 모든 제품들이 그렇듯 OWA도 클라이언트 단위에서 설정한 값이 서버 단위에서 설정한 값보다 우선한다. 즉 세그먼트화도 개개인의 기호에 따라 클라이언트 별로 다르게 적용할 수 있는 것이다. 이를 지원하기 위해서는 액티브 디렉토리(AD) 사용자 특성에서 그 값을 바꾸어야 하는데 다음과 같은 순서로 하면 된다.

[1] adsiedit.msc를 설치해 시작한다.
[2] 해당 도메인 컨테이너를 선택한다.
[3] 도메인 밑에 작업하기 원하는 사용자가 포함된 조직 단위를 선택한다.
[4] 조직 단위 안에 있는 특정 사용자를 선택하고 마우스 오른쪽 버튼을 누른다.
[5] Attributes 목록에서 msExchMailboxFolderSet을 선택하고 ‘Edit’를 누른다.
[6] 원하는 OWA 세그먼트화 비트 값을 입력한다.

OWA에 날개달기, OWA 관리도구
OWA 관리 도구는 익스체인지 관리자가 조정할 수 있는 모든 OWA 설정에 대해 웹 기반 UI를 제공한다. 도메인의 모든 서버 목록을 제공하며 <화면 8>처럼 모든 프론트엔드와 백엔드 서버에서 OWA 설정을 관리할 수 있다. 이밖에도 OWA 테마를 바꾸는 것을 비롯해 OWA 기능 대부분을 레지스트리를 변경하지 않고 관리, 운영할 수 있도록 지원한다. MS홈페이지(www.microsoft.com/downloads/)에서 다운로드해 설치할 수 있는데 익스체인지 서버에 설치할 수도 있고 IIS와 .NET 프레임워크가 설치된 다른 서버나 XP 이상의 클라이언트에 인스톨해 사용할 수 있다(단, 기본적으로 접속할 때는 보안문제 때문에 SSL로 접속해야 한다는 것을 명심하라. 원한다면 IIS의 OWA Admin 가상 디렉토리에서 보안을 수정해 HTTP로 접속할 수 있다). 꼭 활용해보기 바란다.

<화면 9> OWA 관리 도구

익스체인지 2003 OWA이 많이 개선되기는 했지만 아웃룩에 비하면 다음과 같은 기능은 아직 지원되지 않는다. OWA는 여전히 진화중인 애플리케이션이다.

◆ 오프라인으로 작업이 불가능하며 PST 파일을 이용할 수 없다.
◆ 사용자가 URL을 변경하지 않고서는 다른 사람들의 사서함 폴더를 열 수 없다.
◆ OWA 서버에 처음으로 액세스할 때 클라이언트는 250KB만큼의 컨텐츠, 컨트롤, 그래픽을 다운로드하게 되는데 접속 환경에 따라 부담이 될 가능성이 있다(압축을 이용하면 속도가 약간 빠르다)
◆ 전체 주소 목록(Global Address List)를 이용할 수 없다.
◆ S/MIME을 지원하지만 먼저 컨트롤을 다운로드해야 하고 시스템에 디지털 ID를 등록해야 한다.
◆ 익스체인지 5.5의 사서함과 공용 폴더에 액세스할 수 없으며 오직 익스체인지 2000이나 2003에 있는 사서함에만 접근할 수 있다. 또한 익스체인지 2003 OWA로 익스체인지 2000 사서함 서버에 액세스하면 2003 인터페이스로 볼 수 없다.
◆ 작업 할당 등 작업에 대한 기능과 업무일지 등에 대한 지원이 부족하다.

한편 WebDAV, XML 등을 이용하면 완전히 새로운 익스체인지 2003 웹 메일 시스템도 만들 수 있다. 그러나 이 경우는 성능을 보장하지 못하고 많은 인력과 비용이 소요된다(WebDav를 이용해 사서함에 액세스하는 방법은 익스체인지 사용자 그룹 웹사이트(www.msexchange.org)를 참고하라). 일반적인 환경의 관리자라면 이번 강좌에서 다뤄본 내용 정도의 수정과 설정만으로도 성능을 보장하면서 개별 기업에 맞는 웹 메일 환경을 구축할 수 있을 것이다.@

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.
Posted by tornado
|
질문: 마이크로소프트 아웃룩에서 주소록을 누르면 다음과 같은 오류가 발생합니다 hancookie / 2004-12-21 13:25

다음과 같은 오류가 나옵니다

 

그리고 확인 누르고 다른거 한번더 누르면 되기는 되는데 매우 불편합니다 없애는 방법이 없을까요>?

 

 

추가내공도 드리겠습니다 내공은 많이 걸께요  운영체제는 2000이구요  오피스는 2003입니다. 

답변: re: 아웃룩에서 에러... nocodee / 2004-12-21 13:15
LDAP 서버는 smtp, pop, imap 등의 메일 관련 서버가 아니라
인증 관련 서버입니다

아웃룩 - 도구 - 전자메일 계정 - 디렉터리 - 기존의 디렉터리 또는 주소록 보기
또는 변경 체크 후...


Posted by tornado
|

LAN환경에서 같이 작업하다보면 가끔 새로 정책을 따르지 않은 pc로 인해

어느날 갑자기 IP가 충돌하여 인터넷이 안되는 경우가 많습니다.

이때는 시작 > 프로그램 > 보조프로그램 > 명령프롬프트 를 실행하세요.

nbtstat -A 192.168.1.1(충돌하는 IP)라고 입력하신 후 엔터를 치세요.


그러면 이미 쓰고 있는 pc의 사용자이름과 작업그룹이 아래와 같이보여집니다.


이제 CHO가 누구야? 하고 사무실을 한바퀴 돌면 그 사람이 나타나십니다. ^^

Posted by tornado
|

Microsoft Outlook(MS 아웃룩)에서 스팸 메일을 자동으로 걸러내기.

먼저 이글에 첨부된 파일을 다운로드 한다.

첨부된 파일은 Microsoft Outlook에서 사용되는 규칙이 설정된 파일이다.

이 파일은 받은 메일 중에 메일 제목에 특정 단어(예: 광고, 포르노 등)가 들어 있는 메일은 자동으로 '지운 편지함'으로 이동시키도록 하는 규칙을 적용시켜 놓은 것이다.

파일을 다운 받은 후 아래의 설명대로 한다.


1. Microsoft Outlook을 실행시킨다.

 
Microsoft Outlook 실행화면


2. 메뉴에서 '도구'를 누르고 나타나는 항목 중 '규칙 마법사'를 선택한다.


3. 규칙마법사가 실행된 화면

('스팸방지용 제목 설정'이라고 보이는 것은 설정하지 않은 이에겐 나타나지 않음.)

규칙을 적용할 사서함 또는 개인 폴더는 기본적으로 되어 있는 자신의 메일을 선택한다.

(그냥 창이 나타난 상태에서 하면 된다.)


4. 옵션 버튼을 클릭


5. 옵션의 내보내기 가져오기 창이 나타난다.


6. '규칙 가져오기' 클릭


7. 파일 선택 창이 나타난다.


8. 다운 받았던 이 글에 첨부된 파일을 찾아 선택하고 열기를 누른다.

(파일명 spamfiltword.rwz)


9. 뒤쪽에 방금 가져온 규칙이 나타난다.

(본래 있는 것에 추가되어 두 개가 되었다. 처음부터 없던 사람은 하나가 생김)


10. 가져오기 내보내기 창에서 '확인'을 클릭하여 창을 닫는다.


11. 규칙 마법사 창에서 '확인'을 클릭하여 창을 닫는다.

 
위 순서대로 하고난 뒤에 불건전하거나 광고성 메일이 오게 될 경우 해당 메일은 자동으로 '지운 편지함'으로 이동된다.
 
위 설정을 통해 '지운 편지함'으로 자동 이동되는 메일은 메일 제목에 아래의 단어나 글자가 포함된 것들이다.
지운 편지함으로 이동되도록 설정된 단어나 글자
각 항목은 '/'로 구분하여 놓았다. 앞쪽에 있는 단어를 포함하는 메일일 수록 빈도가 높고 악성인 것들이 많다.
광고/홍보/무료/정보/[광/(광/(성/[성/free/sex/adult/섹스/동영상/누드/연예인/포르노/뽀르노/몰카/몰래/보지/자지/좇/언니/빠구리/흥분/시디/성인/벗었/씨디/비아그라/그라/남성/정력/다이어트/경품/상환/대납/금리/보증/담보/대출/?倍??倍?대츌/츌/0만/9만/만원/직장인/교재/자격시험/중개사/선착순/전문직/공무원/현금/마케팅/최저금리/년제/학사
 
 
 
 
Posted by tornado
|