Outlook Anywhere 접속: IPSec을 통한 2FA(2-Factor Authentication)

  본문으로 들어가기 전에 잠시 정리: iOS와 Mac OS X에서는 TMG L2TP/IPSec VPN 접속이 안된다. 안되는 이유는 아래와 같다.

    - Apple OS에서 클라이언트 UDP 통신 포트를 1701을 사용하지 않는다.

    - 키체인으로부터 개인키를 얻어올 때 바이트 계산에 문제가 있다.

    출처: TMG L2TP and Mac Os

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Apple OS에서 L2TP 설정하는 법은 아래 링크 참조

    참조: Using a Linux L2TP/IPsec VPN server with Mac OS X and iPhone

    (그런데, TMG에는 어떻게 해도 접속이 안된다.)

본문 시작.

  1. Outlook Anywhere

  아웃룩으로 Exchange 서버에 접속하는 것은 POP3/SMTP나 IMAP 방식이 아닌 Rpc over HTTP라는 기술을 이용하는 것인데 이것을 일명 Outlook Anywhere라고 부른다.

  그런데 아웃룩으로 접속할 때 Active Directory의 ID와 Password만 알면 누구나 접속할 수 있는 관계로 계정 유출과 같은 보안 문제가 쉽게 발생할 수 있다. 그래서 보통 기업에서는 그러한 보안 문제를 해결하기 위해 여러가지 방법들을 적용하는데, 방화벽이나 VPN을 이용하는 등 실질적으로 메일을 사내에서만 사용할 수 있게 한다든가 하는 일반적이고 전통적인 방법은 여기서 다루지 않겠다. 네트워크 보안 분야에서는 이미 일반적인 만큼이나 식상한 내용이니까.

  여기서 다룰 내용은 회사에 방화벽이 없거나, 있다 하더라도 회사 외부, 즉 인터넷 환경에서 아웃룩으로 자유롭게 사내에 있는 Exchange 서버에 접속해서 사용할 수 있는 환경을 대상으로 한다.

  이 경우 ID/Password만을 사용하여 접속하는 낮은 보안을 크게 바꾸지 않고 살짝 업그레이드하는 대표적인 방법이 클라이언트 인증서를 이용한 2FA(2-Factor Authentication)이며, 클라이언트를 이용한 2FA의 대표적인 방법은 SSL 보안(SSL with Client Certificate)쯤 될 수 있겠다.

여기서 살짝 오해의 소지가 있을 수 있는 부분이 있어서 첨언하자면, 2FA(2-Factor Authentication)에 사용하는 클라이언트 인증서는 사용자를 인증하는 것이 아니라 사용자의 장치를 인증하는 것이다. 즉, 클라이언트 인증서는 비록 사용자를 대상으로 발급되었다 하더라도 사용자 인증서라기 보다는 장치 인증서의 개념으로 이해하는 것이 맞다. 일부 시나리오에서는 클라이언트 인증서를 사용자와 매핑하여 인증서로 직접 인증하는 시나리오가 있는데, 그런 경우는 2FA가 아니라 인증서 단일 인증이 되겠다. 혼동하지 말 것.

  그런데 안타깝게도 그 대표적인 방식은 OWA(Outlook Web Access/App)에나 해당되지 Outlook Anywhere에는 해당되지 않는다. 즉, 웹 브라우저로 OWA에 접속할 때와는 달리, 아웃룩을 이용하여 Exchange 서버에 연결하는 경우에는 클라이언트 인증서를 팝업으로 띄워서 선택하거나 할 방법이 없는 관계로 이와 같은 방식의 2FA를 적용할 수가 없다.

  모바일의 경우에는 Exchange 서버 메일을 사용할 때 ActiveSync(XML over HTTP)라는 기술을 이용하여 접속하게 되는데 이 경우에는 클라이언트 인증서를 요구하게 하여 2FA를 적용할 수 있다. 다만 모바일의 환경이 다양하여 지원되는 플랫폼과 지원되지 않는 플랫폼이 제조사마다, 버전마다 천차만별인 점은 고려해야 하겠다.

  2. 2FA(2-Factor Authentication)

  모바일이 아닌 PC 환경에서 아웃룩을 사용할 때 2FA를 적용할 수 있는 방법은, 그러면 아예 없을까?

  아니다. 있긴 있다.

  아래 링크를 참조하면 IPSec을 구축하여 Outlook Anywhere뿐만 아니라 OWA까지 동일한 포트(HTTPS)를 사용하는 서비스들은 모두 IPSec 보안으로 클라이언트 인증서를 사용하게 하는 방법이 있다. IPSec에 클라이언트가 필요하니 당연히 2FA라 부를 수 있는 것이다. 다만, 설정하는 일이 좀 복잡하다. 클라이언트마다 인증서 설치 후 최소한으로 단순화 한다고 해도 wf.msc를 실행해서 연결 보안 규칙을 작성해주는 작업 또는 자동화 스크립트를 실행하는 작업이 필요하다. 일반인으로서는 상당히 좀... 복잡하게 느껴질 수 있다.

  참조: Using IPsec to Secure Access to Exchange

  (참조2: http://derek858.blogspot.kr/2010/12/two-factor-authentication-for-exchange.html)

  워드 파일을 다운로드해서 열심히 따라해 보다보면 몇 가지 중요한 점이 나온다.

  1. IPSec에 사용할 인증서는 반드시 응용 프로그램 정책에 "IP 보안 IKE 중개"(IP security IKE intermediate) 및 "클라이언트 인증"(Client Authentication) 사용이 활성화되어 있어야 한다.

  2. 주체 이름(Subject) 또는 주체 대체 이름(Subject Alternative Name)에 실제로 사용될 도메인 이름 또는 IP주소가 들어가야 한다.

  3. 서명 및 암호화에 키를 사용할 수 있어야 한다. (기본 선택 옵션이므로 중요하지 않음)

  그런데, IPSec에 참여할 클라이언트는 그렇다 치고, TMG 서버에도 IPSec 인증서가 필요하다! 똑같은 인증서가 있으면 되는 걸까?

  상세한 내용은 아래 링크 참조.

  참조: Create L2TP/IPSec Certificate for TMG 2010 using Enterprise CA

  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  그런데, 위 링크에서는 중요한 것을 빼 먹었다. 위의 방법대로 그대로 따라해봤자 IPSec 연결이 되지 않는다. 그렇다면??? 앞 워드 파일에 중요한 힌트가 있다. 즉,

  4. IPSec에 사용할 TMG 서버용 인증서는 반드시 응용 프로그램 정책에 "IP 보안 IKE 중개"(IP security IKE intermediate) 및 "클라이언트 인증"(Client Authentication) 및 "서버 인증"(Server Authentication) 사용이 활성화되어 있어야 한다.

  클라이언트 인증이 빠져있었다.

  이게 빠지면 IPSec이 동작하지 않는다. 동작하지 않으면 뭔가 에러 로그라도 거창하게 찍어주면 좋겠지만 Windows Server 2008부터는 애써 로그를 찍도록 설정해봤자 생성된 로그 파일을 볼 수도 없다. (뭔가 내부적으로 패러다임이 바뀐건지 oakley.log 파일이 더 이상 생기지 않고 ikeext.etl 파일이 생성되는데 이건 바이너리 파일이다! wfp.fmt 라는 필터가 있어야 볼 수 있는 파일로 변환이라도 되는데 그런 필터 파일은 Microsoft 내부에서만 사용되고 외부에 공개하지 않다니... 웃기는 노릇이다.)

  아마 TMG 서버 인증서에도 "서버 인증" 확장 사용 옵션은 없어도 될 것 같다. 즉, "IP 보안 IKE 중개" 및 "클라이언트 인증"만 있으면 동작한다. "서버 인증" 옵션은 VPN 서버(L2TP/IPsec VPN)로 동작하기 위해 필요한 옵션인 듯 하다.

  인증서가 제대로 설치되었다면 IPSec이 정상 동작하는 것을 확인할 수 있을 것이다.

  인증서를 교체한 후 해당 새 인증서로 동작하게 하려면 그냥 가만히 있으면 안된다. 당연하게도 인증서를 한번 메모리로 로딩하면 계속 메모리에 로딩된 인증서를 쓰기 때문이다. 따라서 관련 서비스를 재시작해주어야 한다. 관련 서비스는 원래는 "IPsec Policy Agent 서비스" 였는데 "IKE and AuthIP IPsec Keying Modules 서비스"로 바뀐 것 같다. 그래도 혹시 모르니 두 서비스를 모두 재시작해주면 된다.

net stop ikeext

net stop policyagent

net start policyagent

net start ikeext

"IKE and AuthIP IPsec Keying Modules 서비스"는 동작 중인 경우 중지가 잘 안 될 때가 많다. 그럴 때는 한 번 더 중지해주면 잘 된다. 이상은 TMG 서버 및 클라이언트 공통사항.

  개인적으로 위 워드 파일에서처럼 HTTPS 구간을 IPSec으로 터널링해서 사용하는 방법이 상당히 매력적이라 여겨진다. 이러한 방법을 응용하면 다양한 서비스에 IPSec을 적용해서 보안을 강화할 수 있을 것 같다. 설치의 편의성이 조금 우려되는 부분이긴 한데... 어떻게든 방법이 있으리라...

  3. 모니터링 - 로그

  위 워드 파일에는 기타 유용한 모니터링 도구들에 대해 설명되어 있다. 그 중 IPSec 로그 파일은 앞에서도 말했지만 더 이상 유용하지 않다. 그렇다면 로그를 확인할 방법이 없을까? 아니다, 있다!

  이벤트 뷰어의 [응용 프로그램 및 서비스 로그]에서 Microsoft\Windows\Windows Firewall With Advanced Security 부분을 보면 유용한 로그가 있다고 워드 파일에는 적혀 있는데, 거긴 사실 별 것 없다. 거기 말고 바로 위, "WFP"부분을 열어보면 "Microsoft-Windows-IKE/Operational"이라는 항목이 있다. 거기에 중요한 로그가 있다!

그걸 클릭해보면 보통 에러가 나서 IPSec이 정상 작동하지 않는 경우

  IPsec: 주 모드 오류

  이런 메시지 한 줄이 덜렁 로그로 기록되어 있는 것을 볼 수 있다. ("주 모드"니 "빠른 모드"니 하는 개념도 있는데 별로 중요하진 않다.) 이 때 [자세히] 탭을 누르고 "XML 보기"로 전환해서 보면 아주 유용한 내용을 볼 수 있다.

  위 그림과 같이 나온다. 대부분 봐도 뭔지 모를 야릇한 숫자들이 잔뜩 있다.

  그런데, 바로 이부분! "FailureErrorCode"라고 된 부분을 보면 이 로그에서 가장 중요한 내용이 적혀 있다. 이걸 기록하기 위해 이 길고 장황한 로그가 작성된 것이라고 봐도 무방하다. 위 그림에 있는 에러 코드는 2148204816. 이 에러 코드가 의미하는 것이 무엇인지 인터넷으로 검색해 봤다.

  참조: Error Codes

  ^^^^^^^^^^^^^^^^^

(위 링크가 열리지 않으면 클릭...)

  바로, CERT_E_WRONG_USAGE, 인증서의 사용 용도가 맞지 않다는 내용이다. 여기서 말하는 인증서는 자기 자신, 즉 로컬 컴퓨터 인증서를 말한다. IPSec의 내부 알고리즘을 상세히 공부해보지 않아 잘 모르겠지만, 그래도 아마도 틀림없겠지만, 연결된 상대방 인증서를 검증하는 것이 아니고 자기 인증서를 검증하는 거다. 즉, 설치된 인증서가 IPSec 용도에 맞지 않다는 에러인 것이다!

  이런 에러를 보면 뭘 어떻게 고쳐야 할 것인지가 감이 올 것이다. 이런 에러가 없으면 참... 난감할 수밖에.

  4. 참고: Mac OS X 에러 로그

  아래는 맨 위에 썼던 Mac OS X L2TP/IPsec VPN 접속 실패 당시 TMG 서버에 기록된 로그다.

  그림에 나와 있는 13805 에러를 찾아보면 협상 중 타임아웃 에러임을 알 수 있다. 즉, Mac OS X와 TMG가 통신을 하는데 TMG에서 보낸 어떤 메시지에 대해서 상대방 측인 Mac OS X가 응답을 하지 않는다는 메시지 임을 알 수 있다. 위에서도 썼지만 포트 문제로 통신이 되지 않았거나 개인키 추출 내부 오류로 인해 응답을 하지 못했음을 알 수 있다. Mac OS X의 문제라는 것을 알 수 있는 대목이다.