무엇이 문제였는지를 찾기 위해 로그 파일들을 뒤졌고, /etc/pam.d/smtp가 없는게 아니냐는 에러메시지를 확인할 수 있었다.

/etc/pam.d/pop3 를 /etc/pam.d/smtp 로 복사하는 방법을 통해 문제는 해결할 수 있었지만 이건 젠투에서 제공하는 기초 패키지의 버그라고 생각되었다.

살펴보니 /etc/pam.d/pop3, /etc/pam.d/imap 등은 mailbase 패키지를 통해 설치된 것임을 알 수 있었다. 그럼 /etc/pam.d/smtp 도 mailbase를 통해 설치되는 것이 옳지 않을까 하는 생각에 버그를 신고했다.

하루가 지나 ‘이 파일은 postfix 등의 mta에서 설치되기 때문에 mailbase에서 설치되지 않는 것인데, 생각을 좀 해봐야겠다.’ 라는 답변이 달렸다. 이 말대로라면 exim의 버그라고 봐야겠지만 분명 /etc/pam.d/imap, /etc/pam.d/pop3 같은 파일들은 courier-imap이나 dovecot를 통해 설치되지 않고 있고 어떤 mta를 사용하던 smtp auth를 사용하려면 /etc/pam.d/smtp가 필요하므로 모든 mta에 공통적으로 의존성이 걸려있는 mailbase에서 /etc/pam.d/smtp를 설치해주는 것이 더 맞을 것 같다는 생각이 들었고, 관련된 내용을 다시 버그질라에 올렸다.

얼렁 수정되서 새로 젠투를 설치하는 사람들은 불편을 느끼지 않게 됐음 좋겠다.

Related Posts

• 2/18/2008 -- 요 며칠 삽질기 -_-! with Exim (1)
• 3/20/2008 -- exim 으로 메일 서버 구성하기… (0)
• 4/10/2009 -- Gentoo에서 fail2ban 쓰기 (2)
• 2/5/2009 -- 당신은 어떻게 리눅스를 사용하게 되셨나요? – 1부 (0)
• 2/26/2008 -- spam filtering with transport/router of exim (0)

제가 처음 리눅스를 설치해봤던 건 2001년, 정확히는 제 두번째 수능이 끝났을 즘이었습니다. 여느 때와 같이 웹서핑을 즐기다가 themes.org를 발견했고, 그곳에 있던 색다르고 이쁜 스크린샷들이 제 눈을 사로잡아버렸어요.

당시에 이름을 날리던 알짜 리눅스를 구해 어렵게 시디를 굽고, 설치를 시작했죠. 하지만 제가 생각했던 모습이 아니었어요. GTK-1.x 기반의 GUI는 I18N(Internalization, 한글 사용)을 위해 손이 너무나도 많이 갔었고, rpm 기반의 알짜 리눅스에 뭔가를 설치하는 건 굉장히 힘들었거든요.[1] 리눅스와의 첫 만남은 알짜, 래드햇, 와우, 한컴 리눅스 등을 번갈아 설치해보는 정도로 끝이 나버릴 수 밖에 없었습니다.

하지만 리눅스와 저와의 인연은 그리 짧지 않았나 봅니다. 2001년 후반 웹에 관심을 가지고 있던, 자신의 홈페이지를 운영하던 친구들을 모아 언픽스 [2]를 만들면서 리눅스와 저는 다시 만나게 됩니다. 지금도 비슷하지만 당시의 웹호스팅은 굉장히 비쌌고, 제약이 많았습니다.

우린 다들 웹호스팅을 하나쯤 받고 있었기 때문에, 차라리 호스팅비를 모아 서버를 빌리는게 어떻겠냐는 생각으로 시작된 곳이 언픽스였어요. 어떤 친구는 php-imap 조합으로 웹메일을 만들어보고 싶었고 어떤 친구는 postgresql을 사용해보고 싶어했어요. 그리고 저는 리눅스로 서버를 만들어보고 싶었죠. 서로 함께 커갈 수 있는 공간… 그게 제가, 우리가 처음 바랬던 언픽스였습니다.

KT에서 임대 서버를 빌렸고, 선릉에 있는 KT-IDC에서 저와 리눅스는 다시 조우하게 됩니다. 당시엔 정말 초보였는데, 그 때 설치했던 레드햇 7.3으로 4년 가까이 별 문제가 없었던 건 정말 행운이었던 거 같아요.

이듬해 홍익대학교에 입학하게 되었고, 지난 몇개월 간 서버를 운영했던 경험과 관련해서 학교 클래스넷의 개선 방향에 대해 학과 게시판에 글을 남겼는데, 그걸 본 정보전산원 주임님께서 학교 정보전산원에서 함께 일할 것을 제의해오셨습니다. 홍익대학교 10층 정보전산원에 제 자리와 컴퓨터가 지급되었고, 기본적인 업무는 리눅스에서도 충분히 가능할 것 같다는 생각에 리눅스로 데스크탑을 꾸며놓게 됩니다.

처음 시작은 Redhat + KDE였지만 여전히 설치는 쉽지 않았고, 완성도도 그다지 높지 않았습니다. 그 즈음에 공격적인 컴파일러 옵션들과 LFS(Linux for Scratch, 시작부터 끝까지 직접 빌드하는 리눅스)를 알게 되었고, LFS를 시도해볼려는 찰나! 제 눈 앞에 Gentoo Linux가 나타났습니다. 비슷한 시기에 GNOME 2.0이 릴리즈 되었고, GNOME 2.0을 설치한 순간 전 리눅스 데스크탑의 미래를 느낄 수 있었습니다.

2부에 계속…

p.s) 리눅스를 처음 접하게 된 계기를 트랙백으로 보내주시면 감사할 것 같아요.

[1] apt-get, yum 등이 없었던 그 시절, rpm 기반의 배포판에 뭔가를 설치한다는 건 보통 짜증나는 일이 아니었습니다. 의존성 지옥이라는 말이 괜히 나온 말이 아니죠. 뭐 하나를 받아서 설치하려고 하면 새로 설치해야하는 것들이 두세가지씩 쏟아졌고, 의존성이 걸린 패키지들을 하나하나 다운받아야 했으니까요.

[2] 언픽스는 제가 운영하는 개인 호스팅 사이트의 대표이름입니다.

Related Posts

• 4/10/2009 -- Gentoo에서 fail2ban 쓰기 (2)
• 4/9/2009 -- Gentoo: /etc/pam.d/smtp 와 exim, mailbase (0)
• 2/18/2008 -- 요 며칠 삽질기 -_-! with Exim (1)
• 4/8/2009 -- 서버 부활… (0)
• 4/6/2009 -- DDoS 공격을 당했습니다. (0)

이 은행에 있던 돈을 다른 은행에 있는 계좌로 이체를 시킨 뒤 잔고가 얼마인지 확인하기 위해 또 다른 은행사 홈페이지로 접속을 했고, 또 다른 프로그램들이 실행되기 시작했다.

도대체 XecureWeb, INISafeWeb등이 뭐하는 프로그램이길래 설치를 강요받아야 하고, 또 무슨 근거로 신뢰를 강요받아야 하는걸까?

XecureWeb / INISafeWeb 도대체 얘네 뭐하는 애들이야?

크게 인터넷 뱅킹에서 필요한 기능은 두 가지 이다. 인터넷 뱅킹을 하는 동안 오가는 데이터를 중간에서 가로챈다고 하더라도 그 내용을 알아 볼 수 없게 하기 위해 보안 채널을 구성하는 것이 그 첫번째이고, 거래(계좌 이체 등)를 한 사람이 본인이라는 사실을 증명하는 것이 그 두번째이다.

위에 열거한 프로그램들이 위에서 얘기한 두 가지 기능을 제공하기 위한 플러그인이라 할 수 있지만 불행하게도 Microsoft Windows용 플러그인만 제공되고 있다.[1] 덕분에 Mac OS X 이나 Linux 등에서는 인터넷 뱅킹을 이용하는 게 쉽지 않고, 일부 플러그인의 경우 윈도우용 firefox를 위한 플러그인도 제공하고 있지만 플러그인의 버젼을 체크하는 javascript 문제로 firefox에서는 동작하지 않는 경우가 태반이라 (BC카드 홈페이지가 대표적 사례) 인터넷 뱅킹은 윈도우용 인터넷 익스플로러 전용 서비스라고 해도 과언이 아닌 것 같다.

그럼 대안은 없는건가?

우선 보안 채널을 형성하는 것과 관련해서는 http over ssl(이하 https)이라는 훌륭한 대안이 있다. 위에서 얘기한 플러그인들의 경우 브라우저나 웹서버에서 기본으로 제공하는 방법이 아닌 자신들 고유의 방법으로 보안 채널을 형성해야 하기 때문에 개발이 복잡해질 수 밖에 없다.

하지만 https 는 대부분의 웹서버와 브라우저에 구현되어 있기 때문에 프로토콜을 https로 명시해주면 끝이므로 개발 비용 및 추가 비용이 발생하지 않는다. 이미 널리 사용되고 있는 방법이므로 Microsoft Windows, Mac OS X, Linux, Firefox, Internet explorer, Opera, lynx, links, w3m 등 어떤 OS, 어떤 브라우저에서도 이용에 제한을 받지 않는다. 심지어는 w3m 같은 텍스트 브라우저마저도 https를 지원한다.

거래를 한 사람이 나라는 사실을 증명하는 방법으로는 전자 서명이 있고, 이는 페이지의 해쉬 값을 내 공인인증서로 암호화 한 내용[2]을 덧붙이는 식으로 구현된다.

이를 위해 필요한 기능은 공인인증서(자신의 사설인증서)로 페이지의 해쉬 값을 암호화 하는 기능이며, 기본적으로 브라우저에서 제공되는 기능은 아니기 때문에 플러그인이 필요할 수 밖에 없다. 최근 크로스 브라우징에 대한 흥보의 효과인지 얼마 전 이니시스에서는 플래쉬 기반의 공인인증 시스템을 발표했지만 아쉽게도 아직까지 이 서비스는 전자 결제 대행에서만 이용이 가능 한 것으로 보인다. (오해가 있을 수 있을 것 같은데, INISafeWeb은 이니시스가 아닌 이니테크의 제품이다.)

하지만 그렇다 하더라도 같은 기능을 위해 각 사이트마다 다른 플러그인을 설치하도록 하는 것은 좋은 방법이라 할 수 없을 것 같다. 더 좋은 해결책이라면 공인인증을 위한 MIMETYPE을 표준화하고 이 MIMETYPE에 대한 처리를 담당하는 플러그인의 API, 즉 공인인증 API를 표준화 하여 이 API를 제대로 구현하고만 있다면 어떤 구현물을 사용하던 서로 호환이 가능하도록 만드는 것이라고 생각한다.

공인인증에 대한 표준화가 이루어진다면 하나의 공인인증 플러그인만으로도 모든 은행의 인터넷 뱅킹 서비스를 자유롭게 이용할 수 있게 될테고, 공인인증 플러그인이 제공되지 않는 브라우저라면 사용자가 스스로 플러그인을 제작해서 사용[3]하는 것도 가능해질 것이다.

마치며

웹은 특정 OS, 특정 브라우저에 제한되어서는 안된다고 생각한다. 암호화 채널을 https 로 바꾸는 것 만으로도 내 통장 거래 내역을 어떤 OS, 어떤 브라우져에서든지 간단히 확인할 수 있게 될 것이다. 비록 반쪽짜리이지만 이 정도만으로도 불편의 반 이상은 해결될 것이라 생각한다. 적용을 위해 약간의 노력이 필요하겠지만 이후 유지 보수의 편리함 등을 생각하면 이 노력은 충분한 의미가 있을 거라고 생각한다. (플러그인에 대한 라이센스 따위는 더 이상 필요 없어진다. 물론 XecureWeb 이라거나 INISafeWeb 등 현 기득권 업체들이 이 시장을 놓치려 하지 않을 것이므로 이 문제는 정치적으로 해결해야할 것이다.)

게다가 공인인증 API 를 표준화 하게 되면 나머지 반쪽의 문제도 해결될 것이다. 많은 것을 바라는 것은 아니다. 단지 자신이 좋아하는 운영체제, 자신이 좋아하는 브라우저를 사용하면서도 차별을 받지 않을 수 있길 바랄 뿐…

[1] XecureWeb의 경우 MS Windows / Mac OS X / Linux 용 플러그인을 모두 제공한다.

[2] 이를 이해하기 위해선 우선 공개키 / 비밀키 알고리즘에 대해 알아야 한다. 간단하게만 얘기하면 어떤 값을 공개키로 암호화 한 것은 비밀키로 복호화 할 수 있고, 어떤 값을 비밀키로 암호화 한 것은 공개키로 복호화가 가능하다.

비밀키는 나만 가질 수 있으므로 공개된 키로 암호화되어 전송된 내용은 나만이 해석할 수 있게 된다. 그렇기 때문에 보안 채널을 구성할 땐 공개키를 이용해서 암호화 하는 방식을 사용한다. (상대방에게 데이터를 전송할 땐 상대방의 공개키를 이용해서 암호화 한 뒤 보내고, 누군가 내게 데이터를 보낼 땐 내 공개키를 이용해서 암호화 한 뒤 보내주게 된다.)

반대로 내 비밀키로 암호화된 내용은 누구나 공개키로 풀어볼 수 있으므로 데이타를 보낼 때 데이터의 뒤에 그 데이타를 내 비밀키로 암호화된 내용을 덧붙인다면 이게 내가 보낸 데이타라는 것을 증명할 수 있게 된다. 실제로는 데이타 자체를 암호화 해서 보내기 보다는 데이타의 해쉬 값을 비밀키로 암호화 한 뒤 원래의 데이타 뒤에 이 값을 붙여서 보내게 된다. 이를 이용하는 애플리케이션으로는 enigmail 등이 있다.

[3] RSS에 비유를 해보자. RSS는 표준화가 되어있기 때문에 RSS feed를 관리하기 위해 특정 애플리케이션을 사용해야할 필요는 없다. 만약 자신이 사용하는 OS에 RSS Reader가 존재하지 않는다면 표준을 참고해서 직접 Reader를 작성할 수도 있다.

Related Posts

• 1/28/2009 -- 번역: 한국의 홈브류 인터넷 (0)
• 10/25/2007 -- 오픈웹과 관련해서… (4)
• 9/15/2007 -- 64bit Windows Vista 와 신한은행… (13)
• 4/6/2009 -- 오픈웹 관련해서 시끄러운 하루하루… (2)
• 2/7/2010 -- 인터넷 결제 시스템을 언제까지 익스플로러에 가둬놓을 셈인가? (3)

사실 계속 제가 맡아서 할 게 아니라 길어야 일 년 정도 만져줄 서버기 때문에 젠투가 아닌 다른 배포판을 생각했었는데, spf 와 srs 를 지원할 수 있도록 하면서 기본으로 제공되는 패키지를 이용할 수 있는 조합이 몇 가지 되질 않더군요. exim 에서 spf 와 srs 는 experimental 로 되어 있기 때문에 바이너리 배포판에선 기본으로 적용이 되어 있질 않고, postfix + milter 조합에서는 srs 를 제공할 수 없기 때문에 남은 선택은 sendmail + milter 조합 밖에 없는데 sendmail 을 사용하기는 싫었거든요.

하여튼! exim 에 procmail 을 붙이는 방법은 아래와 같습니다.

procmail: driver = accept transport = procmail domains = +local_domains check_local_user # emulate OR with "if exists"-expansion require_files = /usr/bin/procmail no_verify no_expn

router 파트의 localuser: 룰 앞에 위와 같은 코드를 추가하고

procmail: driver = pipe path = "/bin:/usr/bin:/usr/local/bin" command = "/usr/bin/procmail" return_path_add delivery_date_add envelope_to_add

transpotes 에 router 에서 정의한 procmail transpote 를 정의해 주면 되죠. procmail 을 이용한 스팸 필터야 예전부터 잘 사용해오던 게 있으니 그걸 사용하면 됐구요.

그 다음은 smtp 설정!! 기본으로 /etc/exim/auth_conf.sub 란 파일이 있길래 그냥 자동으로 smtp 인증 설정이 되어있는줄 알았는데 smtp 인증을 사용하려면 저 안에 있는 내용을 /etc/exim/exim.conf 에 추가해줘야합니다.

plain: driver = plaintext public_name = PLAIN server_condition = "${if pam{$2:$3}{1}{0}}"   login: driver = plaintext public_name = LOGIN server_prompts = "Username:: : Password::" server_condition = "${if pam{$1:${sg{$2}{:}{::}}}{1}{0}}"

그 내용은 위와 같았구요. 하지만 여기서 또 문제가 발생! 예전 시스템이 오래 전에 설치된 것이었는지 비밀번호 암호화를 md5 로 사용하질 않고 있었는데, /etc/pam.d/system-auth 에서 md5 를 제거함으로써 다른 데몬들에선 문제가 해결됐지만 exim 의 stmp 에서만 인증 실패가 나오는겁니다. -_-!

참고로 smtp auth 가 어떤 과정으로 이뤄지는지는 아래 인용된 내용을 참고하세요. 테스트할 때 알아두면 편합니다.

$ telnet localhost 25
EHLO localhost
AUTH LOGIN
base64로인코딩한아이디
base64로인코딩한비밀번호

여담이지만 smtps 나 pop3, imaps 를 꼭 사용하세요. 위에서 처럼 비밀번호가 그냥 넘어갑니다. 패킷이 악의적인 라우터를 지날 경우 아이디/비밀번호가 줄줄 셀 수 있습니다.

하여튼 비굴하게 saslauthd 를 사용해서 우회시켜봤지만 요놈도 마찬가지로 인증 실패 -_-! 아예 다 안되면 모르겠는데 우리 사랑스런 dovecot 은 로그인이 아주! 잘 됩니다. exim 만 나쁜 놈이란 거죠.

saslauthd 라거나 pwcheck 같이 다른 곳에서 잘 사용도 안되는 데몬을 띄우는 게 좀 꺼림찍했는데 잘됐다 싶어서 dovecot-auth 를 활용해봤습니다. dovecot-auth 를 활용하려면 아래와 같이 dovecot.conf 파일을 수정해줘야 합니다.

auth default { mechanisms = plain login passdb pam { args = "*" } userdb passwd { } user = root   socket listen { client { path = /var/run/dovecot/auth-client mode = 0666 } } }

그리고 위에 써있는 auth-client 소켓을 이용해서 로그인하도록 exim.conf 를 고쳐줍시다.

login: driver = dovecot public_name = LOGIN server_socket = /var/run/dovecot/auth-client

이제 끝!! 드디어 smtp 인증이 정상적으로 되기 시작합니다. 휴;;

뭐 대강 다 됐는데, 한 가지 아쉬운 점이라면 .forward 나 alias 를 이용할 경우 procmail 을 거치지 않기 떄문에 스팸 필터링이 안되는 것 정도? 이건 어떻게 해야할 지 별로 답이 안나오네요.

그렇다고 bogofilter, clamav 등이 다 procmail 에서 호출되는데 이걸 spamassassin + clamd 조합으로 새로 설정하긴 완전 귀찮고 (사실 어떻게 하는지도 모르고) 약간 쀍입니다.

그 외에 mailman 과 관련된 삽질이 조금 더 있었고, seliunx 가 적용되어 있는 CentOS 랑 관련된 것도 있었는데 또 언제 시간날 때 관련된 것들을 포스팅해봐야겠습니다.

사실 요새 포스팅 하고 싶은 내용은 많은데 내용이 길어져서 귀차니즘이 발동해버렸네요.

Related Posts

• 2/16/2008 -- exim 에 spf, srs 적용하기 (0)
• 4/9/2009 -- Gentoo: /etc/pam.d/smtp 와 exim, mailbase (0)
• 3/20/2008 -- exim 으로 메일 서버 구성하기… (0)
• 2/26/2008 -- spam filtering with transport/router of exim (0)
• 2/26/2008 -- exim 의 transport, router 를 이용한 스팸 필터링 (2)