[21.9.20] 와이어 샤크를 통한 IPv4 프로토콜 필드 확인

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9791186978313 

와이어샤크를 이용한 패킷 캡처 철저 입문 - 교보문고

 

http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9788965402589 

네트워크 공격패킷 분석 - 교보문고

 

http://ktword.co.kr/test/view/view.php?m_temp1=1859 

IPv4 헤더

 

해당 서적과 블로그를 참고하여 작성하였습니다. 

 

 

 

 

 

와이어 샤크를 구동한 상태에서 'www.yes24.com' url을 검색하여 http 프로토콜을 추출하였다. 

 

yes24 관련 웹 서버가 클라에 리다이렉션 응답을 시작하여 다양한 웹페이지의 다양한 모듈들을 불러오는 과정들이 캡처되었다.

 

패킷 리스트 영역에 있는 패킷중 가장 위에 있는 요청 패킷의 IP 프로토콜을 분석해보겠다. (다 분석하고 싶지만 시간관계상...)

 

 

 

다음과 같이 패킷 데이터 영역에서 총 20바이트로 드래그 된 16진수 값이 IP 프로토콜에 대한 필드 값이며, 필드 값마다 다양한 값이 존재할 수 있다. 

 

 

 

 

 

 

Version + IHL

Version(4bits) : IP 버전이 있으며, 일반적으로 현재 사용 중인 버전 4가 사용된다.

 

IHL(Internet Header Length(4bits)) : IP 헤더 길이에 대한 정보를 담고 있다. 20바이트의 크기라면 4bytes * 5(IHL에 들어가는 필드 값) = 20bytes의 결과로, 보통은 패킷 상세 영역에서는 0101,  패킷 데이터 영역에서는 5로 표기 된다. 마지막 필드인 Options 값에 따라 길이가 가변적일 수 있으며, 최대 15가 될 수 있다. 그러나 Options 값을 거의 사용 안하기 때문에 5로 생각하는 것이 좋을 것이다. 

 

 

 

 

 

Type of service로 서비스 종류 및 혼잡 알림을 나타내어 DSCP 필드와 ECN 필드, 총 1bytes로 구성되어 있다.

 

DSCP(Differentiated Service Code Point(6bits)) : 요구되는 서비스 우선순위에 대한 유형을 나타내어 해당 패킷이 라우터에서 어떻게 처리해야 하는지를 정의하고 있다. CS0 ~ CS7로 각각의 클래스를 구분한다. CS0가 default이며, CS7이 가장 우선순위가 높다.

 

ECN(Explicit Congestion Notification(2bits)) : 혼잡을 알리는 필드이며, 라우터가 패킷을 즉각 폐기하지 않고 최종 노드에 혼잡을 알리는 용도로 사용된다. 특별한 경우가 아니라면 00 값을 넣는다.

 

 

 

 

 

 Total Length(16bits) : IP의 헤더(보통 20bytes) + 캡슐화 된 데이터 길이를 합한 값이며 최대 65535bytes까지 표현할 수 있다. 위와 같이 HTTP Requets의 IP Total Length는 1392bytes 이므로 패킷 데이터 영역에 05 70으로 나타내었다.

 

 

 

 

 

Fragment Identification(16bits) : 네트워크 기기가 전송할 수 있는 최대 전송 단위를 MTU(Maximum Transfer Unit)라고 하며, 네트워크 환경에 따라 각각의 크기는 다르지만, 대부분 네트워크 환경은 이더넷 환경이기 때문에 MTU라고  하면 이더넷 환경의 MTU인 1500bytes로 통용되고 있다. (참고로 무선 통신 환경의 WLAN(802.11)은 7981bytes)

 

만약에 MTU 이상의 크기 데이터가 전송되면 MTU 크기에 맞춰서 패킷이 분할된다. 이것을 단편화(Fragmentation)라고 한다. 데이터의 크기에 따라 단편화되는 패킷의 양이 많고 적을 수 있는데 단편화 된 임의의 패킷이 어떠한 데이터인지 구분하기 위해서 고유번호를 할당한다. 이것이 Fragment Identification이다.

 

만약 단편화 되지 않은 패킷은 오직 하나의 고유한 아이디를 부여받을 것이고, 3개로 단편화 된 패킷은 3개의 같은 아이디를 가진 패킷이 존재할 것이다.

 

 

 

 

 

Flags(3bits) + Fragment Offset(13bits) : 단편화에 대한 필드이며 패킷 데이터 영역에서 이 두개의 필드가 결합 된 값으로 나타나기 때문에 헷갈릴 수 있다. 패킷 상세 영역에서 분석해야 명확한 이해가 가능하다.

 

 

Flags : 단편화 된 추가 패킷의 여부를 알려준다. 수신 측에서는 해당 필드를 바탕으로 원래의 패킷으로 재조합 한다. 

 

Flags 맨 좌측 비트는 reserved bit, 예약 필드로 무조건 0으로 설정되어 있어야한다. 

가운데 비트는 DF 비트라고 하며 해당 데이터가 분할된 패킷이 아니라면 '1'로 설정한다. 즉 16진수로 환산하면 0x40의 값이 나타난다. 

Flags의 맨 우측 비트는 MF 비트라고 하며 '1'인경우 분할된 패킷이 더 있다는 것이며, '0'인 경우 분할된 패킷이 더이상 존재하지 않는다는 뜻이다. 즉, 16진수로 환산한다면 0x20 또는 0x00이 될 것이다. 

 

 

Fragment Offset :  분할된 패킷을 수신 측에서 재배열할 때 패킷들의 순서를 파악하는 데 사용한다. 재배열의 기준은 헤더의 크기를 뺀 encapsulation 된 데이터의 크기이며 예를 통해 더 자세히 살펴보자. 

 

만약 5,000bytes의 ICMP 패킷을 전송했다고 가정하자. Fragment offset이 어떻게 나올 것인가? 

 

첫번째 패킷의 Fragment Offset은 항상 0일 것이다. 그리고 MTU 사이즈가 1500bytes이므로 IP 헤더 20bytes를 제외한 나머지 1480bytes가 데이터 사이즈가 될 것이다. 

결론적으로 두번째 패킷의 Fragment Offset은 결국 0 + 1480이므로, 1480이 될 것이고, 세번째는 0 + 1480 + 1480 = 2960, 네번째 패킷은 0 + 1480 + 1480 + 1480인 4480이 될 것이다. 총 5000bytes의 ICMP 패킷이므로, 우리는 네번째 패킷의 Fragment Offset 4480으로 '마지막 패킷이구나!' 라는 것을 예측할 수 있으며, Flags의 MF를 보고도 판단할 수 있을 것이다.

 

 

 

 

Time to live(TTL(8bits)) : L3 루핑을 방지하기 위해 패킷의 수명을 제한한다. 라우터를 통과할 수 있는 최대 홉 수를 지정하고 만약 0이 된다면 라우터에서 폐기하여 불필요한 패킷이 네트워크에 방치하는 것을 방지한다.

 

 

 

 

 

Protocol(8bits) : IP 헤더에 따라오는 상위 프로토콜을 알려주는 필드로 TCP, UDP, ICMP 등의 프로토콜 종류를 Protocol ID로 판별할 수있다. 상위 프로토콜의 종류는 많지만 자주 사용하는 프로토콜 값만 외운다면 어느정도 패킷 분석이 한결 쉬워질 것이다. 

 

Hex	Protocol Number	Protocol
0x01	1	ICMP
0x06	6	TCP
0x11	17	UDP

 

 

 

 

 

Header Checksum(16bits) : IPv4 헤더의 오류를 검증하기 위해 사용한다. 계산방식은 CRC-32 라는 순환 중복 검사 기반의 방식으로 계산하며, RFC-1952에 규정되어 있다. 

 

 

현재 HTTP Requets의 IP Protocol의 헤더 체크섬은 80 cc이다. 이를 입증하기 위한 계산방식은 다음과 같다.

 

1. 패킷 데이터 영역의 16진수의 합산 항목 값을 4자리씩 끊어서 모두 더한다. 

4500 + 0570 + 7ce0 + 4000 + 8006 + ac1e + 011b + 3d6f + 0d33 = 2 7F31 

 

2. 맨 좌측 올림수가 발생한 첫번째 값 2를 4자리 값과 더한다. 

7F31 + 2 = 7F33 

 

3. 더한 값을 2진수로 표기 후 1의 보수화 한다. 

0111 1111 0011 0011 1의 보수 = 1000 0000 1100 1100

16진수로 다시 환산하면 80CC

 

이러한 방식으로 체크섬 값을 함께 보내 수신 측에서 에러 발생 여부를 확인한다.

 

 

 

 

 

Source Address, Destination Address(각각 32bits) : 송신자(출발지)와 수신자(목적지)의 IP 주소값이 설정 되는 필드이다.