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

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

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

 

사례 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)를 채워 발송한다

  

사용자 삽입 이미지
 (화면 2) ARP 요청(request) 패킷

 

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

 

 

사례 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에서도 가능케 하도록 한 시스템을 개발했다는 소식을 접했다. 이름에서도 알 수 있듯이 이들은 오픈소스 기반인 이더리얼을 기반으로 새로운 시스템을 구현한 것이다.
이처럼 이더리얼은 그 영역을 점점 더 확장시켜 가면서 분석 툴로서의 범용성을 한층 강화시켜가고 있다. 이번 강좌를 통해 이더리얼을 보다 많은 이들이 잘 활용해 주길 바라면서 이더리얼 연재를 마치고자 한다.

 

출처 : www.ionthenet.co.kr

이 댓글을 비밀 댓글로