윈도우 서버 감사로그 분석 시스템 구축(하)

뜻이 있는 곳에 길이 있다 - 감사로그 분석 시스템의 완성

서버 OS 시장에서 매우 높은 점유율을 자랑하는 마이크로소프트 윈도우 운영체제. 널리 사용되는 운영체제인 만큼 윈도우는 수많은 보안 위협들이 존재한다. 현재 많은 기업이 이러한 보안 위협을 피하기 위해 많은 비용과 투자를 한다. 그렇다면 빅데이터 처리 기술을 응용하여 더 비용 효율적으로 윈도우 운영체제의 허점을 이용한 외부 공격을 예방하고 침입을 탐지할 수 없을까 빅데이터 기술 전문가 6기 윈도우 감사로그 분석팀(이하 감사 로그팀)은 이러한 문제를 해결하기 위해 ‘윈도우 서버 감사로그 분석’이라는 프로젝트에 도전했다.

글: 정하권(기술 전문가 과정 6기)

앞 연재에서 윈도우 서버 감사 로그를 주제로 선정한 배경과 목표 달성을 위한 도구를 알아보았다. 우리는 보통 어떤 어떤 일을 맡았을 때, 기존에 갖고 있던 경험과 지식을 동원해 해결하려고 한다. 하지만 늘 새로운 기술이 나오는 IT 분야에서만큼은 이 방법은 그리 잘 통하지 않는다. 늘 새로운 기술이 나오는 이유는 그만큼 예외 사항이라든가 요구 조건이 다양하다는 뜻이기도 하다. ‘감사 로그팀’도 수료 프로젝트를 진행하기에 앞서 조금이라도 알고 있거나 경험이 있는 기술과 도구를 적용하려 했다. 하지만 호미로 막을 일이 있고, 가래로 막을 일이 있음을 실감하고 처음부터 새로 시작하여 하나씩 풀어나갔다.

지난 첫 연재에서도 도전과 시련의 연속이었듯이 이번에도 문제 상황의 연속이었다. 문제가 없으면 재미도 없는 법이다. 혼자가 아니었고 팀원과 멘토까지 있었기에 다시 힘을 내어 목표를 향해 나아갔다.

실시간 처리 장벽에 부딪히다

Redis에 쌓인 로그를 다시 Logstash을 사용해 Elasticsearch에 저장하도록 설정하고, 다른 한쪽은 Storm에서 가져가도록 프로그래밍 하려 했다. 하지만 여기서 예상하지 못했던 난관에 부딪혔다. Storm에서 Redis로부터 데이터를 가져오기 위해 Redis를 들여다 보면, 데이터가 없는 것이었다. Redis에 로그 데이터를 보냈는데도 말이다. 문제가 해결되지 않아 계속 골치를 썩고 있을 때, 윤재문 팀원이 문제 해결의 실마리를 찾아냈다. 그것은 다름 아닌, Logstash에서 Redis로 전달하는 로그의 데이터가 ‘list’ 형태로 전달된다는 것이었다. 이 형식으로 로그를 전달하면, 중간에 한 명이 이 데이터를 가로채 가져가면서 메모리 기반의 Redis 저장소가 비게 되는 것이었다. 즉, Redis에 전달된 데이터를 Elasticsearch 저장소로 전송하기 위해 Indexer 역할을 하는 Logstash에서 Redis의 쌓인 데이터를 가로채고 있었다.

원인을 파악하고 난 뒤에 문제 해결은 그리 어렵지 않았다. 처음에 Logstash에서 Redis로 로그를 전달할 때 ‘list’ 데이터 형태로 전달하는 대신에 ‘channel’로 전달되게 바꿨다. 이는 Redis에서 제공하는 1:N의 가입자/구독 형태 모델로서 channel에 가입한 Subscriber들 모두에게 특정 이벤트를 전달하게 하는 구조다. 따라서 Storm과 Logstash를 통한 Elasticsearch 저장소, 두 곳 모두에게 로그를 전달할 수 있게 됐다.

실시간 보안 위협 대응 방안

Logstash로 수집한 윈도우 보안 이벤트 로그를 Redis에 저장한 다음, 원하는 최종 목적지로 데이터를 전달하는 과정까지 기본 프레임워크가 완성되었다. 하지만 ‘보안 위협 요소를 사전에 발견하고 대응할 수 있어야 한다’는 최종 목표 지점에 도달하기 위해서는 위협 데이터를 가시화하고, 최종 사용자에게 알림 메시지를 줄 수 있어야 했다. 이에 우리팀은 두 가지 솔루션을 갖고 최종 마무리 작업을 진행했다.

첫 번째로 Elasticsearch의 강력한 플러그인 중 하나인 Kibana를 활용한 보안 위협 대시보드의 구현이다. 앞서 언급한 바와 같이 Elasticsearch는 다양한 플러그인을 갖고 있다. 그 중에서 Kibana는 데이터를 가시화해 대시보드 형태로 보여줄 수 있다. <그림 2>와 같이 Elasticsearch에 저장된 로그 데이터를 가져와서 웹 UI에서 사용자가 손쉽게 검색하고 대시보드를 구현할 수 있는 것이다. 이에 따라 우리팀은 계정 로그온 감사 실패 이벤트를 이용해 보안 위협 대시보드를 구현하기로 했다.



우리팀은 무차별 대입 공격(Brute Force)을 체크하기 위해 계정 로그온 감사 실패 이벤트 로그 데이터에 존재하는 상태 값(상편의 <표 4> 참고)을 기준으로 대시보드를 구성해 보았다. 해당 이벤트 안의 상태 값은 다양한 종류가 있지만, 그 중 사용자 계정은 일치하나 패스워드가 틀린 항목에 대해 발생하는 상태 값인 0xC000006A 상태 값을 체크해(공격자가 기본 admin 계정에 Brute Force 공격을 시도했다고 가정) 해당 이벤트를 많이 발생시킨 공격자의 호스트와 공격 대상이 된 호스트로 <그림 3>과 같이 간단한 대시보드를 구현했다.



<표 1> 계정 감사 로그온 실패 이벤트 상태에 따른 설명(Audit account Failed logon events (Ex : Status = 0xC000006A)



두 번째로 실시간 처리 분석 기술인 Storm을 사용해 보안 위협을 사용자에게 실시간으로 알려줄 수 있는 기능을 구현하기로 했다. Elasticsearch를 실시간 검색하고 대시보드에서 확인해 보안위협 요소를 파악할 수 있지만, 이는 사용자가 해당 위협을 감지하기 위해 보안 위협에 대해 지속적으로 모니터링해야 하므로 현실적이지 못하다. 이 문제를 해결하기 위해 우리팀은 다음과 같은 고민을 하기 시작했다. ‘만약 짧은 시간 동안 특정 대상을 노리고 무차별 대입 공격으로 볼 수 있는 이벤트가 다량으로 들어오면, 보안 위협으로 판단해 해당 서버 운영자에게 실시간으로 알려준다’. 이러한 고민 끝에 우리팀은 현재 시점에서 ‘이전 3초 동안 시도한 대상 호스트의 접속 실패 카운트’를 실시간으로 Storm 서버 콘솔 화면에 출력하도록 프로그램을 설계했다. 즉, 계정 로그온 감사 실패 이벤트가 짧은 시간에 특정 호스트에서 얼마나 발생했는가를 화면에 출력해 보게 한 것이다. 사실 처음에는 어떤 식으로든 사용자에게 알릴 수 있도록 메일 또는 메시지를 연동해 보려고 했다. 하지만 프로젝트의 제약조건에 따라 최종적으로 원하는 바를 얻지 못한 점은 아쉬움으로 남아 있다. 그래도 처음에 기획했던 바를 일부 달성한 것만으로 팀원 서로를 격려했다. 실시간 처리 분석 기능을 구현하는 등 추가 발전방향에 대해 다시금 생각해 볼 수 있게스트 과정을 거쳐 <그림 4>와 같은 프로젝트 시스템을 최종적으로 구축할 수 있었다.

Conclusion

프로젝트 팀이 꾸려지자마자 역시나 가장 걱정스러웠던 점은, 교육일정이 끝나고 현업으로 복귀한 뒤의 수료 프로젝트 지속 가능 여부였다. 현업에 복귀해서 각자 맡은 일을 하면서 수료 프로젝트의 발전을 위하여 멘토를 포함한 6명이 시간을 맞춰 한 자리에 모이기란 결코 쉬운 일이 아님을 팀원들 모두는 알고 있었다. 집체교육이 끝나갈 무렵, 프로젝트 주제 확정을 겸해 팀장을 선발하기 위한 모임을 가졌다.

팀원들간의 소통에 대해

‘윈도우 보안 로그 분석’이라는 주제를 기획했던 정하권 팀원이 팀장이 되면 어떻겠냐는 의견이 나왔지만, 김태형 팀원의 결정적 의견으로 김용문 팀원이 팀장으로 선출됐다. 김태형 팀원이 프로젝트 주제를 제안한 사람이 팀장이 되는 것은 바람직하지 않다는 의견을 제시했다. 그 이유는 자칫 프로젝트가 개인 중심으로 흘러갈 수 있다는 것이었다. 따라서 팀장은 팀원이 다 같이 모일 수 있게 노력하고, 소통을 위해 노력하고 헌신하는 사람이었으면 한다는 의견을 내놓았다. 이 의견에 팀원 모두가 동의한 것이 수료 프로젝트 수행 최우수 팀으로 선정될 수 있었던 시발점이 아니었나 싶다. 프로젝트를 진행할 때, 맏형이었던 김태형 팀원이 팀원들을 잘 조율해 준 덕분에 소기의 목적을 수 있었다.

우리팀은 집체교육이 끝나자마자 소통을 원활하게 하기 위해 ‘빅데이터 미니 프로젝트’라는 이름으로 ‘밴드’를 개설하는 한편, 각자가 테스트한 사항을 신속히 공유할 수 있도록 ‘N드라이브’를 개설했다. 또한 정기적인 모임을 갖기 위해 모임 장소를 예약하고, 사전에 공지해 일정을 조율했다. 팀원들의 의견을 들어주고 프로젝트를 진행하는 데 어려움이 없도록 아낌없는 역할을 해준 김용문 팀장께 다시 한번 감사의 마음을 전한다.

프로젝트를 진행할 때 가장 어려운 점은 일정관리, 범위관리, 품질관리가 아닌, 바로 의사소통관리라고 생각한다. 프로젝트 팀이 TFT 형식으로 짧은 기간에 구성이 되든, 물리적으로 멀리 떨어진 가상팀(Virtual Team)으로 구성되든 팀원들 사이에 원활한 의사소통이 이루어지지 않으면, 해당 프로젝트는 결코 좋은 결과물을 도출해 낼 수 없다고 생각한다.

평일일 경우, 우리팀은 보통 오후 7시를 전후해 강남에서 모였다. 수료 프로젝트 팀이 구성되고 집체교육이 끝날 무렵, 김종회 팀원이 수원으로 발령받았음을 알게 되었다. 늦더라도 꼭 참석하려고 최선을 다하는 김 팀원의 모습에서 팀원들 모두가 힘을 얻었다. 윤재문 팀원은 현업에서 진행하는 별도의 프로젝트로 굉장히 바쁜 일정을 소화하고 있었음에도 Storm을 이용한 실시간 처리분석에서 만난 복병을 적극적으로 해쳐나가서 팀원들을 놀라게 했다. 마지막으로 공용준 멘토께 진심으로 감사를 드린다. 집체 교육을 마치고 처음 멘토를 선정하는 자리에서 팀원들의 의견을 구해 공용준 멘토를 모시게 되었다. 공 멘토께서 워낙 인기가 많아서 다른 프로젝트 팀에서 얼른 낚아갈까 노심초사 했던 기억이다. 공 멘토는 매우 바빴으므로 우리팀 프로젝트의 모임을 지원하기 어려울 것이라고 생각했다. 하지만 집체교육 후 외부에서 가진 처음 미팅부터 가장 적극적인 모습을 보여주셨다. 저녁 식사까지 챙겨주면서 프로젝트의 전체 방향을 코칭하고, 직접 참석하기 어려울 때면 영상 통화를 통해서라도 팀원들의 문의에 대한 답변과 프로젝트 진행 방향을 점검해 주었다. 밴드를 통해서도 프로젝트에 도움이 될 만한 의견들을 프로젝트를 진행하는 동안 지속적으로 제안해 주셨다. 공용준 멘토의 지원이 없었다면 최초 목표했던 방향에서 프로젝트를 얼마나 진행할 수 있었을지….

향후 발전 방향

윈도우 보안 로그 분석 프로젝트를 진행하면서 그 동안 몰랐던 빅데이터 처리 기술에 대해 많은 부분을 배우고 경험했다. 프로젝트의 제약조건(일정, 범위, 자원 등)으로 인하여 보다 많은 테스트를 진행해 보지 못한 부분이 다소 아쉽지만, 기회가 된다면 다음과 같은 형태로 프로젝트를 발전시켜볼 계획이다.

첫째, 보안 위협에 실시간 대응 및 처리 강화
- 윈도우 보안 로그의 상관관계를 분석해 보안 위협을 도출
- 해당 보안 위협들에 실시간으로 대응할 수 있도록 프로그래밍(Storm)
- 보안 위협을 사용자에게 신속하게 알려줄 수 있도록 연동(메일 또는 메시지)

둘째, 주기적 로그 분석을 통한 보안 위협 관리
- Elasticsearch의 실시간 검색 뿐만 아니라 주기적으로 보안 로그 분석이 가능한 장치 마련
- Elasticsearch와 Hadoop을 연계(연계 시 MR, Hive, Pig등을 사용)
- R을 이용한 다양한 분석

셋째, 간단한 설치 배포 및 사용 시나리오 작성
- 프로젝트에 사용된 시스템 구성을 간단하게 설치 배포할 수 있도록 구현
- 다양한 시나리오를 적용하여 많은 사용자들이 손쉽게 사용할 수 있도록 제공

끝이 아닌 새로운 시작

당초 목표했던 바를 모두 이루지는 못했으므로 현재의 결과물에 만족하며 안주하지 않을 계획이다. 우리팀은 그동안 경험했던 지식을 꾸준히 다듬고 노력해 지속적으로 프로젝트 결과를 발전시켜 나가기로 했다. 빅데이터 기술 전문가 과정을 통해 많은 지식과 경험을 익힐 수 있도록 기회를 주신 한국DB진흥원 관계자 분들께 감사하며, 두 달이라는 프로젝트 기간에 한 목표를 달성하기 위해 노력해주신 공용준 멘토와 김용문 팀장, 이하 모든 팀원께 다시 한번 감사의 말씀을 전한다.

출처 : 한국데이터베이스진흥원

제공 : 데이터 전문가 지식포털 DBguide.net