Linux 패킷 캡처 명령 tcpdump의 용도는 무엇입니까?

Linux 패킷 캡처 명령 tcpdump는 네트워크 전송 데이터를 덤프하는 데 사용됩니다. 이는 네트워크에서 전송되는 데이터 패킷의 "헤더"를 완전히 가로채고 분석을 제공할 수 있으며 네트워크 계층, 프로토콜, 호스트, 네트워크 또는 포트에 대한 필터링을 지원합니다. , and, or, not 등의 논리문을 제공하여 불필요한 정보를 제거하는 데 도움이 됩니다.

관련 권장 사항: "Linux 비디오 튜토리얼"

Introduction

Linux tcpdump 명령은 네트워크 전송 데이터를 덤프하는 데 사용됩니다.

tcpdump 명령을 실행하여 지정된 네트워크 인터페이스를 통과하는 패킷 파일 헤더를 나열합니다. Linux 운영 체제에서는 시스템 관리자여야 합니다.

tcpdump를 간단히 정의하면 네트워크의 트래픽을 덤프하는 것입니다. 사용자 정의에 따라 네트워크의 데이터 패킷을 가로채는 패킷 분석 도구입니다. tcpdump는 네트워크에서 전송되는 데이터 패킷의 "헤더"를 완전히 가로채서 분석을 제공할 수 있습니다. 네트워크 계층, 프로토콜, 호스트, 네트워크 또는 포트에 대한 필터링을 지원하고, and, or, not 등의 논리문을 제공하여 불필요한 정보를 제거하는 데 도움을 줍니다.

실용적인 명령 예

기본적으로 시작

tcpdump

일반적인 상황에서 tcpdump를 직접 시작하면 첫 번째 네트워크 인터페이스에서 흐르는 모든 데이터 패킷이 모니터링됩니다.

지정된 네트워크 인터페이스의 데이터 패킷을 모니터링합니다

tcpdump -i eth1

네트워크 카드를 지정하지 않으면 기본적으로 tcpdump는 첫 번째 네트워크 인터페이스(일반적으로 eth0)만 모니터링합니다. 다음 예에서는 네트워크 인터페이스를 지정하지 않습니다. .

지정된 호스트의 데이터 패킷을 모니터링합니다

해질녘에 들어오거나 나가는 모든 데이터 패킷을 인쇄합니다.

tcpdump host sundown

또한 IP를 지정할 수도 있습니다. 호스트 패킷

tcpdump host 210.27.48.1

tcpdump host helios and \( hot or ace \)

호스트

와 호스트 210.27.48.2 또는 210.27.48.3

tcpdump host 210.27.48.1 and \ (210.27.48.2 or 210.27.48.3 \)

hostname

tcpdump ip host ace and not helios

tcpdump ip host 210.27.48.1 and ! 210.27.48.2

210.27.48.1에서 수신하거나 보낸 telnet

tcpdump -i eth0 src host hostname

ntp

tcpdump -i eth0 dst host hostname

로컬 호스트와 버클리 네트워크의 호스트 사이의 모든 통신 패킷을 인쇄합니다(nt: ucb-ether, 여기서는 '버클리 네트워크'의 네트워크 주소로 이해될 수 있으며, 이 표현은 가장 원시적인 의미는 다음과 같이 표현할 수 있습니다: 네트워크 주소가 ucb-ether인 모든 패킷을 인쇄합니다.

tcpdump tcp port 23 and host 210.27.48.1

tcpdump udp port 123

(로컬 네트워크가 게이트웨이를 통해 다른 네트워크에 연결된 경우 다른 네트워크는 로컬 호스트로 간주되지 않습니다. network.(nt: 이 문장은 번역이 서툴러 보완이 필요함).localnet은 실제 사용 시 로컬 네트워크 이름으로 바꿔야 함)

tcpdump net ucb-ether

tcpdump 'gateway snup and (port ftp or ftp-data)'

tcpdump ip and not net localnet

成字节数需要乘以4,　即左移2.　(tcp[12]&0xf0)>>4 表示tcp头的长度, 此域的单位也是32bit,　换算成比特数为 ((tcp[12]&0xf0) >> 4)　<<　２,　
即 ((tcp[12]&0xf0)>>2).　((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0　表示: 整个ip数据包的长度减去ip头的长度,再减去
tcp头的长度不为0, 这就意味着, ip数据包中确实是有数据.对于ipv6版本只需考虑ipv6头中的'Payload Length' 与 'tcp头的长度'的差值, 并且其中表达方式'ip[]'需换成'ip6[]'.)

打印长度超过576字节, 并且网关地址是snup的IP数据包

tcpdump 'gateway snup and ip[2:2] > 576'

打印所有IP层广播或多播的数据包， 但不是物理以太网层的广播或多播数据报

tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'

打印除'echo request'或者'echo reply'类型以外的ICMP数据包( 比如,需要打印所有非ping 程序产生的数据包时可用到此表达式 .
(nt: 'echo reuqest' 与 'echo reply' 这两种类型的ICMP数据包通常由ping程序产生))

tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'

tcpdump 与wireshark

Wireshark(以前是ethereal)是Windows下非常简单易用的抓包工具。但在Linux下很难找到一个好用的图形化抓包工具。
还好有Tcpdump。我们可以用Tcpdump + Wireshark 的完美组合实现：在 Linux 里抓包，然后在Windows 里分析包。

tcpdump tcp -i eth1 -t -s 0 -c 100 and dst port ! 22 and src net 192.168.1.0/24 -w ./target.cap

(1)tcp: ip icmp arp rarp 和 tcp、udp、icmp这些选项等都要放到第一个参数的位置，用来过滤数据报的类型
(2)-i eth1 : 只抓经过接口eth1的包
(3)-t : 不显示时间戳
(4)-s 0 : 抓取数据包时默认抓取长度为68字节。加上-S 0 后可以抓到完整的数据包
(5)-c 100 : 只抓取100个数据包
(6)dst port ! 22 : 不抓取目标端口是22的数据包
(7)src net 192.168.1.0/24 : 数据包的源网络地址为192.168.1.0/24
(8)-w ./target.cap : 保存成cap文件，方便用ethereal(即wireshark)分析

使用tcpdump抓取HTTP包

tcpdump  -XvvennSs 0 -i eth0 tcp[20:2]=0x4745 or tcp[20:2]=0x4854

0x4745 为"GET"前两个字母"GE",0x4854 为"HTTP"前两个字母"HT"。

tcpdump 对截获的数据并没有进行彻底解码，数据包内的大部分内容是使用十六进制的形式直接打印输出的。显然这不利于分析网络故障，通常的解决办法是先使用带-w参数的tcpdump 截获数据并保存到文件中，然后再使用其他程序(如Wireshark)进行解码分析。当然也应该定义过滤规则，以避免捕获的数据包填满整个硬盘。

输出信息含义

首先我们注意一下，基本上tcpdump总的的输出格式为：系统时间 来源主机.端口 > 目标主机.端口 数据包参数

tcpdump 的输出格式与协议有关.以下简要描述了大部分常用的格式及相关例子.

链路层头

对于FDDI网络, '-e' 使tcpdump打印出指定数据包的'frame control' 域, 源和目的地址, 以及包的长度.(frame control域
控制对包中其他域的解析). 一般的包(比如那些IP datagrams)都是带有'async'(异步标志)的数据包，并且有取值0到7的优先级;
比如 'async4'就代表此包为异步数据包，并且优先级别为4. 通常认为,这些包们会内含一个 LLC包(逻辑链路控制包); 这时,如果此包
不是一个ISO datagram或所谓的SNAP包，其LLC头部将会被打印(nt:应该是指此包内含的 LLC包的包头).

对于Token Ring网络(令牌环网络), '-e' 使tcpdump打印出指定数据包的'frame control'和'access control'域, 以及源和目的地址,
外加包的长度. 与FDDI网络类似, 此数据包通常内含LLC数据包. 不管 是否有'-e'选项.对于此网络上的'source-routed'类型数据包(nt:
意译为:源地址被追踪的数据包,具体含义未知,需补充), 其包的源路由信息总会被打印.

对于802.11网络(WLAN,即wireless local area network), '-e' 使tcpdump打印出指定数据包的'frame control域,
包头中包含的所有地址, 以及包的长度.与FDDI网络类似, 此数据包通常内含LLC数据包.

(注意: 以下的描述会假设你熟悉SLIP压缩算法 (nt:SLIP为Serial Line Internet Protocol.), 这个算法可以在
RFC-1144中找到相关的蛛丝马迹.)

SLIP 네트워크의 경우(nt: 네트워크로 이해될 수 있는 SLIP 링크, 즉 직렬 회선을 통해 설정된 연결이며 간단한 연결도 네트워크로 간주할 수 있음),
SLIP의 '방향 표시기' 데이터 패킷('방향 표시 플래그')("I"는 in, "O"는 out을 의미), 유형 및 압축 정보가 인쇄됩니다.

유형은 ip, utcp 및 ctcp로 구분됩니다. (nt: 알 수 없음, 추가해야 함) ip 패킷의 경우 연결 정보가 인쇄되지 않습니다. (nt: SLIP 연결에서는 ip 패킷의 연결 정보가 쓸모 없거나 정의되지 않을 수 있습니다.
TCP 패킷의 경우 다시 확인하세요.) 연결 식별자는 유형 표시 옆에 인쇄됩니다. 이 경우 패키지가 압축되고 인코딩된 헤더가 인쇄됩니다.
이때 특수 압축 패키지의 경우
*S+n 또는 * SA+n, 여기서 n은 패키지 번호와 응답 번호의 (순서 번호 또는 (순서)를 나타냄)) 증가 또는 감소 횟수(nt | rt: S, SA는 어색해서 다시 번역해야 함).
특수 압축 패키지가 아닌 경우 'changes'가 0개 이상 인쇄됩니다. 'Changes' '인쇄 시 형식은 다음과 같습니다.
'Flag' +/-/=n 패킷 데이터의 길이와 압축된 헤더 길이입니다.
그 중 'Flag'는 다음과 같은 값을 가질 수 있습니다:
U(긴급 포인터를 나타냄), W(버퍼 창 참조), A(응답), S(일련 번호), I(패키지 ID) 및 증분식 '=n'은 새 값이 할당됨을 의미하고 +/-는 증가 또는 감소를 의미합니다. 예를 들어 다음은 나가는 압축 TCP 데이터 패킷의 인쇄를 보여줍니다. number는 6만큼 증가하고,

ARP/RARP 데이터 패킷

Arp/rarp 패킷에 대한 tcpdump의 출력 정보에는 요청 유형과 요청에 해당하는 매개변수가 포함됩니다. 표시 형식은 간결하고 명확합니다. 다음은 호스트 rtsg에서 호스트 csam으로의 'rlogin'

arp who-has csam Tell rtsg
arp reply csam is-at CSAM
첫 번째 줄은 다음을 나타냅니다. : rtsg는 csam의 이더넷 주소를 요청하기 위해 arp 패킷(nt: 전체 네트워크 세그먼트에 전송, arp 패킷)을 보냈습니다
Csam(nt: 아래에서 볼 수 있음, Csam)은 자신의 이더넷 주소로 응답했습니다(이 예에서는 이더넷 주소는 대문자 이름으로 식별되고, 인터넷
주소(즉, IP 주소)는 모두 소문자 이름으로 식별됩니다.)

tcpdump -n을 사용하면 이름 대신 이더넷과 IP 주소를 명확하게 볼 수 있습니다. 식별자:

arp reply 128.3.254.6 is-at 02:07:01:00:01:c4

tcpdump -e를 사용하면 첫 번째 데이터 패킷은 전체 네트워크에 브로드캐스트되고 두 번째 데이터 패킷은 지점 간입니다.

CSAM RTSG 0806 64: arp reply csam is-at CSAM
첫 번째 데이터 패킷은 다음을 나타냅니다: arp 패킷의 소스 이더넷 주소는 RTSG이고 대상 주소는 전체 이더넷 세그먼트이며 유형 필드의 값은 16진수 0806(ETHER_ARP(nt: arp 패킷의 유형 식별자)을 나타냄),
패킷의 총 길이는 64바이트입니다.

TCP 데이터 패킷 (참고: 다음은 RFC-793에 설명된 TCP에 익숙하다고 가정합니다. 익숙하지 않은 경우 다음을 참조하세요. 설명과 tcpdump 프로그램은 별로 도움이 되지 않을 수 있습니다. (nt: 경고는 무시해도 됩니다.

일반적으로 tcp의 표시 형식입니다. tcpdump에 의한 데이터 패킷 다음과 같습니다:

src 및 dst는 소스 및 대상 IP 주소이며 해당 포트는 S(SYN), F( FIN), P(PUSH, R (RST),

단일 '.'는 플래그 식별자가 없음을 의미합니다. 데이터 세그먼트 시퀀스 번호(Data-seqno)는 이 패킷의 데이터에 해당하는 시퀀스 번호 공간의 위치를 ​​나타냅니다(nt: 전체 데이터가 세그먼트화됨,
각각 세그먼트는 시퀀스 번호를 가지며 모든 시퀀스 번호는 시퀀스 번호 공간을 구성합니다. (다음 예를 참조하십시오) Ack는 로컬 끝이 수신해야 하는 다음 데이터 조각의 동일한 연결, 동일한 방향 및 시퀀스 번호를 설명합니다. (상대방이 보내야 함) Window는 로컬 끝에서 사용할 수 있는 데이터 수신 버퍼입니다(상대방이 데이터를 보낼 때 이 크기에 따라 데이터를 구성해야 함). 데이터 패킷에 긴급 데이터가 있습니다. 옵션은 꺾쇠 괄호(예: )로 표시되는 일부 TCP 옵션을 설명합니다.

src, dst 및 플래그는 항상 표시됩니다. TCP 프로토콜 헤더의 정보.

이것은 trsg에서 csam으로의 rlogin 응용 프로그램 로그인의 시작 단계입니다.
rtsg.1023 > csam.login: S 768512:768512(0) win 4096
csam.login > S 947648:947648(0) ack 768513 win 4096
rtsg.1023 > csam.login: .ack 1 win 4096
rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
csam.login > rtsg.1023: .ack 2 win 4096
rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
csam.login > rtsg.1023 :2(1) ack 21 승리 4077
csam.login > rtsg.1023: P 2:3(1) ack 21 승리 4077 urg 1
csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1
첫 번째 줄은 rtsg 호스트의 tcp 포트 1023에서 csam 호스트의 tcp 포트 로그인으로 데이터 패킷이 전송됨을 나타냅니다(nt: udp 프로토콜의 포트와 tcp 프로토콜의 포트) 두 개의 별도 포트임) 공백, 값 범위는 동일함) S는 SYN 플래그가 설정되어 있음을 의미하며, 데이터를 포함하지 않습니다(표시 형식은 'first:last'입니다). (nbytes)'는 '이 패키지에서 데이터의 시퀀스 번호는 마지막을 제외하고 처음부터 시작하여 마지막으로 끝납니다. 그리고 총 nbytes의
사용자 데이터'를 포함합니다.) 피기백 응답이 없습니다(nt: 다음에서 두 번째 줄은 피기백 응답이 포함된 데이터 패킷입니다. 사용 가능한 수락 창 크기는 4096바이트이고 요청 끝(rtsg)의 최대 허용 데이터 세그먼트 크기는 1024바이트입니다(nt: 이 정보는 다음으로 전송됩니다.

Csam은 기본적으로 동일한 SYN 패킷으로 rtsg에 응답하지만 유일한 차이점은 추가 'piggy-backed ack'(nt: ack 응답)이 있다는 것입니다. rtsg의 SYN 패킷에 대해 다시 가져왔습니다.

데이터 중 이 세션에서 현재 전송되는 데이터 조각의 위치입니다(nt: 양쪽의 첫 번째 위치는 1, 즉 '상대 ​​바이트'의 시작 번호).

6번째 줄의 의미는 다음과 같습니다. rtsg는 19바이트를 csam으로 전송합니다. 데이터(바이트의 번호는 2~20이며, 전송 방향은 rtsg에서 csam으로) ) PUSH 플래그가 패킷에 설정되어 있습니다.
csam은 rtsg에서 21 미만의 바이트를 수신했지만 21번 바이트는 제외했다고 외칩니다. 이 바이트는 그에 따라
csam의 소켓에 저장됩니다. 수신 버퍼 창 크기는 19바이트로 줄어듭니다(nt: 5행과 7행에서 win 속성을 변경할 수 있습니다. 값 변경을 볼 수 있습니다). csam은 7행의 패킷에서
바이트도 rtsg로 보냈습니다. 8과 9에서 csam은 각각 1바이트만 포함하는 두 개의 데이터를 각각 rtsg 패킷으로 전송했으며 이 데이터 패킷에는 PUSH 플래그가 포함되어 있습니다.

캡처된 tcp 패킷(nt: 여기서는 스냅샷)이 너무 작아서 tcpdump가 발생합니다. 헤더 데이터를 완전히 얻을 수 없으면 현재 tcpdump는 이 불완전한 전체 헤더를 구문 분석하고
헤더에 잘못된 속성 정보가 포함된 경우 구문 분석할 수 없는 나머지 부분을 '[|tcp]'로 표시하기 위해 최선을 다합니다. 길이 속성이 실제로 헤더의 실제 길이보다 길거나 짧을 경우) tcpdump는 헤더
에 '[bad opt]'가 표시됩니다. 헤더의 길이가 몇 가지 옵션(nt | rt: 아래에서)을 알려준다면 이를 참조합니다. tcp 패키지 헤더에 있는 IP 패키지에 대한 일부 옵션을 다시 살펴보십시오.) 이 패킷에서
및 실제 IP 길이(데이터 패킷이 이러한 옵션을 수용하기에 충분하지 않으므로 tcpdump는 '[bad hdr length])를 표시합니다.

특수 플래그(예: SYN-ACK 플래그, URG-ACK 플래그 등)를 사용하여 TCP 패킷을 캡처합니다.

TCP 헤더에는 제어 비트 영역으로 사용되는 8비트(비트)가 있으며 그 값은 다음과 같습니다. ​​CWR | ECE | ACK | RST | FIN
(nt | rt: 이 8비트는 OR로 결합됩니다. )

이제 TCP 연결 패킷을 설정하는 전체 과정에서 생성된 데이터를 모니터링한다고 가정합니다. way handshake

1) 연결 개시자(nt: Caller)가 SYN 플래그와 함께 데이터 패킷을 보냅니다.
2) 수신자(nt: Recipient)가 다음과 같이 응답합니다. SYN 및 ACK 플래그가 포함된 데이터 패킷
3) 개시자는 수신자로부터 응답을 받은 후 ACK 플래그가 포함된 데이터 패킷을 보냅니다.

0 15 31
---------------------------------- --- -------
| 소스 포트 대상 포트 |
------------------ -------- ----------------------------- --------
| 시퀀스 번호 |
----------------------- -------------- ---------------
확인번호 |
--------------- ------------- -----------------------
| HL |C|E|U|A| 창 크기 |
------------ --------- -------------
| TCP 체크섬 | 긴급 포인터 |
-------------- ---------------- -------- -

옵션 데이터 없이 보통 20바이트를 차지하는 TCP 헤더(nt | rt:options는 옵션 데이터로 이해되므로 역번역됨) 첫 번째 줄에는 0부터 3까지의 바이트가 포함됩니다.
두 번째 줄에는 4~7의 바이트가 포함됩니다.

숫자가 0부터 시작하는 경우 TCP 제어 플래그는 바이트 13(nt: the 네 번째 줄의 왼쪽 절반)

0 7| 15| 31
---|------------ -|---------------| ---
응답 |C|E|U|A|P| R|S|F| 창 크기 |
-------- ------|---------------|------ --------|--------- -------
| 13번째 옥텟 |

바이트 번호 13을 자세히 살펴보겠습니다. |

|C|E|U|A|P|R|S|F|
|------------ --|
|7 5 3 0|

여기서 관심이 있는 부분은 제어 플래그 비트입니다. 오른쪽에서 왼쪽으로 이 비트는 0부터 7까지 번호가 지정되므로 PSH 비트는 3이고 URG 비트는 다음과 같습니다.

우리는 SYN 플래그가 포함된 패킷을 얻고자 한다는 점을 기억하세요. SYN 비트가 설정된 경우 패킷 헤더의 바이트 13에서 무슨 일이 일어나는지 살펴보겠습니다.

|C|E|U|A| P|R|S|F|
|- ---------------|

|------------ -----|
|7 6 5 4 3 2 1 0|

제어 세그먼트의 데이터에는 비트 번호 1만 설정되어 있습니다.

은 다음과 같습니다:

및 십진수 값:

tcpdump가 이해할 수 있는 관계식은 다음과 같습니다.

따라서 이 관계를 tcpdump의 필터 조건으로 사용할 수 있습니다. 목표는 SYN 플래그만 포함하는 데이터 패킷을 모니터링하는 것입니다.

이 표현은 "TCP 패킷의 13번째 바이트가 값 2를 갖도록 하십시오"라고 되어 있는데, 이는 우리가 원하는 결과이기도 합니다.

이제 다른 플래그가 포함되어 있는지 여부에 관계없이 SYN 플래그를 사용하여 패킷을 캡처해야 한다고 가정합니다. (nt: SYN을 가져오는 한 이것이 바로 우리가 원하는 것입니다.) 패킷이 발생하면 어떤 일이 발생하는지 살펴보겠습니다.
SYN-ACK(nt: SYN 및 ACK 플래그 모두)가 포함된 경우:

|--------------- -|

|--- ------------|
|7 6 5 4 3 2 1 0|

바이트의 비트 1 및 4 13개가 설정되어 있으며 그 이진수 값은
00010010

10진수로 환산하면 다음과 같습니다.

0*2^7 + 0*2^6 + 0*2^5 + 1*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2 = 18 (nt: 1 * 2^6은 1 곱하기 2의 6승을 의미합니다. 아마도 이것이 더 명확할 것입니다. 즉, 지수 7 6 입니다. .. 원래 표현식의 0은 아래로 이동됩니다.)
이제 'tcp[13] 18'을 tcpdump의 필터 표현식으로 사용할 수 없습니다. 이렇게 하면 SYN-ACK 플래그가 포함된 패킷만 선택되고 다른 패킷도 선택되기 때문입니다.

이를 바이트 13의 SYN 값(nt: 00000010)과 비교하는 것입니다.

AND 00000010(SYN을 원함) AND 00000010(SYN을 원함)
-------- --------

ACK 또는 패킷의 다른 플래그가 설정되었는지 여부에 관계없이 위의 AND 연산은 동일한 값을 제공하며 십진수 표현은 2(이진수 표현은 00000010)임을 알 수 있습니다.
그래서 우리는 SYN 플래그가 있는 패킷의 경우 다음 식의 결과는 항상 true입니다.

( ( 옥텟 13 값 ) AND ( 2 ) ) ( 2 ) (nt: 옥텟 13 값, 즉 바이트 번호 13 값 )

영감을 얻었고 다음과 같은 tcpdump 필터 표현식을 얻었습니다.
tcpdump -i xl0 'tcp[13] & 2 2'

참고, 작은따옴표 또는 백슬래시(nt: 여기서는 작은따옴표)는 생략할 수 없습니다. 쉘이 &.

UDP 데이터 패킷

UDP 데이터 패킷 표시 형식은 특정 응용 프로그램 rwho에 의해 생성된 데이터 패킷에 의해 결정될 수 있습니다. 설명:
actinide.who > udp 84

의미는 다음과 같습니다: actinide 호스트에 있는 포트가 브로드캐스트 호스트에 있는 포트로 udp 패킷을 보냈습니다(nt: actinide와 Broadcast는 모두 인터넷 주소를 나타냅니다).
이 패킷이 운반하는 사용자 데이터는 다음과 같습니다. 84바이트.

일부 UDP 서비스는 패킷의 소스 또는 대상 포트 또는 표시되는 상위 계층 프로토콜 정보에서 식별할 수 있습니다(예: 도메인 이름 서비스 요청(DNS 요청,
RFC-1034/1035)). 및 NFS에 대한 Sun RPC 호출(NFS 서버(nt: Sun RPC)에 의해 시작된 원격 호출, RFC-1050에 원격 호출에 대한 설명이 있습니다.)

UDP 이름 서비스 요청

(참고: 다음 설명에서는 당신은 도메인 서비스 프로토콜(nt: RFC-103에 설명됨)에 익숙합니다. 그렇지 않으면 다음 설명이 성경(nt:Greek bible,
주의하지 마세요. 무서워요. 그냥 읽으세요. on))

이름 서비스 요청 형식은 다음과 같습니다.
src > dst: id op? flags qtype qclass name (len)
(nt: 다음에서 형식은 src > dst: id op 여야 합니다. 플래그 qtype qclass? 이름(len))
실제 표시 내용은 다음과 같습니다.
h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu

'+' 기호는 재귀 쿼리 플래그가 설정되었음을 의미합니다( (NT: DNS 서버는 서버에 포함되지 않은 주소 레코드에 대해 상위 DNS 서버에 쿼리할 수 있습니다.) IP 패킷을 통해 전송된 쿼리 요청은 최종적으로 헤더 데이터를 포함하지 않는 37바이트의 데이터 길이를 갖게 됩니다. 왜냐하면 이 쿼리 작업은 기본값(nt | rt: 일반적인 사람의 이해)이고 op 필드가 생략되기 때문입니다.
op 필드를 생략하지 않으면 '3'과 '' 사이에 표시됩니다. +' 마찬가지로 qclass도 기본값이므로 표시되지 않으며, 무시하지 않으면 'A' 뒤에 표시됩니다.

예외 검사에서는 대괄호 안에 추가 필드가 표시됩니다. 응답(nt: 다른 이전 요청에 대한 응답으로 이해될 수 있음) 및 이 응답에는 신뢰할 수 있는 또는 추가 레코드 세그먼트가 포함되어 있습니다.

응답 비트(예: AA 비트, RA 비트, rcode 비트) 또는 바이트 중 하나 2 또는 3 '0이어야 함' 비트가 설정되면(nt: 1로 설정) '[b2&3]=x'가 표시됩니다. 여기서 x는
헤더 바이트 2 및 바이트 3 ANDed

UDP 이름 서비스의 값을 나타냅니다. response

이름 서비스 응답 데이터 패킷의 경우 tcpdump는 다음과 같은 표시 형식을 갖습니다.

예를 들어 구체적인 표시는 다음과 같습니다.
helios.domain > h2opolo .1538: 3 3/3/7 A 128.32.137.3 (273)
helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)

첫 번째 줄은 다음을 나타냅니다. h2opolo로 전송된 Query 요청 3번은 3개의 응답 레코드(nt | rt: 응답 레코드), 3개의 네임 서버 레코드,

이 응답 UDP 패킷에는 273바이트의 데이터(UPD 및 IP 헤더 데이터 제외)가 포함되어 있습니다. op 필드와 rcode 필드는 무시됩니다(nt: 실제 op 값은 Query, rcode, 즉
응답 코드의 실제 값은 NoError), 동일한 무시된 필드는 클래스 필드입니다(nt | rt: 해당 값은 C_IN이며 이는 유형 A 레코드 값의 기본값이기도 합니다) )

두 번째 줄은 helios가 h2opolo가 보낸 2번 쿼리 요청에 응답했음을 나타냅니다. 응답에서 rcode는 NXDomain(nt: 존재하지 않는 도메인을 나타냄)으로 인코딩되어 있으며 응답 기록이 없지만
포함되어 있습니다. 이름 서버 레코드, 권한 있는 서버 레코드를 포함하지 않습니다(nt | ck: 위에서부터 여기의 권한 레코드는 위의 해당 추가
레코드입니다) '*'는 권한 있는 서버 응답 플래그가 설정되었음을 나타냅니다(nt: 추가 레코드는 전거 레코드를 나타냅니다).
답변 레코드가 없으므로 유형, 클래스 및 데이터 필드는 무시됩니다.

플래그 필드에는 '-'(nt: 가능하다는 의미)와 같은 다른 문자가 있을 수 있습니다. 즉, RA 플래그가 설정되지 않은 경우), '|'(nt: 잘린 메시지를 나타냄, 즉 TC 플래그
가 설정된 경우)로 이해될 수 있습니다. 이름 서비스 응답이 포함된 UDP 패킷, tcpdump는 이 유형의 데이터를 알고 있습니다. 패키지의 '질문' 섹션에 있는 각 항목(데이터 구문 분석 방법)은 포함되지 않습니다(nt: 각 항목의 의미, 보완 필요). , '[nq]'가 출력됩니다.

tcpdump는 이미 SMB/CIFS/NBT 관련 애플리케이션의 패킷 내용을 디코딩할 수 있습니다. (nt: 'Server Message Block Common', 'Internet File System' '네트워크 프로토콜 NETBIOS의 약어) 이러한 서비스는 일반적으로 UDP의 137/138 및 TCP의 139 포트를 사용합니다. IPX 및 NetBEUI SMB 패킷에 대한 원래의

예를 들어 단일 SMB 패킷을 사용하면 한 화면 이상의 정보가 생성되므로 이 옵션은 꼭 필요한 경우에만 사용하세요.

SMB 패킷 형식 및 각 필드의 의미에 대한 자세한 내용은 pub/samba/specs/를 참조하세요. www.cifs.org 디렉토리 또는 samba.org 미러 사이트 Andrew Tridgell(tridge@samba.org)에서 제공하는 Linux 패치

NFS 요청 및 응답

tcpdump는 UDP를 인쇄합니다. Sun NFS(네트워크 파일 시스템) 요청 및 응답에 대한 다음 형식의 패킷 출력:
src.xid > dst.nfs: len op args

ushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165
wrl.nfs >ushi.6709: reply ok 40 readlink "../var"
ushi. 201b > wrl.nfs:

wrl.nfs >ushi.201b:
reply ok 128 lookup fh 9,74/4134.3150

출력의 첫 번째 줄은 다음과 같습니다. 호스트 Sushi가 호스트 wrl에 '교환 요청'(nt: 트랜잭션)을 보냈습니다. 요청의 ID는 6709입니다(호스트 이름 뒤에는 소스 포트 번호가 아니라 교환 요청 ID 번호가 옵니다). UDP 및 IP 헤더의 길이를 포함하지 않은 112바이트입니다. 작업 유형은 readlink(nt: 즉 이 작업은 읽기 심볼릭 링크 작업입니다.),
작업 매개변수는 fh 21,24/10.73165(nt: It)입니다. 실제 운영 환경에 따라 다음과 같이 해석할 수 있습니다. fd는 설명이 파일 핸들임을 의미하고, 21,24는 이 핸들에 해당하는 장치를 의미합니다.
마스터/슬레이브 장치 번호 쌍인 10은 이에 해당하는 i-node 번호를 나타냅니다. 핸들(nt: 각 파일은 운영 체제의 i-노드에 해당하며 유닉스 유형 시스템으로 제한됨),
73165는 숫자입니다(nt: can 이 요청을 식별하는 임의의 숫자로 이해되며 특정 의미를 추가해야 함)).

두 번째 줄에서 wrl은 'ok'로 응답하고, 결과 필드에 초밥이 읽고자 했던 기호 링크의 실제 디렉터리를 반환했습니다(nt: 즉, 기호 링크입니다.

의 세 번째 줄은 다음을 나타냅니다. Suzuki는 'fh 9,74/4096.6878'에 설명된 디렉토리에서 'xcolors' 파일을 검색하도록 wrl에 다시 요청합니다. 각 줄에 표시되는 데이터의 의미는
op 필드의 유형(nt: 서로 다른 op에 해당하는 args의 의미가 다름)에 따라 달라지며, 그 형식은 NFS 프로토콜을 따르며 단순성과 명확성을 추구합니다. tcpdump의 -v 옵션(세부사항 인쇄 옵션)이 설정되면 추가 정보가 표시됩니다. 예:
ushi.1372a > wrl.nfs:

wrl.nfs > ;ushi.1372a:

(-v 옵션은 일반적으로 IP 헤더의 TTL, ID, 길이 및 조각화 필드도 인쇄하지만 이 예에서는 모두 생략되었습니다. 간결함))
첫 번째 줄에서ushi는 wrl에게 파일 21,11/12.195(nt: 형식은 위에 설명되어 있음)에서 오프셋 24576바이트에서 시작하여 8192바이트의 데이터를 읽도록 요청합니다.
Wrl은 읽기가 성공했다고 응답합니다. 두 번째 줄은 응답 요청의 시작 조각일 뿐이므로 1472바이트만 포함합니다(다른 데이터는 후속 응답 조각에 들어오지만 이러한 패킷에는 더 이상 NFS
헤더가 없으며 UDP 헤더 정보도 비어 있습니다( nt: 소스 및 대상이 있어야 함), 이로 인해 이러한 조각이 필터 조건을 충족하지 못해 인쇄되지 않습니다.) -v 옵션은 파일 데이터 정보를 표시하는 것 외에도
추가 파일 속성 정보도 표시합니다. 파일 유형(파일 유형, ''REG''는 일반 파일을 의미), 파일 모드(파일 액세스 모드, 8진수로 표시), uid 및 gid(nt: 파일 소유자 및
그룹 소유자), 파일 크기(파일 크기).

-v 플래그를 여러 번 지정하면(nt: -vv 등) tcpdump가 더 자세한 정보를 표시합니다.

tcpdump의 snaplen(nt)에는 NFS 요청 패킷에 많은 데이터가 있다는 점에 유의해야 합니다. : 캡처 길이) 너무 짧으면 자세한 정보가 표시되지 않습니다.
'-s 192'를 사용하여 NFS 애플리케이션의 네트워크 부하(nt: 트래픽)를 모니터링하는 데 사용할 수 있습니다. NFS 응답 패킷은 엄격하지 않으며 이전 해당 요청 패킷(nt: RPC 작업)이 뒤따릅니다. 따라서 tcpdump는 최근에 수신된 일련의 요청 패킷을 추적한 다음

AFS(nt: Andrew File System, Transarc, 알 수 없음, 추가 필요) 요청 및 응답에는 다음 프로토콜이 있습니다

src.sport > : rx 패킷 유형 서비스 호출 호출 이름 args

elvis.7001 > pike.afsfs:
rx data fs call rename old fid 536876964/1/1 ".newsrc.new"

pike.afsfs > elvis.7001: rx data fs reply rename

첫 번째 줄에서 호스트 elvis는 다음을 보냅니다. RX 데이터 패킷 to pike.
이것은 파일 서비스 요청 데이터 패킷(nt: RX 데이터 패킷, 데이터 패킷 전송, 상대방의 서비스를 요청하는 패킷을 보내는 것으로 이해될 수 있음)입니다. RPC

원본 디렉터리 설명자는 원본 파일 이름인 536876964/1/1입니다. 는 '.newsrc.new'이고 새 디렉터리 설명자는 536876964/1 /1이며 새 파일 이름은 '.newsrc'입니다.
호스트 파이크는 이름 바꾸기 작업에 대한 RPC 요청에 응답했습니다(응답은 이름 바꾸기 작업이 응답이 예외 패킷이 아닌 데이터 내용이 포함된 패킷이었기 때문에 작업이 성공했습니다.

일반 예를 들어 모든 'AFS RPC' 요청이 표시되면 이름(nt: 디코드, 디코드)이 지정됩니다. 이 이름은 종종 RPC 요청의 작업 이름입니다.
또한 이러한 RPC 요청의 일부 매개변수가 표시되면 이름도 지정됩니다(nt | rt: 즉, 디코딩, 디코딩, 일반적으로 이름도 지정됩니다). 예를 들어 매우 간단합니다.

이 표시 형식은 '한 눈에 이해'하도록 설계되었지만 AFS 및 RX의 작동 원리에 익숙하지 않은 사람들에게는 그다지 유용하지 않을 수 있습니다(nt: 걱정하지 마십시오. 서면으로 작성하면 겁이 날 것입니다). 아래를 읽으십시오.

(nt: 이해될 수 있음)를 인쇄합니다. 확인 패킷뿐만 아니라 모든 패킷에 대한 추가 헤더 정보), 예를 들어 RX 호출 ID(요청 패킷의 '요청 호출' ID),
호출 번호('요청 호출' 번호), 시퀀스 번호( nt: 패키지 시퀀스 번호),

생략) 또한 확인 패킷의 MTU 협상 정보도 출력됩니다. (nt: 확인 패킷은 요청 패킷에 대한 확인 패킷, 최대 전송 단위, 최대 전송 단위

-v 옵션이 3번 반복되면(nt: -vvv 등) AFS 애플리케이션의 '보안 인덱스'('security index')와 '서비스 인덱스'('service id') 유형의 패킷이
인쇄됩니다.

비정상 데이터 패킷(nt: 중단 패킷, 이 패킷은 수신자에게 예외가 발생했음을 알리는 데 사용됨)의 경우 tcpdump는 오류 코드를 인쇄합니다.
그러나 Ubik 비콘 패킷(nt: Ubik beacon) 표시 패킷, Ubik은 특수 통신 프로토콜로 이해될 수 있습니다. 비콘 패킷, 라이트하우스 데이터 패킷은 통신의 핵심 정보를 나타내는 일부 데이터 패킷으로 이해될 수 있습니다. Ubik 프로토콜의 경우 오류 번호가 인쇄되지 않습니다. 데이터 패킷은 오류를 나타내지 않고 대신 긍정적인 응답을 나타냅니다(nt: 즉, 찬성 투표).

(서비스 인덱스)로 일치시킵니다. 응답 패킷이 최근 기간의 요청 패킷에 대한 것이 아니면 tcpdump는 이를 수행할 수 없습니다. 패킷을 구문 분석합니다.

KIP AppleTalk 프로토콜

(nt | rt: UDP의 DDP는 DDP, The AppleTalk Data Delivery Protocol,으로 이해될 수 있으며 KIP AppleTalk 프로토콜을 지원하는 네트워크 계층 프로토콜과 동일합니다. 그리고 DDP 자체는 UDP를 통해 전송됩니다. 즉, 다른 네트워크를 위해 UDP에 구현된 네트워크 레이어입니다. KIP AppleTalk는 Apple에서 개발한 완전한 네트워크 프로토콜 스택입니다.

AppleTalk DDP 패킷은 UDP 패킷에 캡슐화되고 캡슐화 해제됩니다. (nt: 디코딩과 동일) 그리고 해당 정보의 덤프도 DDP 패키지 규칙을 따릅니다.
(nt: encapsulate, encapsulation, 인코딩과 동일, de-encapsulate, de-encapsulation, 디코딩과 동일, dump, dump, 일반적으로 참조)

숫자 이름

16.1 icsd- net
1.254.110 ace

처음 두 줄은 두 개의 AppleTalk 네트워크가 있음을 나타냅니다. 세 번째 줄은 특정 네트워크의 호스트를 나타냅니다(호스트는 3바이트로 식별되지만 네트워크 식별은 일반적으로 3바이트로 식별됩니다). 이는 두 식별자의 주요 차이점이기도 합니다. (nt: 1.254.110은 에테르 네트워크의 에이스 호스트로 이해될 수 있습니다.)
식별자와 해당 이름은 공백으로 구분되어야 합니다. 위 내용에는 /etc/atalk.names에도 빈 줄과 주석 줄('#'으로 시작하는 줄)이 포함되어 있습니다.

net.host.port

다음 특정 디스플레이:

office.2 > icsd-net.112.220
jssmag.149.235 > 존재하지 않거나 해당 AppleTalk 호스트/네트워크에 대한 항목이 없으면 데이터 패킷의 네트워크 주소가 숫자 형식으로 표시됩니다.)

첫 번째 줄에서는 네트워크 144.1의 노드 209가 NBP 응용 프로그램 패킷을 보냈습니다. 포트 2를 통해 네트워크의 노드 112로 icsd-net 포트 220
(nt | rt: NBP, 이름 바인딩 프로토콜, 이름 바인딩 프로토콜)에서 수신 대기합니다. 데이터 관점에서 NBP 서버는 포트 2에서 이 서비스를 제공합니다.
'DDP 포트 2'는 'DDP 해당 전송 계층 포트 2'로 이해될 수 있으며, DDP 자체에는 포트 개념이 없으므로 이는 아직 결정되지 않았으며 보완이 필요합니다.)

세 번째 줄은 jssmag 네트워크의 149를 나타냅니다. 노드는 235를 통해 icsd에 있는 모든 노드의 포트 2(NBP 포트)로 데이터 패킷을 보냈습니다. -net 네트워크. (AppleTalk 네트워크에서 주소에 노드가 없으면 브로드캐스트 주소를 의미하므로 노드 식별과 /etc/atalk.names에서 네트워크 식별자를 구별하는 것이 가장 좋습니다.

tcpdump는 NBP(Name Binding Protocol) 및 ATP를 구문 분석할 수 있습니다. (AppleTalk Transport Protocol) 데이터 패킷, 기타 응용 계층 프로토콜의 경우 해당 프로토콜 이름만 인쇄됩니다. (
이 프로토콜이 공통 이름을 등록하지 않으면 해당 프로토콜 번호만 인쇄됩니다.) 및 데이터 패킷의 크기.

NBP 데이터 패킷은 다음 형식으로 표시됩니다:
icsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
jssmag.209.2 > -reply 190: "RM1140:LaserWriter@*" 250
techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186

첫 번째 줄은 다음을 나타냅니다: network icsd -Node 112 in net은 포트 220을 통해 네트워크 jssmag에 있는 모든 노드의 포트 2에 'LaserWriter'에 대한 이름 쿼리 요청을 보냈습니다(nt:
여기서 이름은 프린터와 같은 리소스의 이름으로 이해될 수 있습니다). 일련번호는 190입니다.

두 번째 줄은 다음을 나타냅니다. 네트워크 jssmag의 노드 209는 포트 2를 통해 icsd-net.112 노드의 포트 220에 응답했습니다. 'LaserWriter' 리소스가 있고 해당 리소스 이름
은 'RM1140'이며 포트에 있습니다. 250 이 응답의 시퀀스 번호는 190이며, 이는 이전에 쿼리한 시퀀스 번호에 해당합니다. 세 번째 줄도 첫 번째 줄의 요청에 대한 응답입니다. Node techpit는 포트 2를 포트 220으로 전달합니다. icsd-net.112 노드가 응답했습니다. 리소스 이름이 'techpit'인 'LaserWriter' 리소스가 있고 포트 186에서 리소스 수정 서비스를 제공합니다. 이 응답의 시퀀스 번호는 190이며 이전에 쿼리한 시퀀스 번호에 해당합니다.

ATP 데이터 패키지의 표시 형식은 다음과 같습니다:
jssmag.209.165 > helios.132: atp-req 12266<0-7> 0xae030001

helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae 040000
helios.132 > 9.165: atp-resp 12266:3 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
helios.132 > 040000
헬리오스. 132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
jssmag.209.165 > helios.132: atp-req 12266<3,5> 0xae030001
helios.132 > jssmag .209.165: atp-resp 12 266:3 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
jssmag.209.165 > helios.132: atp-rel 12266<0-7 >
jssmag.209.133 > 132: atp-req* 12267<0-7> 0xae030002

첫 번째 줄은 Jssmag.209 노드가 세션 번호 12266의 요청 패킷을 노드 helios에 보냈고 helios
에 8개의 데이터 패킷으로 응답하도록 요청했음을 나타냅니다. 이 8개의 데이터 패킷 중 0-7(nt: 시퀀스 번호는 세션 번호와 다릅니다. 후자는 완전한 전송 수입니다. 전자는 전송에 포함된 각 데이터 패킷의 수입니다. 트랜잭션, 세션, 일반적으로 전송이라고도 함)) 줄 끝의 16진수는

Helios 응답 8 512바이트 데이터 패킷. 세션 번호 뒤의 숫자(nt: 12266)는 세션에 있는 데이터 패킷의 시퀀스 번호를 나타냅니다.
괄호 안의 숫자는 데이터 패킷에 포함되지 않는 데이터의 크기를 나타냅니다. ATP 헤더에는 시퀀스 번호 7(라인 8)이 있는 패킷 외부에 '*' 기호가 있는데, 이는 패킷의 EOM 플래그가 설정되었음을 나타냅니다(nt: EOM, End Of Media, Understandingable(,

요청을 받았습니다. 이 두 데이터 패킷을 다시 보낸 후, jssmag.209는 이 두 데이터 패킷을 다시 수신한 후 세션을 종료(해제)했습니다.

마지막 줄에서 jssmag.209는 helios에게 다음 세션을 시작하라는 메시지를 보냈습니다.

조각화된 IP 데이터 패킷(nt: 큰 IP 데이터 패킷이 끊어진 후 생성된 작은 IP 데이터 패킷)은 다음 두 가지 표시 형식을 갖습니다.

(frag id:size@offset)
(첫 번째 형식은 이 조각 뒤에 후속 조각이 있음을 나타냅니다. 두 번째 형식은 이 조각이 마지막 조각임을 나타냅니다.)

크기는 조각 헤더 데이터를 제외하고 이 조각의 크기를 나타냅니다. 원본 전체 IP 패킷에 이 조각에 포함된 데이터((nt: 다음 중 IP 데이터 패킷은 데이터만 분할되는 것이 아니라 헤더와 데이터를 포함하여 전체적으로 조각화됩니다.) .

每个碎片都会使tcpdump产生相应的输出打印. 第一个碎片包含了高层协议的头数据(nt:从下文来看, 被破碎IP数据包中相应tcp头以及
IP头都放在了第一个碎片中 ), 从而tcpdump会针对第一个碎片显示这些信息, 并接着显示此碎片本身的信息. 其后的一些碎片并不包含高层协议头信息, 从而只会在显示源和目的之后显示碎片本身的信息. 以下有一个例子: 这是一个从arizona.edu 到lbl-rtsg.arpa途经CSNET网络(nt: CSNET connection 可理解为建立在CSNET 网络上的连接)的ftp应用通信片段:
arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
arizona > rtsg: (frag 595a:204@328)
rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560

tcpdump [ -AdDeflLnNOpqRStuUvxX ] [ -c count ]
           [ -C file_size ] [ -F file ]
           [ -i  ] [ -m module ] [ -M secret ]
           [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ]
           [ -W filecount ]
           [ -E spi@ipaddr algo:secret,...  ]
           [ -y datalinktype ] [ -Z user ]
           [ expression ]

-A  以ASCII码方式显示每一个数据包(不会显示数据包中链路层头部信息). 在抓取包含网页数据的数据包时, 可方便查看数据(nt: 即Handy  capturing web pages).

-c  count
    tcpdump将在接受到count个数据包后退出.

-C  file-size (nt: 此选项用于配合-w file 选项使用)
    该选项使得tcpdump 在把原始数据包直接保存到文件中之前, 检查此文件大小是否超过file-size. 如果超过了, 将关闭此文件,另创一个文件继续用于原始数据包的记录. 新创建的文件名与-w 选项指定的文件名一致, 但文件名后多了一个数字.该数字会从1开始随着新创建文件的增多而增加. file-size的单位是百万字节(nt: 这里指1,,000个字节,并非1,,576个字节, 后者是以1024字节为1k, 1024k字节为1M计算所得, 即1M= ＊  ＝ ,,)

-d  以容易阅读的形式,在标准输出上打印出编排过的包匹配码, 随后tcpdump停止.(nt | rt: human readable, 容易阅读的,通常是指以ascii码来打印一些信息. compiled, 编排过的. packet-matching code, 包匹配码,含义未知, 需补充)

-dd 以C语言的形式打印出包匹配码.

-ddd 以十进制数的形式打印出包匹配码(会在包匹配码之前有一个附加的前缀).

-D  打印系统中所有tcpdump可以在其上进行抓包的网络接口. 每一个接口会打印出数字编号, 相应的接口名字, 以及可能的一个网络接口描述. 其中网络接口名字和数字编号可以用在tcpdump 的-i flag 选项(nt: 把名字或数字代替flag), 来指定要在其上抓包的网络接口.

    此选项在不支持接口列表命令的系统上很有用(nt: 比如, Windows 系统, 或缺乏 ifconfig -a 的UNIX系统); 接口的数字编号在windows  或其后的系统中很有用, 因为这些系统上的接口名字比较复杂, 而不易使用.

    如果tcpdump编译时所依赖的libpcap库太老,-D 选项不会被支持, 因为其中缺乏 pcap_findalldevs()函数.

-e  每行的打印输出中将包括数据包的数据链路层头部信息

-E  spi@ipaddr algo:secret,...

    可通过spi@ipaddr algo:secret 来解密IPsec ESP包(nt | rt:IPsec Encapsulating Security Payload,IPsec 封装安全负载, IPsec可理解为, 一整套对ip数据包的加密协议, ESP 为整个IP 数据包或其中上层协议部分被加密后的数据,前者的工作模式称为隧道模式; 后者的工作模式称为传输模式 . 工作原理, 另需补充).

    需要注意的是, 在终端启动tcpdump 时, 可以为IPv4 ESP packets 设置密钥(secret）.

    可用于加密的算法包括des-cbc, 3des-cbc, blowfish-cbc, rc3-cbc, cast128-cbc, 或者没有(none).默认的是des-cbc(nt: des, Data Encryption Standard, 数据加密标准, 加密算法未知, 另需补充).secret 为用于ESP 的密钥, 使用ASCII 字符串方式表达. 如果以 0x 开头, 该密钥将以16进制方式读入.

    该选项中ESP 的定义遵循RFC2406, 而不是 RFC1827. 并且, 此选项只是用来调试的, 不推荐以真实密钥(secret)来使用该选项, 因为这样不安全: 在命令行中输入的secret 可以被其他人通过ps 等命令查看到.

    除了以上的语法格式(nt: 指spi@ipaddr algo:secret), 还可以在后面添加一个语法输入文件名字供tcpdump 使用(nt：即把spi@ipaddr algo:secret,... 中...换成一个语法文件名). 此文件在接受到第一个ESP　包时会打开此文件, 所以最好此时把赋予tcpdump 的一些特权取消(nt: 可理解为, 这样防范之后, 当该文件为恶意编写时,不至于造成过大损害).

-f  显示外部的IPv4 地址时(nt: foreign IPv4 addresses, 可理解为, 非本机ip地址), 采用数字方式而不是名字.(此选项是用来对付Sun公司的NIS服务器的缺陷(nt: NIS, 网络信息服务, tcpdump 显示外部地址的名字时会用到她提供的名称服务): 此NIS服务器在查询非本地地址名字时,常常会陷入无尽的查询循环).

    由于对外部(foreign)IPv4地址的测试需要用到本地网络接口(nt: tcpdump 抓包时用到的接口)及其IPv4 地址和网络掩码. 如果此地址或网络掩码不可用, 或者此接口根本就没有设置相应网络地址和网络掩码(nt: linux 下的  网络接口就不需要设置地址和掩码, 不过此接口可以收到系统中所有接口的数据包), 该选项不能正常工作.

-F  file
    使用file 文件作为过滤条件表达式的输入, 此时命令行上的输入将被忽略.

-i  

    指定tcpdump 需要监听的接口.  如果没有指定, tcpdump 会从系统接口列表中搜寻编号最小的已配置好的接口(不包括 loopback 接口).一但找到第一个符合条件的接口, 搜寻马上结束.

    在采用2.2版本或之后版本内核的Linux 操作系统上,  这个虚拟网络接口可被用来接收所有网络接口上的数据包(nt: 这会包括目的是该网络接口的, 也包括目的不是该网络接口的). 需要注意的是如果真实网络接口不能工作在模式(promiscuous)下,则无法在这个虚拟的网络接口上抓取其数据包.

    如果 -D 标志被指定, tcpdump会打印系统中的接口编号，而该编号就可用于此处的interface 参数.

-l  对标准输出进行行缓冲(nt: 使标准输出设备遇到一个换行符就马上把这行的内容打印出来).在需要同时观察抓包打印以及保存抓包记录的时候很有用. 比如, 可通过以下命令组合来达到此目的:
    ``tcpdump  -l  |  tee dat 或者 ``tcpdump  -l   > dat  &  tail  -f  dat.(nt: 前者使用tee来把tcpdump 的输出同时放到文件dat和标准输出中, 而后者通过重定向操作, 把tcpdump的输出放到dat 文件中, 同时通过tail把dat文件中的内容放到标准输出中)

-L  列出指定网络接口所支持的数据链路层的类型后退出.(nt: 指定接口通过-i 来指定)

-m  module
    通过module 指定的file 装载SMI MIB 模块(nt: SMI，Structure of Management Information, 管理信息结构MIB, Management Information Base, 管理信息库. 可理解为, 这两者用于SNMP(Simple Network Management Protoco)协议数据包的抓取. 具体SNMP 的工作原理未知, 另需补充).

    此选项可多次使用, 从而为tcpdump 装载不同的MIB 模块.

-M  secret  如果TCP 数据包(TCP segments)有TCP-MD5选项(在RFC 2385有相关描述), 则为其摘要的验证指定一个公共的密钥secret.

-n  不对地址(比如, 主机地址, 端口号)进行数字表示到名字表示的转换.

-N  不打印出host 的域名部分. 比如, 如果设置了此选现, tcpdump 将会打印 而不是 .

-O  不启用进行包匹配时所用的优化代码. 当怀疑某些bug是由优化代码引起的, 此选项将很有用.

-p  一般情况下, 把网络接口设置为非模式. 但必须注意 , 在特殊情况下此网络接口还是会以模式来工作； 从而,  的设与不设, 不能当做以下选现的代名词: 或  (nt: 前者表示只匹配以太网地址为host 的包, 后者表示匹配以太网地址为广播地址的数据包).

-q  快速(也许用更好?)打印输出. 即打印很少的协议相关信息, 从而输出行都比较简短.

-R  设定tcpdump 对 ESP/AH 数据包的解析按照 RFC1825而不是RFC1829(nt: AH, 认证头, ESP， 安全负载封装, 这两者会用在IP包的安全传输机制中). 如果此选项被设置, tcpdump 将不会打印出域(nt: relay prevention field). 另外,由于ESP/AH规范中没有规定ESP/AH数据包必须拥有协议版本号域,所以tcpdump不能从收到的ESP/AH数据包中推导出协议版本号.

-r  file
    从文件file 中读取包数据. 如果file 字段为  符号, 则tcpdump 会从标准输入中读取包数据.

-S  打印TCP 数据包的顺序号时, 使用绝对的顺序号, 而不是相对的顺序号.(nt: 相对顺序号可理解为, 相对第一个TCP 包顺序号的差距,比如, 接受方收到第一个数据包的绝对顺序号为232323, 对于后来接收到的第2个,第3个数据包, tcpdump会打印其序列号为1, 2分别表示与第一个数据包的差距为1 和 . 而如果此时-S 选项被设置, 对于后来接收到的第2个, 第3个数据包会打印出其绝对顺序号:, ).

-s  snaplen
    设置tcpdump的数据包抓取长度为snaplen, 如果不设置默认将会是68字节(而支持网络接口分接头(nt: NIT, 上文已有描述,可搜索关键字找到那里)的SunOS系列操作系统中默认的也是最小值是96).68字节对于IP, ICMP(nt: Internet Control Message Protocol,因特网控制报文协议), TCP 以及 UDP 协议的报文已足够, 但对于名称服务(nt: 可理解为dns, nis等服务), NFS服务相关的数据包会产生包截短. 如果产生包截短这种情况, tcpdump的相应打印输出行中会出现[|proto]的标志（proto 实际会显示为被截短的数据包的相关协议层次). 需要注意的是, 采用长的抓取长度(nt: snaplen比较大), 会增加包的处理时间, 并且会减少tcpdump 可缓存的数据包的数量， 从而会导致数据包的丢失. 所以, 在能抓取我们想要的包的前提下, 抓取长度越小越好.把snaplen 设置为0 意味着让tcpdump自动选择合适的长度来抓取数据包.

-T  type
    强制tcpdump按type指定的协议所描述的包结构来分析收到的数据包.  目前已知的type 可取的协议为:
    aodv (Ad-hoc On-demand Distance Vector protocol, 按需距离向量路由协议, 在Ad hoc(点对点模式)网络中使用),
    cnfp (Cisco  NetFlow  protocol),  rpc(Remote Procedure Call), rtp (Real-Time Applications protocol),
    rtcp (Real-Time Applications con-trol protocol), snmp (Simple Network Management Protocol),
    tftp (Trivial File Transfer Protocol, 碎文件协议), vat (Visual Audio Tool, 可用于在internet 上进行电
    视电话会议的应用层协议), 以及wb (distributed White Board, 可用于网络会议的应用层协议).

-t     在每行输出中不打印时间戳

-tt    不对每行输出的时间进行格式处理(nt: 这种格式一眼可能看不出其含义, 如时间戳打印成1261798315)

-ttt   tcpdump 输出时, 每两行打印之间会延迟一个段时间(以毫秒为单位)

-tttt  在每行打印的时间戳之前添加日期的打印

-u     打印出未加密的NFS 句柄(nt: handle可理解为NFS 中使用的文件句柄, 这将包括文件夹和文件夹中的文件)

-U    使得当tcpdump在使用-w 选项时, 其文件写入与包的保存同步.(nt: 即, 当每个数据包被保存时, 它将及时被写入文件中,而不是等文件的输出缓冲已满时才真正写入此文件)

      -U 标志在老版本的libcap库(nt: tcpdump 所依赖的报文捕获库)上不起作用, 因为其中缺乏pcap_cump_flush()函数.

-v    当分析和打印的时候, 产生详细的输出. 比如, 包的生存时间, 标识, 总长度以及IP包的一些选项. 这也会打开一些附加的包完整性检测, 比如对IP或ICMP包头部的校验和.

-vv   产生比-v更详细的输出. 比如, NFS回应包中的附加域将会被打印, SMB数据包也会被完全解码.

-vvv  产生比-vv更详细的输出. 比如, telent 时所使用的SB, SE 选项将会被打印, 如果telnet同时使用的是图形界面,
      其相应的图形选项将会以16进制的方式打印出来(nt: telnet 的SB,SE选项含义未知, 另需补充).

-w    把包数据直接写入文件而不进行分析和打印输出. 这些包数据可在随后通过-r 选项来重新读入并进行分析和打印.

-W    filecount
      此选项与-C 选项配合使用, 这将限制可打开的文件数目, 并且当文件数据超过这里设置的限制时, 依次循环替代之前的文件, 这相当于一个拥有filecount 个文件的文件缓冲池. 同时, 该选项会使得每个文件名的开头会出现足够多并用来占位的0, 这可以方便这些文件被正确的排序.

-x    当分析和打印时, tcpdump 会打印每个包的头部数据, 同时会以16进制打印出每个包的数据(但不包括连接层的头部).总共打印的数据大小不会超过整个数据包的大小与snaplen 中的最小值. 必须要注意的是, 如果高层协议数据没有snaplen 这么长,并且数据链路层(比如, Ethernet层)有填充数据, 则这些填充数据也会被打印.(nt: so  link  layers  that pad, 未能衔接理解和翻译, 需补充 )

-xx   tcpdump 会打印每个包的头部数据, 同时会以16进制打印出每个包的数据, 其中包括数据链路层的头部.

-X    当分析和打印时, tcpdump 会打印每个包的头部数据, 同时会以16进制和ASCII码形式打印出每个包的数据(但不包括连接层的头部).这对于分析一些新协议的数据包很方便.

-XX   当分析和打印时, tcpdump 会打印每个包的头部数据, 同时会以16进制和ASCII码形式打印出每个包的数据, 其中包括数据链路层的头部.这对于分析一些新协议的数据包很方便.

-y    datalinktype
      设置tcpdump 只捕获数据链路层协议类型是datalinktype的数据包

-Z    user
      使tcpdump 放弃自己的超级权限(如果以root用户启动tcpdump, tcpdump将会有超级用户权限), 并把当前tcpdump的用户ID设置为user, 组ID设置为user首要所属组的ID(nt: tcpdump 此处可理解为tcpdump 运行之后对应的进程)

      此选项也可在编译的时候被设置为默认打开.(nt: 此时user 的取值未知, 需补充)

type 修饰符指定id 所代表的对象类型, id可以是名字也可以是数字. 可选的对象类型有: host, net, port 以及portrange(nt: host 表明id表示主机, net 表明id是网络, port 表明id是端而portrange 表明id 是一个端口范围).  如, 'host foo', 'net 128.3', 'port 20', 'portrange 6000-6008'(nt: 分别表示主机 foo,网络 128.3, 端口 20, 端口范围 6000-6008). 如果不指定type 修饰符, id默认的修饰符为host.

dir 修饰符描述id 所对应的传输方向, 即发往id 还是从id 接收（nt: 而id 到底指什么需要看其前面的type 修饰符）.可取的方向为: src, dst, src 或 dst, src并且dst.(nt:分别表示, id是传输源, id是传输目的, id是传输源或者传输目的, id是传输源并且是传输目的). 例如, 'src foo','dst net 128.3', 'src or dst port ftp-data'.(nt: 分别表示符合条件的数据包中, 源主机是foo, 目的网络是128.3, 源或目的端口为 ftp-data).如果不指定dir修饰符, id 默认的修饰符为src 或 dst.对于链路层的协议,比如SLIP(nt: Serial Line InternetProtocol, 串联线路网际网络协议), 以及linux下指定'any' 设备, 并指定'cooked'(nt | rt: cooked 含义未知, 需补充) 抓取类型, 或其他设备类型,可以用'inbound' 和 'outbount' 修饰符来指定想要的传输方向.

proto 修饰符描述id 所属的协议. 可选的协议有: ether, fddi, tr, wlan, ip, ip6, arp, rarp, decnet, tcp以及 upd.(nt | rt: ether, fddi, tr, 具体含义未知, 需补充. 可理解为物理以太网传输协议, 光纤分布数据网传输协议,以及用于路由跟踪的协议.  wlan, 无线局域网协议; ip,ip6 即通常的TCP/IP协议栈中所使用的ipv4以及ipv6网络层协议;arp, rarp 即地址解析协议,反向地址解析协议; decnet, Digital Equipment Corporation开发的, 最早用于PDP-11 机器互联的网络协议; tcp and udp, 即通常TCP/IP协议栈中的两个传输层协议).

    例如, `ether src foo', `arp net 128.3', `tcp port 21', `udp portrange 7000-7009'分别表示 '从以太网地址foo 来的数据包','发往或来自128.3网络的arp协议数据包', '发送或接收端口为21的tcp协议数据包', '发送或接收端口范围为7000-7009的udp协议数据包'.

    如果不指定proto 修饰符, 则默认为与相应type匹配的修饰符. 例如, 'src foo' 含义是 '(ip or arp or rarp) src foo' (nt: 即, 来自主机foo的ip/arp/rarp协议数据包, 默认type为host),`net bar' 含义是`(ip  or  arp  or rarp) net bar'(nt: 即, 来自或发往bar网络的ip/arp/rarp协议数据包),`port 53' 含义是 `(tcp or udp) port 53'(nt: 即, 发送或接收端口为53的tcp/udp协议数据包).(nt: 由于tcpdump 直接通过数据链路层的 BSD 数据包过滤器或 DLPI(datalink provider interface, 数据链层提供者接口)来直接获得网络数据包, 其可抓取的数据包可涵盖上层的各种协议, 包括arp, rarp, icmp(因特网控制报文协议),ip, ip6, tcp, udp, sctp(流控制传输协议).

    对于修饰符后跟id 的格式,可理解为, type id 是对包最基本的过滤条件: 即对包相关的主机, 网络, 端口的限制;dir 表示对包的传送方向的限制; proto表示对包相关的协议限制)

    'fddi'(nt: Fiber Distributed Data Interface) 实际上与'ether' 含义一样: tcpdump 会把他们当作一种''指定网络接口上的数据链路层协议''. 如同ehter网(以太网), FDDI 的头部通常也会有源, 目的, 以及包类型, 从而可以像ether网数据包一样对这些域进行过滤. 此外, FDDI 头部还有其他的域, 但不能被放到表达式中用来过滤

    同样, 'tr' 和 'wlan' 也和 'ether' 含义一致, 上一段对fddi 的描述同样适用于tr(Token Ring) 和wlan(802.11 wireless LAN)的头部. 对于802.11 协议数据包的头部, 目的域称为DA, 源域称为 SA;而其中的 BSSID, RA, TA 域(nt | rt: 具体含义需补充)不会被检测(nt: 不能被用于包过虑表达式中).

 否定操作 (`!' 或 `not')
 与操作(`&&' 或 `and')
 或操作(`||' 或 `or')

위 내용은 Linux 패킷 캡처 명령 tcpdump의 용도는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!