리눅스 네트워크 패킷 모니터링

tcpdump -i eth0 : eth0를 통해 인입되는 패킷 모니터링

tcpdump -i eth0 -w packet_log.txt : eth0를 통해 인입되는 패킷 모니터링 결과를 packet_log.txt에 저장

tcpdump -i eth0 -c 50 : 지정한 수 만큼만 저장

tcpdump -i eth0 -w packet_log.txt -1 1500 tcp port 23 and host 218.38.71.24

: eth0을 통해 들어오는 패킷 중 지정된 포트와 IP로 들어오는 패킷에 대해서만 모니터링하여 packet_log에 저장

tcpdump -r packet_log.txt : 저장된 파일을 확인

시스템 관리자로서 약간의 설정이 필요한 작은 명령어 라인 유틸리티를 문제해결에 사용할 수 있다. tcpdump도 이러한 유틸리티이며 네트워크 문제해결에 유용하다. tcpdump는 네트워크 인터페이스를 통과하는 프레임의 내용을 캡처(sniff)할 수 있는 명령어 라인 유틸리티이며 프레임의 내용은 변경하지 않는다.

프레임은 네트워크에서, 소스에서 목적지로 데이터를 이동시키는데 사용하는 프로토콜 데이터 유닛(PDU)이다. 프레임의 개념을 설명할 때 탑차(boxcar)를 예로들 수 있다. 물건을 원거리에 보낼 때, 안전하고 빠르게 보낼 수 있도록 적절히 포장하여 탑차에 싣는다. 이와 같이 프레임도 두 포인트 사이의 데이터를 전송하기 위해 정의된 데이터 유닛이다.

많은 문서에서 데이터 유닛을 패킷이라고 부르지만, OSI 모델의 3 계층에 PDU로 라벨을 붙였다. 데이터링크(datalink) 계층의 PDU는 프레임(frame)이고 네트워크 계층의 PDU는 패킷(packet) 마지막으로 전송 계층은 세그먼트(segment)다.

프레임 내의 페이로드(payload)는 PDU로 캡슐화된다. TCP/IP 프로토콜을 선택했다면 예를 들 수 있는 페이로드 프로토콜은 IP, TCP 그리고 DNS다. 패킷 스니퍼는 단순히 캡처된 프레임의 데이터를 보여준다. 관리자는 PDU와 PDU 구조를 이해하여 캡처된 데이터의 내용을 이해할 수 있다.

그럼 이제 두 시스템 사이의 네트워크 연결 문제를 해결하는 데 tcpdump를 어떻게 사용할 수 있는지 확인해보자.

이 글에서는 여러분의 이해를 돕기 위해 위의 간단한 샘플 네트워크를 예제로 사용하고 있다. 이 네트워크에는 3대의 컴퓨터가 허브를 통해 연결되어있다. 호스트 192.168.2.10(윈도우 2000)은 192.168.2.165(레드햇 6.2)에 텔넷으로 접속되어 있고 호스트 192.168.2.100(레드햇 7.2)에서 tcpdump 유틸리티를 실행한다. 대부분의 리눅스와 유닉스 운영체제에서는 기본적으로 tcpdump가 설치되어 있지만 윈도우 시스템용은 따로 다운로드[클릭]한다.

호스트 192.168.2.100에서 tcpdump를 실행하려면 명령어 라인에서 ‘tcpdump’라고 실행한다. 명령이 실행되면 ‘CTRL + C’를 누를 때까지 계속해서 관련된 데이터를 출력한다.

# tcpdump

tcpdump: listening on eth0

05:22:27.216338 burner.ssh > prime.1035:

P3797249897:3797249949(52) ack 2183278948 win 8576 (DF) [tos 0x10]

설명을 위해, 하나의 호스트에서 네트워크 트래픽을 생성하기 위해 ssh 세션을 만들었다. tcpdump를 실행하면 모든 내용을 덤프하지만 다양한 옵션을 사용하여 원하는 특정 정보만 볼 수 있다. 옵션에 대한 자세한 설명은 tcpdump 매뉴얼 페이지를 참고하고, SANS 보안 사이트에서 유용한 포켓 레퍼런스를 찾을 수 있다. SANS 문서에서는 사용법을 정리한 표와 특정 프로토콜을 위한 PDU 레이아웃도 제공한다. tcpdump 결과를 분석할 때 SANS 포켓 레퍼런스를 사용하도록 권장한다.

예제 1

다음 명령은 tcpdump를 실행하여 192.168.2.165 IP 주소를 가지고 있는 프레임들만 보여준다.

# tcpdump host 192.168.2.165

tcpdump: listening on eth0

19:16:04.817889 arp who-has tssoss tell prime

19:16:04.818025 arp reply tssoss is-at 0:a0:c9:20:5b:fe

19:16:04.818182 prime.1219 > tssoss.telnet:

S2506660519:2506660519(0) win 16384 (DF)

예제 2

다음 명령은 특정 IP 주소와 지정된 포트를 가지고 있는 프레임만 출력한다. 옵션 ‘-nn’은 이름(호스트 이름)과 포트(서비스 이름)를 변환하지 않고 결과값은 raw 데이터로 출력한다.

# tcpdump -nn host 192.168.2.165 and port 23

tcpdump: listening on eth0

19:20:00.804501 192.168.2.10.1221 > 192.168.2.165.23:

S2565655403:2565655403(0) win 16384 (DF)

예제 3

예제 2의 명령에 ‘-t’ 옵션을 주고 다시 실행하면 시간에 관한 내용이 출력되지 않는다. 아래 ‘-e’ 옵션은 레이어 2나 데이터링크(datalink) 정보를 요청한다. 데이터링크 정보로 목적지와 소스 MAC 주소가 표시된다.

# tcpdump -nne host 192.168.2.165 and port 23

tcpdump: listening on eth0

19:30:13.024247 0:5:5d:f4:9e:1f 0:a0:c9:20:5b:fe 0800 62: 192.168.2.10.1223 > 192.168.2.165.23:

S2718633695:2718633695(0) win 16384 (DF)

몇 개의 예제를 통해 tcpdump의 기본적인 사용법을 설명하였다. 이렇게 출력된 정보가 무엇을 의미하는지 다음 표를 통해 이해해보자.

필드 내용

설명

19:20:00.804501

시간 정보

192.168.2.10.1221

소스 IP 주소와 포트번호

192.168.2.165.23

목적지 IP 주소와 포트번호

S

플래그(Flag)

2565655403

데이터 시퀀스 번호(data sequence numbers)

win 16384

윈도우 사이즈(window size)

위의 표에서 설명하는 내용보다 더 많은 결과가 출력되므로 자세한 사항은 tcpdump 매뉴얼 페이지를 참고한다.

완벽한 데이터 분석을 위해서는 프로토콜의 운영과 구조에 대한 정확한 이해가 필요하다. TCP/IP에서 발견할 수 있는 PDU의 내용에 대한 설명은 SANS 포켓 가이드를 참고한다.

이번에는 시나리오를 사용하여 tcpdump 결과를 분석할 것이다..

Scenario 1: 텔넷 연결

tcpdump를 사용하여 TCP/IP 연결이 확립(establish)되고 종료된 PDU를 분석할 수 있다. TCP는 연결을 열고 종료하는데 특별한 매카니즘을 사용한다. 다음 tcpdump 결과는 호스트 192.168.2.10과 192.168.2.165 사이의 연결을 보여준다.

#tcpdump -nn host 192.168.2.165 and port 23

결과를 분석하기 전에 TCP/IP 연결 관리에 대해 간단히 살펴보자. 이 내용은 프로토콜에 생소한 새로운 유저의 이해를 돕는다. 신뢰할 수 있는 연결을 보장하기 위해 TCP는 3개의 메시지가 교환되는 방식을 사용한다. 이 절차는 3-way-handshake라고 하고 연결을 시작하기 위해:

l 세션 연결을 요청하는 호스트는 연결을 시작하기 위해 TCP 세그먼트에 synchronization flag(SYN)을 보낸다.

l 연결을 받는 호스트 192.168.2.165는 SYN flag를 받고 acknowledgment flag(ACK)를 되돌려 보낸다.

l 세션 연결을 요청하는 호스트 192.168.2.10은 SYN flag를 받고 다시 ACK flag 보낸다.

연결을 종료할 때도 finish flag(FIN)을 사용하는 비슷한 handshake 프로세스가 사용된다.

연결을 확립하려면 연결할 대상 호스트의 IP 주소와 포트 번호를 가지고 있는 세그먼트(segment)를 생성한다. 이 세그먼트에는 SYN flag와 패킷을 보내는 호스트의 초기 시퀀스 번호가 포함되어있다. 데이터는 송신되기 전에 세그먼트화되고, 시퀀스 번호는 세그먼트를 정확한 순서로 조립하는데 사용된다.

20:06:32.845356 192.168.2.10.1249 > 192.168.2.165.23:

S 3263977215:3263977215(0) win 16384 (DF)

연결 요청을 받는 호스트는 자신의 SYN flag와 최초 시퀀스 번호로 응답한다. 이 세그먼트도 보낸 호스트의 SYN(segment 3263977215+1)에 맞는 ACK flag를 가지고 있다. 연결 요청을 받은 쪽은, 받아야 되는 다음 세그먼트의 시퀀스 번호를 승인해야 되므로 이러한 종류의 응답(acknowledgment)을 예외적인 응답이라고 한다.

20:06:32.845725 192.168.2.165.23 > 192.168.2.10.1249: S

48495364:48495364(0) ack 3263977216 win 32120 (DF)

20:06:32.845921 192.168.2.10.1249 > 192.168.2.165.23: . ack 1 win 17520 (DF)

마지막으로 S와 ‘.’ flag가 보이고 전체 출력에 다음과 같은 여섯 개의 문자가 나타난다.

l S: SYN (Synchronize sequence numbers – 연결 요청)

l F: FIN (보낸 쪽에서 연결을 종료 – 정상적인 연결 종료)

l R: RST (비정상적으로 즉시 연결 종료)

l P: PSH (데이터를 즉시 어플리케이션으로 전달)

l Urg: (긴급한 데이터에 우선순위를 높게 줌)

l ‘.’: (SYN, FIN, RESET, PUSH가 아닌 경우로 flag가 설정되지 않았다)

Scenario 2: 텔넷 연결 종료

연결을 끊기 위해 호스트 192.168.2.165에서 세션이 연결된 호스트로 FIN flag가 포함된 세그먼트를 보낸다.

20:07:32.916410 192.168.2.165.23 > 192.168.2.10.1249: F 147:147(0) ack 56 win 32120 (DF)

연결을 요청한쪽에서 연결 종료를 요청하였기 때문에 호스트 192.168.2.10은 FIN 세그먼트에 대해 응답한다.

20:07:32.916680 192.168.2.10.1249 > 192.168.2.165.23: . ack 148 win 17374 (DF)

그리고 호스트 192.168.2.10도 FIN flag가 포함된 세그먼트를 보내어 연결을 종료한다.

20:07:32.928907 192.168.2.10.1249 > 192.168.2.165.23: F 56:56(0) ack 148

win 17374 (DF)

마지막으로 호스트 192.168.2.165는 세그먼트에 응답한다.

20:07:32.929121 192.168.2.165.23 > 192.168.2.10.1249: . ack 57 win 32120 (DF)

Scenario 3: 텔넷 연결 거부(호스트에서 서비스가 동작하지 않음)

호스트 192.168.2.10는 연결하려는 호스트의 IP 주소와 포트 번호가 있는 세그먼트를 보낸다. 이 세그먼트는 SYN flag와 최초의 시퀀스 번호를 가지고 있다.

댓글 남기기

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Videos, Slideshows and Podcasts by Cincopa Wordpress Plugin