와이어샤크
[2019-1]
#02
일단은 저번에 했던 실습내용을 더 자세히 했다.
이미지로 정리하면 이렇게 되는데,
라우터의 Destination의 정보에서 33:33:00:....은 멀티 캐스팅을 나타낸다. 그리고 라우터 패킷은 MAC 주소를 포함하며, ARP(데이터 링크 계층) 프로토콜의 역할도 한다.
그리고 DB-LSP-DISC는 Dropbox LAN Sync Discovery이며, 클라이언트가 드롭박스를 사용했다는 뜻이다. 255:255:255:255는 로컬 내의 모든 기기에 패킷을 보낼 때 나타난다. Dropbox는 주로 UDP 프로토콜으로 전송해 드롭박스 클라이언트와 서버를 동기화 한다고 한다.
그리고 클라이언트가 서버를 요청할 시에 IP(최종 목적지)는 서버의 IP여도, MAC(물리 목적지)은 라우터를 가리키는데, 이후 라우팅 테이블에서 MAC 주소를 삭제해 자기 MAC을 덮어쓰기 때문이다.
그리고 3-way-handshake을 나타내는 그림은 이와 같다.
이번 주에는 http-google101.pcapng 파일을 분석해보았다.
이 패킷은 www.google.com을 방문할 때 생성되는 트래픽이며, DNS 서버의 주소가 75.75.75.75이며, A레코드는 IPv4를 질의를 나타낸다. AAAA레코드는 IPv6를 질의하므로, 클라이언트가 IPv4와 IPv6를 모두 지원하는 경우에 IPv6주소로도 변환하기 위해서 DNS 요청을 한번 더 보낸 기록이다.
HTTP 패킷을 분석해보면, HTTP 헤더 정보도 볼 수 있다.
백그라운드 트래픽은 Burp Suite에서 실제 방문하지 않아도 표시되는 사이트(회색으로 표시되는 사이트)를 말한다. 이는 자동화된 프로세스들이 구동될 때 생성되며 사용자 상호작용 없이도 트래픽이 생성되므로 백그라운드 트래픽이라고 한다.
이런 백그라운드 트래픽은 악성코드 삽입에 좋아서 정상적인 백그라운드 트래픽인지 아닌지를 구분해야 한다. 정상적인 백그라운드 트래픽이 생성되는 경우는 자바의 업데이트 스캔(Java, JDK..), 바이러스 탐지 도구의 스캔, 드롭박스 체크인, IPv6의 라우터를 검색, 네트워트 프린터 등의 장비를 검색(SNMP)할 때이므로 이런 트래픽은 정상으로 간주하면 된다.
의심 가는 트래픽은 두 기기가 연결(서버와 클라이언트)될 때 secure관련 포트(22번 -ssh)을 통해 패킷이 이동하는 경우이다. 일반적으로는 HTTP의 80번 포트를 쓰거나 HTTPS의 433번 포트를 사용하기 때문이다. 또한 이더넷 헤더 혹은 TCP 헤더 등 여러 헤더의 필드 값들 중 비정상적인 값이 포함되는 경우(와이어 샤크에서 표시 해줌) 비정상 백그라운드 트래픽으로 의심할 수 있다.
와이어샤크에서 Mybackground101.pcapng 파일에서 비정상 백그라운드 트래픽을 찾을 수 있다. 411패킷에서 Acknowledgment number은 원래 0,1,2의 flag역할을 하는데, 너무 큰 숫자가 들어있고, 와이어샤크에서 표시해준 것을 알 수 있다.
이렇게 백그라운드 트래픽을 수집하려면 와이어샤크를 제외한 모든 어플리케이션(프로그램)을 종료하고, 메인 툴바 위의 capture>option을 클릭(혹은 ctrl+k)을 하면, Sparkline에서 활성 중인 트래픽을 나타내는 인터페이스가 나온다.
지금 나는 이걸 쓰면서 capture interfaces를 켜서 뜨지 않았지만, 인터페이스를 선택하고 Start를 클릭한 후, 일정 시간이 지난 후 Stop Capture을 하고, 메인 툴바의 Save 버튼을 클릭하면 된다.
와이어 샤크에서 패킷 목록 화면에 임의의 Column(열)을 추가하려면, 패킷 상세 창에 있는 내용이라면 패킷 상세 창에서 필드를 선택해 오른쪽 버튼을 누르면 나오는 Apply as column을 누르면 된다. 만약 source를 column으로 넣고 싶다면, 이렇게 하면 되는 것이다.
만약 필드에 없는 내용을 추가하고 싶다면, Edit의 Preferences의 Columns에서 +버튼을 클릭하면 된다.
마지막으로 TTL이란 네트워크 상에서 패킷의 유효기간을 일컫는다. 정해진 유효기간이 지나면 라우터에서 데이터가 폐기되므로, 패킷이 네트워크 상에서 무한히 순환하는 것을 방지한다. IPv4에서 1TTL=1초를 말하며, 최대 크기는 255이다. (TTL을 나타내는 bit가 8bit이므로) 1개의 hop을 거칠 때마다 TTL값이 1씩 감소하며, TTL 값이 0이면, 라우터가 해당 패킷을 폐기하는 방식으로 이루어진다. OS 별로 기본 TTL값이 정해져 있는데, Window는 128, Unix는 64, others는 255라고 한다.
추적 파일 분석 실습으로는 Challenge101-0.pcapng 파일을 사용했다.
1. 이 추적 파일에는 몇 개의 패킷이 있는가?
맨 밑에 Packets20으로 되어있는 것으로 보아 20개이다.
2. 프레임 1,2,3에서 TCP 연결을 구성하는 IP주소는?
위의 사진에서 볼 수 있듯이, SYN을 요청하는 클라이언트의 IP 주소 192.168.1.108이며, 서버의 주소는 50.19.229.205이다.
3. 프레임 4로 보낸 HTTP 명령어는?
마찬가지로 위의 사진의 프레임 4의 Info를 보면, GET /Tr~....인것으로 보아서 GET이다.
4. 이 추적 파일 안에서 가장 긴 프레임 길이는?
Length를 두 번 누르면, 1428이 가장 긴 길이임을 알 수 있다.
5. 어떤 프로토콜이 Protocol 열에 보이는가?
Protocol을 누르면 자동으로 정렬해 주는데, 찾아봐도 HTTP와 TCP밖에 없다.
6. HTTP가 서버에 보낸 응답은 무엇인가?
302 found이다.
7. 이 추적 파일 안에 IPv6 트래픽이 있는가?
아무리 봐도 IPv6 형태(~:~:~:~:~:~:~:~)의 아이피가 보이지 않는다.
~끝~
참조 :