이런 테마의 글이 잘 맞는지 안맞는지, 커뮤니티로 가야할 글인지 저도 잘 모르겠습니다. 이에 대해서는 관대하신 낄대인님께서 결정해주실거라 믿고 올려봅니다. 오늘이 휴가 마지막날인데, 그동안 한게 방 바닥에 붙어 비비적대며 기글에 덧글 달며 낄낄거리거나 아니면 아이들을 평소와 같이 봐주고, 놀아주는 것 말고는 한게 없어서, 이 글은 뭔가 그 휴가 기간동안 그나마 하나 했습니다... 하는 자기 위로형 게시글에 속합니다. 다소 길고 재미없을 수 있기에 죄송하다는 말씀 먼저 전합니다.

 

===================================================

법적 책임의 부인(disclaimer): 아래에서는 특정 환경에서의 보안정책을 우회하여, 필요한 서비스를 제한적으로 구성하는 방법을 소개하고 있습니다. 특정 기업이나 조직의 보안정책은 나름의 근거와 이유로 책정된 것이며, 필수불가결한 경우 제한적으로 보안 정책 담당자나 망 관리자와의 협의와 함께, 적정한 책임 소재를 문서화하는 등, 적법한 절차를 거쳐 적용되어야 합니다. 해당 문서의 내용을 실행하여 일어나는 보안사고 및 실행자에게 주어지는 포괄적 피해에 대해서, 본 글의 게시자, 게시처 및 그에 관련된 이해관계자에게 책임이 존재하지 않음을 알려드립니다. 또한, 아래 시나리오에 적혀있는 상세 내용은 가상의 환경을 바탕으로 꾸며낸 것이며, 작성자와 일체의 관련이 없음을 알려드립니다.

===================================================

 

 

여기 기본적인 보안정책을 잘 갖춰놓은 조직이 있습니다. 외부 공공망, 즉 일반 인터넷에 붙어 있는 웹, 앱서버는 별도의 DMZ 공간에 두어, 내부망에서는 접근이 용이하되, DMZ 망에서 내부로 들어오는 경로는 차단하여 최대한 내부망에 보호하는 노력을 들입니다. 이 정도 정책은 기본에 속한다고 할 수 있습니다.

 

여기에 추가로, DMZ 망에 들어 있는 서버들은 인바운드 요청에 대해서만 일정한 처리를 하여 그 결과를 반환할 것이기 때문에, 해당 서버들은 일부 서버 유지보수에 필요한 업데이트 서버를 제외하고 나머지 아웃바운드 경로까지 차단하여 C&C 서버 등으로 이용될 기댓값을 낮추었습니다. 방화벽 세팅만 올바르게 하면, 추가 피해를 막는데는 효과적인 정책입니다.

 

그리고 이 큰 조직 내 하위 말단 조직에서 일하고 있는 개발자 A가 있습니다. 개발자 A는 서버 관리도 겸하고 있습니다. 그의 터미널에는 (모두 GNU/Linux로 구동되는) DMZ 망에 올라가 있는 외부 웹 서비스용 서버 한 대(이하 "서버 P"; Public)와, 내부망에서 24시간 동작하는 관리용 서버 한대(이하 "서버 N"; iNternal)에 접속할 수 있는 방법이 있습니다. 그 웹 서비스용 서버는 그 조직의 하위 도메인 하나를 겨우 얻어 사용하고 있으며, 그 이외에는 다른게 아무 것도 주어지지 않습니다. 그에게는 메일 서버를 연동할 수 있는 MX 도메인도 없으며, 그 도메인을 사고 유지할 수 있는 적정한 예산 집행 방법도 없습니다. DMZ 망에 올라가 있는 서버는 오직 HTTP 요청을 HTTPS로 리다이렉션 시키기 위한 80포트와, 웹 서비스에 사용되는 443 포트만이 개방되어 있습니다. 다행히, Let's encrypt(https://letsencrypt.org/)가 있어 자가 서명 SSL 인증서(self-signed SSL certification) 사용으로 인해 별도의 보안경고 페이지를 보는 일이 없이 웹 서비스에 무료로 SSL을 적용할 수 있다는 사실에 A는 만족하며 살고 있습니다.

 

어느날, 개발자 A의 관리자 B는 A에게 웹 서비스를 추가할 것을 명령합니다: 특정 게시글이 등록되면, 그 내용을 이해 관계자 C와, 관리자 B에게 메일로 전송할 수 있게 하기를 원합니다. 돈도 "더" 안주면서 이런거는 잘 시킵니다. 하지만 A의 주머니에 돈이 들어가게 하려면 B의 말을 들을 수 밖에 없는 것이, 일반적인 인간 사회의 규칙입니다. 이른바 일이 되게 하기 위한 부품인 A는 그에 걸맞게 살아야 하는거죠.

 

메일을 전송하기 위해서는 MTA(Mail-Transfer Agent) 서버가 존재해야 합니다. GNU/Linux에서는 sendmail과 postfix를 손에 꼽을 수 있겠네요. Exim과 Qmail이 빠지면 섭하다고 이야기할 동료가 생각납니다. 하지만 인터넷은 수 많은 스패머(spammer)의 활약으로 인해, 어설프게 MX 레코드가 붙은 도메인 네임과 IP 없이 MTA만 달랑 설치해서는 전송이 성공한다고 하더라도 필경 수신측 MTA에서 퇴짜를 놓거나, 조용히 스팸처리를 하게 될 것입니다. 아까도 이야기 했지만, A에게는 이를 적합하게 실행할 수 있는 예산이 없습니다. 어떻게 해야 할까요?

 

A는 주저하지 않고, *글 메일을 사용하기로 결정합니다. 자애로운 *글은 STARTTLS 프로토콜로 통신 내용을 보호하는 SMTP 접속 방법을 제공해줍니다. G suite에 가입하지 않아도, 많은 양이 아니면 보낼 수 있습니다. 하루에 잘 해봤자 10통 이내의 메일을 보내기에는, mailgun과 같은 유료 서비스를 사용하지 않아도 된다는 거죠.

 

개발자 A는 잘 만들어진 각종 Open-sourced 소프트웨어의 힘과, 스택*버플로, *글 검색엔진의 힘으로 기능을 구현하였습니다. DMZ 망에 라이브로 서비스를 올리는데 다이렉트로 테스트할 정도로 A가 허술하지는 않은 관계로, A는 자신이 접근할 수 있는 내부 서버 N에서 작업을 완료하게 됩니다. 정상적으로 메일이 보내지는 것을 보고, A는 코드를 서버 P에 업로드하고, 작업 완료를 관리자 B에게 알리기 전에 마지막으로 서버 P에서 라이브 테스트를 수행합니다. 이제 퇴근이 눈앞이군요. 클릭. 클릭.

 

...

 

불행히도, 서버 P에서 해당 코드는 올바르게 동작하지 않았습니다. "STARTTLS 접속이 실패했습니다." A가 만들어놓은 디버깅 트랩이 적절하게 동작해서, 원인은 금방 파악할 수 있었습니다. 글이 이미 충분히 길어졌기 때문에, 위의 설명을 네트워크 구조도로 설명하겠습니다:

 

(A의 회사는 비싼 MS Visio를 사주지 않았기 때문에, dia를 사용했습니다...)

 

A가 코드를 올리고, 서비스가 돌아가는 곳은 DMZ 망 내 서버 P입니다. DMZ망은 앞서 이야기한 내용과 같이, 일부 업데이트 서버를 제외하고 나머지 아웃바운드를 모두 막아놓았습니다. smtp.g*ail.com 포트 587 뿐만 아니라, smtp.off*ce3*5.com, 포트 587 접근 역시 여지없이 필터링 당합니다. 그동안 A가 개발한데 사용한 서버 N은 이상 없이 전송이 가능했었고, DMZ 망의 특성을 몰랐던 탓에 (게다가, 보안관리자 Z는 보안이라는 이름으로 그 방화벽의 존재여부와 작동 구성에 대해서 NCND; 즉 확인도 부인도 하지 않습니다.) 자체 퇴근 10분 카운트다운 시계가 박살날 위기에 처해 있습니다.

 

정말로 서버 P에서 smtp.g*ail.com:587 접속이 안되는 것인지 확인하기 위해, A는 openssl의 커맨드라인 명령어를 사용하여 STARTTLS 접속 테스트를 수행합니다:

 

[서버 P] $ openssl s_client -starttls smtp -crlf -connect smtp.g*ail.com:587 <엔터>
CONNECTED(00000003)
Didn't find STARTTLS in server response, trying anyway...
write:errno=32
---
no peer certificate available
---
No client certificate CA names sent

.... <이하 생략>

 

안됩니다. 만약 정상적으로 접속된다면 어떻게 나와야 할까요? A는 서버 N에서 다시 위의 명령어를 날려봅니다:

 

[서버 N] $ openssl s_client -starttls smtp -crlf -connect smtp.g*ail.com:587 <엔터>
CONNECTED(00000003)
depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign

..... <중략>

SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384

.... <중략>

---
250 SMTPUTF8

 

앞서 처절하게 서술한 대로, 하위 말단 개발자 A는 그 조직의 보안관리자 Z를 푸시할 수 있는 힘이 없습니다. 상급 관리자 B를 거쳐, 일반적인 bottom-up 보고 절차를 거쳐 Z에게 푸시를 할 수는 있겠으나, B는 디테일에 대해서는 잘 모르니 힘이 되어주지 못합니다. 하지만 기능이 작동하지 않으면 B는 이와 상관없이 A를 George겠지요.

 

A는 새로운 방법을 강구해야 합니다. DMZ 망의 웹 서버는 외부 Proxy 서버를 탈 수도 없고, 그렇다고 어딘가에 자비를 들여서 VPN 망을 구성해도 이게 괜찮다는 보장이 없습니다. VPN 연결은 그 내용을 알기는 어려우나, 잘 알려지지 않은 obfuscation과 같은 "특별한" 처리를 하지 않는다면, 잘 만들어진 DPI(Deep-packet inspection) 장비에 의해서 연결의 존재 여부는 탄로나기 마련입니다. Z는 여느 똑똑한 보안관리자와 마찬가지로 다소 paranoiac하게 때문에, 외부 장비에 24시간동안 주기적으로 샘플링되는 접속 위치를 의심해볼 여지가 충분합니다.

 

A는 돈이 없고 권한이 없을 뿐이지, 능력이 없던건 아닌 관계로 꼼수를 부리기 시작합니다. 서버 N에서 서버 P로의 SSH 접속은 가능하고, 서버 P는 PKI 인증을 통해 접속이 가능합니다. 이 조건이 만족한다는 것은, 서버 P의 특정 loopback 포트 접속을 통해 서버 N으로 거꾸로 갈 수 있는 터널을 생성할 수 있다는 결론으로 이끌 수 있습니다. 이른바 SSH Reverse proxy입니다.

 

SSH Reverse Proxy를 여는 방법은, 서버 N에서 P로 SSH 접속할 때 -R 옵션과 함께 적절한 파라미터를 대입해주는 것으로 충분합니다:

[서버 N] $ ssh -R 30022:localhost:22 id@server_p's_ip

 

상기 예시를 통해 Reverse connection tunnel을 열어 놓으면, 서버 P에서 127.0.0.1:30022 에 접속하면 서버 N의 22번 포트에 접근하는 효과를 얻게 됩니다.

 

물론, 저 ssh 접속 명령은 핵심만을 포함하는 옵션으로, 기본 행동으로 터미널(vt)을 열기 때문에, 접속을 끊으면 터널도 함께 사라집니다. 영속적으로 ssh 접속을 유지하는 방법은 -N 옵션과 ampersand(&)를 통한 background 동작 뿐만 아니라, 까리한 tmux나 고전적인 screen 명령어를 사용하거나, nohup을 사용하거나, 아니면 autossh와 약간의 bash 스크립팅을 통해서 해결할 수 있습니다.

 

위의 행동을 통해 만들 수 있는 SSH Reverse proxy를 통해서 서버 N에 모든 접속을 통과시킬 수 있는 Proxy를 놓아도 되고, OpenVPN을 올려도 되겠지만, A는 가급적 문제가 생겼을때 발생할 피해를 최소화 하기 위해 SMTP 접속만 사용하기를 원합니다. 누군가 내부망으로 타고 들어오는 일이 벌어지고, 그 경로가 서버 P가 되었을 때- A는, 당연히 직장을 잃게 될 것입니다. 그것도, 제한적인 SMTP 접속만 일어나야 합니다.

 

G suite를 사용하면 SMTP relay가 가능하지만, A는 공짜로 그저 하루에 몇 통을 보내기를 원했기 때문에, 그리고 잘못된 MTA 설정과 악몽같은 sendmail.cf 세팅으로 골머리를 쥐어짜고 싶지 않았습니다.

 

다행히, A는 약간의 구글링 기법을 통해 누군가가 만들어 놓은 E-mail relay 서버 프로그램을 찾았습니다:

 

http://emailrelay.sourceforge.net

 

만약 여기서 이 글을 끝내면 조악하게 짜여진 한편의 기-승-전-광고가 되겠지만, A는 이 오픈소스 서버 프로그램에 눈꼽만큼의 이해관계도 없습니다. A는 디테일하게 쓰는 방법까지 정리하고 싶을 뿐입니다. 다음에 또 이런 환경에 처해질 수 있는 미래의 A를 위해서요.

 

소스코드가 포함되어 있는 타르볼을 적당히 다운로드 하고, *글 SMTP 서버에 접근이 가능한 서버 N에서 작업을 수행합니다.

통속적인 configure - make - (sudo) make install 명령어를 통해서 emailrelay 코드를 빌드하고, 설치합니다. *글 SMTP에 접속하기 위해서는 STARTTLS 프로토콜을 사용할 것이기 때문에, openSSL 헤더가 포함되어 있는 development 패키지가 설치되어 있어야 합니다. configure 할 때 파라미터로 --with-openssl 을 줌으로, 이를 좀 더 확실하게 할 수 있습니다.

 

빌드와 설치가 무사히 완료되면, emailrelay 명령어를 쓸 수 있게 됩니다. *글 SMTP 서버를 사용해야 하니, 이 SMTP 계정에 접속할 수 있는 인증 정보를 어딘가에 저장해야 합니다.

 

인증정보가 담긴 파일을 /etc 아래 만듭니다. 귀찮으니 A는 cat을 사용합니다:

[서버 N, I AM ROOT] # cat > /etc/emailrelay_smtp_conn_info << EOF

> client plain 너의_지*일_주소@gm*il.com 너의_*메일_비밀번호

> EOF

[서버 N, I AM ROOT] #

 

emailrelay는 sudo 등을 사용하여 root 권한으로 실행 시 daemon 계정으로 띄워집니다. 그러므로, 만든 파일 역시 일반 계정으로 조회가 되지 않도록 chown과 chmod로 권한을 조정합니다:

[서버 N, I AM ROOT] # chown root:daemon /etc/emailrelay_smtp_conn_info

[서버 N, I AM ROOT] # chmod 660 /etc/emailrelay_smtp_conn_info

 

이제 emailrelay 서버를 실행합니다:

[서버 N] $ sudo -H emailrelay --as-proxy smtp.gmail.com:587 --interface 127.0.0.1 --port 20587 --client-tls --client-auth=/etc/emailrelay_smtp_conn_info

 

위 명령으로, 서버 N의 loopback interface(127.0.0.1, 또는 localhost), 20587 포트로 email relay 서버를 생성했습니다. 외부 이더넷 주소를 넣을 필요가 없습니다. 어차피 서버 P에서 reverse tunnel로 접속할거니까, 괜히 노출시켜서 위험에 빠질 필요가 없습니다.

 

또한, emailrelay 프로그램은 자동으로 daemonize 되기 때문에, 셸을 종료해도 유지될 것입니다. 이제 reverse proxy만 개통해주고, 서버 P에서는 암호화 없는 Plain SMTP 접근 방식으로 그 포트에 접근하게 세팅하면 됩니다.

 

서버 N에서, P에 접속하며 reverse proxy tunnel을 만듭니다:

[서버 N] $ ssh -R 40587:localhost:20587 id@server_p's_ip

 

즉, 서버 P에서 localhost(=127.0.0.1):40587 에 억세스하면, 서버 N의 20587 포트, 즉, 아까 생성한 emailrelay 서버로 접속되게 됩니다.

 

서버 P에서는 기존의 *글 메일 SMTP 세팅 대신, Plain SMTP 로 설정합니다. telnet을 사용해 간단하게 테스트 해봅니다.

[서버 P] $ telnet localhost 40587

Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 hostname.domainname.com -- E-MailRelay V2.0 -- Service ready
HELO localhost <엔터>
250 OK

... <이하 SMTP 전송 규약에 맞게 타이핑>

 

그리고 *글 메일에 접속해, 보낸 편지함에서 자신이 타이핑 했던 메일이 보이면 세팅이 잘 끝났다고 보면 됩니다.

 

마지막으로 자동으로 서버가 재시작되었을 때 emailrelay 서버를 새로 띄우고, SSH reverse tunnel을 생성하는 부분까지만 자동화하면 됩니다. 그건 내일 해도 괜찮아요. A는 이제 집에 갈 수 있습니다. emailrelay 서버의 안정성을 확인하는 것 역시, 내일 해도 괜찮습니다. 코드는 볼 수 있으니, 많은 노력을 기울이면 더 안전하게 꾸며낼 수 있는 방법도 있을것입니다.

 

A는 게시글을 작성하여 B와 C에게 서비스가 가능함을 알리고, 아이들이 있는 집으로 갑니다.

 

TL;DR - 개발자 A는 어려움에 빠졌지만, 약간의 꼼수를 발휘해서 잠재적인 리스크를 잔뜩 껴안고 임무를 완수합니다. 어찌되었건 완료했으니 A는 집에 갈 수 있습니다. 집에는 A가 사랑하는 가족이 있습니다. 그걸로도 충분합니다. 지금은요.