어드민플레이 - Linux Security Q&A

기본 tcpdump사용법

시스템 관리자로서 약간의 설정이 필요한 작은 명령어 라인 유틸리티를 문제해결에 사용할 수 있다. 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 <mss 1460,nop,nop,sackOK> (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 <mss 1460,nop,nop,sackOK> (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와 최초의 시퀀스 번호를 가지고 있다.

05:28:00.080798 192.168.2.10.1063 > 192.168.2.165.23:

S 3034008467:3034008467(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)

호스트 192.168.2.165는 R (연결 리셋)과 ACK flag를 가지고 있는 세그먼트를 보내서 호스트 192.168.2.10의 SYN에 응답한다.

05:28:00.080979 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0) ack 3034008468 win 0

호스트는 응답을 하지 않으므로 다시 연결을 시도한다.

05:28:00.579420 192.168.2.10.1063 > 192.168.2.165.23: S

3034008467:3034008467(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)

그러나 연결을 받는 호스트로부터 동일한 응답을 받는다.

05:28:00.579524 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0) ack 1 win 0

마지막 시도도 연결되지 않는다

05:28:01.080114 192.168.2.10.1063 &glt; 192.168.2.165.23: S

3034008467:3034008467(0) win 16384 <mss 1460,nop,nop,sackOK> (DF).

3번의 시도만 허용되기 때문에 연결을 요청한 호스트는 포기한다.

05:28:01.080225 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0) ack 1 win 0

Scenario 3: 텔넷 연결 거부 (호스트에 tcp wrappers 보안 사용)

연결을 확립하기 위해 앞에서와 같이 연결 시도를 한다.

05:40:39.838710 192.168.2.10.1064 > 192.168.2.165.23: S

3223709294:3223709294(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)

받는 호스트는 SYN flag와 최초의 시퀀스 번호로 응답한다. 이 세그먼트도 보낸 호스트 SYN(segment 3223709294 +1)에 응답하는 ACK flag를 가지고 있다.

05:40:39.839045 192.168.2.165.23 > 192.168.2.10.1064: S 063202536:2063202536(0) ack 3223709295 win 32120 <mss 1460,nop,nop,sackOK> (DF)

호스트 192.168.2.10은 ‘.’과 ACK flag를 가지고 있는 다른 세그먼트를 보내서 호스트 192.168.2.165의 SYN에 응답한다.

05:40:39.839295 192.168.2.10.1064 > 192.168.2.165.23: . ack 1 win 17520 (DF)

호스트 192.168.2.165는 연결을 종료하는 FIN flag를 가지고 있는 세그먼트로 응답하여 받는 호스트에게 연결이 허용되지 않는다고 말한다.

05:40:44.852844 192.168.2.165.23 > 192.168.2.10.1064: F 1:1(0) ack 1 win 32120 (DF)

호스트 192.168.2.10은 두 번째 응답에 flag set이 없다.

05:40:44.853137 192.168.2.10.1064 > 192.168.2.165.23: . ack 2 win 17520 (DF)

FIN flag 세그먼트를 받았기 때문에 이 연결은 종료되고, 호스트 192.168.2.10은 연결을 끊기 위해 FIN flag를 보낸다.

05:40:44.855050 192.168.2.10.1064 > 192.168.2.165.23: F 1:1(0) ack 2 win 17520 (DF)

호스트 192.168.2.165는 ack 세그먼트로 응답한다.

05:40:44.855176 192.168.2.165.23 > 192.168.2.10.1064: . ack 2 win 32120 (DF)

연결이 된 텔넷 연결 시나리오와 텔넷 연결이 거부(tcp wrappers)되는 시나리오의 결과를 비교해보면 받는 호스트의 응답이 다르다. 텔넷이 거부되는 시나리오에서, 받는 호스트의 tcp wrappers는 /etc/hosts.deny 파일에 ‘ALL:192.168.2.10’이 추가되어 활성화되어 있다. 이 의미는 192.168.2.10의 IP 주소를 가진 호스트로부터의 모든 연결을 거부한다는 것이다. Iptable 방화벽 룰을 사용하여 비슷한 연결 테스트를 했지만 결과는 동일하다.

Scenario 4: 텔넷 연결이 없다(네트워크에서 호스트가 제거됐다)

텔넷 연결을 하기 위해 동일한 연결시도가 발생한다.

05:55:21.557846 192.168.2.10.1065 > 192.168.2.165.23: S

3443876657:3443876657(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)

응답이 없기 때문에 보내는 호스트는 같은 요청을 다시 시도한다.

05:55:24.560891 192.168.2.10.1065 > 192.168.2.165.23: S

3443876657:3443876657(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)

3번째 시도에도 응답이 없어서 보내는 호스트는 연결 시도를 포기한다.

05:55:30.569584 192.168.2.10.1065 > 192.168.2.165.23: S

3443876657:3443876657(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)

tcpdump를 설명하면서 TCP/IP 프로토콜에 잠시 설명했다. 다른 프로토콜과 성능 모니터와 같은, tcpdump를 사용하여 확인할 수 있는 다른 영역도 있다. 네트워크/시스템 성능을 체크하기 위해 PDU의 응답 속도를 확인하는 방법도 있다.

기본 tcpdump사용법

단축키

Who's ADMINPLAY

Articles