최근 SecureGuard AM을 사용할 기회가 생겼다. 관리하는 서버 수가 많아지고, 서버에 접근할 수 있는 사람이 많아짐에 따라서 접근 관제에 대한 필요성이 나왔기 때문이다. 시큐어가드를 써본 적 있는 분의 추천으로 단기간 사용해 보았다.

이 글에서는 깊은 내용 까지는 다루지 않는다. 인터넷에 SecureGuard와 관련된 글이 많지 않고, 보안과 관련이 있는 부분이 있을 수 있기 때문이다. 공식 페이지의 브로슈어에 나와있는 내용만을 다룬다.

혹시나 이 글을 보고 써보고 싶다면 필자 처럼 nCloud Marketplace에 월 단위 상품이 있으니까 써보자. 참고로, 필자는 따로 돈을 받은 적이 없고, SecureGuard 측과 관련이 있지 않다.

우선 알아야 할 것…

SecureGuard를 사용하기 위해서는 우선 계정을 만들어야 한다. 해당 계정에 SSH, SFTP, FTP, RDP 등의 접속 정책을 넣어야 원격지에 연결 할 수 있다. 계정을 기반으로 접속 관리를 할 수 있다. 추가적인 보안을 위해 계정에 2FA 인증을 켤 수도 있다. SecureGuard의 비밀번호만 알았다고 끝이 아니다. 해당 서버(SSH, RDP)의 계정 정보도 알아야 한다.

브로슈어 상에서는 SecureGuard PM을 쓰면 비밀번호 관리? 같은게 된다고는 하는데, 써보지 않아서 확신이 없다.

원격지 접속은 SecureGuard AM 서버를 거치게 된다. 쉽게 말해서 중계 서버이다. SecureGuard AM을 내부망에 두면 Jump 서버 처럼 활용 할 수도 있을것 같다. 모든 원격 접속이 SecureGuard를 통하는 구조이므로 방화벽에 SSH, RDP에 SecureGuard AM측 IP만 허용하면 된다. 그러므로 방화벽 정책도 깔끔해진다. (임시로 풀어놓은 IP가 수년째 방치되는 일이 없어진다)

반대급부로 SecureGuard 서버 자체가 해킹 당하면, 모든 방향으로 원격 접속이 가능할 것 같은 구조이다. 모든 목적지에 SecureGuard AM서버 측 IP를 연결 허용 해놔야 하기 때문이다.

결과적으로 서버를 접속하기 위해서는 [SecureGuard에 로그인 (2FA, IP Whitelist 등 적용)] -> [SecureGuard AM 중계 서버 접속] -> [서버에 로그인]의 과정이 걸쳐진다.

공격자는 다음 정보를 알아야 SSH, FTP, RDP 등으로 접속할 수 있다.

• “SecureGuard가 적용되어 있다는 정보” 자체를 알아야 함
• SecureGuard 로그인 정보 (2FA 적용시 사실상 불가능)
• SecureGuard 서버 IP
• 원격지 서버 IP
• 원격지 서버의 접속 정보 (계정 정보 또는 private key)

SecureGuard AM 서버를 거치는 구조

모든 원격지 접속은 SecureGuard AM 서버를 거쳐야 한다. SecureGuard AM 서버 한 곳에서 원격지 접속에 관한 모든 관리를 할 수 있다.

A라는 사람이 C 라는 서버에 접속했다? 그러면 SecureGuard AM 서버에 사용자 정보, IP, 시간 등이 모두 로그화 되어 있을 것이다. B라는 사람이 C에 접속한 것도 모두 로그화 되어 있다. “무조건 거쳐야 하는 관문”이므로, 이곳에서 접근 통제만 하면 왠만한 의심스러운 연결을 막을 수 있다. 쉽게 생각해서, 사무실 IP만 접속 허용하면 사무실 외에서는 접속 자체가 불가해 진다.

Socks5 지원

SecureGuard는 Socks5 프로토콜을 사용한다. Socks5를 지원하는 SecureCRT, Putty가 있다면 간단한 설정을 통해서 바로 서버에 접근 할 수 있다. 기존에 사용하던 원격 접속 프로그램을 그대로 사용할 수 있다는 것은 큰 장점이 된다.

Socks5에는 Username + Password를 통한 인증 기법이 있다. (RFC1929) SecureGuard도 이것을 활용한다. 실제로 SecureCRT에 Socks5 + Username: SecureGuard ID, Password: SecureGuard PW를 넣으니 잘 붙는것을 확인했다.

Socks5 인증과 원격지 접속 인증은 다르다. 지금 이 부분에서는 Socks5 인증을 이야기 한다. Socks5 인증을 통과 하더라도, 실제 서버의 로그인 정보가 필요하다.

Socks5는 프록시 서버를 접속하기 위한 인증이다.
원격지 접속 인증은 실제 서버에 로그인 하기 위한 정보이다. 쉽게 SSH 로그인 정보라고 생각하면 된다.

다만에, 몇가지를 테스트 해 보니까 Socks5를 정확하게 (RFC대로) 구현하지는 않은 것 같다. 일부 상황에서 잘못된 Username, Password를 입력했더니 “무한 대기”에 빠지는 현상이 발견됐다. 주변 사원들에게 사용법을 알릴때 작동이 안한다! 하면 대부분 이 문제였다. 추후에는 로그인에 실패하면 “실패했음”을 알려주거나, CONNECT 명령시 0x01(일반 실패) 또는 0x02(권한 없음)을 내주면 좋을것 같다.

Socks5 프록시로 어떻게 세션 녹화를 하는가?

SSH, SFTP, RDP 모두 암호화 기법이 들어가 있다. 프록시 서버는 연결을 중계만 한다. 암호화 된 데이터는 중간에서 뜯어볼 수 없다. 만약 중간에서 데이터를 뜯어 볼 수 있었다면, 진작에 MITM 패치가 이루어졌을 것이다. 그러므로 그냥은 세션을 녹화하는 것은 불가능 하다.

이것을 파훼하기 위해서 결과적으로는 MITM 기법을 이용한다. SecureGuard의 “가상 쉘”을 거치게 된다. 즉, SecureGuard 내부에 가짜 SSH, RDP 서버가 돌아가고 있다. 사용자는 SecureGuard Proxy를 통해서 원격 서버와 “직결”한 것과 같은 체험을 한다. 하지만 실제로는 SecureGuard 내부의 가상 쉘에 접속을 한 것이며, 모든 입출력은 가상 쉘 단에서 캡쳐된다.

실제 사용자는 원격 접속 클라이언트(Putty) – 가상 쉘 구간까지만 연결한 상태이다. 실제 서버에 명령어를 친다고 생각하지만, 사실은 가상 쉘 서버에 명령어를 입력한 꼴이다. 가상 쉘 서버는 모두 SecureGuard측이 만든 것이므로, 세션 녹화, 명령어 실행 차단등이 모두 가능하다.

우선 가상 쉘에 접속하므로, SSH가 없는 윈도우 서버로 접속을 시도해도 SSH Server Hello가 나온다. 심지어 죽어있는 서버에 접속해도 그렇다. 다만, Server Hello를 보내자 마자 실제 서버로 접속을 시도하는 것 같다. 죽은 서버에 접속 시도시 무한 대기(블로킹) 상태에 들어가기 때문이다. 사용자 입장에서는 “어쨌든 접속이 안되는 서버는 (죽어있는 서버는) 접속이 되지 않는다”로 보인다. 일반 사용자 입장에서는 경험이 동일하다.

RDP는 어떻게 접속하는가?

SecureCRT, Putty와 같은 프로그램은 Socks를 지원한다. 그러나 mstsc는 socks5를 지원하지 않는다. 그러면 RDP는 어떻게 접속할까? 아주 자세히 알아본 것은 아니지만, Proxifier와 같은 후킹을 사용하는것으로 의심된다. 즉, Connect()를 함수를 후킹해서 프록시 서버와 연결된 소켓을 사용하는 것이다.

그렇게 의심한 이유는 RDP를 연결한 상태에서netstat -nta 를 찍어 봤을때도 SecureGuard의 프록시 서버만이 보였기 때문이다.

보안을 위해서 자세한 정보는 넘어간다.

Wireshark를 이용해서 패킷을 확인해본 결과, Socks5 프록시를 사용하긴 한다. 그러나 특수 처리된 Username, Password를 사용한다. 그러므로 Proxifier 등을 들고와도 Socks5의 Username, Password 때문에 왠만하면 연결 할 수 없다. Username, Password에 규칙 자체는 있는데, 아무런 생각 없이는 맞추기 불가능 하다.

참고로 Username 또는 Password가 틀리면 무한 대기가(블로킹) 발생한다. 혹시나 Proxifier 등으로 접속을 시도할 때 무한 대기가 발생한다면 Username, Password 문제일 가능성이 매우 높다.

Socks5가 없는 커스텀 프로그램은 어떻게 하나?

개발을 하다 보면 SSH 프로토콜을 사용해야 할 때가 있다. 예를 들어, Git 서버를 운영한다면 SSH 프로토콜을 사용하는것이 일반적이다. Ansible을 사용할 때에도 SSH로 원격 서버에 접근할 수 있다. 그 외에도 시스템 정보를 수집하기 위해 프로그램이 SSH를 접근할 수도 있다. SSH뿐 아니라 RDP의 경우도 마찬가지다.

지금과 같은 구조에서는 무조건 SecureGuard를 거쳐야 한다. 하지만 프로그램 구현상 여건이 어렵다면 직접 프록시 접속기를 만들어야 한다. 필자는 주기적으로 SSH에 접속하여 간단한 프로그램을 실행하는 프로그램을 운용중이었다. 문제는, 이 프로그램에 Socks5를 집어 넣는것이 불가능 했다는 것이다.

그래서, 다음과 같은 프록시 유도 서버를 만들었다. 원격 접속이 필요한 서버가 11개가 있다고 했을때, 127.0.0.1:30000 ~127.0.0.1:30010 에서 Listen하는 프로그램을 만든다. 각 포트는 소켓 Accept시 사전에 지정된 주소로 프록시 연결을 만든다. Ansible 같은 SSH 클라이언트는 실제 서버에 접속하는 대신, 127.0.0.1:30005 등에 접속한다. 그러면 어쨌든 프록시가 안되는 환경에서 프록시를 태울 수 있다.

혹자는 방화벽에 특수 정책을 넣으면 되지 않냐…라고 한다. 하지만 필자는 그러다가 어디서 구멍이 뚫려서 문제가 생긴다고 말하고 싶다.
어짜피 SecureGuard를 도입했다면, 모든 접속을 SecureGuard를 거치게 하는 것이 좋다고 본다.

물론, 해당 프로그램을 만들어야 한다는 것이 번거롭다. 게다가 접속 타겟을 지정하는게 번거로울 수 있다. (기존에는 hostname으로 접속했지만, 이제는 안된다.) 프로그램을 만들어야 한다는 것 자체는 어쩔수 없다. 하지만 리눅스 환경이라면 127.0.0.1/8이 전부 Loopback임을 활용하여 조금은 편리하게 서버 구성을 할 수 있다. /etc/hosts 에 sv1.local -> 127.0.0.2, sv2.local -> 127.0.0.3 와 같이 구성하고, Accept시에 Local EndPoint를 확인하면 도메인을 확인하거나 동적으로 서버를 라우팅 할 여지가 생긴다.

결론

원격 서버의 접근 관제용으로는 상당히 좋은 프로그램 같다. 특히 Socks5를 쓰기 때문에 확장성이 생긴다. 이상한 자기만의 프로토콜을 사용했다면 위와 같이 커스텀 프로그램도 애초에 만들 수 없었을 것이다.

그런데, “과연 타사 제품보다 좋은가” 라고 묻는다면 잘 모르겠다. 아마 가장 대표적인 대안 프로그램은 Teleport일 것이다. 이미 7년전 이야기이므로 잘은 모르겠다만은, 그 당시의 기억으로만 봐도 tsh 라는 프로그램 제공, 웹 기반 접속 지원등에 있어서 SecureGuard 보다 더 편했던것 같다. 필자는 리눅스(Mint) 환경에서 작업했기에 더 그렇게 생각했을 지도 모른다.

다만에, 국내+윈도우 환경에서는 CLI 또는 웹 기반 접속보다 SecureCRT, mstsc에 익숙한 사람이 더 많으므로 SecureGuard가 편하다는 사람은 더 많을 것 같다. 만약 조금의 사용자들 이라도 Mac 또는 리눅스를 사용했다면 Teleport가 압승이지 않을까 생각이 든다.

최근에는 입사시 Mac 지급, Mac을 통한 개발 등등을 내세우는 기업이 많아졌다. 과연 최근의 젊어진 개발 분위기 속에서 SecureGuard가 살아 남을 수 있을지 모르겠다. 윈도우에서만 네이티브로 사용할 수 있다는 점에서 ActiveX와 같은 장애물로 굳어질 것 같다. 공공 기관 상대로는 잘 되겠지만, 최근의 사기업을 상대로 한다면 분명 Teleport 처럼 플랫폼 다변화 혹은 웹 접속 지원을 해야할 것으로 보인다.