자동차를 운전하던 당신에게 비즈니스로 중요한 이메일이 왔다. 평상시라면 주차를 한 후 메일을 확인하겠지만 당장 급한 마음에 핸드폰을 열어 이메일을 확인하다가 결국 사고를 내고 말았다. 주행 중 운전자가 전방 주시 의무를 소홀히 한 결과다. 이처럼 우리의 일상생활에서부터 전방주시, 즉 실시간 모니터링의 역할은 이미 필수적 요소로 자리 잡고 있다.

대부분의 사람들에게 익숙한 자동차의 모니터링 시스템의 구조를 먼저 파악해 보자. 운전자의 수동적인 전/후/측면 주시 의무를 비롯하여, 차량의 속도, 연료의 양, 주행거리, 부속품이나 기능의 오류 유무 등의 각종 측정값을 표시해 주는 다양한 계기판들이 대시보드에 있다. 그리고 이런 계기판들은 임계값을 벗어날 경우, 불빛이나 소리의 알람으로 경고를 한다. 이러한 측정값들의 공통점은 임계값 초과 시 위험이나 문제와 관련되는 항목들이라는 것이다. 그래서 이러한 항목들이 모니터링 시스템의 존재 이유가 된다.

이 영 진┃와일드패킷 한국지사장(ylee@wildpackets.com)

IT 네트워크 보안 모니터링 솔루션이 되기 위해서는, 보안 위반 및 공격 행위와 증상을 모니터링해 문제나 사고가 발생하기 전에, 그 원인이 되는 싹을 잘라버리는 것이다. 예를 들어, 자동차 엔진의 과열 상태 알람을 지나치지 않고 점검하여 엔진 폭발을 방지하는 것과 유사하다. 여기서 중요하게 집고 넘어가야 할 부분은, 실질적으로 보안 위반 및 공격 행위와 증상이 발생 단계 이전에 드러나서 알아낼 수 있도록 모니터링해야 하고, 알람 발생 시 그 행위 내용과 행위자를 알아낼 수 있는 분석 기능과 능력도 있어야 한다는 것이다.

사업 및 업무 목적의 어플리케이션과 인터넷에 대한 모니터링

대부분 기업의 IT 네트워크 인프라 구축의 목적은 그 통신 선로를 통하여 그 기업의 임직원 또는 고객들이 사업 및 업무 목적의 각종 어플리케이션과 인터넷 서비스 통신을 원활하고 끊임없이 이용하도록 하기 위한 것이다. 따라서 가장 첫 번째 측정 항목은 사업 및 업무 목적의 어플리케이션과 인터넷 서비스 통신 성능/품질 저하에 대한 모니터링이다.

인터넷에서 주로 사용되는 HTTP 프로토콜을 비롯해, 대다수의 TCP 기반의 어플리케이션 서비스에 대한 성능 또는 품질은 데이터 요청 후 응답에 걸리는 시간을 측정한 값을 이용한다. 하지만, 단 한 번의 응답시간이 사용자가 느끼는 전체 응답시간이 아니다. 예를 들어, 사용자가 웹브라우저를 이용하여 어느 웹사이트의 한 페이지를 보는 경우, 이 작업 과정은 일부 그림, 일부 프레임 내용과 같은 것들로 이루어진, 보통 수십 개 이상의 데이터 요청과 응답 과정들로 구성된다.

그림 1은 사업/업무 목적의 TCP 포트별 어플리케이션 서비스에 대해 사용자가 느끼는 품질을 모니터링 하는 화면이다. 즉, 단 하나의 응답시간이 느린 것을 마치 사용자가 불편을 겪은 것처럼 실제와 다르게 알람 경고하는 것이 아니라, 실제 사용자가 체감할 수 있는 다수의 응답시간이 느린 지를 모니터링 하는 것이다. 그림 1에서 화면의 각각의 계기판은 각 어플리케이션 서비스의 사용자 체감 품질이 거의 완벽하게 매우 우수한지, 우수한 편인지, 보통 정도인지, 기준 시간보다 4배 이상 지연이 되어 일반적인 사람들이 참기 힘들어 하는 품질인지 등을 숫자로 된 점수와 파란색/녹색/노란색/빨간색 등의 색깔을 표시하여 어떤 서비스의 사용자 체감 품질이 좋고 나쁜지를 즉각적으로 발견하도록 하고 있다.

따라서 DDoS 공격과 같은, 서비스를 중단시키기 위한 공격을 받았을 때, 이용 중이던 각종 서비스들의 사용자 체감 품질 저하에 의한 알람이 매우 많이 울릴 것이다.

어플리케이션 서비스 모니터링의 주의점

어플리케이션 서비스 모니터링시 특히 주의해야 할 부분이 있는데, 그것은 만약 어플리케이션 서비스 단위만으로 정의해 묶어서 응답시간을 측정하게 되면 정상적인 상황에서도 그 어플리케이션 서비스 내의 다양한 세션에서 너무나도 큰 차이가 나는 다양한 응답시간이 있다는 것을 항상 발견할 수 있다. 또한, 같은 포트 번호의 세션 중에서도 요청 구문의 내용에 따라 응답시간이 크게 다른 경우도 많이 발생한다.

즉, 단순하게 다수의 IP 주소와 포트 범위로 어플리케이션 서비스를 정의하여 모니터링 할 때, 획일적으로 응답시간의 임계값을 부여하여 정상 또는 비정상 여부를 정확하게 파악할 수 없다는 것이다. 이러한 설정 오류는 기업의 어플리케이션 서비스의 세션들을 상세히 분석해 보지 않은 사람들에게서 발생할 수 있으며, 누구라도 일정 규모 이상의 기업 어플리케이션 서비스의 세션들을 정밀 진단해 보았다면 어렵지 않게 직접 발견할 수 있다.

그림 2의 화면에서, 어플리케이션 서비스 별 평균 및 최대(Worst) 응답시간, 각 어플리케이션 서비스의 서버 IP 별 평균 및 최대(Worst) 응답시간, 각 어플리케이션 서비스의 각 서버 IP의 클라이언트 IP 별 평균 및 최대(Worst) 응답시간 등의 통계 측정값을 확인하고 비교할 수 있다. 이 화면 사례에서도 보면 알 수 있듯이, Web 어플리케이션의 평균 및 최대(Worst) 응답시간이 모든 서버 IP 및 모든 클라이언트 IP의 응답시간과 일치하지 않는 것을 볼 수 있다. 최대(Worst) 응답시간의 차이는 말할 것도 없고, 평균 응답시간의 차이도 서버 IP 간에는 수백ms, 클라이언트 IP 간에도 1.8초 이상 나는 것을 확인할 수 있다.

만약, 어플리케이션 서비스의 성능/품질 저하나 오류를 일정한 임계값으로 정확히 모니터링 할 수 있도록 서버 IP, 포트 번호/범위, 요청 구문 내용 등의 조건 조합으로 잘 선별하고 정의하여 설정했다면, 그림 2와 같은 화면 구성의 통계 결과는 다음과 같을 것이다.

어플리케이션 서비스 자체가 성능/품질 저하 또는 오류의 원인일 경우, 어플리케이션 서비스의 응답시간과 서버 IP 및 클라이언트 IP의 응답시간이 모두 같을 것이다. 또한 특정 서버 IP가 원인일 경우, 특정 서버 IP의 응답시간만 다르고 클라이언트 IP의 응답시간은 같을 것이다. 그리고 특정 클라이언트 IP 또는 그 세그먼트가 원인일 경우, 그 특정 클라이언트 IP의 응답시간만 다르게 나타난다. 즉, 제대로 설정된 모니터링을 하게 되면 이러한 통계 화면 하나 만으로도 성능/품질 저하 또는 오류의 원인이 어플리케이션 자체, 특정 서버, 특정 클라이언트 또는 세그먼트 중에서 어디에 있는지 바로 확인할 수 있게 된다.

이러한 상세 모니터링 측정값을 이용해 해킹 공격이 특정 서버에 집중되었는지 아니면 모든 서버를 대상으로 하고 있는지 등을 파악할 수 있다.

결국, 어플리케이션 서비스의 성능/품질 저하 및 오류를 정확히 모니터링 하기 위해서는 너무 큰 범위로 묶는 것 보다 작은 범위이더라도 문제나 장애 단계 이전의 증상이 잘 감지될 수 있도록 설정하는 것이 핵심적이며 매우 중요하다.

이렇게 잘 설정된 모니터링을 하여, 보안 문제나 사고가 되기 이전의 증상이 확인되면 그 원인을 파악하여 그 행위자를 제거해야 된다.

그림 3의 화면을 보면, TCP 기반 서비스의 성능/품질 저하 또는 오류에 의한 느린 응답시간의 원인을 세션 별로 상세하게 파악할 수 있다. 느린 응답시간의 원인이 네트워크 지연인지, 네트워크 손실인지, 서버의 프로세싱 지연 또는 손실인지, 클라이언트 시스템의 처리 지연 또는 손실인지, 너무 느린 재전송 타임아웃 설정에 의한 것인지, 서버 또는 클라이언트 시스템의 성능 부족인지 및 기타 등과 같이 매우 전문적이고 정밀하게 원인을 확인하여 그 원인을 제거할 수 있는 충분하고 사실 기반의 정확한 정보를 확보할 수 있다.

이러한 상황은 사람의 대화와 비교할 수 있는데, 하나의 패킷이 사람의 언어에서 하나의 단어와 유사할 수 있다. 즉, 어떤 사람이 대답을 못하고 있을 때 질문한 사람이 중요한 단어를 빼고 말해서 그런 것인지 질문한 사람이 모든 단어의 문장을 정확하게 말했는데, 듣는 사람이 듣지를 못해서 대답을 못한 것인지 등의 원인과 행위를 파악하는 과정과 유사하다.

네트워크 어플리케이션 서비스의 성능 관리 솔루션

네트워크 어플리케이션 서비스의 성능 관리 솔루션은 기존 NMS(Network Management System) 솔루션이 대략적인 네트워크 트래픽 측정과 장비 자체 불량 감시 위주의 역할에 제한되어 있었던 것과 차별화해, 네트워크의 어느 지점에서도 해당 위치에서의 어플리케이션 서비스의 성능을 모니터링 및 감시하고 전문적인 고급 패킷 분석 기능이 연동되어 알람 로그의 증상을 명확하게 설명되도록 규명하고 품질 저하와 오류의 원인을 매우 빠르게 밝혀내는데 혁신적인 기여를 한다. 때문에, 이 부분은 기존의 어떠한 관리 시스템도 수행하지 못했던 분야이며 영역이다.

기존의 통합 네트워크 관리 시스템, TNMS(Total Network Management System) 솔루션이 코어망에만 연결되어 동작한다는 것은 매우 아이러니한 일이기도 하다. 당연히 기술적으로 전체 네트워크를 모두 관리하지 않는다는 의미이다. 예를 들어, 서버팜에서 링크 상의 트래픽을 직접 수집하여 서버의 어플리케이션 서비스를 진단한다고 가정해도, 이 경우 대부분 서버 측면만을 확인하는 것이지 클라이언트가 체감하는 어플리케이션 서비스의 품질과 오류 상태를 알지 못하는 경우가 매우 많다.

진정한 TNMS는 통합된 전체 네트워크의 모든 구간과 사용자에 대한 APM(Application Performance Management)과 NPM(Network Performance Management) 기능이 동반되었을 때 이루어질 수 있다.

가장 대표적인 NPM(Network Performance Management) 기능으로써, 그림 7과 같이 통합 네트워크의 주요 구간별 패킷 이동시간, 패킷 손실, TCP 패킷 재전송 등을 하나의 통합 화면에서 매우 간편하게 확인할 수 있다.

패킷 이동시간은 케이블 통과시 지연도 있지만 각종 네트워크/보안 장치 통과시 지연시간도 파악한다. 패킷 손실도 케이블 통과시 손실이 있지만 각종 네트워크/보안 장치 통과시 손실 개수를 파악한다. TCP 패킷 재전송 항목은 TCP/HTTP 기반 어플리케이션의 오류 진단 항목의 의미로써, 재전송 발생시 지연과 손실을 동시에 비교하여 네트워크가 원인이 되어 발생된 TCP 재전송인지 아닌지를 즉시 확인할 수 있다.

그림 4의 경우, 각 네트워크 구간별 평균/최소/최대 지연시간을 한 눈에 확인하여, 사용자에서 서버까지의 총 지연 시간 중에서 대부분의 지연이 지점 라우터와 백본 스위치 사이에서 발생했고 양방향 지연시간이 비슷한 것을 시각적인 화면을 통하여 빠르게 알 수 있다. 또한, 구름모양의 그림 안에 적혀 있는 숫자는 라우팅홉수를 표시하고 있어서 지연시간과 라우팅홉수와의 관계도 즉시 파악할 수 있다. 그리고 그림 바로 윗부분에서는 패킷 수집 위치별 패킷 손실과 TCP 패킷 재전송 등을 목록 형식으로 제공하여 아래의 그림과 더불어 동시에 참고할 수 있도록 하고 있다.

그림 5의 화면은 그림 7과 같이 네 곳의 지점으로부터 수집한 패킷들의 세션 플로우를 하나의 화면에서 동일 패킷을 연결하여 표시함으로써, 각각의 패킷이 네트워크 구간별 이동시간이 얼마나 오래 걸렸고 구간별로 차이가 많이 나는지 시각적으로 쉽게 파악할 수 있다. 그림 8의 경우, 지점 라우터와 백본 스위치 사이 구간에서 화살표가 수평적이지 않고 화살표의 경사가 아래로 많이 내려갔기에 지연이 심했다는 것을 먼저 알 수 있으며, 일정한 간격의 시간 눈금을 보고 그 사이에서 각 패킷이 100ms 지연이 발생된 것을 확인한다.

이와 같이, 예전에 분석기를 들고 다니며, 여기저기 우왕좌왕하며 패킷 수집하여 분석하던 방식에서 탈피하여, 이제 통합 네트워크의 수많은 세그먼트에 대해서도 하나의 통합 화면에서 효과적으로 각 세그먼트의 성능을 진단해야 한다.

특히, 이렇게 네트워크 구간별로 어플리케이션 서비스 통신을 하는 패킷들의 네트워크 지연시간을 통합적으로 동시에 측정하기 위해, 그림 7과 같이, 여러 대의 어플라이언스 분석시스템을 주요 네트워크 구간이 구분되는 지점에 배치하고, 중앙 콘솔이 원격으로 동시에 여러 대의 어플라이언스 분석시스템에 연결하여 동일 세션과 패킷을 자동으로 찾아서 그림 4와 그림 5와 같이 표시되도록 구성하면 매우 효율적인 네트워크 성능 관리를 할 수 있다.

그림 7을 보면, 현재 통합 네트워크에서 발생하고 있는 다양한 이슈들을 알 수 있다. 이러한 이슈들은 특정 세그먼트에서만 원인이 되는 경우가 매우 많기에 다수의 네트워크 세그먼트 개별에 대한 통합 분석과 진단이 필요한 것이며, 이러한 이슈 중에는 클라이언트 사용자 단에서만 그 증상이 오류 현상으로 나타나는 경우도 상당하다.

통합 네트워크 관리 방안을 설명할 때, 많은 사람들이 End-to-End 성능 분석이라는 표현을 많이 사용하는데, 이 의미를 그 중간에 위치해 있는 세그먼트 별 성능 분석을 생략한다는 것으로 오해하지 말아야 한다. 예를 들어, 어떤 침입자가 빌딩을 들어오고 나가는 것만 CCTV에 기록이 되었고 빌딩 내부에서 어디를 배회하다가 몇 층의 어느 보안 시설 구역에 언제 출입을 했는지 전혀 파악할 수 없다면 제대로 된 빌딩 보안관리 시스템이 될 수 없다.

그래서 서버팜 스위치에서만 패킷을 수집하여 어플리케이션 서비스의 트랜잭션 품질만을 분석하는 APM만으로는 통합네트워크 성능을 관리하기에 부족하다. 세부적인 네트워크 세그먼트별 성능과 각 네트워크 세그먼트 상에서의 어플리케이션 서비스 품질과 오류 상황까지 파악하는 NPM도 필수적으로 필요하다.

그림 8을 보면, 앞으로 네트워크의 모든 주요 구간이 감시 및 분석 되도록 ANPM(Application& Network Performance Management) 시스템이 배치되는 구성 사례를 볼 수 있다. 그만큼 IT 네트워크 인프라의 중요성은 이미 크게 부각되고 있고, 모든 네트워크 구간과 요소에 대해 명백한 확인과 조치가 이루어져야만 하기 때문이다.

각 네트워크 세그먼트별 배치되는 ANPM 시스템은 트래픽 용량과 인터페이스 규격에 맞는 등급의 장치로 선택되어 다양하게 적용되기 때문에, 다양한 용량의 어플라이언스와 소프트웨어 분석시스템 중에서 최적의 선택으로 전체 배치와 구성을 설계하면 된다. 대용량 트래픽을 위한 몇 가지의 어플라이언스 분석시스템, 소용량 트래픽 및 Virtual(가상화) 시스템을 위한 소프트웨어 분석시스템, 사용자 PC의 직접 수집 솔루션, 통합 모니터링 및 리포팅 전용 서버 등이 모두 연계된 구성으로 통합네트워크의 어떤 부분도 놓치지 않고 관리하며 분석할 수 있다.

지금까지 완전하게 적용하지 못했던 통합네트워크 보안 관리 시스템을 이제는 ANPM 솔루션의 발전으로 완전한 보안 관리를 실현할 수 있는 시대가 되었다. 원천 과학 기술의 발전 없이 공학이 발전할 수 없듯이, 패킷 분석 기술의 숙련자들만이 이러한 패킷 분석 원리를 기반으로 하는 APM과 NPM 복합 시스템의 보안 관리를 위한 운용도 훨씬 효과적이고 전문적으로 가능할 것이다.

[월간 시큐리티월드 통권 제202호(sw@infothe.com)]

<저작권자 : 시큐리티월드(www.securityworldmag.co.kr) 무단전재-재배포금지>