네트워크 공격패킷 분석 1-2-1. 패킷이 오가는 방법, IP 헤더: IP 정보

참고도서: 방주원, 이정환, 이주 『보안 실무자를 위한 네트워크 공격패킷 분석』, 프리렉

 

패킷 구조: IP, TCP/UDP, 데이터

IP 헤더 (L3)

TCP/UDP 헤더 (L4)

데이터(payload)

 

오늘 배울 내용은 IP헤더

 

헤더에는 “이 패킷을 어디로 보내야 하지?”, “조각 났으면 어떻게 합칠까?”
같은 길찾기 정보가 들어 있다.

 

특이사항은 길만 찾아주기 때문에 잘 도착했는지 여부에는 관심이 없다.

편지를 보내면 됐지, 뭘 도착했는가 확인전화까지 하느냐 마인드다.

 

IP 헤더의 구조

4	8	16	32
Version	IHL	Type of service	Total Length
Identification			Flags (3bit)	Fragment offset (13bit)
Time To Live		Protocol	Header checksum
Source IP address
Destination IP address
Options + Padding

 

패킷을 분석하기 위해 와이어샤크(www.wireshark.org)를 설치한다. 

와이어샤크를 설치하고 켜고, 인터넷 연결선을 찾아 누르면

씬이 오간 모습과 왼쪽 패킷상태창(프로토콜 해석), 오른쪽 바이트창(핵스와 아스키코드 값)이 나온 모습이다. 

 

 

패킷 상태창: 인간 친화적 번역

HEX(헥스) 창 = 원본 데이터, 원본 바이트

ASCII 창 = 핵스창의 내용을 아스키코드로 변환한 내용이다. 헥스의 내용이 실제 숫자나 문자로 변환된다.

        -> 예: 헥스에서의 45는 아스키코드에서 E로 변환된다. 

        -> 아스키코드로 출력이 불가한 내용은 (.)으로 표시한다.

Version & IHL (Internet Header Length)

IPv4의 첫 번째 바이트(8bit)는 Ver와 IHL이다.

1) Version

IPv4인지, IPv6인지 구분지어준다. 보통 IPv4이다.

(앞 부분은 이진수) 

 

2) IHL (Internet Header Length, 4bit)

IP 헤더 길이. IP의 정보를 담은 IP헤더의 총 길이를 의미한다.

이 IHL 칸은 한 칸이 4bit를 차지하고 있고, IHL 칸의 단위는 4byte다.

보통 여기에 5라고 적혀있는데,  4바이트의 단위 블록이 5개있다는 의미이다. 

  

IP기본 헤더는 20바이트이다. (5 × 4바이트 = 20바이트)

보통 IHL은 20바이트인데, 옵션이 추가되면 용량이 증가해서 60바이트가 되기도 한다.

여기서 옵션은 마지막 필드인 Options가 맞다.

IHL의 옵션: 패킷의 이동 경로를 기록하거나 강제하는 기능들

이 내용은 패킷 바이트창 헥스(HEX) 부분에서도 확인이 가능하다. 바이트창은 16진수 형태를 사용한다.

 

재밌는건 ver나 IHL이나 각각 15비트씩 밖에 되지 않으므로, 그냥 같이 표현한다는 거다.

version은 IPv4이고, IHL은 5라는 의미이다. 

 

물론 그 옆에 아스키코드(ASKII) 부분에서도 볼 수 있다.

TOS & DSCP/ECN

IPv4의 두 번째 바이트는 Qos에 해당하는 DSCP/ECN이다.

옛날엔 TOS라고 불렀는데, 오늘날엔 DSCP/ECN이라고 부른다.

TOS: Type of Servic, 
DSCP:
ECN: 
Qos: Quality of Service, 중요한 트래픽을 먼저 보내주는 시스템

지금도 TOS라고 부르는 이유는 그냥 TOS라고 배운 사람들이 아직 정년이 안돼서 그래요. 

옛날방식인 TOS는 쿨하게 생략한다..

 

1) DSCP

현대 QoS는 IPv4/IPv6 모두 DSCP/ECN을 사용한다.

 

1bit	2bit	3bit	4bit	5bit	6bit	7bit	8bit
DSCP						ECN

 

DSCP는 6비트[0000 00..]를 사용하고, 트래픽의 우선 순위에 관여한다. 숫자가 클수록 우선 순위가 높다.

마치 다이아몬드같네

 

아래는 시험에서 자주 나오는 CS0~CS7(class seletor)이다.

DSCP0	2진수	16진수	10진수	우선순위
CS0(Default)	000000	0X00	0	낮음
CS1	001000	0X08	8
CS2	010000	0X10	16
CS3	011000	0X18	24
CS4	100000	0X20	32
CS5	101000	0X28	40
CS6	110000	0X30	48
CS7	111000	0X38	56	높음

 

이걸 배우는 이유는 실제 네트워크 트래픽이 어떤 우선순위로 보내지고 있는지 보기 위함이다. 

허가되지 않는 명령으로 보내지고 있으면 해커가 침입했거나 무언가 오류가난거니까.

 

2) ECN

DSCP 뒤에 붙은 2bit가 ECN이다. 

[.... ..00]부분을 담당한다.

 

ECN은 네트워크 혼잡여부(패킷처리에 혼잡여부)를 2bit로 표시한다.

00	Non ECN-Capable	ECN 사용 안 함
10 or 01	ECN Capable (ECT(1)) or ECN Capable (ECT(0))	ECN 가능
11	Congestion Experienced (CE)	네트워크 혼잡 발생했음!

 

네트워크가 혼잡해지면, ECN은 11로 바뀌고, 수신자의 TCP는 송신자에게 이 소식을 전하고(TCP 헤더의 ECE 플래그=1), 송신자는 패킷을 보내는 속도를 늦춘 후 CWR 플래그 =1 로 회신한다.

 

그리고 이건 엄청 중요한 내용은 아니다. 

우리는 보안팀이지, 네트워크 팀이 아니거든;; 딥하게 공부하다가 탈출했다. 

 

Total Length (16bit)

어디까지가 패킷인지 알려주는 정보가 들어있다.

 

헤더와 데이터를 합한 전체 길이를 의미한다. 단위는 byte

Total Length의 최대 길이가 16bit이기 때문에 최대 65,535 bytes까지 표현 가능하다.

(2진수 1111 1111 1111 1111의 값이 65535임)

근데.. 현재 네트워크 환경에서는 1500bytes로 제한(아래 배움)해서 이론상 65,535bytes일 뿐...

Total Length는 가장 커도 1500bytes까지만 표시된다.

아무튼 이곳에서 확인할 수 있다. 

그리고 각각 헥스창와 아스키 코드창에도 표시된다.

287의 16진법값인 11f와 문자열로 나올 수 없는 아스키코드 ..

Identification (16bit)

요약: 같은 패킷 조각임을 식별하는 번호.

 

네트워크 기기가 전송할 수 있는 패킷의 최대 크기를 MTU(Maximum Transfer Unit)라고 한다.

현재 대부분의 네트워크 환경이 이더넷 환경이기 때문에 일반적으로 MTU라고 하면 1500byte를 의미한다.

그랫서 total length가 65,535bytes여도 의미가 없다...

 

만약 MTU이상의 데이터가 전송된다면 MTU 크기에 맞춰 패킷이 분할되며, 이를 단편화(Fragmentation)라고 한다. 

그리고 얘네들은 똑같은 값의 ID(Identification)를 갖게 된다.

왜냐면 전송 후에 다시 합쳐져야 하니까..

패킷 상태창에선 아래의 위치에 있다.

단편화가 된 패킷의 ID를 확인하기

 -> 이건 옵션에서 넣어서 꺼내왔다. 

 

상단 바의 [편집] -> [설정]->[모양]->[열]에서 적용 가능하다.

 

그리고 오늘 날엔 파일 보내는 송신자가 애초에 MTU(1500bytes)를 지켜서 보내기 때문에 이걸 확인할 일은 많지 않다.

 

Flags (3bit)

단편화 하려고 무진무진 애써봤지만, 오늘날엔 이 단편화도 안함. ㅎ

운영체제가 알아서 MTU이하로 잘라서 보내거든.

개념으로만 알아두세요...ㅎ....

그래서 그냥 교재 내용 첨부합니다. 
나중에 기운 나거나, 제가 똑똑해지면 수정하러 올게요..

 

 

Fragment Offset (13bit)

지쳐서 얘 또한 교재 업뎃... 얘도 윈도우로 확인 안됨.

 

IP 패킷이 너무 커서 조각(Fragment)으로 나뉘어 전송될 때,
각 조각이 원래 데이터의 몇 번째 위치에 해당하는지 알려주는 필드.

 

조금 정리하자면 단편화된 파일이 

..1. .... = more ffragements일 땐 다음 패킷이 있다는 의미고

..0. .... = more ffragements일 땐 패킷이 종료 되었다는 뜻임

 

TTL (Time To Live, 8bit)

패킷 수명을 관장하는 부분이다.

0이 되면 버려진다. 잘못해서 패킷이 무한루프에 걸리더라도 혼자 사라지게 해 네트워크 혼선을 줄이기 위함이다.

택배로 따지자면 옥천 버뮤다에 빠지더라도 혼자 폐기해서 옥천 터미널이 터지지 않게 한다는 느낌이다.

OS별로 TTL값을 갖는다. 엄청 중요한 내용은 아니다.

와이어샤크에서도 물론 볼 수 있고

cmd(명령 프롬프트)에서 ping을 검색하여 TTL 값을 볼 수도 있다.

윈11은 128 TTL인 것 같다.

 

Protocol (8bit)

서로 약속한 규칙으로 언어도 일종의 프로토콜이다. 사회적 약속이니까.

 

여기서는 해당 패킷이 가지고 있는 내용이 무슨 내용인지 알려주는 일종의 태그라고 할 수 있다. 

 

라우터는 IP 헤더만 보고 패킷을 전달하며

프로토콜 번호는 수신 측 장비가 IP 패킷 안에 들어있는 내용물이

TCP인지, UDP인지, ICMP인지 판단하는 데 사용된다.

이후 프로토콜을 수신한 수신자는

TCP/UDP인 경우에는 포트 번호를 확인하고

해당 프로토콜에 맞는 응용프로그램에게 전달한다. 

ICMP는 ICMP 모듈에서 처리한다.

OS 내부에서 바로 처리하기 때문에 넘어갈 응용프로그램이없다.

라우터
↓ (IP 헤더만 보고 이동)
수신 장비(L3)
↓ (Protocol 번호 확인)
수신 장비(L4: TCP/UDP/ICMP)
↓ (포트 번호 확인)
응용프로그램(HTTP, DNS, SSH 등)

 

프로토콜의 위치는 아래와같다.

가장 대표적으로 우리가 알아야하는 프로토콜은 아래와 같다.

 

1	ICMP	핑, 에러 알림 (네트워크 진단)	①  PC → 8.8.8.8로 ICMP Echo Request(살아있냐?) 전송 ② 8.8.8.8는 답장: ICMP Echo Reply(나 살아있어!) 얘는 보조 프로토콜이라 L3임;;;
6	TCP	신뢰성 있는 연결 (웹, ssh 대부분)	① 연결 요청 (SYN) PC → 서버 ② 연결 수락 (SYN+ACK) 서버 → PC ③ 연결 확인 (ACK) PC → 서버
17	UDP	빠른 전송 (DNS, 게임, 스트리밍)	데이터 → 바로 보냄 → 끝 (연결 과정 없음)

위키피디아에 List of IP protocol numbers를 검색해서 모든 프로토콜을 확인할 수 있다.

Header Checksum (16bit)

IP 헤더가 전송 중 손상되었는지 검사하는 값이다.

 

여기서 발생하는 모든 값을 더해서 체크섬에 저장한다.

 

 

책으로 내용을 대체한다. (보안 이슈로 어디까지 올려도 되는지 아직 잘 모름)

TMI. 체크섬을 이런 방식으로 계산하는 이유

1. 체크섬이 적용되는 시기인 1970~80년대 하드웨어가 너무 느려서 ‘덧셈+비트반전’이 가장 빨랐음

2. 1의 보수를 쓰면 비트 하나만 바뀌어도 체크섬 계산 결과가 크게 변하고 라우터가 바로 감지함

즉, 오류 검출 능력이 좋음 + 계산이 매우 가벼움

3. 1의 보수 덧셈은 “캐리(올림수)”를 다시 더할 수 있어서 네트워크에 매우 적합함

1111 0000 0000 0000 + 0000 0000 0000 1111 = 1 0000 0000 0000 1111 (1비트 넘침)

1의 보수 규칙: 넘친 1을 다시 더해라.

→ 0000 0000 0000 1111 + 1 = 0000 0000 0001 0000


라우터는 패킷을 받을 때마다 TTL을 줄임
TTL 값이 바뀌면 헤더 체크섬도 다시 계산해야 함
1의 보수 덧셈은 빠르게 수정하기가 엄청 쉬움

 

체크섬 기능 활성화 방법

[편집] -> [설정] ->[프로토콜의 IPv4]->[체크섬]

 

Source IP Address (32bit)

보내는 사람 IP.

Destination IP Address (32bit)

받는 사람 IP.

Options + Padding

말그대로 옵션! 

거의 안 씀 → IHL 기본값이 5.

 

IHL의 옵션: 패킷의 이동 경로를 기록하거나 강제하는 기능들