김근혜피지피넷 스니퍼 분석 기술 지원부 차장
kgsun@pgpnet.com
연 재순서
1. 네트워크 분석 바이블 I
2. 네트워크 분석 바이블 II
3. 네트워크 분석 바이블 III
4. TCP/IP 트러블슈팅 I
5. TCP/IP 트러블슈팅 II
6. 애플리케이션 성능 관리(이번호)
이 번 호에서는 OSI 7계층 중 커넥션 계층(Connection Layer)에서의 유해 트래픽 분석 방법과 OSI 7계층에서의 애플리케이션 계층에서 제공하는 응답시간 분석방법에 대해 알아보도록 한다.<편집자>
스니퍼 활용으로 애플리케이션 성능 관리 효과 극대화
TCP/IP 프로토콜 충분한 이해 필수 … 분석자 패킷 분석 능력 중요
지 난 호까지 설명했던 레이어 2 엑스퍼트(Expert) 기능은 DLC 계층에서의 패킷 분석을 심도 있게 하고자 하는 사용자들이 필수적으로 알아야 하는 기능이다. 지금부터는 실제 TCP/IP 통신에 해당하는 3계층부터 살펴보자.
네트워크 레이어 분석
네트워크 레이어는 OSI 7계층 가운데 네트워크 계층에 해당하며, IP나 IPX, ICMP 프로토콜을 분석한다. 따라서 ICMP 패킷과 관련된 내용, IP 라우팅과 관련된 내용이 포함돼 있다. ICMP 패킷은 네트워크 상태나 장비 접속 상태 및 경로 설정 상태를 검사하기 위해 주로 사용되는 프로토콜이며, 이 프로토콜에 해당하는 패킷에는 타입(Type) 및 코드(Code)에 해당하는 헤더 필드가 정의돼 있다.
장비의 운영 체제나 사용자가 입력하는 핑(Ping)과 같은 명령어는 ICMP 패킷의 타입과 코드를 해석해 네트워크 및 장비 접속 상태를 검사하도록 설계돼 있다. 우선 IP 헤더(Header)에 대해 살펴보자.
■ 버전(Version) : 4비트
- 버전 넘버로 현재 IPv4를 나타냄.
■ IHL(Internet Header Length) : 32비트
- IP 헤더의 길이 측정. 이 부분은 TCP 헤더와 같은 상위 계층 정보가 그 데이터그램 내에서 시작하는 곳의 계측 제공.
■ ToS(Type of Services) : 8비트
- 데이터가 어떻게 다뤄질 것인가를 표시하는 것으로, 특정한 패킷에 우선 순위 배정, 가장 우선적인 전송, 지정된 시간 내 전송, 특정 응용 프로그램을 위한 대역폭 배정 등의 QoS 서비스를 제공하는 용도로 사용.
■ 전체 길이(Total Length) : 16비트
- IP 데이터 그램의 길이를 측정한다(헤더+데이터).
■ 아이덴티피케이션(Identification, 16비트)
- IP 데이터그램을 유일하게 구별하는 숫자 값으로 다중 링크를 지원하는 라우팅 영역에서의 IP 데이터그램이 다른 경로를 통해서 중복돼 들어오는 경우를 검사하거나 프레그먼테이션(Fragmentation)이 일어나 패킷에 대한 재조립에 사용.
■ 플래그(Flags)
- 전송 매체들의 MTU 차이로 인해 프레그먼테이션이 일어났을 때 프레그먼테이션이 발생한 IP 데이터그램의 일부인지, 프레그먼테이션의 마지막 패킷인지, 프레그먼테이션 패킷이 아닌지를 지정.
■ 프래그먼트 옵셋(Fragment Offset)
- 프레그먼테이션이 일어나 IP 데이터그램(패킷)의 시작 부분에서 얼마만큼 떨어져 있는가에 대한 위치 지정.
- 라우터에서 프레그먼테이션이 일어나면 인접 라우터에서 재조립을 하는 것이 아니라 마지막 엔드 노드에서 재조립 수행.
■ TTL(Time-to-Live)
- 인터넷 속에서 생존할 수 있는 최대 시간으로, TTL=0이면 데이터그램은 파괴됨. 최대 255초로 지정돼 있음.
■ 프로토콜(8비트)
- 사용중인 상위 계층 프로토콜을 식별함
< 그림 2>와 <그림 3>은 IP 헤더에 대한 분석을 통해 볼 수 있는 스니퍼 스테이션 레이어 엑스퍼트(Sniffer Station Layer Expert) 화면 내용이다. 이 스테이션 레이어 분석을 통해 각 IP별 트래픽 사용현황과 발생되는 네트워크 상의 이상 징후에 대해 확인할 수 있다.
■ 스테이션 요약(Station Summary)
- Net Station : 각 스테이션의 네트워크 주소
- DLC Station : 해당 스테이션의 DLC 주소
- Rx Frames : 해당 스테이션이 수신한 프레임 개수
- Tx Frames : 해당 스테이션이 송신한 프레임 개수
- Rx Bytes : 해당 스테이션이 수신한 바이트 수
- Tx Bytes : 해당 스테이션이 송신한 바이트 수
- Connections : 해당 스테이션에 대해 검출되는 커넥션 개수
- Diag/Symp : 해당 스테이션 상에서 발생한 알람 이벤트 개수
- Last Diag/Symp : 해당 네트워크 스테이션 상에서 발생한 마지막 알람
- Duration : 해당 네트워크 스테이션이 활동한 시간
- Protocol : 해당 네트워크 스테이션이 활동한 토폴로지 종류
- First Frame : 해당 스테이션에서 프레임이 처음 검출된 시간
- Last Frame : 해당 스테이션에서 가장 최근에 프레임이 검출된 시간
- Attributes : 스테이션들의 특수 기능을 알 수 있다면 이곳에 표시
커넥션 레이어 분석
커넥션 레이어는 OSI 7계층 트랜스포트(Transport) 계층에 해당하며, TCP나 UDP 같은 프로토콜을 분석한다. 이 계층에서는 포트 번호 및 전송 방식을 기본으로 패킷을 분석하며, 대부분의 네트워크에서 가장 많은 분석 대상(objects)을 포함하고 있다.
먼저 이 계층을 분석하기 위해 꼭 알고 있어야 할 TCP 헤더와 UDP 헤더에 대해 살펴보자. 모든 신뢰성을 중요시하는 애플리케이션들은 TCP로 개발돼 있으며, 데이터 전송속도에 민감한 애플리케이션들은 UDP 헤더로 개발됐다. 따라서 실제 헤더를 보더라도 그만큼 TCP가 복잡하다.
■ Sequence Number Field
- TCP 세그먼트 표시를 위한 번호
- 각각의 TCP 수신 측을 확인하기 위해 부여됨
- 데이터 송수신 과정동안에 상대방에서 전송된 이전 패킷의 ACK 번호와 일치
- 전송되는 패킷에 포함된 데이터 크기만큼 번호 증가
- 패킷 내부에 데이터가 포함돼 있지 않는 경우에는 다음 패킷도 동일한 번호 사용
■ Next expected Seq. number
- 스니퍼에서 패킷 내부에 포함된 데이터 크기에 따라서 다음 패킷에 부여되는 Seq. number를 계산한 값
- Seq. number와의 차이값이 해당 패킷에 포함된 실제 데이터의 크기
■ Acknowledgment Number Field
- 이 필드에 있는 번호는 상대방 측에서 다음에 전송되는 패킷에 부여할 Seq. number다.
■ URG flag
- TCP 헤더 내에 있는 urgent pointer에 값이 있음.
- 해당 패킷이 긴급한 데이터를 포함하고 있음.
■ ACK flag
- 이미 전송된 패킷에 대한 Acknowledgement 패킷
■ PSH flag(push)
- 해당 패킷을 수신하는 TCP 스택은 전송된 패킷을 버퍼에 누적하지 않고 상위 계층으로 곧바로 전달.
- 고속 처리가 필요하거나 단일 패킷만 사용하는 애플리케이션에서 사용됨.
- 최근에는 애플리케이션 계층까지의 처리 시간이 오래 걸리지 않기 때문에 이 비트는 무시.
■ RST flag(reset)
- 커넥션을 초기화
- 서버쪽으로 TCP SYN 패킷을 보내는 클라이언트에게 해당 TCP 포트에서는 어떤 작업도 수행되지 않고 있다는 응답을 하기 위해서 설정.
- 해킹 확인.
■ SYN flag
- 커넥션 초기화 및 sequence number 동기화.
- MSS(Maximum Segment Size) 조절.
■ FIN flag
- 송신측에서 모든 데이터 전송이 끝났음을 의미.
- TCP 커넥션 중지.
기본적인 헤더에 대한 이해를 했다면 이제 커넥션 레이어에 대한
엑스퍼트 분석 내용을 살펴보자.
■ 커넥션 엑스퍼트 요약(Connection Expert Summary)
- Net Station 1: 해당 커넥션에 대한 한쪽의 네트워크 주소
- Net Station 2 : 해당 커넥션에 대한 다른 한쪽의 네트워크 주소
- Protocol : 해당 커넥션의 커넥션-레벨 프로토콜
- Frames : 해당 커넥션에서 전달된 총 프레임 개수
- Bytes : 해당 커넥션에서 전달된 총 바이트 수
- Diag/Symp : 해당 커넥션에서 발생한 알람 이벤트 개수
- Last Diag/Symp : 해당 커넥션에서 발생한 마지막 알람
- Duration : 해당 커넥션이 유지된 시간
- DLC Station 1 : Net Station 1의 DLC 주소
- DLC Station 2 : Net Station 2의 DLC 주소
- Frames 1 : 스테이션 1에 의해 전송된 프레임 개수
- Frames 2 : 스테이션 2에 의해 전송된 프레임 개수
- Bytes 1 : 스테이션 1에 의해 전송된 바이트 수
- Bytes 2 : 스테이션 2에 의해 전송된 바이트 수
- First Frame : 해당 커넥션에서 프레임이 처음 검출된 시간
- Last Frame : 해당 커넥션에서 가장 최근에 프레임이 검출된 시간
커넥션 계층에서는 재전송 패킷분석, 응답시간, 커넥션 상에서의 문제, 포트 정보 등에 대한 분석을 제공한다. 알람 항목은 대부분이 중요도가 마이너(Minor)지만, 특별히 주의해서 봐야 할 항목(Diagnosis)은 아래 두 가지다.
■ Too Many Retransmissions
- 발생 원인 : 전송하는 TCP 세그먼트 또는 돌아오던 ACK 패킷이 스위치나 라우터에서 버려진 경우, 패킷이 전송되는 도중에 손상된 경우(CRC 에러), 스위치나 라우터에 의해 패킷의 TCP 데이터 부분이 손상된 경우(TCP 체크섬 에러), 수신측에서 해당 패킷을 버퍼에 저장할 수 없을 경우, TCP 세그먼트가 조각난 상태에서 한 조각이 버려졌거나 손상된 경우 등
■ Non-Responsive Station
- 발생 원인 : 이 메시지는 네트워크에 연결된 상태에서 오류 없는 전송에 대한 재전송의 이 메시지는 특정 스테이션이 스니퍼 프로의 엑스퍼트 프로퍼티스 대화상자 내 알람 탭에 있는 이 메시지의 No Response Count 항목에 설정한 임계값인 3회 이상의 재전송에도 응답이 없을 경우, 소프트웨어 구성이 적절치 못한 경우 서버가 과부하 됐을 경우 하드웨어적인 결함이 있을 경우 등
이번에는 TCP 통신상의 약점을 이용한 유해 트래픽의 유형을 알아보도록 하자. 일반적인 Syn Flooding의 경우 1:N, N:1의 유형을 가지고 있으며, 현재까지 발견된 사용 포트는 135, 445, 137, 138, 139 등이 있다. 현재 네트워크 관리자들이 특별하게 네트워크에서 사용되지 않는다면 135, 445 포트는 스위치에서 막아놓는 경우들도 있다.
<그림 8>과 <그림 9>는 유해 트래픽 유형이다. <그림 10>에 대해서만 간략하게 설명하면 이는 실제 Syn 공격이지만 HTTP 애플리케이션인 것처럼 변조된 공격 중의 한 유형이며, 이 패킷들이 문제가 있는 이유를 몇 <그림 10>에 나와있는 번호별로 설명하도록 하겠다.
① 데스티네이션 주소가 하나이고, 크기가 74바이트로 동일한 패킷이 초당 16352 발생했으며, TCP 80 포트를 이용해 HTTP 형식을 취한 패킷이 이렇게 많이 발생할 수는 없음을 확인. 확실히 바이러스 또는 해킹 시도에 의한 것이라고 예측할 수 있음.
② TCP 포트 1000 이하의 번호들은 일반적으로 많이 사용하는 애플리케이션들의 포트로 사용하고 있기 때문에 클라이언트에서 번호로 잘 사용하지 않는다. 이 경우 모든 소스의 포트가 대부분 1000 이하로 할당돼 있음.
③ 80 포트를 이용해 많은 IP들이 하나의 IP 쪽으로 데이터 패킷을 전송하는 상황처럼 보이는데 TCP 헤더를 보면 모든 패킷들의 Sequence 번호와 Acknowledge 번호가 모두 동일함. 또한 앞에 TCP 헤더에서 살펴보았듯 플래그 설정을 보면 모든 패킷이 SYC 패킷임. 이 패킷들이 정상적으로 HTTP 패킷이라면 Syn 플래그 비트는 0으로 설정돼 있어야 함.
④ TCP 헤더의 일부분이 맞지 않거나 수정돼 전송됐기 때문에 체크섬 오류가 발생하고 있음.
⑤ TCP 80 포트를 이용하는 HTTP 패킷들인데 데이터는 전혀 없음. 네트워크 애플리케이션과 전혀 상관없는 패킷들로 보여짐.
이상 커넥션 레이어에 대해 살펴봤다. 요즘에 발생하는 네트워크 문제들이 보안과도 밀접한 관계가 있고 또한 TCP 애플리케이션 상에서 발생하므로 다른 계층에 비해 이 계층은 통신상에 문제 발생시 심도 있게 체계적으로 분석해 볼 필요가 있다.
애플리케이션 레이어 분석
이 계층은 말 그대로 OSI 7계층 가운데 애플리케이션 계층에 해당하며, 이 계층에서는 현재 네트워크에서 송신 및 수신된 패킷들의 애플리케이션 계층에 대한 정보를 분석해 요약 창에 표시한다. 이 계층에는 사용자들이 특정 애플리케이션 서버에 접속하는 경우, 접속 속도와 응답 속도, 로그 온 실패, 접속 거부, 접속 불능. 접속 후 전송 속도 등과 관련된 분석 결과를 포함하고 있다.
■ 애플리케이션 레이어 요약(Application Layer Summary)
- Net Station 1 : 해당 애플리케이션을 사용하고 있는 커넥션의 한쪽 네트워크 주소
- Net Station 2 : 해당 애플리케이션을 사용하고 있는 커넥션의 다른 한쪽 네트워크 주소
- Protocol : 해당 커넥션 상에서 사용하는 애플리케이션-레벨 프로토콜
- Requests : 애플리케이션 세션 상에서 양쪽으로 검출되는 요청 개수
- Frames : 해당 애플리케이션 세션의 양방향으로 전송되는 프레임의 총 개수
- Bytes : 애플리케이션 세션의 양방향으로 전송되는 총 바이트 수
- Diag/Symp : 해당 애플리케이션 세션에서 발생한 알람 이벤트 개수
- Last Diag/Symp : 해당 애플리케이션 세션에서 발생한 마지막 알람
- Duration : 해당 애플리케이션이 사용됐던 시간
- DLC Station 1 : Net Station 1의 DLC 주소
- DLC Station 2 : Net Station 2의 DLC 주소
- First Frame : 커넥션에서 프레임이 처음 검출된 시간
- Last Frame : 커넥션에서 가장 최근에 프레임이 검출된 시간
<그림 11>은 애플리케이션 레이어에서 분석 가능한 엑스퍼트 내용이다. 이 부분에서 보면 트랜잭션 시간 분석 내용이 포함돼 있다. 앞에 커넥션 레이어에서 분석된 응답시간과 어떻게 다른지 그리고 어떤 분석을 통해 나온 값인지를 설명하도록 하겠다.
TCP 커넥션 레이어에서 제공하는 응답시간의 측정 기준은 그림에서 보듯 리퀘스트(Request) 패킷에 대한 응답 패킷이 모두 다 들어 올 때까지의 누적시간(Relative Time)이며, 애플리케이션 레이어에서 제공하는 트랜잭션 시간은 리퀘스트 패킷에 대한 응답 패킷의 첫 번째 패킷에 대한 델타(Delta) 시간의 측정치다.
따라서 서버 앞단에 스니퍼를 설치했을 경우 이 애플리케이션 레이어에서의 트랜잭션 시간은 서버 프로세싱 타임이 될 수 도 있으며, 클라이언트 앞단에 스니퍼를 설치했을 경우에 커넥션 레이어의 응답시간은 서버 프로세싱 타임과 전체 응답시간이 전송될 때까지 네트워크 지연시간이 포함된 값이 될 수 있다. 보다 세부적인 응답시간이 필요하다면 아래와 같은 방법을 이용하면 된다.
■ 스니퍼 설치
- 응답 시간과 관련된 모든 지점을 측정 : 스니퍼를 이용해 반드시 클라이언트와 서버 측에서 동시에 패킷을 캡쳐해야 함.
- 양측에서 캡쳐된 트래픽을 분석해 다음과 같은 항목 관찰 : 네트워크 지연, 서버 응답시간, 클라이언트 응답시간
- 트레이스(Trace) 파일에는 두 지점의 트래픽 정보를 포함하고 있음.
■ 클라이언트의 MAC 또는 IP 주소를 이용해 캡쳐 필터 구성(오직 클라이언트와 서버 사이의 프레임만 필요하므로 스니퍼 캡처 → 디파인 필터(Define Filter) → 어드레스 이용)
■ 클라이언트에서 서버로의 접속을 시도하기 전에 스니퍼의 캡쳐 기능 실행.
이와 같은 작업을 실행한 후 실제 서버에 접속한 다음 두 트레이스 파일을 비교 분석하면 보다 상세한 구간별 응답시간을 측정 할 수도 있다.
이상 각 엑스퍼트 시스템에서 분석해 볼 수 있는 기능들을 설명했다. 짧은 지면으로 스니퍼의 다양한 활용도를 설명하다 보니, 부족한 점이 많은 것 같다. 스니퍼의 일반적인 기능들은 많이 사용하다 보면 익숙해질 수 있지만 실제 네트워크 트러블슈팅시 중요한 것은 분석자의 패킷 분석 능력에 의해 많이 좌우된다.
스니퍼를 사용하는 사용자라면 먼저 TCP/IP 프로토콜에 대한 충분한 이해가 있어야 하며, 다양한 패킷들을 실제 분석해 봄으로써 접하게 되는 경험이 가장 중요하다. 스니퍼에 관심이 있는 독자들이라면 앞으로 스니퍼 동호회의 자료를 많이 이용하기 바라며, 또한 지금까지 게재한 내용들을 기초로 네트워크 트래픽 분석 전문가로서의 초석을 다지는 지식에 조금이나마 도움이 되길 바란다
■ 커넥션 엑스퍼트 요약(Connection Expert Summary)
- Net Station 1: 해당 커넥션에 대한 한쪽의 네트워크 주소
- Net Station 2 : 해당 커넥션에 대한 다른 한쪽의 네트워크 주소
- Protocol : 해당 커넥션의 커넥션-레벨 프로토콜
- Frames : 해당 커넥션에서 전달된 총 프레임 개수
- Bytes : 해당 커넥션에서 전달된 총 바이트 수
- Diag/Symp : 해당 커넥션에서 발생한 알람 이벤트 개수
- Last Diag/Symp : 해당 커넥션에서 발생한 마지막 알람
- Duration : 해당 커넥션이 유지된 시간
- DLC Station 1 : Net Station 1의 DLC 주소
- DLC Station 2 : Net Station 2의 DLC 주소
- Frames 1 : 스테이션 1에 의해 전송된 프레임 개수
- Frames 2 : 스테이션 2에 의해 전송된 프레임 개수
- Bytes 1 : 스테이션 1에 의해 전송된 바이트 수
- Bytes 2 : 스테이션 2에 의해 전송된 바이트 수
- First Frame : 해당 커넥션에서 프레임이 처음 검출된 시간
- Last Frame : 해당 커넥션에서 가장 최근에 프레임이 검출된 시간
커넥션 계층에서는 재전송 패킷분석, 응답시간, 커넥션 상에서의 문제, 포트 정보 등에 대한 분석을 제공한다. 알람 항목은 대부분이 중요도가 마이너(Minor)지만, 특별히 주의해서 봐야 할 항목(Diagnosis)은 아래 두 가지다.
■ Too Many Retransmissions
- 발생 원인 : 전송하는 TCP 세그먼트 또는 돌아오던 ACK 패킷이 스위치나 라우터에서 버려진 경우, 패킷이 전송되는 도중에 손상된 경우(CRC 에러), 스위치나 라우터에 의해 패킷의 TCP 데이터 부분이 손상된 경우(TCP 체크섬 에러), 수신측에서 해당 패킷을 버퍼에 저장할 수 없을 경우, TCP 세그먼트가 조각난 상태에서 한 조각이 버려졌거나 손상된 경우 등
■ Non-Responsive Station
- 발생 원인 : 이 메시지는 네트워크에 연결된 상태에서 오류 없는 전송에 대한 재전송의 이 메시지는 특정 스테이션이 스니퍼 프로의 엑스퍼트 프로퍼티스 대화상자 내 알람 탭에 있는 이 메시지의 No Response Count 항목에 설정한 임계값인 3회 이상의 재전송에도 응답이 없을 경우, 소프트웨어 구성이 적절치 못한 경우 서버가 과부하 됐을 경우 하드웨어적인 결함이 있을 경우 등
이번에는 TCP 통신상의 약점을 이용한 유해 트래픽의 유형을 알아보도록 하자. 일반적인 Syn Flooding의 경우 1:N, N:1의 유형을 가지고 있으며, 현재까지 발견된 사용 포트는 135, 445, 137, 138, 139 등이 있다. 현재 네트워크 관리자들이 특별하게 네트워크에서 사용되지 않는다면 135, 445 포트는 스위치에서 막아놓는 경우들도 있다.
<그림 8>과 <그림 9>는 유해 트래픽 유형이다. <그림 10>에 대해서만 간략하게 설명하면 이는 실제 Syn 공격이지만 HTTP 애플리케이션인 것처럼 변조된 공격 중의 한 유형이며, 이 패킷들이 문제가 있는 이유를 몇 <그림 10>에 나와있는 번호별로 설명하도록 하겠다.
① 데스티네이션 주소가 하나이고, 크기가 74바이트로 동일한 패킷이 초당 16352 발생했으며, TCP 80 포트를 이용해 HTTP 형식을 취한 패킷이 이렇게 많이 발생할 수는 없음을 확인. 확실히 바이러스 또는 해킹 시도에 의한 것이라고 예측할 수 있음.
② TCP 포트 1000 이하의 번호들은 일반적으로 많이 사용하는 애플리케이션들의 포트로 사용하고 있기 때문에 클라이언트에서 번호로 잘 사용하지 않는다. 이 경우 모든 소스의 포트가 대부분 1000 이하로 할당돼 있음.
③ 80 포트를 이용해 많은 IP들이 하나의 IP 쪽으로 데이터 패킷을 전송하는 상황처럼 보이는데 TCP 헤더를 보면 모든 패킷들의 Sequence 번호와 Acknowledge 번호가 모두 동일함. 또한 앞에 TCP 헤더에서 살펴보았듯 플래그 설정을 보면 모든 패킷이 SYC 패킷임. 이 패킷들이 정상적으로 HTTP 패킷이라면 Syn 플래그 비트는 0으로 설정돼 있어야 함.
④ TCP 헤더의 일부분이 맞지 않거나 수정돼 전송됐기 때문에 체크섬 오류가 발생하고 있음.
⑤ TCP 80 포트를 이용하는 HTTP 패킷들인데 데이터는 전혀 없음. 네트워크 애플리케이션과 전혀 상관없는 패킷들로 보여짐.
이상 커넥션 레이어에 대해 살펴봤다. 요즘에 발생하는 네트워크 문제들이 보안과도 밀접한 관계가 있고 또한 TCP 애플리케이션 상에서 발생하므로 다른 계층에 비해 이 계층은 통신상에 문제 발생시 심도 있게 체계적으로 분석해 볼 필요가 있다.
애플리케이션 레이어 분석
이 계층은 말 그대로 OSI 7계층 가운데 애플리케이션 계층에 해당하며, 이 계층에서는 현재 네트워크에서 송신 및 수신된 패킷들의 애플리케이션 계층에 대한 정보를 분석해 요약 창에 표시한다. 이 계층에는 사용자들이 특정 애플리케이션 서버에 접속하는 경우, 접속 속도와 응답 속도, 로그 온 실패, 접속 거부, 접속 불능. 접속 후 전송 속도 등과 관련된 분석 결과를 포함하고 있다.
■ 애플리케이션 레이어 요약(Application Layer Summary)
- Net Station 1 : 해당 애플리케이션을 사용하고 있는 커넥션의 한쪽 네트워크 주소
- Net Station 2 : 해당 애플리케이션을 사용하고 있는 커넥션의 다른 한쪽 네트워크 주소
- Protocol : 해당 커넥션 상에서 사용하는 애플리케이션-레벨 프로토콜
- Requests : 애플리케이션 세션 상에서 양쪽으로 검출되는 요청 개수
- Frames : 해당 애플리케이션 세션의 양방향으로 전송되는 프레임의 총 개수
- Bytes : 애플리케이션 세션의 양방향으로 전송되는 총 바이트 수
- Diag/Symp : 해당 애플리케이션 세션에서 발생한 알람 이벤트 개수
- Last Diag/Symp : 해당 애플리케이션 세션에서 발생한 마지막 알람
- Duration : 해당 애플리케이션이 사용됐던 시간
- DLC Station 1 : Net Station 1의 DLC 주소
- DLC Station 2 : Net Station 2의 DLC 주소
- First Frame : 커넥션에서 프레임이 처음 검출된 시간
- Last Frame : 커넥션에서 가장 최근에 프레임이 검출된 시간
<그림 11>은 애플리케이션 레이어에서 분석 가능한 엑스퍼트 내용이다. 이 부분에서 보면 트랜잭션 시간 분석 내용이 포함돼 있다. 앞에 커넥션 레이어에서 분석된 응답시간과 어떻게 다른지 그리고 어떤 분석을 통해 나온 값인지를 설명하도록 하겠다.
TCP 커넥션 레이어에서 제공하는 응답시간의 측정 기준은 그림에서 보듯 리퀘스트(Request) 패킷에 대한 응답 패킷이 모두 다 들어 올 때까지의 누적시간(Relative Time)이며, 애플리케이션 레이어에서 제공하는 트랜잭션 시간은 리퀘스트 패킷에 대한 응답 패킷의 첫 번째 패킷에 대한 델타(Delta) 시간의 측정치다.
따라서 서버 앞단에 스니퍼를 설치했을 경우 이 애플리케이션 레이어에서의 트랜잭션 시간은 서버 프로세싱 타임이 될 수 도 있으며, 클라이언트 앞단에 스니퍼를 설치했을 경우에 커넥션 레이어의 응답시간은 서버 프로세싱 타임과 전체 응답시간이 전송될 때까지 네트워크 지연시간이 포함된 값이 될 수 있다. 보다 세부적인 응답시간이 필요하다면 아래와 같은 방법을 이용하면 된다.
■ 스니퍼 설치
- 응답 시간과 관련된 모든 지점을 측정 : 스니퍼를 이용해 반드시 클라이언트와 서버 측에서 동시에 패킷을 캡쳐해야 함.
- 양측에서 캡쳐된 트래픽을 분석해 다음과 같은 항목 관찰 : 네트워크 지연, 서버 응답시간, 클라이언트 응답시간
- 트레이스(Trace) 파일에는 두 지점의 트래픽 정보를 포함하고 있음.
■ 클라이언트의 MAC 또는 IP 주소를 이용해 캡쳐 필터 구성(오직 클라이언트와 서버 사이의 프레임만 필요하므로 스니퍼 캡처 → 디파인 필터(Define Filter) → 어드레스 이용)
■ 클라이언트에서 서버로의 접속을 시도하기 전에 스니퍼의 캡쳐 기능 실행.
이와 같은 작업을 실행한 후 실제 서버에 접속한 다음 두 트레이스 파일을 비교 분석하면 보다 상세한 구간별 응답시간을 측정 할 수도 있다.
이상 각 엑스퍼트 시스템에서 분석해 볼 수 있는 기능들을 설명했다. 짧은 지면으로 스니퍼의 다양한 활용도를 설명하다 보니, 부족한 점이 많은 것 같다. 스니퍼의 일반적인 기능들은 많이 사용하다 보면 익숙해질 수 있지만 실제 네트워크 트러블슈팅시 중요한 것은 분석자의 패킷 분석 능력에 의해 많이 좌우된다.
스니퍼를 사용하는 사용자라면 먼저 TCP/IP 프로토콜에 대한 충분한 이해가 있어야 하며, 다양한 패킷들을 실제 분석해 봄으로써 접하게 되는 경험이 가장 중요하다. 스니퍼에 관심이 있는 독자들이라면 앞으로 스니퍼 동호회의 자료를 많이 이용하기 바라며, 또한 지금까지 게재한 내용들을 기초로 네트워크 트래픽 분석 전문가로서의 초석을 다지는 지식에 조금이나마 도움이 되길 바란다
'IT인생_스크랩 > Network' 카테고리의 다른 글
| 윈도우 cmd 네트워크 명령어 (0) | 2010.06.24 |
|---|---|
| ROUTER 명령어 _ CCNA(ICND)완벽정리 (0) | 2010.06.24 |
| 네트워크 분석 바이블 III (0) | 2010.06.24 |
| 네트워크 분석 바이블 II - 스니퍼 활용 가이드 (0) | 2010.06.24 |
| 스니퍼 활용 가이드 - TCP/IP 트러블슈팅 II (0) | 2010.06.24 |