네트워크 패킷 분석[Network Packet Analysis] - 3

 

<실습>

<이론>

FileZilla가 있는 것을 보면 FTP 서버에 연결한 것이데, FTP에서는 2가지 모드가 있다

Active Mode : 접속자 클라이언트가 특정 포트를 지정해서 파일을 받는 경우

Passive Mode : 서버가 임의적으로 포트를 할당해서 접속자 클라이언트에게 연결시키는 경우로 defalut이다.

=>클라이언트는 FTP서버에 21번으로 접속을 요청하고 서버는 Active, Passive mode에 따라서 클라이언트에게 포트를 할당해서 연결시켜 준다.

TTL이 128인 것을 보아 리눅스인 것을 알 수 있다.

source port가 웹인것을 보아 서버에서 클라이언트에게 접속한 것을 알 수 있다.

 

FTP만 출력된다(TCP도 나오게 되는데 이유는 모름)

 

<Meta 접속>

ID : msfadmin

PW : msfadmin

<backtrack 접속>

firefox를 실행하는데 접속주소는 meta주소이다.

DVWA 웹에 접속

ID : admin

PW : password

wireshark를 통해서 eth0를 패킷을 잡는다

Edit에서 Find Packet을 들어가면 여러가지 패킷을 조건에 맞게 검색이 가능하다.

String을 조건으로 아까 접속했던 DVWA의 패킷만 검색을 한다.

해당 패킷이 등장하는데

패킷을 잡고 Follow TCP Stream으로 보게 되면

아래와 같이 여러 정보가 나오게 된다.

스크롤을 내리다 보면 로그인 했던 기록도 볼수 있다.

패킷 분석용 파일들에서 http_goolge.pcap을 wireshark로 열게 된다면

TIme 영역을 보게 되면 시간이 엄청 딜레이 되는 것을 볼 수 있다.

Create Stat을 누른다.

해당 패킷길이가 긴것들은 다운로드 같은 특정행동을 하는 것을 알 수 있다.

보통 패킷의 평범한 길이는 아래와 같다.

<이론>

일반적인 패킷의 길이
Ethernet		14byte
IP		20byte
데이터나 옵션이 없는 TCP		20byte
표준TCP 제어 패킷		54byte

 

그래프 상에서 값이 떨어질 때 느려지는 것이다.

download-fast는 이전 것과 비교하면 단위가 10배 차이나며 평균 속도 일정한 것을 알 수 있다.

Statistics-TCP StreamGraph-Time-Sequence Graph(Stevens)를 누른다.

 

download-fast의 그래프

download-slow의 그래프

https_google.pcap을 wireshark로 열어서 Flow Graph로 본다.

<이론>

전문가 정보(Expert Infos)

와이어샤크에서 각 프로토콜에 대한 정밀 분석기는 해당 프로토콜의 패킷 내의 특정 상태를 사용자에게

expert_info를 다음과 같이 4가지를 정의한다.

Chats : 통신에서의 정상적 패킷

Notes : 일부 오류 패킷

Warnings : 많은 오류 패킷

Errors : 완전 오류 패킷

=>chats, notes, warning까지는 정상적인 통신이 가능하다.

 

▶Chat 메세지 중에서

window Update는 두 호스트 간의 TCP 수신 크기(window size)를 협상해서 변경하는 것

 

▶Note 메세지 중에서

TCP Retransmission은 수신시 패킷이 손실되었거나 전송 시간 내에 수신자로부터 ACK를 받지 못했을 때 자가 다시 데이터를 보내는 것

duplicate ACK는 어느 호스트가 예상하고 있었던 다음 패킷 순서번호를 받지 못했을 때 다시 확인을 요청하는 것

Zero Window Probe는 데이터가 없는 window size 0 패킷을 받으면 window 크기를 살펴보게 하는 것

Zero Window Probe ACK는 데이터가 없는 window size 0 패킷을 확인하고 응답하는 것

Keep Alive ACK는 호스트가 살아 있는 지 확인하는 것

 

▶Warning 메세지 중에서

Previous Segment Lost는 데이터 스트림에서 예상되는 순서번호가 없는 경우에 보이는 것, 패킷 손실이 있는 경우

ACKed Lost Packet는 ACK 패킷을 받았지만 순서에 의한 승인된 패킷이 아닐 때 발생되는 것

Keep Alive는 상대가 살아있는 연결일 때 보이는 것

Zero Window는 TCP 버퍼(수신) 창이 가득차서 새로운 데이터를 수신할 수 없다고 송신자에게 데이터 전송을 중지(source quenching)하는 요청. Window is Full과 유사하다.

Out-of-Order는 패킷이 잘못된 순서 번호를 수신한 경우 잘못된 순서 번호라고 탐지하는 것

Fast Retransmission은 Duplicate ACK가 발생했을 때 20ms 이내에 재전송된다는 의미로써 클라이언트가 GET 요청을 보내면 서버가 ACK를 보내서 요청 요구를 잘 받았다고 보내는데 이것이 늦게 오면 Duplicate ACK가 여럿 발생하고 재전송을 하는 일이 생김

 

▶Error 메세지 중에서

지연(delay)과 관련된 문제, 비정상(abnormal)으로 작동되는 API 식별 문제, 이상한(wired) 트래픽 문제 등을 발견하려면 먼저 정상적인 트래픽을 이해하고 있어야 한다. 비정상을 알려면 먼저 정상을 알아야 한다는 의미이다. 여기서 패킷 수준에서 정상적인 네트워크 트래픽이 어떻게 동작되는지 알아보자. 보통 조직에서는 2~3주 정도 패킷 모니터링을 통해서 Baseline을 설정해두고 이후에 패킷을 모아서 이상치를 판단한다.

이제 일반적으로 널리 사용되는 TCP, UDP, IP 뿐만 아니라 HTTP, DHCP, DNS와 같은 응용층 프로토콜을 살펴보자. 아주 중요한 부분이다.

 

 

ARP의 정의

주소 결정 프로토콜(Address Resolution Protocol, ARP)은 네트워크 상에서 IP 주소를 물리적 네트워크 주소로 대응(bind) 시키기 위해 사용되는 프로토콜이다. 여기서 물리적 네트워크 주소는 이더넷 또는 토큰링의 48 비트 네트워크 카드 주소를 뜻한다.

ARP는 1982년 인터넷 표준 STD 37인 "RFC 826"에 의해 정의되었다.

이를테면, IP 호스트 A가 IP 호스트 B에게 IP 패킷을 전송하려고 할 때 IP 호스트 B의 물리적 네트워크 주소를 모른다면,

ARP 프로토콜을 사용하여 목적지 IP 주소 B와 브로드캐스팅 물리적 네트워크 주소 FFFFFFFFFFFF를 가지는 ARP 패킷을 네트워크 상에 전송한다.

IP 호스트 B는 자신의 IP 주소가 목적지에 있는 ARP 패킷을 수신하면 자신의 물리적 네트워크 주소를 A에게 응답한다.

이와 같은 방식으로 수집된 IP 주소와 이에 해당하는 물리적 네트워크 주소 정보는

각 IP 호스트의 ARP 캐시라 불리는 메모리에 테이블 형태로 저장된 다음, 패킷을 전송할 때에 다시 사용된다.

ARP와는 반대로, IP 호스트가 자신의 물리 네트워크 주소는 알지만 IP 주소를 모르는 경우, 서버로부터 IP 주소를 요청하기 위해 RARP를 사용한다.

ARP프로토콜의 특징

- ARP 캐쉬 포이즈닝과 ARP 스푸핑을 당할 수 있다.

- boardcast에서 사용된다.

- 로컬영역에서 사용된다.

- IP주소를 MAC주소로 변환해준다.

Hardware Type (HTYPE)	네트워크 유형을 정의하며, Ethernet 환경의 경우 0x0001으로 세팅
Protocol Type (PTYPE)	프로토콜을 정의하며, IP 프로토콜 버전 4(IPv4)의 경우 0x0800 세팅
Hardware Length (HLEN)	MAC 주소의 길이를 정의하며, Ethernet 환경의 경우 6 byte 세팅
Protocol Length (PLEN)	프로토콜의 길이를 정의하며, IPv4의 경우 4 byte 세팅
Operation (OPER)	패킷의 유형이며, ARP 요청(ARP Request)의 경우 1, ARP 응답 (ARP Reply)의 경우 2 세팅
Sender Hardware Address (SHA)	발신자의 MAC 주소 세팅
Sender Protocol Address (SPA)	발신자 IP 주소 세팅
Target Hardware Address (THA)	목적지 MAC 주소, 그러나 ARP Request의 경우 알 수 없음
Target Protocol Address (TPA)	목적지 IP 주소 세팅

 

Analyze - Expert Info에 접속

 

ARP알아보기

ff:ff:ff:ff:ff:ff은 기본적인 broadcast이며, ARP를 뿌렸다는 것은 로컬영역임을 알 수 있다.

ff:ff:ff:ff:ff:ff가 아니라 192.168.0.ff(dirct boardcast)(multicast)로 해서 찾아야 빠르게 찾을 수 있다.

 

TTL(Time To Live)는 hop 수를 기반으로 하는 라우터에서는 RIP 라우팅 프로토콜에서 사용되는데

첫번째 라우터 0, 두번째 라우터 -1, .... 해서 -15가 될 때가지 상대방에게 도달되지 못하면 폐기된다.

=>하지만 TTL은 time based이기 때문에 시간이 더 지체되면 TTL 숫자가 -1이 아니라 -2처럼 더 많이 빠지기도 한다.

시스템간 통신에서는 Linux에서는 256, Windows에서는 128이지만 이는 별로 의미가 없다.

==>네트워크에서는 TTL과 관련이 있는 것으로 Metric이 있다.

 

같은 영역에 있는데 주소가 다르다면 서브네팅과 Vlan이며, TTL이 줄어든다면 서브네팅이다.

hi를 보내는데 앞에 의미없는 문자가 채워지는 것은 크기를 채우려고 하는 것이며 데이터로써 의미는 없다.

이것을 패딩이라고 한다.

 

<이론>

이더넷의 한 번 최대 MTU가 1500인데 signal이 40정도여서 실제 데이터는 1460이 최대 전송량이다.

데이터를 fragmented하는 이유는 인터넷상에서 다양한 장비에서의 일관성 유지를 위함이다.

Linux에서는 ifconfig eth0 mtu 1200 up으로 해주면 이 리눅스는 1200을 MTU로 사용한다.

ATM통신에서도 fragment가 발생한다.

Asynchronous Transfer Mode의 약어. 패킷 교환망(packet switch network)의 표준 프로토콜을 가리키는 용어. 송수신 데이터에 동일한 53바이트 길이의 셀(cell)을 사용하며, 이 셀들은 디지털 ATM 망을 통해 매우 빠른 속도로 처리가 되어 600Mbps가 넘는 속도로 전송이 가능하다.

ATM은 비동기식 시분할 다중화를 사용하는 특수한 형태의 패킷형 전달 방식으로서, 이 고정된 패킷들을 ATM 셀이라고 한다. ATM 방식은 송신측의 단말에서 수신측의 단말로 보내는 정보를 48바이트씩 분할하여 수신처 레이블 정보에 5바이트의 헤더를 붙여 53바이트의 일정 셀(cell) 단위로 정보를 보낸다. ATM은 음성, 그래픽, 데이터, 비디오 영상 등의 다양한 서비스들을 지원할 수 있도록 설계되었다.

 

DNS에서 TCP와 UDP를 쓰는 기준이 다르다.

 

class : IN(internet)

Type : A(간단하게 도메인(domain) name에 IP Address를 매핑하는 방법)

이 패킷은 로컬 도메인이 캐쉬에 매핑되어 있어서 바로 응답을 해주었지만, 없을경우 다른 서버에다가 물어봐서 응답할 수 있다는 부분이 적혀있다.

 

ICMP 패킷의 구조는 Type과 정의된 목적에 따라 Code 필드의 값이 다른데 예를 들어 Type 3은 '목적지 도달 불가'를 의미한다. 이 정보만으로는 문제가 있을 때 해결하기 힘들 수도 있지만 3이라는 숫자를 보게 되면 여하튼 통신 포트에 문제가 있다고 느낄 수 있다.

타입과 오류 메시지들은

∎ ICMP 오류 메세지(Error Reporting Message)

패킷이 루프를 돌거나, 과밀 발생, 타이머 값이 너무 낮게 설정된 경우

① 목적지 도달 불가(Destination Unreachable) : Type 3

. Network Unreachable : Code 0

. Host Unreachable : Code 1

. Protocol Unreachable : Code 2

. Port Unreachable : Code 3

② 발신 억제(Source Quench) : Type 4(표준에서 제외됨)

③ 재지정(Redirect) : Type 5

④ 시간 초과(Time Exceeded) : Type 11

⑤ 매개변수 문제(Parameter Problem) : Type 12

∎ ICMP 정보 메시지(Informational Message) / 질의 메시지(Query Message)

호스트 간에 연결성 검사 확인(Ping 명령어 등)

⑥ 에코 응답(Echo Reply) : Type 0 =>hello packet(‘Hi’)

⑦ 에코 요청(Echo Request) : Type 8 =>hello packet(‘Hi’)

⑧ 라우터 알림(Router Advertisement) : Type 9

⑨ 라우터 요청(Router Solicitation) : Type 10 등으로 분류된다.

 

참고로 실제 데이터 전송이 아닌 타겟이 alive 상태인지 확인을 위한 시그널 hello packet을 heart beat라고 하고,

프로토콜이 숫자로 표시될 수 있는데

ICMP(1), IP(4), TCP(6), UDP(17), IPv6(41) 등이다.