네트워크 포렌식 분석을 통한 사이버 행위 파악과 증명 (2)

완벽하지 않고 많은 작은 빈틈이 있는 조사와 수사가 있을 때 범죄는 기승을 부리게 된다. 범죄자는 그러한 빈틈을 사전에 파악하고 충분히 인지한 상태에서 범죄를 수행하기 때문이다. 현재까지 발생되고 있는 거의 모든 바이러스/악성코드, 사이버 공격과 해킹도 마찬가지로 이러한 원칙을 이용하여 보안의 기술적 결함을 악용해 왔으며 또한 잡히지 않을 것까지 사전에 확인한 후 그러한 사이버 범죄를 수행한다.

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

컴퓨팅과 인터넷 통신 기술을 잘 모르는 일부 사람들은 PC방이나 공공장소의 와이파이 네트워크에서 몰래 숨어서 사이버 범죄 행위를 하는 범인을 찾는 것은 불가능하고 그 범죄 행위도 보이지 않아서 증명할 수 없는 것이라고 단정 짓는 경우가 있다. 그리고 이러한 사이버 범죄 부분에 대해서 밝혀내지 못하는 것을 마치 불가항력 자연재해처럼 특정한 누구도 책임지지 않고 원인과 해결 방법을 찾지 못한 것을 모두가 이해하고 넘어가곤 한다. 그러나 이러한 표현과 생각은 현재의 IT 기술을 너무 모르고 있음을 반증하는 것이기도 하다. 오히려 사이버 행위 분석과 재현 기술은 기존 물리적 공간의 범죄 행위 조사보다 훨씬 완전하고 철저하게 수행할 수 있다.

네트워크 통신 언어 ‘프로토콜’

네트워크 통신은 사용자 간 또는 장치 간 대화를 할 때 각각의 표준화된 언어를 이용하며 이것이 프로토콜이다. 이 프로토콜도 영어, 일본어와 같이 누구나 공부하면 해석할 수 있도록 프로토콜에 대한 표준화된 정의와 방식 및 내역이 완전하게 공개되어 있다. 즉, 이 프로토콜들의 내용을 해석해 보면 컴퓨터 사용자들이 대화하는 내용을 모두 밝혀낼 수 있고, 컴퓨터와 통신 장치들이 주고받는 동작 내용도 모두 알아낼 수 있는 것이다. 예를 들어, 특정 PC가 언제 켜졌고, 어떤 IP주소를 획득한 후 무슨 사용자 ID를 이용하여 어떤 서버에 해킹을 언제부터 어떤 방식으로 시도했고, 언제 해킹이 성공하여 서버 접근이 가능해졌고, 어떤 보안 데이터 파일들을 얼마나 많이 얼마나 오랫동안 유출했는지를 확인해 설명하고 증명할 수 있다.

이러한 프로토콜 표준을 기반으로 통신 장치가 데이터를 전송하는 기본 단위가 패킷이 되는 것이며, 사이버 행위를 조사하기 위해 네트워크에서 길목이 되는 특정 구간의 트래픽을 수집할 때도 기본 단위는 패킷이 된다. 즉, 영어, 일본어의 하나의 문자가 하나의 패킷에 대응될 수 있다.

패킷을 가로채 정보를 수집하는 ‘패킷 스니핑’

패킷 스니핑이라는 용어는 IT 업계에서 이미 일반적으로 널리 알려져 있어서, IT 업계의 어떤 엔지니어에게 이 용어를 아는지 물어봐도 용어 자체를 모르는 사람은 거의 없을 정도이다. 하지만, 이용어가 의미하는 기술적 깊이와 원리 그리고 광범위한 활용도까지 이해하고 있는 사람들은 그리 많지 않은 것 같다.

패킷을 스니핑한다는 사전적 의미는 패킷의 냄새를 맡는다는 것이고 직접적인 의미는 네트워크상에 전송되는 패킷을 가로채는 방식으로 수집하여 그 패킷의 모든 정보를 확보한다는 의미이다. 즉, 패킷 감청이다. 실전에서 패킷을 스니핑하는 방법은 네트워크 장치에서 미러링을 하거나 인라인(In-Line)으로 연결된 탭(Tap)을 통해 특정 링크에서 전송되는 패킷의 모든 정보를 똑같이 복사한 내용을 받아보는 것이다.

따라서 패킷 스니핑을 할 줄 안다는 사람들은 그림 1과 같이 패킷은 어떠한 구조로 구성되어 있고 어떤 내용까지가 통신 선로를 통해 전송되던 것이고 어떤 부분의 내용은 패킷을수신하는 랜카드에서 붙여준 헤더 정보인지를 최소한 알아야 한다. 예를 들어, 가장 앞부분에 있는 Timestamp를 포함한 Packet Info의 항목들의 내용은 상대 IP/MAC에서 전송한 패킷의 내용이 아니다. 그래서 Packet Info 부분은 전문 분석기 제품에 따라 더욱 편리한 정보가 더 들어가도록 제조된 것이 있고 그렇지 않은 것이 있기도 하다.

즉, 패킷을 수집할 때 패킷의 헤더 부분만을 128바이트 또는 이상으로 자르고 나머지 데이터 부분은 버리도록 설정하는 ‘패킷 슬라이싱(Packet Slicing)’ 기능을 적용하는 경우가 간혹 있는데, 이렇게 데이터 부분이 버려져서 없더라도 원래의 패킷 사이즈를 알 수 있도록 Packet Info에서 ‘패킷이 슬라이싱 되었다(Packet Sliced)’는 표현과 Packet Length 부분에서는 항상 원래의 패킷 사이즈 값이 보관되어 제공된다.

통신 데이터의 내용 파악

패킷이라는 것은 통신을 위해 전송되는 데이터의 최소 단위다. 때문에 전송되는 큰 사이즈의 그림이나 문서 파일과 같이 보다 큰 데이터 단위의 정보를 파악할 때는 여러 개의 패킷에 포함된 페이로드(Payload)라고 하는 데이터 부분을 하나의 데이터 단위로 합쳐서 봐야 한다.

그래서 전문 분석기에서 여러 가지 방법과 형태로 이러한 데이터 단위의 정보를 제공하는데, 그림 2와 같이 특정 패킷에서 ‘Decode Reassembled PDU’ 메뉴를 이용하여 그 패킷에 실린 데이터의 일부분이 포함된 전체 데이터로 묶여진 패킷을 볼 수도 있고, 그 패킷이 포함된 세션의 통신 내용을 모두 데이터 단위로 묶은 후 주고받는 대화 형식으로도 파악할 수 있다. 그림 2에서 보이는 데이터 단위의 정보를 활용하여, 클라이언트의 시스템(‘User-Agent:’ 부분)이 애플사의 맥(MAC) OS이며, 서버의 도메인 이름(‘Host:’ 부분)과 시스템의 종류(‘Server:’ 부분)도 쉽게 확인할 수 있다.

이러한 통신 데이터의 내용 파악과 검색은 매우 많은 상황에서 필요로 하여 편리하고 빠르게 활용할 수 있어야 한다. 일부의 예를 들면, 시스템에서 보내는 특정 에러 메시지의 제목과 내용 확인, 유해 및 악성 코드의 실행 파일 제목 검색, 비업무적통신 여부의 판단, 과다 트래픽을 유발하는 업무의 종류 파악, 품질 불량의 원인이 되는 특정 트랜잭션 내용 확인, 중요 문서 및 정보 유출 여부 검색 등과 같이 매우 다양한 곳에서 다양한 목적으로 이러한 데이터의 내용 파악을 필요로 한다.

전문 분석기를 이용한 패턴 검색

그림 3은 전문분석기를 이용해 텍스트 형태의 ASCII 패턴 검색을 직접 또는 필터를 만들어 수행하고, 패킷의 디코드 페이지에서 TCP Window와 같은 특정 필드 값을 그 위치에서 마우스 우측버튼을 클릭해 나타나는 메뉴를 이용, 즉시 자동으로 필터가 만들어 지는 것을 보여주고 있다. 이러한 세부적인 작업을 간편하게 한다는 것은 반복되는 수행 시간을 절약하는 것뿐만 아니라, 자칫 분석시간이 길어지고 잡다하게 복잡해져서 실수할 수 있는 경우까지 배제할 수 있다.

특히, 그림 4와 같이, 패킷 디코드의 특정 필드 값에 대한 필터 작성 시, 같은 값에 대한 것으로 검색할 수 있는 것이 아니라, 특정 값 이하(<=), 미만(<), 이상(>=), 초과(>) 또는 이외(!=) 등과 같은 여러 개의 논리 연산자를 선택적으로 이용해 적용할 수 있다. 그리고 이렇게 만든 필터는 다시 여러 개의 필터 간에 논리 연산자를 적용할 수 있어서, 여러 개의 필터들을 조합으로 적용할 수 있다.

예를 들어, 특정 서비스 서버 IP 그룹 또는 서비스 포트 범위의 필터와 TCP Window 사이즈 필터를 AND 연산자로 연결하여 적용하면, 특정 서비스에서 발생되지 않아야 할 비정상적인 TCP Window 사이즈 저하 문제를 일으키는 장치와 시점, 그 증상의 패킷들을 지나간 데이터에서 쉽게 찾아내거나 실시간 감시를 할 수도 있다.

패킷 분석으로 오류 확인

TCP/UDP 세션 단위의 패킷 분석을 통해 효율적으로 잘 설계된 후 개발되면 자체적으로 우수한 어플리케이션 서비스와 오류가 많은 어플리케이션 서비스를 구분 및 판단할 수 있고, 네트워크의 지연이나 패킷 손실과 같은 서비스 품질 저하 요소와 어플리케이션 자체 유발의 서비스 품질 저하 요소 간에 실질적으로 사용자가 체감하는 느린 응답시간과 접속 끊김 증상의 원인이 무엇인지 결정할 수 있다.

그림 5에서 HTTP 프로토콜의 Web 통신 세션을, 클라이언트와 서버 간에 시간 순서로 패킷을 주고받는 내용으로 직관적으로 빠르게 파악할 수 있도록 도식화된 플로우를 표시하고 있다. 이 화면과 패킷 수집 위치를 통하여, 사용자가 사내 그룹웨어의 Web 페이지 하나를 여는 데, 최소 수십 초에서 수분 이상을 기다려야 하는 통신 불량 문제의 원인을 확인할 수 있다.

패킷 수집 위치는 이 사내 그룹웨어 웹서버의 바로 앞단 스위치에서 하고 있기 때문에 이 서버와 패킷 수집 위치 사이에서의 네트워크 지연이나 손실은 없는 것으로 확신할 수 있다. 그리고 그림 5의 분할된 화면 중 좌측 부분을 보면, 왼쪽의 녹색 막대 하나가 클릭되어 진하게 색깔이 반전되어 있고 그 위에 네 개의 주황색 막대가 엷은 하늘색으로 색깔이 반전되어 있다. 이렇게 색깔이 반전되어 표시되는 의미는 전문분석기에서 TCP 세션의 패킷 간에 ACK 관계의 패킷들을 즉시 파악할 수 있도록 제공하는, 매우 효과적인 편의 기능이다.

따라서 132279번의 클라이언트가 그 위의 119957번부터 131399번의 서버의 데이터 패킷들을 ACK한 것이다. 또한, 이 막대의 길이는 각 패킷에 실린 데이터 크기를 시각적으로 파악할 수 있도록 표시되어 가장 짧은 길이가 데이터가 전혀 실리지 않은 ACK 패킷들이다. 서버가 데이터 응답 패킷 재전송을 하게 된 원인을 파악해 보면, 119957번과 119958번의 데이터 응답을 하고 나서 클라이언트로부터 ACK를 2초간 받지 못해, 124099번 패킷을 이전과 같은 내용으로 재전송하고 있다.

결국 서버는 패킷을 재전송하고도 5초 후에 클라이언트로부터 ACK를 힘들게 받고 통신을 이어가고 있다. 여기서, 분석하는 당사자는 패킷 수집 위치가 서버 앞단이라는 것을 알고 있기 때문에, 클라이언트가 서버의 데이터 패킷을 못 받았거나, 클라이언트가 보낸 ACK 패킷이 서버까지 전달되지 않았다는 것을 알 수 있다.

결국, 이곳의 문제 원인은 어플리케이션이나 서버/클라이언트 시스템의 문제가 아닌, 네트워크의 지연 또는 손실이 원인인 경우이다. 이런 경우, 만약 클라이언트 앞 단에서도 동시에 패킷을 수집했다면, 네트워크 WAN 구간의 지연인지 손실인지를 확인할 수 있고, 지연일 경우 WAN 구간에서만 몇 초의 지연이 발생했는지도 알아낼 수 있다. 또한, 분할된 화면의 우측 부분을 보면 이 세션의 주고받는 통신 내용을 데이터 단위로 시간 순서대로 보여주고 있다.

즉, 이 내용을 통하여 클라이언트가 어떤 업무의 목적으로 어떤 내부 업무 서버로 접속하여 통신을 하다가 품질 불량을 경험했었고 따라서 이 통신이 경유되는 네트워크 경로가 정확히 어디를 통하는지 확인할 수 있다.

클라이언트와 서버 시스템 자체의 성능 부족 증상은 없었으며, 어플리케이션은 충분한 데이터 전송을 위하여 패킷에 실을 수 있는 최대 데이터 사이즈를 잘 활용하고 있고, 클라이언트의 TCP Window 사이즈도 잘 유지가 되어 서버의 두 개의 데이터 응답 패킷에 대해 클라이언트가 한 번의 ACK로 정상적일 때 처리하고 있기 때문에 어플리케이션 자체적인 비효율적인 측면은 발견되지 않는다.

<다음호에 계속>

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

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