집 >운영 및 유지보수 >리눅스 운영 및 유지 관리 >Linux 패킷 캡처 명령 tcpdump의 용도는 무엇입니까?
Linux 패킷 캡처 명령 tcpdump의 용도는 무엇입니까?
- 青灯夜游원래의
- 2020-11-03 11:14:379435검색
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
helios와 hot 또는 ace 간의 통신 패킷을 인쇄합니다.
tcpdump host helios and \( hot or ace \)
호스트
210.27.48.1와 호스트 210.27.48.2 또는 210.27.48.3 tcpdump host 210.27.48.1 and \ (210.27.48.2 or 210.27.48.3 \)
간의 통신을 차단합니다. 사이의 통신을 인쇄하세요. ace 및 다른 호스트 간에 통신되는 모든 IP 데이터 패킷(helios의 데이터 패킷은 포함되지 않음)
hostname
tcpdump ip host ace and not helios호스트로 보낸 모든 데이터 패킷 모니터링 hostname
tcpdump ip host 210.27.48.1 and ! 210.27.48.2지정된 호스트 및 포트의 데이터 패킷 모니터링
If 호스트
210.27.48.1에서 수신하거나 보낸 telnet
패킷에 대해 다음 명령tcpdump -i eth0 src host hostname을 사용하여 이 시스템의 udp 123 포트 123 가 서비스 포트
ntp
tcpdump -i eth0 dst host hostname인지 모니터링합니다. 지정된 네트워크의 데이터 패킷
로컬 호스트와 버클리 네트워크의 호스트 사이의 모든 통신 패킷을 인쇄합니다(nt: ucb-ether, 여기서는 '버클리 네트워크'의 네트워크 주소로 이해될 수 있으며, 이 표현은 가장 원시적인 의미는 다음과 같이 표현할 수 있습니다: 네트워크 주소가 ucb-ether인 모든 패킷을 인쇄합니다.
tcpdump tcp port 23 and host 210.27.48.1게이트웨이 snup을 통과하는 모든 ftp 패킷을 인쇄합니다(표현은 작은따옴표로 묶여 있으므로 쉘이 해석할 수 없습니다). 오류 분석)
tcpdump udp port 123발신지 또는 목적지 주소가 로컬 호스트인 모든 IP 패킷을 인쇄합니다
(로컬 네트워크가 게이트웨이를 통해 다른 네트워크에 연결된 경우 다른 네트워크는 로컬 호스트로 간주되지 않습니다. network.(nt: 이 문장은 번역이 서툴러 보완이 필요함).localnet은 실제 사용 시 로컬 네트워크 이름으로 바꿔야 함)tcpdump net ucb-ether
tcpdump 'gateway snup and (port ftp or ftp-data)'모든 소스 또는 대상 포트는 80이고 네트워크 계층 프로토콜은 IPv4이며 데이터를 포함하지 않는 SYN, FIN 및 ACK 전용과 같은 데이터 패킷 대신 데이터를 포함합니다. (ipv6 버전의 표현은 다음과 같습니다. 연습으로 사용하세요)
tcpdump ip and not net localnet(nt: ip[2:2]는 전체 IP 데이터 패킷을 나타냅니다. 길이, (ip[0]&0xf)<<2)는 IP 데이터 패킷의 길이를 나타냅니다. ip 데이터 패킷 헤더(ip[0]&0xf는 패킷의 IHL 필드를 나타내며 이 필드의 단위는 32비트이므로 변환이 필요합니다
成字节数需要乘以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는 로컬 끝에서 사용할 수 있는 데이터 수신 버퍼입니다(상대방이 데이터를 보낼 때 이 크기에 따라 데이터를 구성해야 함). 데이터 패킷에 긴급 데이터가 있습니다. 옵션은 꺾쇠 괄호(예:
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
연결 순서와 해당 TCP 제어 플래그가 포함된 데이터 패킷은 다음과 같습니다. 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만 설정되어 있습니다.
은 다음과 같습니다:
00000010
및 십진수 값:
tcpdump가 이해할 수 있는 관계식은 다음과 같습니다.
따라서 이 관계를 tcpdump의 필터 조건으로 사용할 수 있습니다. 목표는 SYN 플래그만 포함하는 데이터 패킷을 모니터링하는 것입니다.
이 표현은 "TCP 패킷의 13번째 바이트가 값 2를 갖도록 하십시오"라고 되어 있는데, 이는 우리가 원하는 결과이기도 합니다.
이제 다른 플래그가 포함되어 있는지 여부에 관계없이 SYN 플래그를 사용하여 패킷을 캡처해야 한다고 가정합니다. (nt: SYN을 가져오는 한 이것이 바로 우리가 원하는 것입니다.) 패킷이 발생하면 어떤 일이 발생하는지 살펴보겠습니다.
SYN-ACK(nt: SYN 및 ACK 플래그 모두)가 포함된 경우:
|--------------- -|
|0 0 0 1 0 0 1 0| |--- ------------|
|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는 다음과 같은 표시 형식을 갖습니다.
src > dst: id op rcode flags a/n/au 유형 클래스 데이터(len) 예를 들어 구체적인 표시는 다음과 같습니다.
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 패킷에 대한 원래의
디코딩 기능을 계속 사용할 수 있습니다(nt: NetBEUI는 NETBIOS의 향상된 버전입니다). tcpdump는 기본적으로 가장 간단한 모드에서만 해당 패킷을 디코딩합니다. 자세한 디코딩 정보를 보려면 -v 시작 옵션을 사용할 수 있습니다. -v는 매우 자세한 정보를 생성합니다. 예를 들어 단일 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:
답글 확인 1472 읽기 REG 100664 ids 417/0 sz 29388(-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 > dst.dport: rx packet-typesrc.sport > : rx 패킷 유형 서비스 호출 호출 이름 args
src.sport > dst.dport: 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에서 네트워크 식별자를 구별하는 것이 가장 좋습니다.
nt: 그렇지 않으면 식별자 x.port가 네트워크에 있는 모든 호스트의 포트를 참조하는지 아니면 지정된 호스트의 포트를 참조하는지 확인하는 것이 불가능합니다. x)
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头以及 有几点值得注意: 第二, 从第一行的信息中, 可以发现arizona需要向rtsg发送308字节的用户数据, 而事实是, 相应IP包经破碎后会总共产生512字节 一个数据包(nt | rt: 指IP数据包)如果带有非IP破碎标志, 则显示时会在最后显示'(DF)'.(nt: 意味着此IP包没有被破碎过). 时间戳 tcpdump的所有输出打印行中都会默认包含时间戳信息. 命令使用 tcpdump采用命令行方式，它的命令格式为： tcpdump的简单选项介绍 tcpdump条件表达式 该表达式用于决定哪些数据包将被打印. 如果不给定条件表达式, 网络上所有被捕获的包都会被打印,否则, 只有满足条件表达式的数据包被打印.(nt: all packets, 可理解为, 所有被指定接口捕获的数据包). 表达式由一个或多个'表达元'组成(nt: primitive, 表达元, 可理解为组成表达式的基本元素). 一个表达元通常由一个或多个修饰符(qualifiers)后跟一个名字或数字表示的id组成(nt: 即, 'qualifiers id').有三种不同类型的修饰符:type, dir以及 proto. 除以上所描述的表达元('primitive')， 还有其他形式的表达元, 并且与上述表达元格式不同. 比如: gateway, broadcast, less, greater以及算术表达式(nt: 其中每一个都算一种新的表达元). 下面将会对这些表达元进行说明. 表达元之间还可以通过关键字and, or 以及 not 进行连接, 从而可组成比较复杂的条件表达式. 比如,`host foo and not port ftp and not port ftp-data'(nt: 其过滤条件可理解为, 数据包的主机为foo,并且端口不是ftp(端口21) 和ftp-data(端口20, 常用端口和名字的对应可在linux 系统中的/etc/service 文件中找到)). 为了表示方便, 同样的修饰符可以被省略, 如'tcp dst port ftp or ftp-data or domain' 与以下的表达式含义相同'tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'.(nt: 其过滤条件可理解为,包的协议为tcp, 目的端口为ftp 或 ftp-data 或 domain(端口53) ). 借助括号以及相应操作符,可把表达元组合在一起使用(由于括号是shell的特殊字符, 所以在shell脚本或终端中使用时必须对括号进行转义, 即'(' 与')'需要分别表达成'\(' 与 '\)'). 有效的操作符有: 否定操作符的优先级别最高. 与操作和或操作优先级别相同, 并且二者的结合顺序是从左到右. 要注意的是, 表达'与操作'时, 앞뒤 표현 요소를 나란히 배치하는 대신 'and' 연산자를 명시적으로 작성해야 합니다. (nt: 둘 사이의 'and' 연산자는 생략할 수 없습니다. an 앞에 키워드가 없는 경우. 식별자, 표현식 수식의 구문 분석 과정에서 가장 최근에 사용된 키워드(일반적으로 왼쪽에서 오른쪽으로 식별자에 가장 가까운 키워드)가 사용됩니다. 예를 들어 부록: tcpdump 표현식 요소 (nt: 다음 설명의 의미: 해당 조건식에는 아래 나열된 특정 표현식 요소가 하나만 포함됩니다. 이때 표현식은 조건을 충족합니다.) dst 호스트 호스트 src 호스트 호스트 는 다음과 같이 표현할 수도 있습니다. ether dst ehost ' net은 네트워크 데이터베이스 파일의 이름일 수 있습니다. etc/networks 또는 숫자 네트워크 번호일 수 있습니다. 숫자 IPv4 네트워크 번호는 점으로 구분된 쿼드(예: 192.168.1.0), 점으로 구분된 삼중(예: 192.168.1) 또는 점으로 구분된 튜플(예: 172.16)입니다. ) 또는 단일 단위 그룹(예: 10)을 표현합니다. 이 네 가지 상황에 해당하는 네트워크 마스크는 다음과 같습니다. Quadruple: 255.255.255.255(이것은 또한 net의 일치를 의미합니다. 호스트 주소(host)의 일치와 같습니다: 주소의 네 부분이 모두 사용됩니다), 삼중항: 255.255.255.0, 튜플: 255.255.0.0, 1-튜플: 255.0. 0.0. IPv6 주소 형식의 경우 네트워크 번호를 전체로 작성해야 합니다(8개 부분을 모두 작성해야 함). 해당 네트워크 마스크는 src net net net net net net 마스크 netmask net net/len dst 포트 포트 src port port port port dst portrange port1-port2 src portrange port1-port2 portrange port1과 같습니다. -port2 다음에 tcp 또는 udp 키워드를 추가할 수 있습니다. 위의 포트 옵션 앞, 예: tcp src port port 길이가 적음 더 큰 길이 ip의 의미와 일치합니다. proto 프로토콜 ip6 proto 프로토콜 ip6 프로토체인 프로토콜 ip6 protochain 6 ip 프로토체인 프로토콜 ether Broadcast ip Broadcast any' 네트워크 인터페이스에서 캡처되었습니다. Linux(이 'any' 인터페이스는 시스템으로부터 두 개 이상의 패킷을 수신할 수 있습니다. 인터페이스의 패킷에 대해(nt: 실제로는 시스템에서 사용 가능한 모든 인터페이스로 이해될 수 있음), 네트워크 마스크 검사 ether multicast 0 ether proto 프로토콜 프로토콜 필드는 숫자이거나 다음 프로토콜 이름 중 하나일 수 있습니다: ip, ip6, arp, rarp, atalk, aarp, decnet, sca, lat, (SNAP: SubNetwork Access Protocol) 광섬유 네트워크 인터페이스에 분산된 데이터(표현 메타폼은 'fddi 프로토콜 arp'), 토큰 링(표현 메타 형식은 'tr 프로토콜 arp'일 수 있음), 이러한 네트워크의 해당 프로토콜 식별자가 필터 조건으로 사용되는 경우 tcpdump는 구성 요소 단위 식별자(OUI, 0x000000 iso tcpdump는 LLC 헤더 포인트의 DSAP 필드(대상 서비스 액세스 포인트, 대상 서비스 액세스) 및 stp 및 netbeui atalk tcpdump는 AppleTalk etype 필드를 확인합니다. 이더넷 물리적 프레임을 확인하고 데이터 패킷의 LLC 헤더에서 aarp tcpdump는 이더넷 물리적 프레임에 있거나 LLC(802.2에 의해 정의됨)의 및 LLC 헤더의 IPX etype 필드 데이터 패킷의 DECNET 소스 주소가 호스트인 경우 이 해당 조건식은 true입니다. 데이터 패킷의 DECNET 대상 주소가 호스트인 경우, 그러면 이에 해당하는 조건식이 참이 됩니다. 데이터 패킷의 DECNET 대상 주소 또는 DECNET 소스 주소가 호스트이면 이에 해당하는 조건식은 공식은 true입니다. interface데이터 패킷이 지정된 네트워크 인터페이스에서 수신된 것으로 표시되면 해당 조건식이 true입니다. interface는 ifname 패킷이 PF의 규칙과 일치하는 것으로 표시되면 해당 조건식이 true입니다. 은 rulenum num과 같은 의미입니다. 패킷에 PF의 일치 결과 코드가 포함된 것으로 표시되면 해당 조건식이 true입니다. 유효한 결과 코드는 match, bad-offset, 패킷이 지정된 규칙 세트와 일치하는 것으로 표시되면 해당 조건식이 true입니다. 은 rset name과 같은 의미입니다. 패킷이 표시되어 있는 경우 지정된 규칙에서 특정 규칙과 일치합니다. set(nt: 지정된 PF 규칙 번호, 특정 규칙 번호, 즉 특정 규칙), 은 srnr과 같은 의미입니다. 패킷이 기록되면 PF는 act에서 지정한 동작을 수행하고, 해당 조건식은 유효한 조치는 pass, block입니다. 는 다음 표현과 같은 의미입니다. 은 다음 표현과 일치합니다. vlan [vlan_id] vlan 데이터 패킷이 MPLS 데이터 패킷이면 해당 조건식이 true입니다. 주의해야 할 점은 MPLS 정보가 포함된 IP 데이터 패킷(즉, MPLS 데이터 패킷), 표현식에서 처음 발견된 MPLS 키워드는 필터링 시 패킷 내 데이터의 mpls mpls && mpls 데이터 패킷이 PPP-over인 경우 - 이더넷 서버 검색 패킷(nt: 검색 패킷, 데이터 패킷이 PPP-over-Ethernet 세션 데이터 패킷인 경우(nt: 이더넷 유형은 0x8864, PPP-over-Ethernet은 위에서 설명했듯이 pppoes && ip tcp, udp, icmp (nt: clnp, 연결 없는 네트워크 프로토콜, 이는 OSI입니다. 네트워크 모델인 esis, isis의 네트워크 계층 프로토콜은 알려져 있지 않으며 이를 확인해야 합니다. 보충) iso proto p l1, l2, iih, lsp, snp, csnp, psnp 데이터 패킷이 ATM 데이터 패킷인 경우 해당 조건식이 true입니다. Solaris 운영 체제 장치의 SunATM LANE 논리 장치 제어 패킷인 경우 표현식의 첫 번째 레인 키워드가 변경됩니다. 표현식의 후속 조건 테스트입니다. 레인 키워드가 지정되지 않은 경우 조건 테스트는 데이터 패킷에 LLC(Logical Link Layer)가 포함된 ATM 패킷을 기반으로 합니다. 및 VCI= (nt: OAM, Operation Administration and Maintenance, Operation Management and Maintenance로 이해될 수 있습니다: ATM 네트워크에서 네트워크 채널)을 형성합니다. OAM F4 플로우 셀은 세그먼트 클래스와 엔드-투-엔드 클래스로 나눌 수 있으며 차이점은 알 수 없으며 보완이 필요합니다.) )인 경우 이는 조건식에 해당합니다. 는 사실입니다. ' ), 해당 조건식이 true입니다. ), 해당 조건식이 true입니다. metac bcc sc ilmic connectmsg 데이터 패킷이 ATM 데이터 패킷인 경우 해당 조건식은 SunATM의 경우 true입니다. Solaris 운영 체제의 장비, 데이터 패킷이 ATM 패킷 relop 양쪽의 피연산자(expr)가 relop에서 지정한 관계를 만족하면 해당 조건식은 다음과 같습니다. proto의 값은 ether, fddi, tr, wlan, ppp, lip, link, ip, arp, rarp, 는 데이터 패킷의 필드임) 길이는 1, 'ether[0] & 1 != 0'은 tcpdump는 모든 멀티캐스트 패킷을 캡처합니다. (nt: ether[0] 바이트의 가장 낮은 비트는 1입니다. 이는 패킷의 대상 주소가 멀티캐스트 주소임을 의미합니다. ' 다음은 ICMP 프로토콜 헤더의 유형 필드에 사용 가능한 값입니다: icmp-ireq, icmp-ireqreply, icmp -maskreq , icmp-maskreply. 자세히 알아보기 프로그래밍 관련 지식을 더 보려면
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
第一, 第二行的打印中, 地址后面没有端口号.
这是因为TCP协议信息都放到了第一个碎片中, 当显示第二个碎片时, 我们无法知道此碎片所对应TCP包的顺序号.
数据(第一个碎片包含308字节的数据, 第二个碎片包含204个字节的数据, 这超过了308字节). 如果你在查找数据包的顺序号空间中的
一些空洞(nt: hole,空洞, 指数据包之间的顺序号没有上下衔接上), 512这个数据就足够使你迷茫一阵(nt: 其实只要关注308就行,
不必关注破碎后的数据总量).
时间戳信息的显示格式如下
hh:mm:ss.frac (nt: 小时:分钟:秒.(nt: frac未知, 需补充))
此时间戳的精度与内核时间精度一致, 反映的是内核第一次看到对应数据包的时间(nt: saw, 即可对该数据包进行操作).
而数据包从物理线路传递到内核的时间, 以及内核花费在此包上的中断处理时间都没有算进来.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')
not Host vs 및 ace
는 다음을 단순화한 것입니다. 표현:
not (host vs or ace) 대신에 Host ace
(nt: 처음 두 개는 필요한 데이터 패킷이 호스트 vs에서 전송되거나 호스트에서 전송되지 않고 ace에서 전송되거나 전송됨을 의미합니다. 후자는 전체 조건식은 단일 문자열 매개변수로 사용되거나 공백으로 구분되어 tcpdump에 전달되는 여러 매개변수로 사용될 수 있습니다. 일반적으로 표현식에 다음이 포함되어 있으면 후자가 더 편리합니다. 메타 문자(nt: 정규 표현식의 '*', '.', 셸의 '(' 및 기타 문자). 별도의 문자열로 전달하는 것이 가장 좋습니다. 이때 전체 표현식이 필요합니다. 다중 매개변수 입력 방법에서는 결국 모든 매개변수가 공백으로 연결되어 문자열로 구문 분석됩니다.
IPv4/v6 패킷의 소스 도메인이 호스트인 경우 해당 조건식은
host일 수 있습니다.
host 호스트
IPv4/v6 패킷의 소스 또는 대상 주소가 호스트인 경우 해당 조건식이 true입니다. 위의 호스트 표현식 앞에 다음 키워드를 추가할 수 있습니다: ip, arp, rarp 및 ip6 예:
ether proto ip 및 호스트 호스트(nt: 이 표현은 아래 설명과 같이 ip가 이미 tcpdump의 키워드이기 때문에 먼저 이스케이프해야 합니다. .)
호스트가 여러 IP를 가진 호스트인 경우 임의의 주소가 패키지 매칭에 사용됩니다. (nt: 호스트로 전송되는 데이터 패킷의 대상 주소는 이 IP 중 하나일 수 있으며 소스 주소는 호스트로부터 수신된 데이터 패킷 중 이 IP 중 하나일 수도 있습니다.
ether src ehost
etherhost ehost
gateway 호스트
로 이해될 수 있습니다. 참고 '. 이더넷 소스 또는 대상 주소, 이더넷 소스 및 대상 주소는 다음과 같을 수 있습니다. 이전 문장의 ' 게이트웨이 주소 ' ).host를 가리키는 것으로 이해됩니다. 숫자가 아닌 이름이어야 하며, 컴퓨터의 'hostname-ip 주소에 항목이 있어야 합니다. ' 및 'hostname-Ethernet address' (이전 매핑 관계는 /etc/hosts 파일, DNS 또는 NIS를 통해 얻을 수 있으며 후자의 매핑 관계는 /etc/ethers를 통해 얻을 수 있습니다. file.nt: /etc/ethers는 반드시 존재하는 것은 아니며, 해당 데이터 형식은 man ethers를 통해 확인할 수 있습니다. 이 파일을 만드는 방법은 알 수 없습니다. 즉, 호스트는 호스트 호스트가 아닌 ether 호스트 ehost를 의미합니다. , ehost는 숫자가 아닌 이름이어야 합니다. 현재 IPv6 주소 형식을 지원하는 구성 환경에서는 이 옵션을 사용할 수 없습니다. 기능(nt: 구성, 구성 환경, 통신 당사자 모두의 네트워크 구성으로 이해될 수 있음) .
dst net net
ff:ff:ff:ff: ff:ff:ff :ff, 따라서 IPv6 네트워크 일치는 실제 'host' 일치입니다. (nt | rt | rc: 네트워크에 속하지 않는 문자인지 여부에 관계없이 주소의 8개 부분이 모두 사용됩니다. 섹션의 경우 0에 있고 다음에 추가해야 함), 동시에 네트워크 마스크 앞에 몇 바이트가 있는지 지정하려면 네트워크 마스크 길이 매개변수가 필요합니다(nt: 다음 net net/len을 통해 지정할 수 있음). )
데이터 패킷의 소스 주소(IPv4 또는 IPv6 형식)의 네트워크 번호 필드가 net이면 해당 조건식이 true입니다.
소스 또는 대상 주소(IPv4) 또는 IPv6 형식) 데이터 패킷의 네트워크 번호 필드가 net이면 해당 조건식이 true입니다.
소스 또는 대상 주소(IPv4 또는 IPv6 형식)의 네트워크 마스크가 true입니다. 데이터 패킷이 넷마스크와 일치하면 조건식이 true입니다. 이 옵션은 src 및 dst와 함께 사용하여 소스 네트워크 주소 또는 대상 네트워크 주소(nt: src net net Mask 255.255.255.0 등)와 일치시킬 수도 있습니다. ) 이 옵션은 ipv6 네트워크 주소에는 유효하지 않습니다.
데이터 패킷의 소스 또는 대상 주소(IPv4 또는 IPv6 형식)의 네트워크 번호 필드에 있는 비트 수가 len과 동일한 경우 이면 해당 조건식이 true입니다. 이 옵션은 src before 및 dst와 함께 사용하여 소스 네트워크 주소 또는 대상 네트워크 주소(nt | rt | tt: src net net/24)를 일치시킬 수도 있습니다. 소스 주소는 24비트 패킷과 일치해야 합니다.
데이터가 패키지의 대상 포트인 경우(ip/tcp, ip/udp, ip6/tcp 또는 ip6/udp 프로토콜 포함) )가 포트이면 해당 조건식이 true입니다. 포트는 숫자 또는 이름일 수 있습니다(해당 이름은 /etc/services에서 찾을 수 있거나 관련 설명 정보는 man tcp 및 man udp를 통해 얻을 수 있습니다). 이름을 사용하는 경우 이름에 해당하는 포트 번호와 사용된 해당 프로토콜을 확인합니다. 숫자 포트 번호만 사용하는 경우 해당 포트 번호만 확인합니다(예: dst 포트 513). tcpdump가 tcp 프로토콜의 로그인 서비스와 udp 프로토콜의 who 서비스 패킷을 캡처하도록 하고, 포트 도메인은 tcpdump가 tcp 프로토콜 도메인 서비스 데이터 패킷 및 udp 프로토콜의 도메인 데이터 패킷을 캡처하도록 합니다. (nt | rt: 모호한 이름is 사용은 이해하기 어려워 보완 필요).
데이터 패킷의 소스 포트가 port이면 해당 조건식은 true입니다.
소스 또는 데이터 패킷의 대상 포트가 포트이면 해당 조건식이 true입니다.
데이터 패킷(ip/tcp, ip/udp, ip6/tcp 또는 ip6/udp 프로토콜 포함)이 대상인 경우 port가 port1에서 port2(port1, port2 포함)까지의 포트 범위에 속하면 해당 조건식이 true입니다. tcpdump는 port1과 port2를 구문 분석합니다. 포트 구문 분석은 일관됩니다(nt: dst 포트 포트 옵션 설명에 설명되어 있음).
데이터 패킷의 소스 포트가 port1부터 port2까지의 포트 범위(port1, port2 포함)에 속하면 해당 조건식은
데이터 패킷의 소스 포트 또는 대상 포트가 port1에서 port2까지의 포트 범위(port1, port2 포함)에 속하는 경우 해당 조건식이 true입니다.
이렇게 하면 tcpdump가 소스 포트가 포트인 tcp 패킷만 캡처하게 됩니다.
데이터 패킷의 길이가 길이보다 작거나 같은 경우 length에 해당하는 조건식이 true입니다. 이는 'len <= length'.
데이터 패킷의 길이가 길이보다 크거나 같으면 해당 조건식이 true입니다. 이는 'len >= length'.
데이터 패킷이 ipv4 데이터 패킷이고 해당 프로토콜 유형이 프로토콜인 경우 해당 조건식이 true입니다.
프로토콜은 icmp6, igmp, igrp(nt: Interior Gateway Routing)와 같이 숫자 또는 이름일 수 있습니다. 프로토콜, 내부 게이트웨이 라우팅 프로토콜), pim(Protocol Independent Multicast, 독립 멀티캐스트 프로토콜, 멀티캐스트 라우터에 적용), ah, esp(nt: ah, 인증 헤더, esp 보안 페이로드 캡슐화, 둘 다 IP에서 사용됩니다. 패킷의 보안 전송 메커니즘), vrrp(Virtual Router Redundancy Protocol, Virtual Router Redundancy Protocol), udp 또는 tcp. tcp, udp 및 icmp는 tcpdump의 키워드이므로 Escape(필요한 경우) 앞에 사용해야 합니다. C-셸에서 이스케이프하기 위해 \를 사용하는 경우) 이 표현식 요소는 데이터 패킷의 프로토콜 헤더 체인에 있는 모든 프로토콜 헤더 내용을 인쇄하지 않습니다(nt: 실제로는 지정된 프로토콜만 인쇄함). 예를 들어 tcpdump -i eth0 'ip proto tcp 및 호스트 192.168.3.144'를 사용할 수 있습니다. 그러면 호스트 192.168.3.144에서 보내거나 받는 데이터 패킷의 tcp만 다음과 같습니다. 프로토콜 헤더에 포함된 정보)
데이터 패킷이 ipv6 데이터 패킷이고 해당 프로토콜 유형이 프로토콜인 경우 해당 조건식이 true입니다.
이 표현식 요소에는 프로토콜이 포함되지 않습니다. 데이터 패킷 헤더 체인의 모든 프로토콜 헤더 내용이 인쇄됩니다
데이터 패킷이 ipv6 데이터 패킷이고 해당 프로토콜 체인에 프로토콜 유형의 프로토콜 헤더가 포함되어 있으면 해당 조건식이 true입니다. 예를 들어,
은 프로토콜 헤더 체인에 TCP 프로토콜 헤더가 있는 IPv6 패킷과 일치합니다. 이 패킷에는 인증 헤더, 라우팅 헤더 또는 홉 간 라우팅 옵션 헤더가 포함될 수도 있습니다.
이로 인해 트리거되는 해당 BPF(Berkeley Packets Filter, 데이터 링크 계층에서 패킷 필터링을 제공하는 메커니즘으로 이해될 수 있음) 코드는 상대적으로 번거롭고
BPF 최적화 코드는 실패했습니다.
은 ip6 프로토체인 프로토콜과 같은 의미이지만 IPv4 패킷에 사용됩니다.
패킷이 이더넷 브로드캐스트 패킷과 같습니다. 이에 해당하는 조건식은 true입니다. ether 키워드는 선택 사항입니다.
패킷이 IPv4 브로드캐스트 패킷인 경우 이에 해당하는 조건식은 true입니다. tcpdump가 브로드캐스트 주소가 모두 0과 모두 1인 일부 규칙을 준수하는지 확인하고 네트워크 인터페이스의 네트워크 마스크를 찾습니다(네트워크 인터페이스는 당시 패킷이 캡처되는 네트워크 인터페이스입니다). 패킷이 캡처된 네트워크 인터페이스의 네트워크 마스크가 불법이거나, 인터페이스에 해당 네트워크 주소와 네트워크가 전혀 설정되지 않았거나, 패킷이
] & 1의 의미는 다음과 같습니다. != 0'(nt: 이더넷 패킷의 숫자 1로 이해될 수 있습니다. 0바이트의 최하위 비트는 1이며 이는 멀티캐스트 패킷임을 의미합니다).ip 멀티캐스트
ip6 multicast
데이터 패킷이 다음 이더넷 프로토콜 유형에 속하는 경우 해당 조건식이 true입니다.
프로토콜 필드는 아래 나열된 숫자 또는 이름일 수 있습니다: ip, ip6, arp, rarp , atalk(AppleTalk 네트워크 프로토콜),
aarp(nt: AppleTalk 주소 확인 프로토콜, AppleTalk 네트워크의 주소 확인 프로토콜),
decnet(nt: DEC에서 제공하는 네트워크 프로토콜 스택), sca(nt: 알 수 없음, 필수 Supplement),
lat (Local Area Transport, 지역 전송 프로토콜, DEC에서 개발한 이더넷 호스트 상호 연결 프로토콜),
mopdl, moprc, iso(nt: 알 수 없음, 보완 필요), stp(Spanning Tree Protocol, 스패닝 트리 프로토콜)를 사용하여 사용할 수 있습니다. 네트워크의 링크 루프 방지),
ipx(nt: Internetwork Packet Exchange, Novell 네트워크에서 사용되는 네트워크 계층 프로토콜) 또는
netbeui(nt: NetBIOS 확장 사용자 인터페이스, 네트워크 기본 입력 및 출력 시스템으로 이해 가능) 인터페이스 확장)
mopdl, moprc, iso, stp, ipx, 또는 netbeui .
식별자도 키워드이므로 ''로 이스케이프해야 합니다.
및 IEEE 802.11 무선 LAN에서는(표현 메타 형식은 다음과 같을 수 있음) 'wlan 프로토콜 arp'), 프로토콜
식별자는 802.2 논리 링크 제어 계층 헤더,
in FDDI, 토큰 링 또는 에서 나옵니다. 802.1 헤더에는 이 논리 링크가 포함됩니다. 제어 계층 헤더입니다.
는 내부 이더넷을 식별함) 세그먼트 '로 0x000000이 있는 LLC 헤더만 확인합니다. SNAP 형식 구조 '의 프로토콜 ID 필드, OUI가 0x000000 'SNAP 형식
Structure'(nt: SNAP, SubNetwork)인 패킷에 세그먼트가 있는지 여부에 관계 없음 액세스 프로토콜, 서브넷 액세스 프로토콜) 다음 예외:
SSAP 도메인(소스 서비스 액세스 포인트)을 확인합니다. nt: iso 프로토콜을 알 수 없음, 추가 필요)
tcpdump는 LLC 헤더에서 대상 서비스 액세스 포인트(대상 서비스 액세스 포인트)를 확인합니다. ;
tcpdump는 'SNAP을 확인합니다. 0x080007이 OUI인 LLC 헤더의 형식 구조'를 확인하고 AppleTalk etype 필드를 확인합니다.
(nt: AppleTalk etype이 SNAP 형식 구조에 있는지 여부를 알 수 없음, 추가해야 함)
추가로 , 이더넷에서 ether proto 프로토콜 옵션의 경우 tcpdump는 다음 프로토콜을 제외하고 프로토콜에 지정된 프로토콜에 대해 이더넷 유형 필드(이더넷 유형 필드)를 확인합니다.
iso, stp 및 netbeui
tcpdump는 802를 확인합니다. .
3 물리적 프레임 및 LLC 헤더(이 두 검사는 FDDI, TR, 802.11 네트워크의 해당 검사와 일치함);(nt:
802.3, IEEE 802.3로 이해됨)은 모음입니다. 일련의 IEEE 표준 중 이 컬렉션은 유선 이더넷 네트워크의 물리적 계층과 데이터 링크 계층의 미디어 액세스 제어 하위 계층을 정의합니다. stp는 위에서 언급했습니다. 설명)
'SNAP 형식 구조'도 확인합니다(이 두 확인은 FDDI, TR,
802.11 네트워크의 해당 확인과 동일함). 일관성이 있습니다)
'SNAP 형식 구조 '에 존재하는 AppleTalk ARP etype 필드를 확인합니다. 후자의 경우 'SNAP 형식 구조 '의 OUI 식별자는 0x000000;
(nt: 802.2, 이는 논리적 링크 제어 계층(LLC)을 정의하는 IEEE802.2로 이해될 수 있음) ), 이는 OSI 네트워크 모델에서 데이터 링크 계층의 상위 부분에 해당합니다. LLC 계층은 데이터 링크 계층을 사용하는 사용자에게 통합 인터페이스를 제공합니다(일반적으로 사용자는 네트워크 계층임). 미디어 액세스. 제어 계층(nt: MAC 계층,
데이터 링크 계층의 하위 부분에 해당) 이 계층의 구현 및 작동 모드는 다양한 물리적 전송 매체(예: 이더넷, 토큰 링 네트워크,
광섬유)에 따라 달라집니다. 분산 데이터 인터페이스(nt: 실제로는 광섬유 네트워크로 이해될 수 있음), 무선 LAN(
802.11) 등)
'SNAP 형식 구조 ' (nt | rt: SNAP 프레임, '로 이해 가능) LLC 헤더의 SNAP 형식 구조'. 이 의미는 예비 이해 단계이므로 보완이 필요합니다.
(Digital Equipment Corporation에서 개발한 nt:decnet, 기계 상호 연결을 위한 PDP-
11 네트워크 프로토콜에서 처음 사용됨)
(nt:decnet은 위에서 설명했습니다)
(nt: decnet은 위에서 설명했습니다)
(이 옵션은 OpenBSD에서 pf 프로그램으로 표시된 패킷에 적용 가능합니다(nt: pf, OpenBSD의 방화벽 프로그램으로 이해될 수 있는 패킷 필터)
interface
(이 옵션은 OpenBSD의 pf 프로그램으로 표시된 패킷에만 적용됩니다(nt: pf, packet filter, can be OpenBSD에서는 방화벽 프로그램으로 이해))
fragment,
short, Normalize 및 memory입니다. (이 옵션은 OpenBSD에서 pf 프로그램으로 표시된 패키지에만 적용됩니다(nt: pf, 패킷 필터는 다음과 같이 이해될 수 있음). 방화벽 프로그램))
(이 옵션은 OpenBSD에서 pf 프로그램으로 표시된 패킷에만 적용됩니다(nt : pf, OpenBSD의 방화벽 프로그램으로 이해될 수 있는 패킷 필터))
해당 조건식이 true입니다. (이 옵션은 OpenBSD 표시 패킷(nt: pf, 패킷 필터)의 pf 프로그램에만 적용됩니다. ,
OpenBSD의 방화벽 프로그램으로 이해 가능))
(이 옵션은 OpenBSD에서 pf 프로그램으로 표시된 패킷에만 적용됩니다(nt: pf, 패킷 필터, OpenBSD 방화벽 프로그램으로 이해 가능))
ether proto p
p는 위 프로토콜 중 하나입니다.
ether proto p
p는 위 프로토콜 중 하나입니다. tcpdump는 현재 이러한 프로토콜을 분석할 수 없다는 점에 유의해야 합니다.
데이터 패킷이 IEEE802.1Q VLAN 데이터 패킷이면 해당 조건식이 true입니다.
(nt: IEEE802.1Q VLAN, 즉 IEEE802.1Q 가상 네트워크 프로토콜, 이 프로토콜은 다음 용도로 사용됩니다.
[vlan_id]를 지정하면 데이터에만 지정된 가상 네트워크 ID(vlan_id)가 포함되고 해당 조건식이 true가 됩니다.
VLAN 데이터 패킷의 경우 첫 번째 표현식에 있는 vlan 키워드는 표현식의 다음 키워드에 해당하는 데이터 패킷의 데이터 시작 위치(즉, 디코딩 오프셋)를 변경합니다. VLAN 네트워크 시스템에서 데이터 패킷을 필터링할 때 vlan [vlan_id] 표현식은 다음과 같습니다. 여러 번 사용됩니다. 키워드 vlan이 나타날 때마다
4바이트 필터 오프셋(nt: 필터 오프셋, 위의 디코딩 오프셋으로 이해될 수 있음)
100 && vlan 200 의미: VLAN100의 VLAN200 네트워크에 캡슐화된 데이터 패킷을 필터링합니다.
또 다른 예:
vlan && vlan
300 && ip 의미: VLAN300 네트워크에 캡슐화된 IPv4 데이터 패킷을 필터링하고 VLAN300 네트워크가 캡슐화됩니다. by an external VLAN
(nt: MPLS, Multi-Protocol Label Switch, Multi-protocol Label Switching을 사용하는 기술) 개방형 통신 네트워크에서 데이터 전송을 안내하는 레이블).
시작 위치를 변경합니다. MPLS 네트워크 시스템의 데이터 패킷에서 mpls [label_num] 표현식은 여러 번 사용될 수 있습니다. mpls 키워드가 나타날 때마다
4 바이트가 필터 Offset(nt: 필터 오프셋, 위의 디코딩으로 이해될 수 있음)
100000 && mpls 1024 의미: 외부 라벨이 100000이고 레이어 라벨이 1024인 패킷 필터링
1024 && 호스트 192.9. 200.1 의미: 192.
9.200.1과 주고받는 데이터 패킷을 필터링합니다. 데이터 패킷의 내부 레이블은 1024이고 외부 레이블이 있습니다.
이더넷 유형은 0x8863)이면 해당 조건식이 true입니다.
(nt: PPP-over-Ethernet, point-to-point 이더넷 베어러 프로토콜입니다. -포인트 연결 설정은 Discovery 단계(주소 검색)와
PPPoE 세션 설정 단계로 구분됩니다. Discovery 패킷은 첫 번째 단계에서 전송되는 패킷입니다. 이더넷 유형
은 이더넷 프레임에 적용되는 프로토콜을 나타내는 데 사용됩니다. 프레임 데이터 필드)
키워드
'를 검색하면 됩니다. PPP-over-Ethernet' 설명을 찾으려면) 해당 조건식이 true입니다.
는 다음을 의미합니다. PPPoE 패킷에 포함된 ipv4 패킷
의미는 다음 표현과 일치합니다.
ip proto p 또는 ip6 proto p
iso proto 프로토콜
데이터 패킷의 프로토콜 유형이 iso-osi 프로토콜 스택의 프로토콜이면 해당 조건식이 true입니다. (nt: [초기 솔루션. ] iso-osi 네트워크 모델의 각 레이어의 특정 프로토콜은 tcp/ip의 해당 레이어에서 사용되는 프로토콜과 다릅니다. iso-osi의 각 레이어의 특정 프로토콜은 별도로 보완해야 합니다.)
프로토콜은 다음과 같습니다. 숫자 또는 다음 이름 중 하나:
clnp, esis, isis
여기서 p는 위 프로토콜 중 하나
는 IS-IS PDU 유형의 약어입니다.
(nt: IS-IS PDU, 중간 시스템에서 중간 시스템까지의 프로토콜 데이터 단위, 중간 시스템에서
중간까지의 프로토콜 시스템 데이터 단위 OSI(Open Systems Interconnection) 네트워크는 최종 시스템과 중간 시스템으로 구성됩니다. 최종 시스템은 라우터를 의미하며, 최종 시스템은 라우터에 의해 형성된 로컬 그룹을 의미합니다. ) 및 여러 영역이
'domain'(도메인)을 형성합니다.IS-IS는 l1, l2, iih, lsp, snp, csnp, psnp 유형을 나타내는 도메인 내 또는 영역 내 라우팅을 제공합니다. PDU, 구체적인 의미 추가 필요)vpi n데이터 패킷이 ATM 데이터 패킷인 경우 해당 조건식이 true입니다. Solaris 운영 체제의 SunATM 장치의 경우 데이터 패킷이 ATM인 경우. 가상 경로 식별자는 n이고, 해당 조건식은 true입니다. (nt: ATM, Asychronous Transfer Mode. 이는 실제로 ITU-T(International Telecommunications Union Telecommunications Standardization Sector)에서 제안한 프로토콜로 이해될 수 있습니다. ) 및 TCP /A 일련의 프로토콜은 IP에서 동등한 IP 계층 기능을 가지며, 특정 프로토콜 수준은 별도로 보완되어야 합니다.)
데이터 패킷이 ATM 데이터 패킷이고 해당 가상 채널 ID가 n이면 해당 조건식이 true입니다.
(위에서 설명한 nt: ATM)
lane
llc
데이터 패킷이 ATM 패킷인 경우. , 그러면 해당 조건식이 true입니다. Solaris 운영 체제의 SunATM 장치의 경우
oamf4s
데이터 패킷이 ATM 데이터인 경우 Solaris 운영 체제의 SunATM 장치의 경우 데이터 패킷이 ATM 데이터 패킷
이고 세그먼트 OAM F4 셀(VPI=
3
)인 경우 해당 조건식이 true입니다. 그러면 해당 조건식이 참이 됩니다.
관리를 위해 생성된 ATM 셀 분류 방법.
전송 단위 ATM 네트워크에서 전송되는 데이터는 결국 고정된 길이(53바이트)의 셀로 분할됩니다. (초기 이해: 물리적 회선을 다중화하여 가상 경로(virtual 경로)를 형성할 수 있습니다. 그리고 가상 경로를 다시 재사용하여 가상 채널(
통신하는 두 당사자의 주소 지정 방법은 가상 경로 번호(VPI)/가상 채널 번호(VCI)입니다.
oamf4e데이터 패킷이 ATM 데이터 패킷이면 해당 조건식 공식은 true입니다. . Solaris 운영 체제의 SunATM 장치의 경우 패킷이 ATM 패킷이고 종단 간 OAM F4 셀(VPI=0
및 VCI=
oamf4s'로 검색하여 찾을 수 있습니다.)
oamf4데이터 패킷이 ATM 패킷인 경우 해당 조건식은 Solaris 운영 체제의 SunATM 장치의 경우 패킷이 ATM 패킷이고 종단 간 또는 세그먼트 OAM F4 셀인 경우(VPI=0 및 VCI=3 또는 VCI=입니다.
(nt: OAM 및 end-to-end OAM F4는 위에 설명되어 있으므로
' oamf4s'로 검색하여 찾을 수 있습니다.)
oam 패킷이 ATM 패킷인 경우 해당 조건식이 true입니다. Solaris 운영 체제의 SunATM 장치의 경우 패킷이 ATM 패킷이고 종단 간 또는 세그먼트 OAM F4 셀(VPI= 0 및 VCI=3 또는 VCI=
(nt: 이 옵션은 oamf4 중복과 동일하므로 확인 필요)
패킷이 ATM 패킷인 경우 해당 조건식이 true입니다. Solaris 운영 체제의 SunATM 장치의 경우 패킷이 ATM 패킷
이고 '메타 신호 라인 '에서 오는 경우입니다. (nt: VPI=0 및 VCI=1, '메타 신호 회로', 메타 신호 회로, 구체적인 의미는 알 수 없으므로 보완이 필요함),
는 이에 해당합니다. 조건부 표현식은 true입니다.
패킷이 ATM 패킷인 경우 해당 조건식이 true입니다. Solaris 운영 체제의 SunATM 장치의 경우 패킷이 ATM 패킷
이고 '브로드캐스트 신호 회로에서 온 경우입니다. '(nt: VPI=0 and VCI=2, '방송 신호 회로', 방송 신호 회로, 구체적인 의미는 알 수 없으므로 추가해야 함) ,
그러면 이에 해당하는 조건식이 true입니다.
데이터 패킷이 ATM 데이터 패킷이면 이에 해당하는 조건식이 true입니다. Solaris 운영 체제의 SunATM 장치의 경우 데이터 패킷이 ATM이면 데이터 패킷
' 신호 회로'(nt: VPI=0 및 VCI=5, '신호 라인'에서 옵니다. 신호 회로, 구체적인 의미는 알 수 없습니다. 추가),
그러면 이에 해당하는 조건식이 true입니다.
데이터 패킷이 ATM 데이터 패킷인 경우 Solaris 운영 체제의 SunATM 장치의 경우 데이터가 true입니다. 패킷은 ATM 패킷
이며 'ILMI 라인 '(nt: VPI=0 및 VCI=16, 'ILMI', It에서 제공됩니다.
SNMP(Simple Network Management Protocol) 기반의 네트워크 관리를 위한 인터페이스
라고 이해하시면 됩니다. 그러면 이에 해당하는 조건식이 참이 됩니다.
데이터 패킷이 ATM 데이터 패킷이라면 이에 해당하는 조건은 Solaris 운영 체제의 SunATM 장치의 경우 데이터 패킷이 ATM 패킷
이고 ' 신호 라인 '에서 나오며 Q.2931에 지정된 다음 메시지 중 하나인 경우 표현식은 참입니다. 프로토콜: Setup, Calling Proceeding, Connect,
Connect Ack, Release 또는 Release Done. 해당 조건식이 true입니다.
(nt: Q.2931는 ITU(International Telecommunications Union)에서 개발한 신호 프로토콜입니다. 광대역 통합 서비스 디지털 네트워크의 사용자 인터페이스 계층에서 네트워크 연결 설정, 유지 및 취소에 대한 관련 단계를 규정합니다.)
이고
' 메타 신호 라인 '에서 나오고 Q.2931 프로토콜에 지정된 다음 메시지인 경우: 설정, 호출 진행, 연결 ,Connect Ack, Release 또는 Release Done 그러면 해당 조건식은 true입니다.
relop은 >, <, <=, =, != 중 하나일 수 있습니다.
expr은 이 표현식에서 정수 상수를 사용할 수 있습니다. 표현은 표준 C와 일치합니다. ), 이진 연산자(+, -, *, /, &, |,
<<, >>), 길이 연산자 및 특정 패킷의 데이터에 대한 참조 연산자는 모든 비교 작업이 기본값이라는 점에 유의해야 합니다. 예를 들어
0x80000000
및 0xffffffff는 모두 0보다 큽니다(nt: 부호 있는 비교의 경우 보수 규칙에 따라 데이터를 인용하려는 경우 0xffffffff는 0보다 작습니다). 패킷에서 다음 표현식을 사용할 수 있습니다: proto [expr : size]
tcp, udp, icmp, ip6 또는 radio 중 하나일 수 있습니다. 해당 프로토콜 계층(ether, fddi, wlan,
tr, ppp, lip 및 link는 데이터 링크 계층에 해당, 라디오는 일부 데이터 패킷 "
에 첨부된 802.11(wlan, 무선 LAN)에 해당함) radio"헤더(nt: 전송 속도, 데이터 암호화 및 기타 정보를 설명함).
tcp 및 udp와 같은 상위 계층 프로토콜은 현재 네트워크 계층에만 적용될 수 있으며 IPv4 또는 IPv6 프로토콜을 사용하는 네트워크(이 제한은 tcpdump의 향후 버전에서 수정될 예정입니다.) 지정된 프로토콜의 필수 데이터에 대해 패킷 데이터의 오프셋 바이트는 위 표현식에서 expr
2 또는 4바이트일 수 있습니다. 기본값은 1바이트입니다. 길이 연산자의 키워드는 len입니다.이 코드는 전체 패킷의 길이입니다.
ip[0] & 0xf != 5 '는 옵션이 포함된 모든 IPv4 패킷을 가져오는 데 해당합니다. '
ip[6:2] & 0x1fff = 0'은 깨지지 않은 IPv4 패킷을 가져오는 데 해당하거나 조각 번호가 0인 조각난 IPv4 패킷을 가져옵니다. . 이 데이터 검사 방법은 tcp 및 udp 데이터에 대한 참조에도 적용됩니다. 즉, tcp[0
]는 중간 바이트에 해당하지 않고 TCP 헤더의 첫 번째 바이트에 해당합니다.
일부 오프셋 및 필드 값 숫자뿐 아니라 이름으로도 표현할 수 있습니다. 다음은 사용 가능한 일부 필드(프로토콜 헤더의 필드)의 이름입니다: icmptype(ICMP 프로토콜 헤더 참조) type 필드), icmpcode(ICMP 참조) 프로토콜 헤더 코드 필드) 및 tcpflags(TCP 프로토콜 헤더의 플래그 필드 참조)
icmp-echoreply, icmp-unreach , icmp -sourcequench, icmp-redirect, icmp-echo, icmp-routeradvert,
TCP 프로토콜 헤더의 플래그 필드에 사용 가능한 값은 tcp-fin, tcp-syn, tcp-rst, tcp-push,
tcp-ack, tcp-urg입니다.
프로그래밍 학습 코스
위 내용은 Linux 패킷 캡처 명령 tcpdump의 용도는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!