이더리얼 강좌 2

오리지날 | 오리    출 처:오공의 블로그
http://blog.naver.com/goduck2/11668133

 

[이더리얼 강좌] 통계·그래픽·색지정 사용법과 팁 ①

 

지난회 까지는 이더리얼을 사용하는 가장 핵심적이고 기본적인 필터 문법에 대해 자세히 알아봤다. 그런데 과연 이더리얼을 지난 시간까지 익혀왔던 것처럼 딱딱한 텍스트로만 사용이 가능한 것일까. 좀 더 편하게 사용하는 법은 없을까. 물론 다양한 방법이 있다. 이더리얼은 나름의 또다른 편리한 도구를 갖고 있다. 이를 이용하면 상용 패킷분석기처럼 화려하지는 않지만 전체 통계치 등을 편리하게 확인할 수 있다. 이번 시간에는 이런 방법에 대해 소개한다.

네트워크 패킷 분석기를 통해 패킷을 살펴볼 때 캡처한 패킷의 양이 얼마만큼인지, 또 여러 개의 패킷 흐름을 봐야 하는 상황에서 그것들에 대한 나름의 구별은 어떻게 할 것인지 등의 고민을 하게 된다. 이더리얼은 이 같은 고민을 해결해주는 몇 가지 다양한 기능을 지원한다.

 

캡처한 패킷 색깔별로 구분하기
이더리얼에서 사용하는 여러 가지 편리한 기능 중 하나는 캡처한 패킷들을 필터에 따라서 색깔로 구별시키는 것이다. 두세가지 종류의 패킷을 전체 흐름 속에서 추적해 나갈 때 매우 유용한 기능이다.
이더리얼 메뉴중에서 View > Coloring Rules...를 선택하면 (화면 1)과 같이 프로토콜별로 컬러링을 할 수 있는 대화창이 뜬다.

 

(화면 1) 필터 정의시 활성화되는 Order 항목(대화창 왼쪽).  

이미 필터가 정의돼 있을 경우에는 대화창 왼쪽의 순서(Order) 항목이 활성화 돼 있으며(화면 1), 아무것도 정의돼 있지 않을 경우는 (화면 1)과 같이 업/다운(Up/Down) 버튼이 비활성화돼 있을 것이다. 지금부터는 컬러필터를 적용시키는 방법을 알아보자.
(화면 1)의 대화창에서 편집(Edit) 메뉴에서 새로만들기(New..) 버튼을 클릭하면 (화면 2)와 같이 컬러필터를 실제로 입력하는 대화창이 뜬다.

 

(화면 2) 컬러필터를 입력하는 대화창

 

 

이 편집창에서는 필터의 이름(Filter > Name)과 실제 필터 스트링(Filter > String)을 입력하기만 하면 된다. (화면 2)에서 필자는 스패닝트리 프로토콜에 관련된 패킷들에 색깔을 지정하기 위해서 stp라는 필터 이름과 프로토콜을 구분하는 stp 스트링을 입력했다. 여기서 우리가 사용하게 될 필터의 스트링은 대부분 이더리얼 화면중에서 프로토콜 항목이 될 것이다. 앞서 필자가 프로토콜을 아는 것이 중요하다고 언급했던 부분이 바로 여기서 적용이 되는 것이다.
다시 컬러필터 적용으로 돌아가서 (화면 2)처럼 이름과 스트링을 주고나서 실제로 어떤 색을 적용할 것인지를 선택하는 부분이 컬러표시(Display Colors) 항목이다. 이 항목에서 전면색(Foreground Color)과 배경색(Background Color)을 선택하면 (화면 3)과 같이 색을 조정할 수 있는 창이 뜬다.

 

화면 3) 색을 조정할 수 있는 창

 

여기에서 패킷을 구별할 때 나타나는 문자의 색만 다르게 하고 싶을 경우는 전면색(Foreground Color)만 선택하고, 배경색(Background Color)은 선택하지 않은 상태로 두면 된다. 또한 문자의 색은 그대로 두고 배경색(Background Color)만 바꾸고 싶을 경우는 전면색은 그대로 두고 배경색만 바꾸면 된다.
그러면, 지금까지 알아본 컬러필터를 적용해서 실제 패킷들에 이 필터가 어떤 식으로 적용되었는지를 살펴보도록 하자.

 

(화면 4) 색으로 구분되는 프로토콜 항목들  

(화면 4)에서 ARP 패킷은 내용문자만 파란색으로 구별했고, 스패닝트리 프로토콜(STP) 패킷은 문자는 붉은색, 배경은 연녹색으로 처리했다. 그리고 넷바이오스(NETBIOS) 패킷은 배경색만 진한 녹색으로 설정돼 있으며, 나머지는 원래 기본적으로 보는 색이다. 앞서 이야기했던 것처럼 (화면 4)에서 보여지는 프로토콜 항목이 색을 구분하는 기준이 되는 것을 볼 수 있다.
특히 이 컬러필터 기능은 실시간 모니터링 시에 유용한데, 무차별 모드로 패킷을 캡처하면서 특정 패킷의 흐름을 아주 정확하고 편리하게 볼 수 있다.

 

캡처한 패킷의 통계보기

이더리얼은 캡처한 패킷들의 크기가 평균적으로 어느 정도인지, 그리고 초당 어느 정도의 패킷들이 지나다니는지 살펴볼 수 있다(화면 5).

 

(화면 5) summary 항목 선택시 볼 수 있는 결과창.  

(화면 5)는 앞서 컬러필터를 적용했던 캡처파일을 이더리얼의 분석(Analyze) 메뉴에서 요약(Summary) 항목을 선택했을 때 볼 수 있는 결과창이다. 이 결과창을 분석할 때 필요한 부분은 전체패킷 수(Packet count)와 초당 패킷수(Avg. packets/sec), 초당 바이트 수(Bytes of traffic) 패킷의 평균크기와 전체 크기 등이 될 것이다.
이더리얼로 패킷을 살펴보는 구간의 대체적인 네트워크 상태 등은 이를 통해 알 수 있는데, (화면 5)에서는 전체 3305개의 패킷을 캡처했다. 이 캡처된 패킷들로 분석할 때 현재 초당 1.367개의 패킷들이 지나고 있고, 이 패킷들의 평균크기는 85.857바이트이며 캡처한 인터페이스를 기준으로 초당 117.385바이트의 대역폭(117.385bps)을 차지하고 있음을 알 수 있다.
통계 요약정보보기 툴로서 이더리얼이 갖고 있는 또 하나의 기능은 캡처한 패킷들을 전체 캡처된 패킷들 중에서 각 프로토콜 종류별로 얼마만큼의 비율을 차지하는지를 살펴보는 프로토콜 구조 통계(Protocol Hierarchy Statics)이다.
이더리얼 메뉴중에서 Analyze > Protocol Hierarchy Statics를 선택하면 (화면 6)과 같이 전체 패킷들의 종류별 구조도와 점유하는 비율을 알 수 있다.

 

(화면 6) 전체 패킷의 종류별 구조도와 점유비율

 

이 프로토콜 구조 통계는 앞서의 요약정보와 함께 네트워크 상태의 판단기준이 된다. 과도하게 넷바이오스 패킷들이 발생한다거나, ARP 브로드 캐스팅이 발생하는 것은 많은 경우 비정상적인 네트워크 환경에서 유발되기 때문이다. (화면 6)은 각 항목을 클릭하면 보다 자세한 하부구조의 프로토콜 종류가 표시되기 때문에 하나하나의 패킷보다는 전체적인 트래픽의 흐름을 살펴보는데 큰 도움을 줄 것이다.

[이더리얼 강좌] 통계·그래픽·색지정 사용법과 팁 ②

 

캡처한 패킷의 통계치를 그래프로 나타내기
'간단하게 살펴본 패킷의 통계치를 그래프로 나타낼 수는 없을까?' 하는 의문을 필자도 늘 해왔다. 이런 통계치는 실제 데이터베이스화된 패킷들을 가지고 다른 프로그램과 연동하는 방식 등을 통해 이뤄질 수 있을 것이다. 이더리얼에서는 간단한 그래프 기능이 있는데 'Analyze > Statics > IO > IO-Stat'이 바로 그것이다.

 

 

 

(화면 7) IO 상태 그래프  

캡처한 패킷의 I/O 상태를 나타내는 상태 그래프를 실제 패킷들의 필터를 색으로 구분해서 표시할 수 있다. 기본적으로 표현할 수 있는 필터의 개수는 (화면 7)에서와 같이 5가지 이다. (화면 7)에서 보이는 바와 같이 각각의 필터를 기록하고, styile 란에서 선으로 표시할 것인지 아니면 점으로 표시할 것인지 등을 지정할 수 있다. 그리고 막대그래프의 간격과 하나하나의 구분점(Tick)당 얼마의 픽셀을 적용할 것인지, 그리고 y축의 크기 등도 지정할 수가 있다.
이런 상태그래프는 패킷을 캡처하는 인터페이스를 기준으로 앞서봤던 프로토콜 구조 통계와 같은 정보를 그래픽으로 표현해 주는 것으로 볼 수 있다. 물론 어떤 필터를 쓰는가에 따라서 다를 수 있지만, 기본적으로 프로토콜별 구분을 그래픽화하기 위해서 많이 사용하고 있다.

프로토콜에 대한 선행 학습 필수
지금까지 현존하는 가장 직관적인 패킷 분석기인 이더리얼의 또다른 측면을 살펴보았다. 이들 기능은 이더리얼의 탄생배경에서 살펴봤던 것처럼 많은 개발자들이 패킷을 분석하면서 조금씩 편리한 기능들을 추가해가면서 생겨난 것들이다. 물론 직관적이고 명확한 패킷의 분석을 위해 사용하는 이더리얼의 숨겨진 편리한 기능들도 실제로는 잘 사용하지 않는 경우도 많지만, 버전 업이 될 때마다 조금씩 더 개선되고 있기 때문에 나중에는 이더리얼의 강력한 핵심기능이 될 것이라 생각한다.
다음 호에는 실제로 이더리얼을 사용해 문제를 해결해 가는 과정을 다뤄볼 것이다. 패킷을 분석해서 문제를 해결하기 위해서는 그 패킷이 어떤 프로토콜인지를 먼저 알아야 한다. 그리고 이를 위해서는 우리가 자주 접하는 프로토콜들에 대한 선행학습이 이뤄져야만 한다.
먼저 네트워크 장비만을 놓고 볼때는 OSI 7계층에 기반해서 패킷들을 볼 수 있을 것이지만, 웹(80)이나 DB(1521) 또는 DNS(53), FTP(21), SMTP(25), 텔넷(23) 등과 같이 잘 알려진 애플리케이션을 분석할 때는 TCP/IP 계층구분에 기반해서 패킷들을 분석해야 한다. 인터넷의 TCP/IP 통신을 통해 이뤄지고, 이런 인터넷을 연결하는 각종 네트워크 장비들은 OSI 7 계층의 표준을 따르고 있기 때문에 어느 한쪽으로만 생각해서는 완전히 문제를 파악하기 힘들 것이다. 예를 들어 스위치와 어떤 장비들 사이의 통신 문제를 파악하는 데는 대부분 MAC 통신이기 때문에 ARP를 기준으로 문제의 범위를 좁혀나갈 수 있고, FTP 통신이 문제가 있다고 할 경우는 IP와 포트 번호를 기준으로 애플리케이션의 소켓 통신쪽 문제를 확인할 수 있을 것이다. 다음에는 이런 상황별 특성을 고려한 이더리얼 적용기를 다뤄보고자 한다.

지금까지 이더리얼을 사용하는데 필요한 간단한 기능부터 복잡하고 자세한 필터구문 까지 차근히 살펴봤다. 이더리얼의 기능을 실제 환경에서 어떻게 활용할 것인가는 전적으로 개인의 의지와 노력에 달려 있다. 이번호에는 이더리얼을 사용해서 실제로 트러블슈팅에 어떻게 활용하는지를 살펴봄으로써 이더리얼 강좌의 마침표를 찍으려고 한다.

이더리얼의 세부 기능을 확실하게 익혔다면 지금부터는 이더리얼을 이용해서 얼마나 정확하고 신속하게 문제를 파악할 것인가를 고민해야 한다. 물론 각각의 상황마다 동일하게 적용할 수 없는 많은 환경적 요인들이 존재하지만, 대부분 기본 패턴이 있기 때문에 공통 코드를 찾아낼 수 있다. 그러한 것은 경험에 많은 영향을 받지만 얼마나 프로토콜의 동작방식을 잘 이해하고 있는가와도 밀접한 관련이 있다. 지난번 강좌에서 네트워크 프로토콜을 강조했던 이유도 바로 그것 때문이다. 
네트워크는 수많은 환경 매개변수들을 내포하고 있다. 그러나 이런 것들은 프로토콜이라는 표준에 의해서 연결되고 그 범위가 전세계로 이어지기 때문에, 항상 단서가 되는 프로토콜과 그 프로토콜에 부합된 패킷들을 통해서 문제를 들여다 볼 수 있다. 그러면 어떻게 그런 부분들이 실제 문제해결에 이용되는지 살펴보도록 하자.

사례 1 : 통신은 하지 않고 ARP 브로드캐스트만 발생시키는 서버
이 번에 새로 변경한 서버가 정상적으로 외부 사용자에게 서비스를 하지 못하고 있다. 서비스 자체는 크게 변경된 것이 없으며, 중간 네트워크 장비와의 통신에는 전혀 문제가 없다. 그러나 서버는 다른 네트워크 사용자와는 통신이 전혀되지 않는 상황이다. 과연 어떤 문제 때문일까?

(그림 1)과 같은 환경에서 서버와 사용자간에 통신을 하지 못한다는 것은 기본적으로 핑(Ping)조차 되지 않는 상황이라고 할 수 있다. 그렇다면 서버에서 보내는 패킷에 어떤 문제가 있기 때문은 아닐까.

 

 

그림 1)에서 서버쪽 2계층 스위치에서 포트 미러링을 걸어두고 서버에서 패킷들이 오는지를 확인하였다. 그 결과는 (화면 1)과 같다.

 

 

 

  (화면 1) 이더리얼로 패킷 덤프한 화면  

서버쪽 2계층에서 패킷을 덤프해 봤더니 (화면 1)과 같은 상황이었다. 그러면 어떤 문제 때문에 서버와 사용자간의 통신이 안됐던 것일까. 단서는 (화면 1)의 이더리얼로 뜬 패킷캡처 화면에 아주 잘 나와있다. 같은 네트워크가 아닌데도 서버에서는 사용자에게 ARP 브로드캐스트를 하고 있는 상황이다. 이것은 같은 네트워크라고 인식하고 있기 때문이며, 원인은 서브넷 마스크에 있다. 실제로 필자가 현장에서 종종 경험하게 되는 사례인데, 이 경우 해당 서버의 서브넷 마스크 값을 확인해보면 255.255.0.0의 B클래스로 돼 있는 것을 발견하게 된다. 같은 서브넷 상에서의 ARP의 동작방식은 다음과 같다.

·목적지의 하드웨어 주소를 알아야 하므로 먼저 자기자신의 ARP 캐시(Cache)를 참조한다. 캐시에 없으면 ARP 브로드캐스트를 한다.

·해당 IP 주소를 갖고 있는 노드에서 응답한다. 자신의 IP, 하드웨어 주소를 실어서 다이렉티드(Directed) 패킷으로 응답한다.

·목적지의 하드웨어 주소를 알게 됐으므로 프레임의 헤더에 DA 필드(Field)를 채워 발송한다

 

 

 

이번 사례는 '로컬 네트워크에서의 통신은 ARP를 통해서 얻어진 MAC이 있어야 정상적으로 통신이 된다'는 로컬 통신의 기본원리를 알고 있어야 해결할 수 있는 대표적인 사례다. 대부분 모든 통신이 IP만을 통해서 이뤄지는 것처럼 생각할 수 있다. 그러나 로컬 네트워크의 크기에 상관없이 해당 네트워크에서의 통신은 MAC에 대한 정보를 알고 있는 상태에서 호스트 대 호스트 기반으로 이뤄진다. 아주 직관적으로 알아본 2계층 통신의 원리가 사례 1에서 적용되고 있다.

 

[이더리얼 강좌 7] 사례 연구를 통한 이더리얼 적용기 ②

 

사례 2 : RST 패킷의 발생과 텔넷접속 차단
 사 내에 여러 가지 보안 솔루션을 도입, 구축함으로써 사내 보안을 보다 강화하게 됐다고 안심하고 있었다. 하지만 외부망과 연결하는 네트워크 대역에 파이어월을 새로 도입하고 IP대역을 변경한 후 파이어월 외부에서 내부의 네트워크 장비들로 원격접속이 제대로 이뤄지지 않는 문제가 발생했다. 문제가 무엇일까.

(그림 2)를 통해 현재 사내에 여러 가지 보안장비와 네트워크 장비가 도입돼 있는 것을 알 수 있다. 그런데 문제는 기존에 잘 쓰고 있었던 네트워크 장비들로의 텔넷 원격접속이 현재 잘 되지 않는다는 것이다.

 

 

 

그림 2)에서 보면 신규로 네트워크를 구축하면서 파이어월의 외부쪽 IP에 변경이 있었다는 것을 알 수 있으며, 그후 외부의 라우터 등에서 내부의 스위치로는 텔넷 접근이 안되는 현상이 발생하고 있는 것이다. 이 상황에서는 중간에 있는 파이어월 등에서 출발지와 목적지를 필터로 걸어서 오고 나가는 패킷을 먼저 살펴봐야 한다.

 

 

(화면 3) 사례 2의 이더리얼 패킷 덤프 화면

 

(화면 3)에서 보면 텔넷 접속에 대해 파이어월 하단의 2계층 스위치에서 지속적으로 RST 패킷이 발생하고 있음을 알 수 있다. RST(Reset) 패킷은 정상적인 접속종료가 아닌 긴급 상황 등이 발생해 SYN으로 접속을 요청받고, 연결돼 있던 상태나 연결하려는 상태의 상대방에서 요청지로 접속을 종료시킬 때 발생하는 패킷이다.
이번 사례는 TCP/IP의 소켓 통신과 TFLAG 값을 통한 통신상황에 대해 이해할 수 있어야 해결할 수 있는 문제다. 정상적인 상태라면 SYN → SYN/ACK → ACK로 이어지는 3웨이 핸드쉐이크(3 way handshake) 과정으로 접속이 이뤄지면 정상적으로 통신을 해야 하는데, 사례 2는 (화면 4)와 같은 상태에서 접속이 이뤄지면서 (화면 3)의 상황이 발생한 것이다.

(화면 4) 3웨이 핸드쉐이크를 통해 접속이 이뤄진 상태

 

여기서 정상적인 접속이 이뤄진 이후에 어떤 원인에 의해서 내부의 스위치가 RST 패킷을 던지고 있음을 알 수 있다. 이런 패킷이 발생하는 것은 확인 결과 내부의 IP 인증 솔루션에서 스위치의 관리 IP에 대한 허용이 허가되지 않았기 때문에 접속한 이후에 이에 대한 정상 응답패킷 대신 자신이 출발지에 대해서 RST으로 커넥션을 강제 종료하는 역할을 한 것이다. 가끔 4계층 스위치에서도 서버에 대한 접근에 대해 RST 패킷을 발생하기도 하는데 그런 경우는 실제로는 드물고, 많은 경우는 사례 2와 같이 내부 IP 인증 솔루션이나 유해사이트 차단 시스템 등에서 RST를 통해서 제어를 하는 과정에서 발생하는 문제가 많다. 이런 상황을 파악하려면 (그림 3)과 같은 TCP 헤더의 내용을 잘 알고 있어야 한다.

 

 

(그림 3)의 TCP 헤더 중에서 사례 2를 해결하기 위해 살펴봤던 것은 (그림 3)에 보이는 것처럼 플래그(Flags) 값이다. 이더리얼로 해당 패킷을 살펴보면 자세한 구분 내용들이 표시된다. 이런 부분까지 다 확인해 봐야할 필요가 있는 경우도 있으므로 다음에 소개할 내용을 꼭 확인해 두기 바란다.

 

 

(화면 5) 이더리얼로 본 RST 패킷

Flags 안쪽의 여러 가지 제어비트들은 각각 활성화돼 있을 경우 다음과 같은 의미를 지니게 된다. 여기서 ( )안의 숫자는 TFLAG 값이다.

 

·Urgent : 긴급 포인터의 필드가 유효하다(32)
·Ack : 수신 데이터의 일련 번호 필드가 유효하다. 보통 데이터가 정확히 수신측에 도착한 것을 의미한다(16).
·Push : 플러쉬(flush) 동작에 의해 송신된 데이터임을 나타낸다(8).
·Reset : 접속을 강제적으로 종료하는데, 이상 종료시에 쓰인다(4).
·Syn : 송신측과 수신측에서 일련 번호를 서로 확인하면서 이 제어비트로 접속 동작을 나타내게 된다(2).
·Fin : 접속의 정상적인(타임아웃 등에 의한) 종료를 나타낸다(1).

 

참고로 (화면 6, 7)의 구문처럼 하면 RST 패킷만 캡처할 수 있다. TCP[13]&4!=0에서 &뒤의 숫자 '4'가 RST의 TFLAGS 값이다. 동일하게 SYN 패킷만을 캡처할 때는 TCP[13]&2!=0과 같이 필터문구를 설정하면 된다.

 

 

(화면 6) RST 패킷만 캡처하는 구문

 

 

 

(화면 7) SYN 패킷만 캡처하는 구문

 

이더리얼 마지막 강좌에서 이야기하고 싶었던 내용은 사례 1, 2에 모두 들어있다. 문제의 해결을 위해서는 무턱대고 이더리얼로 패킷을 캡처하는 것이 아니라, 논리적으로 어떤 지점에서 문제해결의 단서를 찾아야 하는지를 먼저 판단한 후에 필요한 패킷을 캡처하고, 캡처된 패킷을 바탕으로 범위를 조금씩 더 좁혀나가야만 한다. 이런 노력들이 지속적으로 반복되면 무료이며, 강력하고, 가장 직관적인 이더리얼을 자유자재로 사용할 수 있게 될 것이다.
얼마전 한국루슨트벨랩에서 인턴근무를 마친 대학생 두명이 `루테리얼(Luthereal : Lucent+Ethereal)'이라는 모 통신사의 EV-DO 네트워크상에서 각 시스템간 메시지 분석(파싱)과 데이터 시그널링 메시지 분석을 개인용 PC에서도 가능케 하도록 한 시스템을 개발했다는 소식을 접했다. 이름에서도 알 수 있듯이 이들은 오픈소스 기반인 이더리얼을 기반으로 새로운 시스템을 구현한 것이다.
이처럼 이더리얼은 그 영역을 점점 더 확장시켜 가면서 분석 툴로서의 범용성을 한층 강화시켜가고 있다. 이번 강좌를 통해 이더리얼을 보다 많은 이들이 잘 활용해 주길 바라면서 이더리얼 연재를 마치고자 한다.