[네트워크 해킹] OSI 7 계층과 패킷 분석 개요

네트워크 개요

정보보안 관점에서 네트워크가 중요한 이유

• 네트워크와 관련된 다양한 해킹 공격 시나리오가 존재
• MTIM, ARP 스푸핑, 디도스 등등

네트워크란?

• 단순히 시스템 컴퓨터에 한정되지 않고 객체, 사람 등이 서로 연결되어 정보나 자원을 교환하거나 상호작용 하는 구조나 시스템을 의미
• 컴퓨터 네트워크는 컴퓨터 기기들이 서로 연결되어 정보를 공유할 수 있도록 구성된 시스템

네트워크의 종류

• LAN : 논리적, 물리적 영역 안에서 연결된 네트워크
• WAN : 넓은 지리적 영역에 걸쳐있는 컴퓨터 및 자원을 연결

도시, 국가, 대륙 간 ISP(end system에게 다양한 네트워크 접속을 제공)에 의해 관리된다.

하위 계층 ISP는 국가, 국제 상위 계층 ISP를 통해 연결된다.

 

인터넷

전 세계적으로 컴퓨터 장치(end system)를 연결하는 컴퓨터 네트워크 (네트워크의 네트워크)

 

패킷 

• end system에서 수신하여 end system으로 보내지는 데이터
• 보내고자하는 데이터를 segment 단위로 나누고, 각 segment에 헤더를 연결하여 전송
• 캡슐화된 시스템에 의거하여 목적지에서 다시 조립

경로(=path or route)

패킷이 수신되어 end system에 도달하는 동안 거쳐온 모든(일련의) 통신 링크

---

OSI 7 계층

<OSI 서비스 모델>

 프로토콜 스택을 거치면서 기존 정보에 헤더를 붙여서 캡슐화 한다. 여기서 프로토콜은 장치 간에 통신할 때 지켜야 하는 규약이며 메시지의 형식, 순서, 메시지 전송, 수신시 수행하는 작업을 정의한다. 라우터는 3계층 패킷 교환기(네트워크 계층 주소 사용),  스위치(패킷 스위치이지만 mac 주소 사용)는 2계층 패킷 교환기이다.

 

계층적 구조를 사용하는 이유

• 계층 구조는 크고 복잡한 시스템의 정의된 특정 부분을 논의할 수 있게 해준다. -> 단순화
• 어떤 계층의 하나의 형태가 변하더라도 나머지 계층에 크게 영향을 주지 않는다.

 

물리 계층

• 단위: 비트
• 프레임 내부의 각 비트를 한 노드에서 다음 노드로 이동 (실제 전송 매체에 의존한다.)

 

데이터링크 계층

• 단위: 프레임
• 전체 프레임을 한 네트워크 요소에서 이웃 네트워크 요소로 이동
• 서비스가 해당 링크 계층에서 사용하는 프로트콜에 의해 결정된다.
• 다음 상위 계층인 네트워크 계층은 "데이터그램"을 링크 계층으로 보낸다 즉, "링크 계층 서비스에 의존"한다. 라고 표현할 수 있다.

 

네트워크 계층

• 단위: 데이터그램(=패킷)
• 한 호스트에서 다른 호스트로 데이터의 최적의 경로를 선택하고 데이터그램을 전송한다. 즉 라우팅의 역할을 수행
• 네트워크 계층을 가진 모든 인터넷 요소는 ip 프로토콜을 수행한다.
• 상위 계층 전송 계층에서 세그먼트를 운반한다.

 

전송 계층

• 단위: 세그먼트
• 클라이언트와 서버 간에 애플리케이션 계층 메시지를 전송하는 서비스 제공
• TCP
  • 연결 지향형 서비스를 제공
  • 흐름 제어를 포함(송신자와 수신자와의 속도 일치)
  • 혼잡 제어 기능 제공(출발지의 전송률을 줄임)
• UDP
  • 비연결형 서비스 제공
  • 신뢰성, 흐름 제어, 혼잡 제어등을 제공하지 않는다.
  • 따라서 영화같은 데이터 량이 방대한 서비스에서 깨짐 현상이 일어난다.

세션 계층

• 기기 간 통신을 담당하고 제어한다(생성, 유지, 종료).
• 리소스 낭비를 방지하기 위하여 세션 개방과 종료의 시간을 결정한다(인증과 재연결 포함).

 

표현 계층(구문 계층이라 표현하기도 한다.)

• 구문과 의미론에 따라 데이터를 변형하기도 한다.
• 즉, 응용 계층에서 요구하는 대부분의 암호화와 복호화를 수행한다.

 

응용 계층

• 단위: 메시지
• 네트워크 애플리케이션과 애플리케이션 계층 프로토콜
• end system에 있는 애리케이션 간에 메시지를 교환하는데 사용
• 소프트웨어와 직접 상호작용을 수행

 

TCP/IP 와 OSI

두 모델에서 2개의 계층인 세션 계층과 표현 계층이 TCP/IP 프로토콜 그룹에는 없다. 그 이유는 크게 2가지로 유추해 볼 수 있다.

1. TCP/IP는 하나 이상의 전송층 프로토콜을 가지고 있다.
   • 세션층의 일부 기능은 몇몇 전송층 프로토콜에서 가능
2. 응용 계층이 단순히 소프트웨어의 한 부분만은 아니다.
   • 만약 세션 그리고 표현 계층에서 사용하는 기능 중 몇 개가 특정 응용 계층에서 필요로 한다면, 소프트웨어의 한 부분으로 개발할 수 있다.

 

OSI 모델이 TCP/IP 모델을 모두 대체하지 못한 이유

OSI 모델은 TCP/IP 모델 이후에 나타났으나 TCP/IP 모델을 완벽히 대체하지는 못하였다.

1. OSI 모델은 TCP/IP 모델이 나오고 많은 시간이 흐른 뒤에 등장하였다.
   • TCP/IP 모델이 이미 완전히 자리잡고, 많은 돈과 시간이 TCP/IP 그룹에 투자되고 난 이후에 완성되었다.
2. OSI 모델의 일부 계층은 완전히 정의되지 않았다.
   • 표현 계층과 세션 계층에 의해 제공된 서비스들이 문서에는 기술되어 있으나 두 계층에 대한 실제 프로토콜은 완전히 정의되거나 기술되지 않았다. 당연히 이에 따라 대응하는 소프트웨어가 완전히 개발되지 않았다.
3. OSI가 완전히 구현되었을 때 TCP/IP 프로토콜에서 OSI 모델로 완전히 전환하기 위한 충분히 높은 수준의 성능을 보여주지 못하였다. 

---

네트워크 패킷 분석 

WireShark를 사용하여 실제 패킷을 간략하게 분석해본다. 와이어샤크는 호스트 장치에서 발생하는 네트워크 패킷을 캡쳐하고 분석할 수 있는 도구이다. 디지털 포렌식적 관점에서 트래픽이 오갈 때 공격자 행위를 유추 및 분석(명확한 타임라인 확보 등)하는 것에 가치가 있는 도구이다. 이번에는 와이어샤크로 간단한 분석을 진행해 본다. 

 

와이어샤크 도구를 처음 실행해보면 많은 패킷이 오가는 것을 식별할 수 있으며 만약 엣지 브라우저를 사용하고 있으면 크롬 기반이기에 QUIC 프로토콜이 많은 것을 확인할 수 있다.

 

패킷을 분석해보기 React를 사용하여 간단한 페이지를 제작하여 로컬호스트로 접속하는 과정을 와이어샤크로 캡쳐해 본다.

<로컬호스트 열기(npm start)>

react로 간단한 페이지를 제작한 후에 npm start 명령어를 입력하여 로컬호스트로 접속가능한 웹 페이지를 간단하고 빠르게 실행할 수 있다. (3000포트 사용 설정)

 

<구현한 웹페이지>

웹페이지에 접속하기전 와이어샤크 캡처를 시작한 후에 http 패킷 분석을 진행한다.

 

<http 필터 적용>

http 필터를 적용하고 보면 여러 해당 패킷들을 확인할 수 있다. 로컬 호스트로 된 페이지에 접속하였으므로 Source와 Destination의 IP가 동일하다. 빨간색 박스의 HTTP 처음 통신 과정 응답에서 보통 HTTP/1.1 200 OK로 시작하지만 304 Not Modified인 이유는 브라우저 캐시 때문이다. 이는 react를 로컬호스트로 실행하면 생기는 정상적인 동작이며 이전에 브라우저에서 한번 받아본 적이 있으면 파일 변경 여부에 대한 조건부 요청을 보내고 파일이 변경되지 않았으면 304 Not Modified로 응답하며 브라우저는 캐시에 저장된 파일을 그대로 사용한다. 리소스를 수정한 뒤에 새로 저장하여 빌드하면 파일의 해시와 타임스탬프가 변경되기에 브라우저가 새 파일을 인식하고 200 OK를 보내게 된다.

 

<개요>

위의 개요에서 Frame은 데이터링크에서 사용하는 단위이며 데이터 링크 계층에서 네트워크 요소로 전달하기 위한 모든 데이터를 담고있기에 Frame을 오버레이(클릭)하면 모든 데이터가 select된다. 

<IPV4 상세>

상단에 0100 4개의 비트를 사용하여 Version을 나타낸다. Protocol에서 TCP를 사용함(세그먼트가 어떤 프로토콜을 사용하는 지)을 나타내고 있으며 Time to Live(TTL)에서는 네트워크에서 데이터가 헛돌게 하지 않기 위하여 라우팅 되는 과정에서 제한을 걸어둔다. Header Checksum에서는 데이터그램의 비트 손실 여부를 판단한다.

 

<TCP 상세>

상단에 Source Port(59185)와 Destination Port(3000)을 확인할 수 있다. Sequence Number와 Acknowledgment Number를 통하여 TCP로 요청과 응답을 받으며 신뢰적인 연결임을 알 수 있다.

 

<http request 확인>

상기의 http request를 확인해보면 http 버전(1.1) method인 GET 방식을 확인(URL로 접속하였기 때문)할 수 있으며 Host 즉 서버에 대한 정보(주소)도 확인할 수 있다. 밑으로 많은 Header들을 볼 수 있는데 여기서 User-Agent는 본인이 현재 접속한 장치의 환경을 나타낸다. 브라우저 서버는 여기서 모바일 및 컴퓨터 장치를 식별하여 웹페이지를 다르게 나타낸다.

 

<http response 확인>

요청에 대한 응답 패킷을 확인해보면 Date로 날짜도 확인할 수 있다. 이후 빨간색 동그라미의 \r\n 개행 아래에는 응답에 대한 본문(데이터)이 담겨 있다.

 

추가 기능

<follow -> TCP Stream 클릭>

<요청과 응답 확인>

와이어샤크에서 패킷을 우클릭하고 follow -> tcp stream을 클릭하면 오고간 데이터들을 직관적으로 확인할 수 있다.

 

<Statistics -> Flow Graph 클릭>

<Graph 확인>

추가적으로 Statistics -> Flow Graph를 클릭하면 TCP의 3-way handshake 과정을 포함하여 직관적으로 확인할 수 있다. 앞서 TCP 상세에서의 SYN과 ACK가 오고가는 과정을 한눈에 알기 쉽다. 좌측 하단의 Limit to display filter를 클릭하면 와이어샤크에서 적용한 필터를 Flow Graph에서도 적용할 수 있으며 "ip.addr == (주소)"필터를 사용하여 더욱 편하게 확인할 수 있다. 위의 TCP 연결에서는 로컬호스트를 사용하였기에 소스 주소와 목적지 주소가 동일하여 예외적으로 일반적인 경우보다 직관성이 떨어진다.

---

Reference

Behrouz A. Forouzan, Data Communications and Networking 5th ed, McGraw-Hill Education, 2012.