스타트업을 위한 해킹 방어 테크닉

스타트업에서 세상을 변혁하는 이들은 해커들이 무엇을 노리고 왜 이렇게 영세한 업체를 공격하는지를 알지 못한다. 하지만 서비스가 성숙되지 않은 상태에서 해킹을 당하는 서비스를 보면 이유는 간단하다. 해커들도 연습할 트레이닝 상대가 필요하기 때문이다. 한마디로 스파링 뛰는 것이다. 모의 해킹이나 모의 해킹 케이스는 볼 만큼 봤으니 정말로 ‘다들 이 정도는 막아 놓고 살 것 같지만, 현실은 그렇지 않은지’ 호기심으로 해킹은 시작된다.

이 경우 대부분 해킹을 시작한 IP가 해커들의 가정집이거나 스타벅스와 같은 커피숍, 학교 PC인 경우가 대부분이다. 안타깝게도 수백 번의 해킹 중 한 번 정도 추적을 당하거나 법적인 제재를 받는다. 해커는 심한 장난을 치지 않는 한, 잘 걸리지 않는다.

내가 아는 희귀한 해킹 사고 체포 사례는 여자 친구와 헤어지고 술을 마신 뒤 사무실에서 정통부 홈페이지에 실연의 아픔을 토로했다가 걸린 경우이다. 한두 번의 해킹 성공은 연쇄 살인마처럼 기법을 발전시킨다. 연쇄 살인마의 첫 살인은 흥분과 당황으로 여러 단서를 남겨놓지만, 살인이 진행될수록 점점 기법은 세련되고 단서는 적어진다고 한다. 해커들도 이런 수련생 생활을 가진다.

해커 대부분이 스타트업 홈페이지를 노리는 이유는 대체로 제대로 된 보안이 없기 때문이다. 개발하기 바쁜데 보안은 당연히 뒷전이고 보안 전문가가 아니라 플스택[footnote]full stack. 한 마디로 모든 걸 다 할 줄 아는 개발자를 풀스택 개발자라고 한다.[/footnote] 지향으로 인해 지식의 한계도 있다. 일의 범위 역시 모바일부터 서버, DB까지 넓은 범위를 포괄한다. 요즘은 개발자도 시스템 엔지니어(SE) 업무가 가능하다는 클라우드의 패러다임이 생김에 따라 아마존웹서비스(AWS) 등 클라우드를 이용해 개발자가 서버를 설치하는 것이 일반적이다.

해커가 스타트업 사이트를 해킹했을 때 대부분의 스타트업 개발자는 이구동성으로 이렇게 말한다.

“우리 서비스는 그리 유명하지도 않고 시작한 지 얼마 되지도 않았는데 왜 해킹을 당했는지 모르겠어요!”

영화 [올드보이]는 이런 대사가 나온다.

“내가 누군지는 중요하지 않아요, ‘왜?’가 중요하지.”

예를 하나 들어보자. PHP라는 언어에서 기본으로 제공하는 phpinfo();가 얼마나 많은 정보를 주는지 아는가?

보안 취약점에 관한 뉴스가 나오고 언더그라운드 해킹 사이트에서 해킹 방법이 담긴 영상, 스크립트 파일, 봇 등이 공유된다. 해커가 되려는 해킹 수련생들은 브루트 포스[footnote]brute force. 무차별 대입.[/footnote] 형태로 특정 IP 대역을 긁어 그중 원하는 취약점이 있는 사이트를 찾는다.

그들이 이제 막 서비스를 개발 중인 스타트업인지 아닌지는 처음부터 고려 대상이 아니라는 것이다. 보안 취약점이 있어서 자신의 해킹 프로그램이나 기술이 통하는지만 본다.

스타트업이 하지 말아야 할 것 3가지

테스트 서버를 라이브 서버로 전환해서 사용하지 마라.
테스트 서버 소스를 복사해서 라이브 서버로 돌리지 마라.
테스트 서버는 public으로 열지 마라.

흔히 하는 실수가 서비스 오픈이 급한 나머지 테스트 서버를 라이브 서버로 전환하는 것이다. 문제는 테스트 서버는 수많은 개발자들이 다양한 세팅과 설치했던 기억까지 잊어버린 경우가 많다는 점이다. 삼성카드가 IDC 화재로 테스트 서버를 라이브 서버로 전환해서 사용한 것은 보안의 관점에서 절대 하지 말아야 할 리스크를 안고 서비스를 개통할 수밖에 없었던 차차선이였다고 볼 수 있다.

테스트 서버를 퍼블릭 IP, 즉, 인터넷 환경에 그대로 오픈하면 해커들이 해킹을 위해 사전 준비 단계인 스캐닝에 당할 가능성이 높다. 서비스가 돈과 연관되면 될수록 해커들은 상대적으로 관심과 보안이 덜한 테스트 서버부터 점령을 시작한다.

당연하지만 지키지 않는 3가지

RDP[footnote]Remote Desktop Protocol. 기본적으로 TCP 포트 3389를 이용해 원격지에서 특정 컴퓨터에 접속해 제어하는 프로토콜.[/footnote], SSH[footnote]Secure Shell. 네트워크상의 다른 컴퓨터에 로그인해서 각종 명령을 실행하는 원격 터미널 접속 서비스. 기본적으로 TCP 포트 23를 이용하며 상대적으로 보안에 취약한 telnet, rlogin 등을 대체해 이용한다.[/footnote]를 퍼블릭 IP로 열지 마라.
DB 포트도 열지 마라. 편하다고 MySQL을 root[footnote]시스템의 최상위 관리자를 지칭한다.[/footnote] 계정으로 사용하지 마라.
회사 앞 카페는 정글이다.

하루에 수십 만 건의 댓글이 달리는 스타트업 서버의 SSH가 열려 있었다고 하면 믿지 않을 수 있다. 하지만 그 정도는 약과이며 해킹 당한 서버를 재설치 하지 않고 악성 코드만 제거한 다음 DB의 root 비밀번호를 바꾸지 않고 몇 년간 사용한 회사도 있다. MySQL을 root로 실행하고 퍼블릭 IP 오픈이 되어 있다면 외부에서 쉘[footnote]shell. 텍스트로 입력하는 명령어 처리기를 뜻한다.[/footnote]을 통해 MySQL을 실행할 수 있다. 즉, 5분 안에 바로 점령할 수도 있다는 말이다.

많은 개발자가 일의 효율을 위해 카페에서 일한다. 일하는 공간의 문제는 크게 말할 것이 아니지만, 카페에서 제공하는 와이파이로 일하는 것은 문제다. 대부분 카페의 무선 인터넷은 보안 패치에 관심을 가지지 않는다. 이미 해커들에 의해 점령된 커피숍의 와이파이 기기는 심심치 않게 볼 수 있다.

많은 해커가 유명 웹사이트와 앱을 해킹하기 위해 그 회사 주변의 커피숍의 와이파이를 해킹하거나 무료 와이파이를 거짓으로 만드는 방법으로 서버 원격 접속 계정을 탈취한다. 지금도 이 방법은 유용하고 개인적으로 잘 사용하는 기법 중 하나다. 많은 프로그래머가 데이터 요금 때문에 스마트폰 테더링을 사용하지 않기에 거의 대부분 기업에서 사회공학적으로 잘 통하는 방식이다.

흔히 대중이 생각하는 것처럼 해커들이 고도의 해킹 기법으로 방화벽을 뚫고 서버의 root 권한을 뚫는 영화 같은 방법들은 충분한 시간과 노력을 투자해야 하기 때문에 대부분 가성비가 맞지 않아 잘 하지 않는다.

해킹의 흔적을 찾기 쉬운 방법

터미널 히스토리를 살펴보라.
현재 접속 중인 유저가 누구인지 살펴보라.
fail2ban과 슬랙을 사용하라.

리눅스에는 history라는 명령어가 있다. 즉 터미널에서 사용자가 어떤 명령을 실행했는지를 확인할 수 있는 기능이다.

여기에서 언제 실행했는지 정확히 알면 더 도움이 된다.

[box type=”info”]

history에 실행 시각 추가하기

1. /etc/profile에 아래 내용 추가
# vi /etc/profile
HISTTIMEFORMAT=”%F %T — ”
export HISTTIMEFORMAT

2. 적용 하기
# source /etc/profile
[/box]

나와 친분이 있는 전직 해커이자 시스템 엔지니어는 매일 아침 출근해서 history를 체크하여 대부분의 보안 이슈에 대응했다. 무려 200대의 서버를 간단한 쉘 스크립트와 grep[footnote]파일 속의 문자열을 찾는 명령어.[/footnote] 명령어를 통해 관리하고 있다.

많은 바보 같은 해커들은 history 전체를 삭제하는 일을 벌려 꼬리를 잡힌다. 장담하건대, 중급이 넘는 해커일수록 history를 삭제한다. 사실 서버에 로그인한 해커들이 먼저 보는 것이 history로 서버에서 서버 관리자가 무슨 행위를 했는지를 분석하는 것이다.

왜 fail2ban인가?

최근 iOS 9의 비밀번호 관련 보안 기능이 각광을 받고 있다. FBI에서 테러리스트의 휴대폰 비밀번호 6자리[footnote]아이폰은 비밀번호로 숫자, 문자를 입력할 수 있다.[/footnote]를 깨려다가 5년 이내에는 깨지 못한다는 답을 얻자, 애플에 백도어 설치를 요청했던 것이다.

아이폰은 입력한 비밀번호가 틀릴 때마다 입력에 지연 시간(1/12초)을 뒀고, 4회 이상 틀리면 추가 지연 시간이 발생한다. 비밀번호를 9번 틀리면 1시간 동안 입력을 시도할 수 없고, 10번 틀리면 데이터를 자동 삭제하도록 설정할 수도 있다.

fail2ban도 비슷한 역할을 한다. fail2ban은 유닉스, 리눅스용 보안 프로그램으로 대표적인 해킹 방지 솔루션이다. 무료라는 점도 매력적이다.

일정 횟수 로그인 실패가 발생할 경우 지정 시간 동안 로그인을 거부하거나 일정 로그인 실패가 있으면 아예 블랙리스트에 등록시켜 접근을 차단할 수 있다. 설치와 운영은 간단하고 매우 효율적이다.

최근 카드사 선불카드의 카드 번호, CVC를 브루트 포스를 통해 유출한 사태를 방지하는 데에 도움이 되는 기술이다. 절대적인 시간은 해커도 스킵할 수 없는 허들이 된다.

여기에 내가 잘 사용하는 것은 fail2ban 로그를 슬랙(Slack)[footnote]업무용 메신저로 데스크탑, 모바일을 모두 지원하며 써드파티 서비스를 연동할 수 있는 등 많은 편리한 기능 덕에 인기가 많다.[/footnote]과 연동해서 로그를 슬랙에서 받아보는 것이다. 지금도 슬랙 알람을 통해 해킹 시도를 확인하고 있다. 슬랙과의 연동은 스타트업에서 사용하기에 유용한 통합 보안의 포인트가 될 수 있다.

중요한 것을 강조하는 비주얼한 대시보드를 만들어라

대시보드(dashboard)라는 개념이 여러 시스템에서 중요해진 사건 중의 하나는 체르노빌 원전 사고라고 한다. 원전의 제어실 사진을 살펴보면 엄청나게 많은 계기판이 존재하고 중요도에 관계없이 기능적으로 배치되어 있었다.

막상 사고가 나자, 엔지니어들은 각종 지표를 읽어 해석하고 어떤 상황 판단을 내려야 할지에 대한 판단을 쉽사리 할 수 없었고 각종 데이터를 오독했다고 한다. 사고에 대한 분석 보고서가 원전 전문가들에게 공개되고 재해 방지 전문가들이 분석했고, 원전 제어실이 너무 복잡하고 한 눈에 상황을 파악할 수 없어서 사고를 냈다고 평가했다.

통합 보안 솔루션에서도 이런 대시보드의 철학이 들어가 있다. 가난한 스타트업은 이런 고가의 솔루션을 사용할 가능성도 없기에 무료로 이용할 방법을 소개하고자 한다.

마이크로소프트 애저 애플리케이션 인사이트 (Microsoft Azure Application Insight)
스플렁크 (Splunk)

마이크로소프트 애저에서 지원하는 어플리케이션 인사이트는 서버의 상태와 어플리케이션의 상태를 모니터링하고 각종 로그를 비주얼하게 보여주는 웹 기반의 클라우드 솔루션이다. 마이크로소프트 제품이라 윈도우 서버만 지원하는 것이 아니라 파이썬, 자바 등 다양한 언어와 로그4제이(Log4j) 등도 지원하여 각종 로그를 이쁘게 비주얼라이징할 수 있다.

애저는 클라우드이고 유료 서비스라는 편견이 있지만, 다음 가격 정책을 보면 어떻게 체리 피킹을 할 수 있는지에 대한 아이디어를 얻을 수 있을 것이다.

서버를 포함한 각종 디바이스 숫자 무제한, 세션 수 무제한, 데이터 포인트 월 5백만 개까지 무료이다. 물론 7일간 데이터를 저장한다는 것은 한계이지만 스타트업의 보안 운영 스타일에서 충분하다.

애플리케이션 인사이트의 장점은 서버 CPU, 메모리, 웹 서버 상태, 에러까지 하나의 대시보드로 비주얼하게 보여줄 수 있을 뿐 아니라, 스타트업이 만든 서버의 각종 로그까지도 비주얼하게 중요도에 따라 보여줄 수 있다는 것이다.

하나의 서비스 운영 대시보드로써 fail2ban, SSH 접속 유저 수 통계 등을 비주얼하게 노출하면 서비스 공격과 비정상 지점을 쉽게 인지하도록 만들 수 있다. 이런 데이터는 아마존웹서비스(AWS)에 있는 VM[footnote]Virtual Machine.[/footnote]이나 PaaS[footnote]Platform as a Service. 인터넷으로 애플리케이션 개발·배포에 필요한 하드웨어와 소프트웨어를 제공하는 방식.[/footnote]라도 쉽게 연동할 수 있다.

클라우드를 사용하고 싶지 않다면 “스플렁크”를 추천한다. 스플렁크를 아는 사람들이라면 데이터 분석, 통계 쪽 사람들일 것이다. 스플렁크는 고가의 데이터 분석 솔루션이지만, 500MB 이내의 데이터를 사용한다면 무료 솔루션이다.

최고의 장점은 비정형 로그뿐 아니라 시스템 로그를 대시보드로 꾸미는 것까지 1시간이 걸리지 않는다. 초보자라도 기초 스터디를 보면서 기본적인 로그 대시보드를 하루 안에 만들 수 있다.

맺는 말

스타트업은 시간이 돈이고 작은 인력이 모든 것을 바친다. 하지만 그들은 보안 전문가가 아니다. 개발 결과물을 내기도 급급한 사람들이다. 그들을 위한 보안은 간단하고 비용이 적으며 간단한 원칙을 지켜야 한다.

모 소셜커머스 CTO가 나에게 이렇게 말 한 적이 있다.

“iptables는 오버헤드가 많아 앞단에 방화벽이 있다면 서버에 설치하지 않아도 됩니다.”

나는 이렇게 말했다.

“방화벽을 넘어 서버 한대가 뚫리면 다른 서버로 전이를 막는 것이 iptables입니다. 오버헤드가 있는 것은 시스템 엔지니어가 컴맹이거나 발로 셋팅했다는 말입니다.”

그는 CTO이지만 보안 전문가는 아니였다. 그의 결정은 각 서버간 아방가르드한 자유로운 통신을 보장하고 있다. iptables가 없고 누구나 root로 접속하는 개발은 편하겠지만, 라이브 서비스로는 결격이라 나는 믿는다. 그들이 서비스로는 성공했지만 언젠가는 SK컴즈, KT 등처럼 대규모 개인정보 유출 사건이 발생할 수도 있을 것이다.