이름
tcpdump - 네트워크 트래픽 덤프
개요
tcpdump [ -adeflnNOpqRStuvxX ] [ -c 개수 ]
[ -C file_size ] [ -F file ]
[ -i 인터페이스 ] [ -m module ] [ -r file ]
[ -s snaplen ] [ -T type ] [ -U 사용자 ] [ -w file ]
[ -E algo : 비밀 ] [ 표현 ]
기술
Tcpdump 는 부울 식과 일치하는 네트워크 인터페이스에서 패킷의 헤더를 출력합니다. 나중에 분석 할 수 있도록 패킷 데이터를 파일에 저장하거나 -r 플래그를 사용하여 패킷을 읽지 않고 저장된 패킷 파일에서 읽도록하는 -w 플래그를 사용하여 실행할 수도 있습니다 네트워크 인터페이스에서. 모든 경우에, 표현식 과 일치 하는 패킷 만 tcpdump에 의해 처리됩니다.
Tcpdump 는 -c 플래그와 함께 실행되지 않으면 SIGINT 신호 (예 : 인터럽트 문자, 일반적으로 control-C를 입력하여 생성 됨) 또는 SIGTERM 신호 (일반적으로 kill (1) 명령); -c 플래그와 함께 실행되면 SIGINT 또는 SIGTERM 신호에 의해 인터럽트되거나 지정된 수의 패킷이 처리 될 때까지 패킷을 캡처합니다.
tcpdump 가 패킷 캡처를 끝내면 다음의 수를보고합니다.
패킷에 의해```필터에 의해 수신 됨 '(이 의미는 tcpdump를 실행하고있는 운영 체제에 따라 다르며, 아마도 OS가 구성된 방식에 따라 달라질 수 있습니다.) - 명령 행에 필터가 지정된 경우, 패킷이 필터 식과 일치하는지 여부에 관계없이 다른 운영 체제에서는 필터 식과 일치하고 tcpdump에 의해 처리 된 패킷 만 계산합니다.
패킷이``커널에 의해 삭제되었습니다 ''(이것은 버퍼 공간이 부족하여 tcpdump 가 실행중인 OS의 패킷 캡처 메커니즘에 의해 삭제 된 패킷의 수입니다. 그렇지 않은 경우 0으로보고됩니다.
대부분의 BSD와 같이 SIGINFO 신호를 지원하는 플랫폼에서는 SIGINFO 신호 (예 :``status ''문자를 입력하여 생성, 일반적으로 control-T로 생성)를 받았을 때 그 카운트를보고하고 패킷을 계속 캡처합니다 .
네트워크 인터페이스에서 패킷을 읽으려면 특별한 권한이 필요합니다.
NIT 또는 BPF가있는 SunOS 3.x 또는 4.x :
/ dev / nit 또는 / dev / bpf *에 대한 읽기 액세스 권한이 있어야합니다.
DLPI가있는 Solaris에서 :
/ dev / le 와 같은 네트워크 의사 장치에 대한 읽기 / 쓰기 액세스 권한이 있어야합니다. 그러나 Solaris의 일부 버전에서는 tcpdump 가 무차별 모드로 캡처하는 것을 허용하기에 충분하지 않습니다. 이러한 Solaris 버전에서는 무차별 모드로 캡처하려면 root이거나 tcpdump 를 setuid를 root로 설치해야합니다. 많은 (아마 모든) 인터페이스에서 무차별 모드로 캡처하지 않으면 나가는 패킷이 표시되지 않으므로 무차별 모드로 캡처하지 않으면 매우 유용하지 않을 수 있습니다.
DLPI가있는 HP-UX에서
사용자는 root 여야합니다. 그렇지 않으면 tcpdump 가 root로 setuid에 설치되어야합니다.
스눕 (snoop)이있는 IRIX에서 :
사용자는 root 여야합니다. 그렇지 않으면 tcpdump 가 root로 setuid에 설치되어야합니다.
Linux에서 :
사용자는 root 여야합니다. 그렇지 않으면 tcpdump 가 root로 setuid에 설치되어야합니다.
Ultrix 및 Digital UNIX / Tru64 UNIX에서 :
모든 사용자는 tcpdump로 네트워크 트래픽을 캡처 할 수 있습니다. 그러나 수퍼 유저가 pfconfig (8)를 사용하여 해당 인터페이스에서 무차별 모드 작업을 사용 가능하게 설정하지 않은 경우 사용자 (심지어 수퍼 유저조차도 아님)는 사용자 인터페이스에서 무차별 모드로 캡처 할 수 없으며 수퍼 유저조차 사용할 수 없습니다 )는 수퍼 유저가 pfconfig를 사용하여 해당 인터페이스에서 copy-all-mode 작업을 활성화하지 않은 경우 인터페이스에서 시스템이 수신하거나 인터페이스에서 보낸 유니 캐스트 트래픽을 캡처 할 수 있으므로 인터페이스에서 유용한 패킷 캡처는 무차별 모드 또는 사본 - all-mode 조작 또는 두 조작 모드가 해당 인터페이스에서 사용 가능하게 될 수 있습니다.
BSD에서 :
/ dev / bpf *에 대한 읽기 액세스 권한이 있어야합니다.
저장된 패킷 파일을 읽는 데는 특별한 권한이 필요하지 않습니다.
옵션
-에이
네트워크 및 브로드 캐스트 주소를 이름으로 변환하려고 시도합니다.
-기음
카운트 패킷을받은 후 종료하십시오.
-기음
원시 패킷을 저장 파일에 기록하기 전에 파일이 현재 file_size 보다 큰지 점검하고, 그렇다면 현재 저장 파일을 닫고 새 저장 파일을여십시오. 첫 x 째 savefile 이후의 Savefile은 -w 플래그로 지정된 이름을 가지며, 그 뒤에 숫자가 있으며, 2에서 시작하여 계속해서 위로 향합니다. file_size 의 단위는 수백만 바이트 (1,000,000 바이트가 아니라 1,048,576 바이트)입니다.
-디
사람이 읽을 수있는 형식으로 컴파일 된 패킷 일치 코드를 표준 출력으로 덤프하고 중지합니다.
-dd
패킷 매칭 코드를 C 프로그램 조각으로 덤프합니다.
-ddd
패킷 매칭 코드를 십진수 (갯수로 시작)로 덤프합니다.
-이자형
각 덤프 행에 링크 레벨 헤더를 인쇄하십시오.
-이자형
IPsec ESP 패킷을 해독하는 데 algo : secret 를 사용합니다. 알고리즘은 des-cbc , 3des-cbc , blowfish-cbc , rc3-cbc , cast128-cbc 또는 none이 될 수 있습니다. 기본값은 des-cbc 입니다. 패킷을 해독하는 기능은 tcpdump 가 암호화를 사용하도록 컴파일 된 경우에만 존재합니다. 비밀 ESP 비밀 키에 대한 아스키 텍스트. 현재로서는 임의의 2 진 값을 취할 수 없습니다. 이 옵션은 RFC2406 ESP가 아니라 RFC1827 ESP를 가정합니다. 이 옵션은 디버깅 목적으로 만 사용되며이 옵션을 진정한 '비밀'키와 함께 사용하는 것은 권장하지 않습니다. 명령 줄에 IPsec 비밀 키를 표시하면 ps (1) 및 다른 경우를 통해 다른 사람이 볼 수있게됩니다.
-에프
상징적 인 것보다 수치 적으로`외국의 '인터넷 주소를 출력하십시오 (이 옵션은 Sun의 yp 서버에서 심각한 뇌 손상을 피하기위한 것입니다. 보통 비 지역 인터넷 번호를 영원히 번역하지 않습니다).
-에프
파일 을 필터 식의 입력으로 사용하십시오. 명령 행에 주어진 추가 표현식은 무시됩니다.
-나는
인터페이스에서 들어보십시오. 지정하지 않으면 tcpdump 는 시스템 인터페이스 목록에서 가장 낮은 번호의 구성된 인터페이스 (루프백 제외)를 검색합니다. 가장 빠른 시합을 선택하면 연결 고리가 끊어집니다.
2.2 또는 그 이후 커널을 가진 리눅스 시스템에서,``any ''의 인터페이스 인자는 모든 인터페이스로부터의 패킷을 캡쳐하는데 사용될 수 있습니다. ``any ''디바이스의 캡처는 무차별 모드로 수행되지 않습니다.
-엘
stdout 행을 버퍼링하십시오. 캡처하는 동안 데이터를보고 싶을 때 유용합니다. 예를 들어,
``tcpdump -l | tee dat ''또는 'tcpdump -l> dat & tail -f dat' '.
-엠
파일 모듈 에서 SMI MIB 모듈 정의를로드하십시오. 이 옵션은 여러 MIB 모듈을 tcpdump 에로드하기 위해 여러 번 사용할 수 있습니다.
-엔
호스트 주소를 이름으로 변환하지 마십시오. 이것은 DNS 조회를 피하기 위해 사용될 수 있습니다.
-nn
프로토콜과 포트 번호 등을 이름으로 변환하지 마십시오.
-엔
호스트 이름의 도메인 이름 자격을 인쇄하지 마십시오. 예를 들어이 플래그를 주면 tcpdump 는``nic.ddn.mil ''대신에``nic ''을 출력 할 것입니다.
-영형
패킷 일치 코드 최적화 프로그램을 실행하지 마십시오. 이는 최적화 프로그램에서 버그가 의심 될 때만 유용합니다.
-피
인터페이스를 무차별 모드로 설정 하지 마십시오 . 다른 이유로 인터페이스가 무차별 모드 일 수 있습니다. 따라서`-p '는`ether host {local-hw-addr} 또는 ether broadcast'의 약어로 사용될 수 없다.
-큐
빠른 (조용한?) 출력. 더 적은 프로토콜 정보를 출력하여 출력 라인이 짧아집니다.
-아르 자형
ESP / AH 패킷이 이전 사양 (RFC1825에서 RFC1829)을 기반으로한다고 가정합니다. 지정하면 tcpdump 는 재생 방지 필드를 인쇄하지 않습니다. ESP / AH 스펙에는 프로토콜 버전 필드가 없기 때문에 tcpdump 는 ESP / AH 프로토콜의 버전을 추론 할 수 없습니다.
-아르 자형
파일 에서 패킷을 읽습니다 (-w 옵션으로 작성됨). 파일 이``- ''이면 표준 입력이 사용됩니다.
-에스
상대적이 아닌 TCP 시퀀스 번호를 인쇄하십시오.
-에스
Snarf는 기본값 인 68 대신에 각 패킷에서 데이터의 바이트 수를 결정합니다 (SunOS의 NIT를 사용하면 최소값은 실제로 96입니다). 68 바이트는 IP, ICMP, TCP 및 UDP에는 적합하지만 네임 서버 및 NFS 패킷 (아래 참조)에서 프로토콜 정보를 잘라낼 수 있습니다. 제한된 스냅 샷으로 인해 잘린 패킷은 출력에``[| proto ] ''이며, 여기서 proto 는 잘림이 발생한 프로토콜 수준의 이름입니다. 더 큰 스냅 샷을 사용하면 패킷을 처리하는 데 걸리는 시간이 늘어나고 효과적으로 패킷 버퍼링 양이 줄어 듭니다. 이로 인해 패킷이 손실 될 수 있습니다. snaplen 을 관심있는 프로토콜 정보를 포착 할 수있는 최소 숫자로 제한해야합니다. snaplen 을 0으로 설정하면 필수 길이를 사용하여 전체 패킷을 포착 할 수 있습니다.
-티
" 표현식 "에 의해 선택된 패킷을 지정된 유형 으로 해석합니다. 현재 알려진 유형은 cnfp (Cisco NetFlow 프로토콜), rpc (원격 프로 시저 호출), rtp (실시간 응용 프로그램 프로토콜), rtcp (실시간 응용 프로그램 제어 프로토콜), snmp (단순 네트워크 관리 프로토콜) ) 및 wb (분산 화이트 보드).
-티
각 덤프 행에 시간 소인을 인쇄 하지 마십시오 .
-tt
각 덤프 행에 형식화되지 않은 시간 소인을 인쇄하십시오.
-유
루트 권한을 삭제하고 사용자 ID를 사용자 및 그룹 ID로 변경하여 기본 사용자 그룹에 추가 합니다 .
노트! Red Hat Linux는 아무 것도 지정하지 않으면 자동으로 사용자``pcap ''에 권한을 삭제합니다.
-ttt
각 덤프 행의 현재 행과 이전 행 사이의 델타 (초 단위)를 인쇄하십시오.
-tttt
각 덤프 행의 날짜별로 진행되는 기본 형식의 시간 소인을 인쇄하십시오.
-유
undecoded NFS 핸들을 인쇄하십시오.
-V
(약간 더) 자세한 출력. 예를 들어 IP 패킷의 수명, 식별, 총 길이 및 옵션이 인쇄됩니다. 또한 IP 및 ICMP 헤더 체크섬 확인과 같은 추가 패킷 무결성 검사를 가능하게합니다.
-vv
더 자세한 출력. 예를 들어 추가 필드는 NFS 응답 패킷에서 인쇄되고 SMB 패킷은 완전히 디코딩됩니다.
-vvv
더 자세한 출력. 예를 들어 telnet SB ... SE 옵션이 모두 인쇄됩니다. -X 텔넷 옵션은 16 진수로 인쇄됩니다.
-w
원본 패킷을 파싱 및 인쇄하는 대신 파일에 기록하십시오. 나중에 -r 옵션을 사용하여 인쇄 할 수 있습니다. 파일 이``- ''이면 표준 출력이 사용됩니다.
-엑스
각 패킷 (링크 레벨 헤더 빼기)을 16 진수로 인쇄하십시오. 전체 패킷 또는 snaplen 바이트 중 더 작은 수가 인쇄됩니다. 이것은 전체 링크 레이어 패킷이므로, 패드 레이어 (예 : 이더넷)의 경우 상위 레이어 패킷이 필요한 패딩보다 짧은 경우 패딩 바이트도 인쇄됩니다.
-엑스
16 진수를 인쇄 할 때 ascii도 인쇄하십시오. 따라서 -x 가 설정되면 패킷은 16 진수 / ASCII로 인쇄됩니다. 이는 새로운 프로토콜을 분석 할 때 매우 편리합니다. -x 가 설정되어 있지 않더라도 일부 패킷의 일부는 16 진수 / ASCII로 인쇄 될 수 있습니다.
표현
어떤 패킷이 덤프 될지 선택합니다. 표현식 이 주어지지 않으면 그물에있는 모든 패킷이 덤프됩니다. 그렇지 않으면, 표현식 이 '참'인 패킷 만 덤프됩니다.
표현식 은 하나 이상의 프리미티브 로 구성됩니다 . 프리미티브는 대개 하나 이상의 한정자가 붙은 ID (이름 또는 번호)로 구성됩니다. 한정자에는 세 가지 종류가 있습니다.
유형
한정어는 ID 이름이나 숫자가 어떤 종류의 것을 가리키는 지 말합니다. 가능한 유형은 host , net 및 port 입니다. 예 :`host foo ',`net 128.3',`port 20 '. 형식 한정자가 없으면 호스트 가 사용됩니다.
지시
한정어는 id 와 / 또는 id 로의 특정 전송 방향을 지정합니다. 가능한 방향은 src , dst , src 또는 dst 및 src 및 dst 입니다. 예를 들어,`src foo ',`dst net 128.3',`src 또는 dst port ftp-data '. dir 한정자가 없으면 src 또는 dst 가 사용됩니다. 널 (null) 링크 계층 (예 : slip과 같은 point to point 프로토콜)의 경우 인바운드 및 아웃 바운드 한정자를 사용하여 원하는 방향을 지정할 수 있습니다.
프로토
한정어는 일치를 특정 프로토콜로 제한합니다. 가능한 프로토 타입은 ether , fddi , tr , ip , ip6 , arp , rarp , decnet , tcp 및 udp 입니다. 예 :`ether src foo ',`arp net 128.3',`tcp port 21 '. 프로토콜 한정자가 없으면 유형과 일치하는 모든 프로토콜이 사용됩니다. 예를 들어`src foo '는`(ip 또는 arp or rarp) src foo'를 의미하며`net bar '는`(ip or arp or rarp) net bar'를 의미하고`port 53 '는 `(tcp 또는 udp) 포트 53 '.
[`fddi '는 실제로`ether'의 별칭입니다; 파서는 "지정된 네트워크 인터페이스에서 사용되는 데이터 링크 레벨"을 의미하는 것으로 취급합니다. FDDI 헤더는 이더넷과 같은 소스 및 대상 주소를 포함하며 이더넷 형식 패킷 유형을 포함하기 때문에 이러한 FDDI 필드를 필터링 할 수 있습니다 유사한 이더넷 필드와 마찬가지입니다. FDDI 헤더에는 다른 필드도 포함되어 있지만 필터 표현식에 명시 적으로 지정할 수는 없습니다.
비슷하게,`tr '은`ether'의 별칭입니다; FDDI 헤더에 관한 이전 단락의 내용은 토큰 링 헤더에도 적용됩니다.]
위의 것 외에도 패턴을 따르지 않는 특별한 원시 키워드가 있습니다 ( 게이트웨이 , 브로드 캐스트 , 덜 작음 및 더 많은 산술 표현식). 이들 모두는 아래에 설명되어 있습니다.
더 복잡한 필터 표현식은 단어 와 , and 및 or 를 사용하여 프리미티브를 결합합니다. 예 :`호스트 foo. 포트 ftp가 아닌 포트 ftp-data '. 타이핑을 줄이기 위해 동일한 한정자 목록을 생략 할 수 있습니다. 예를 들어`tcp dst port ftp 또는 ftp-data or domain '은`tcp dst port ftp 또는 tcp dst port ftp-data 또는 tcp dst port domain'과 정확히 동일합니다.
허용 가능한 프리미티브는 다음과 같습니다.
dst 호스트 호스트
패킷의 IPv4 / v6 대상 필드가 주소이거나 이름 일 수있는 호스트 인 경우 true입니다.
src 호스트 호스트
패킷의 IPv4 / v6 소스 필드가 호스트 이면 참입니다.
호스트 호스트
패킷의 IPv4 / v6 원본 또는 대상이 호스트 인 경우 True입니다. 위의 호스트 표현식 중 임의의 키워드 앞에 ip , arp , rarp 또는 ip6 키워드를 붙일 수 있습니다.
ip 호스트 호스트이는 다음과 같습니다.
ether proto \ ip 와 호스트 호스트호스트 가 여러 IP 주소를 가진 이름 인 경우 각 주소가 일치하는지 검사됩니다.
에테르 dst에 호스트
이더넷 대상 주소가 ehost 이면 true 입니다. Ehost 는 / etc / ethers의 이름이거나 숫자 (숫자 형식의 경우 ethers (3N) 참조) 일 수 있습니다.
이더넷 src에 호스트
이더넷 소스 주소가 ehost 이면 true 입니다.
에테르 호스트 ehost
이더넷 소스 또는 대상 주소가 ehost 이면 참 입니다.
게이트웨이 호스트
패킷이 호스트 를 게이트웨이로 사용하면 참입니다. 즉, 이더넷 소스 또는 대상 주소가 호스트 이지만 IP 소스 나 IP 대상 모두 호스트 가 아닙니다. 호스트 는 이름이어야하며 시스템의 호스트 이름 - IP 주소 확인 메커니즘 (호스트 이름 파일, DNS, NIS 등)과 시스템의 호스트 이름 - 이더넷 주소 해석에 의해 모두 발견되어야합니다 메커니즘 (/ etc / ethers 등). (동일한 표현식은
ether 호스트 ehost 가 아니라 호스트 호스트host / ehost의 이름이나 번호와 함께 사용할 수 있습니다.)이 구문은 현재 IPv6 사용 구성에서는 작동하지 않습니다.
DNS 넷
패킷의 IPv4 / v6 대상 주소에 net 의 네트워크 번호가 있으면 true입니다. Net 은 / etc / networks의 이름이거나 네트워크 번호입니다 (자세한 내용은 networks (4) 참조).
src net net
패킷의 IPv4 / v6 원본 주소에 net 의 네트워크 번호가 있으면 true입니다.
그물망
패킷의 IPv4 / v6 원본 또는 대상 주소에 net 의 네트워크 번호가 있으면 참입니다.
net net mask netmask
IP 주소가 특정 netmask 와 net 이 일치하면 참입니다. src 또는 dst 로 규정 할 수 있습니다. 이 구문은 IPv6 net 에는 유효하지 않습니다.
net net / len
IPv4 / v6 주소가 net 와 len 비트만큼 일치하는 경우 true입니다. src 또는 dst 로 규정 할 수 있습니다.
dst 포트 포트
패킷이 ip / tcp, ip / udp, ip6 / tcp 또는 ip6 / udp이고 대상 포트 값이 port 인 경우 true입니다. 포트 는 / etc / services에서 사용되는 숫자 또는 이름이 될 수 있습니다 ( tcp (4P) 및 udp (4P) 참조). 이름이 사용되면 포트 x 호와 프로토콜이 모두 점검됩니다. 숫자 또는 모호한 이름이 사용되면 포트 번호 만 검사됩니다 (예 : dst 포트 513 은 tcp / login 트래픽과 udp / who 트래픽을 모두 인쇄하고 port 도메인 은 tcp / domain 및 udp / domain 트래픽을 모두 인쇄합니다).
src 포트 포트
패킷의 소스 포트 값이 port 이면 true입니다.
포트 포트
패킷의 소스 또는 대상 포트가 포트이면 참입니다. 위의 포트 표현식은 다음과 같이 키워드 tcp 또는 udp를 앞에 붙일 수 있습니다.
tcp src 포트 포트소스 포트가 port 인 tcp 패킷과 만 일치합니다.
길이가 짧다.
패킷의 길이가 길이보다 작거나 같은 경우 true입니다. 이것은 다음과 같습니다.
len <= 길이더 긴 길이
패킷의 길이가 길이보다 크거나 같으면 true입니다. 이것은 다음과 같습니다.
len> = 길이 .IP 프로토 프로토콜
패킷이 프로토콜 유형 프로토콜 의 IP 패킷 ( ip (4P) 참조)이면 true입니다. Protocol 은 숫자 또는 icmp , icmp6 , igmp , igrp , pim , ah , esp , vrrp , udp 또는 tcp 중 하나 일 수 있습니다. 식별자 tcp , udp 및 icmp 는 키워드이기도하고 C 쉘에서 백 슬래시 (\) (\)를 통해 이스케이프해야합니다. 이 프리미티브는 프로토콜 헤더 체인을 추적하지 않는다.
ip6 프로토 프로토콜
패킷이 프로토콜 유형 프로토콜 의 IPv6 패킷이면 true입니다. 이 프리미티브는 프로토콜 헤더 체인을 추적하지 않는다.
ip6 프로토콜
패킷이 IPv6 패킷 인 경우 참이며 프로토콜 헤더 체인에 프로토콜 유형이있는 프로토콜 헤더를 포함합니다. 예를 들어,
ip6 protochain 6모든 IPv6 패킷을 프로토콜 헤더 체인의 TCP 프로토콜 헤더와 일치시킵니다. 패킷은 IPv6 헤더와 TCP 헤더 사이에 인증 헤더, 라우팅 헤더 또는 hop-by-hop 옵션 헤더를 포함 할 수 있습니다. 이 프리미티브에 의해 생성 된 BPF 코드는 복잡하며 tcpdump의 BPF 옵티 마이저 코드로 최적화 할 수 없으므로 다소 느릴 수 있습니다.
IP protochain 프로토콜
ip6 protochain 프로토콜 과 동일하지만 IPv4 용입니다.
에테르 방송
패킷이 이더넷 브로드 캐스트 패킷이면 true입니다. ether 키워드는 선택 사항입니다.
IP 방송
패킷이 IP 브로드 캐스트 패킷이면 true입니다. all-zeroes 및 all-ones 브로드 캐스트 규칙을 확인하고 로컬 서브넷 마스크를 조회합니다.
에테르 멀티 캐스트
패킷이 이더넷 멀티 캐스트 패킷이면 true입니다. ether 키워드는 선택 사항입니다. 이것은` ether [0] & 1! = 0 '의 줄임말이다.
IP 멀티 캐스트
패킷이 IP 멀티 캐스트 패킷이면 true입니다.
ip6 multicast
패킷이 IPv6 멀티 캐스트 패킷이면 true입니다.
에테르 프로토 프로토콜
패킷이 ether 형 프로토콜 의 경우는 true 프로토콜 은 ip , ip6 , arp , rarp , atalk , aarp , decnet , sca , lat , mopdl , moprc , iso , stp , ipx 또는 netbeui 중 하나 일 수 있습니다. 이러한 식별자는 키워드이기도하므로 백 슬래시 (\)를 통해 이스케이프해야합니다.
[FDDI (예 :` fddi protocol arp ')와 토큰 링 (` tr protocol arp ')의 경우 대부분의 프로토콜에서 프로토콜 식별은 802.2 논리 링크 제어 (LLC) 헤더에서 유래합니다. FDDI 또는 토큰 링 헤더 맨 위에 일반적으로 계층화되어 있습니다.
FDDI 또는 토큰 링에서 대부분의 프로토콜 식별자를 필터링 할 때 tcpdump 는 캡슐화 된 이더넷의 OUI (Organizational Unit Identifier)가 0x000000 인 소위 SNAP 형식의 LLC 헤더의 프로토콜 ID 필드 만 검사합니다. OUI가 0x000000 인 SNAP 형식인지 여부는 확인하지 않습니다.
예외는 iso입니다. iso 는 LLC 헤더의 DSAP (대상 서비스 액세스 지점) 및 SSAP (소스 서비스 액세스 지점) 필드, stp 및 netbeui , LLC 헤더의 DSAP을 확인하고 atalk 은 어디에 있는지 검사합니다 0x080007의 OUI 및 Appletalk etype을 사용하여 SNAP 형식의 패킷을 확인합니다.
이더넷의 경우, tcpdump 는 대부분의 프로토콜에 대해 이더넷 유형 필드를 검사합니다. 예외는 iso , sap 및 netbeui 이며, 802.3 프레임을 확인한 다음 FDDI 및 Token Ring과 마찬가지로 LLC 헤더를 확인합니다. atalk 는 이더넷 프레임의 Appletalk etype과 FDDI 및 토큰 링, aarp에 대한 SNAP 형식 패킷과 마찬가지로 OUI가 0x000000 인 이더넷 프레임 또는 802.2 SNAP 프레임과 IPX에서 IPX etype을 확인하는 Appletalk ARP etype을 확인합니다 이더넷 프레임, LLC 헤더의 IPX DSAP, IPX의 LLC 헤더 캡슐화가없는 802.3 및 SNAP 프레임의 IPX etype.]
decnet src 호스트
DECNET 소스 주소가 "10.123"형식의 주소 또는 DECNET 호스트 이름 일 수있는 호스트 인 경우 참입니다. [DECNET 호스트 이름 지원은 DECNET을 실행하도록 구성된 Ultrix 시스템에서만 사용할 수 있습니다.]
decnet dst host
DECNET 대상 주소가 host 이면 참입니다.
데넷 호스트 호스트
DECNET 소스 또는 대상 주소가 호스트 이면 참입니다.
ip , ip6 , arp , rarp , atalk , aarp , decnet , iso , stp , ipx , netbeui
약어 :
에테르 프로토여기서 p 는 위의 프로토콜 중 하나입니다.
위도 , moprc , mopdl
약어 :
에테르 프로토여기서 p 는 위의 프로토콜 중 하나입니다. tcpdump 는 현재 이러한 프로토콜을 구문 분석하는 방법을 알지 못합니다.
vlan [vlan_id]
패킷이 IEEE 802.1Q VLAN 패킷이면 true입니다. [vlan_id] 가 지정되면 패킷에 vlan_id 가 지정된 것만 true입니다. 표현식 에서 발견 된 첫 번째 vlan 키워드는 패킷이 VLAN 패킷이라는 가정하에 나머지 표현식 에 대한 디코딩 오프셋을 변경합니다.
tcp , udp , icmp
약어 :
ip proto p 또는 ip6 proto p여기서 p 는 위의 프로토콜 중 하나입니다.
이소 프로토콜 프로토콜
패킷이 프로토콜 유형 프로토콜 의 OSI 패킷이면 true입니다. Protocol 은 clnp , esis 또는 isis 이름 중 하나 일 수 있습니다.
clnp , esis , isis
약어 :
iso proto p여기서 p 는 위의 프로토콜 중 하나입니다. tcpdump 는 이러한 프로토콜을 파싱하는 불완전한 작업을합니다.
expr relop expr
Relop 이>, <=> , <=, = ,! = 중 하나 인 관계가 성립하면 참이며, expr 은 정수 상수 (표준 C 구문으로 표현됨), 일반 이진 연산자 [+ , -, *, /, &, |, 길이 연산자 및 특수 패킷 데이터 접근자를 포함합니다. 패킷 내부의 데이터에 액세스하려면 다음 구문을 사용하십시오.
proto [ expr : 크기 ]Proto 는 ether, fddi, tr, ppp, slip, link, ip, arp, rarp, tcp, udp, icmp 또는 ip6 중 하나이며 인덱스 작업을위한 프로토콜 계층을 나타냅니다. ( ether, fddi, tr, ppp, slip 및 link는 모두 링크 계층을 참조합니다.) tcp, udp 및 기타 상위 계층 프로토콜 유형은 IPv6이 아닌 IPv4에만 적용됩니다 (향후 수정 예정). 표시된 프로토콜 계층을 기준으로 한 바이트 오프셋은 expr에 의해 제공됩니다. 크기 는 선택 사항이며 관심 분야의 바이트 수를 나타냅니다. 1, 2 또는 4 일 수 있으며 기본값은 1입니다. len 키워드로 표시되는 길이 연산자는 패킷의 길이를 제공합니다.
예를 들어, ' ether [0] & 1! = 0 '은 모든 멀티 캐스트 트래픽을 포착합니다. 표현식` ip [0] & 0xf! = 5 '는 옵션이있는 모든 IP 패킷을 포착합니다. 표현` ip [6 : 2] & 0x1fff = 0 '은 단편화되지 않은 데이터 그램과 단편화 된 데이터 그램의 단점을 포착합니다. 이 검사는 tcp 및 udp 색인 작업에 암시 적으로 적용됩니다. 예를 들어, tcp [0]은 항상 TCP 헤더 의 첫 번째 바이트를 의미하며 중간에있는 조각의 첫 번째 바이트를 의미하지 않습니다.
일부 오프셋 및 필드 값은 숫자 값이 아닌 이름으로 표현 될 수 있습니다. icmptype (ICMP 유형 필드), ICMP 코드 (ICMP 코드 필드) 및 tcpflags (TCP 플래그 필드)와 같은 프로토콜 헤더 필드 오프셋을 사용할 수 있습니다.
icmp-echoreply , icmp-unreach , icmp-sourcequench , icmp-redirect , icmp-echo , icmp-routeradvert , icmp-routersolicit , icmp-timxceed , icmp-paramprob , icmp-tstamp , icmp와 같은 ICMP 유형 필드 값을 사용할 수 있습니다. -stamp , icmp-ireq , icmp-ireqreply , icmp-maskreq , icmp-maskreply .
다음 TCP 플래그 필드 값을 사용할 수 있습니다 : tcp-fin , tcp-syn , tcp-rst , tcp-push , tcp-push , tcp-ack , tcp-urg .
프리미티브는 다음을 사용하여 결합 될 수 있습니다.
괄호로 묶은 프리미티브 및 연산자 그룹 (괄호는 셸에만 적용되므로 이스케이프 처리해야 함).
부정 (` ! '또는` not ').
연결 (` && '또는` and ').
대체 (` || '또는` or ').
부정은 우선 순위가 가장 높습니다. 교대와 연결은 우선 순위가 같고 왼쪽에서 오른쪽으로 연결됩니다. 병렬 연결이 아닌 명시 적 및 토큰이 연결에 필요합니다.
식별자없이 키워드가 주어지면, 가장 최근의 키워드로 간주됩니다. 예를 들어,
호스트 대 에이스가 아니다.짧다.
호스트 대 호스트가 아닌 호스트 에이스그것은 혼동해서는 안된다.
not (호스트 대 에이스)표현식 인수는 tcpdump 에 단일 인수 또는 다중 인수 중 더 편리하게 전달 될 수 있습니다. 일반적으로 표현식에 쉘 메타 문자가 포함되어 있으면이를 따옴표 붙은 단일 인수로 전달하는 것이 더 쉽습니다. 여러 인수는 구문 분석되기 전에 공백으로 연결됩니다.
사용 예
일몰에 도착하거나 출발하는 모든 패킷을 인쇄하려면 :
tcpdump 호스트 일몰helios 와 hot 또는 ace 사이의 트래픽을 인쇄하려면 다음을 수행하십시오.
tcpdump 호스트 helios 및 \ (핫 또는 에이스)에이스 와 helios를 제외한 모든 호스트간에 모든 IP 패킷을 인쇄하려면 다음을 수행하십시오.
tcpdump IP 호스트 에이스가 아니라 헬리오스버클리에서 로컬 호스트와 호스트 간의 모든 트래픽을 인쇄하려면 다음을 수행하십시오.
tcpdump net ucb-ether인터넷 게이트웨이 snup을 통해 모든 ftp 트래픽을 출력하려면 다음과 같이하십시오 (셸이 괄호를 잘못 해석하는 것을 방지하기 위해 표현식이 인용되어 있음에 유의하십시오).
tcpdump '게이트웨이 snup 및 (포트 ftp 또는 ftp-data)'로컬 호스트에서 출처도 트래픽도 출력하지 않으려면 (다른 하나의 게이트웨이로가는 경우 로컬 네트워크에 연결해서는 안됩니다).
tcpdump ip 및 net net이 아님로컬이 아닌 호스트가 관련된 각 TCP 대화의 시작 및 끝 패킷 (SYN 및 FIN 패킷)을 인쇄합니다.
tcpdump 'tcp [tcpflags] & (tcp-syn | tcp-fin)! = 0이 아니라 src 및 dst net localnet '게이트웨이 snup을 통해 전송 된 576 바이트보다 긴 IP 패킷을 인쇄하려면 다음을 수행하십시오 .
tcpdump '게이트웨이 snup 및 ip [2 : 2]> 576'이더넷 브로드 캐스트 또는 멀티 캐스트를 통해 전송 되지 않은 IP 브로드 캐스트 또는 멀티 캐스트 패킷을 인쇄하려면 다음을 수행하십시오.
tcpdump 'ether [0] & 1 = 0 and ip [16]> = 224'에코 요청 / 응답이 아닌 모든 ICMP 패킷을 인쇄하려면 (즉, 패킷을 핑하지 않음) :
tcpdump 'icmp [icmptype]! = icmp-echo와 icmp [icmptype]! = icmp-echoreply'출력 형식
tcpdump 의 출력은 프로토콜에 따라 다릅니다. 다음은 대부분의 형식에 대한 간단한 설명과 예제를 제공합니다.
링크 레벨 헤더
'-e'옵션이 주어지면, 링크 레벨 헤더가 출력됩니다. 이더 넷에서는 소스 및 대상 주소, 프로토콜 및 패킷 길이가 인쇄됩니다.
FDDI 네트워크에서 '-e'옵션은 tcpdump 가`프레임 제어 '필드, 출발지와 목적지 주소, 그리고 패킷 길이를 출력하게합니다. ( '프레임 제어'필드는 나머지 패킷의 해석을 제어합니다 .IP 데이터 그램을 포함하는 패킷과 같은 일반 패킷은 우선 순위 값이 0과 7 사이 인 'async'패킷입니다 (예 : ' async4 '). 패킷은 802.2 논리 링크 제어 (LLC) 패킷을 포함한다고 가정하고, LLC 헤더가 ISO 데이터 그램 또는 소위 SNAP 패킷이 아닌 경우 인쇄됩니다.
토큰 링 네트워크에서 '-e'옵션을 사용하면 tcpdump 가 '액세스 제어'및 '프레임 제어'필드, 원본 및 대상 주소 및 패킷 길이를 인쇄합니다. FDDI 네트워크 에서처럼 패킷은 LLC 패킷을 포함한다고 가정합니다. '-e'옵션이 지정되었는지 여부에 관계없이 원본 라우팅 정보는 원본 라우팅 패킷에 대해 인쇄됩니다.
(주의 : 다음 설명은 RFC-1144에 설명 된 SLIP 압축 알고리즘에 익숙하다고 가정합니다.)
SLIP 링크에서 방향 표시기 (인바운드의 경우 I, 아웃 바운드의 경우 O), 패킷 유형 및 압축 정보가 인쇄됩니다. 패킷 유형이 먼저 인쇄됩니다. 세 가지 유형은 ip , utcp 및 ctcp 입니다. ip 패킷에 대한 추가 링크 정보는 인쇄되지 않습니다. TCP 패킷의 경우 연결 식별자가 유형 다음에 인쇄됩니다. 패킷이 압축되면 인코딩 된 헤더가 인쇄됩니다. 특수한 경우는 * S + n 및 * SA + n 으로 인쇄됩니다. 여기서 n 은 순차 번호 (또는 순차 번호와 ack)가 변경된 양입니다. 특수한 경우가 아니면 0 개 이상의 변경 사항이 인쇄됩니다. 변경은 U (긴급 포인터), W (창), A (확인), S (시퀀스 번호) 및 I (패킷 ID) 다음에 델타 (+ n 또는 -n) 또는 새 값 (= n). 마지막으로 패킷의 데이터 양과 압축 된 머리글 길이가 인쇄됩니다.
예를 들어, 다음 행은 암시 적 연결 식별자가있는 아웃 Y 운드 압축 TCP 패킷을 표시합니다. ack는 6, 시퀀스 번호는 49, 패킷 ID는 6으로 변경되었습니다. 3 바이트의 데이터와 6 바이트의 압축 된 헤더가 있습니다.
O ctcp * A + 6 S + 49 I + 6 3 (6)ARP / RARP 패킷
Arp / rarp 출력은 요청 유형과 그 인수를 표시합니다. 이 형식은 자명하다. 다음은 호스트 rtsg 에서 호스트 csam 까지의 'rlogin'의 시작에서 취한 짧은 샘플입니다.
arp who-csam은 rtsg arp reply csam에게 CSAM을 알려줍니다.첫 번째 라인은 rtsg가 인터넷 호스트 csam의 이더넷 주소를 묻는 ARP 패킷을 보냈다는 것입니다. Csam은 이더넷 주소로 응답합니다 (이 예제에서 이더넷 주소는 대문자와 소문자로 된 인터넷 주소입니다).
우리가 tcpdump -n을 수행했다면 이것은 덜 불필요 해 보인다.
arp who-has 128.3.254.6 128.3.254.68 ARP 답장 128.3.254.6에 02 : 07 : 01 : 00 : 01 : c4라고 말하십시오.tcpdump -e를 수행했다면 첫 번째 패킷이 브로드 캐스트이고 두 번째 패킷이 지점 간 (point-to-point)이라는 사실이 표시됩니다.
RTSG 브로드 캐스트 0806 64 : arp who-csam tell rtsg CSAM RTSG 0806 64 : arp reply csam is at CSAM첫 번째 패킷의 경우 이더넷 소스 주소는 RTSG이고 대상은 이더넷 브로드 캐스트 주소이고 유형 필드는 16 진수 0806 (ETHER_ARP 유형)이며 총 길이는 64 바이트입니다.
TCP 패킷
(주의 : 다음 설명은 RFC-793에 설명 된 TCP 프로토콜에 익숙하다고 가정합니다. 프로토콜에 익숙하지 않은 경우이 설명이나 tcpdump 는별로 유용 하지 않습니다 .)
tcp 프로토콜 라인의 일반적인 형식은 다음과 같습니다.
src> dst : flags data-seqno ack 창 긴급 옵션 Src 및 dst 는 소스 및 대상 IP 주소 및 포트입니다. 플래그 는 S (SYN), F (FIN), P (PUSH) 또는 R (RST) 또는 단일 '.' 플래그 의 일부 조합입니다. (플래그 없음). Data-seqno 는이 패킷의 데이터가 포함하는 시퀀스 공간의 일부를 설명합니다 (아래 예 참조). Ack 는이 연결에서 다른 방향으로 예상되는 다음 데이터의 시퀀스 번호입니다. Window 는이 연결에서 다른 방향으로 사용할 수있는 수신 버퍼 공간의 바이트 수입니다. Urg 는 패킷에 '긴급한'데이터가 있음을 나타냅니다. 옵션 은 꺽쇠 괄호로 묶인 tcp 옵션입니다 (예 :
Src, dst 및 플래그 는 항상 존재합니다. 다른 필드는 패킷의 TCP 프로토콜 헤더의 내용에 따라 다르며 적절한 경우에만 출력됩니다.
다음은 호스트 rtsg 에서 호스트 csam 까지의 rlogin의 시작 부분입니다.
rtsg.1023> csam.login : S 768512 : 768512 (0) 4096첫 번째 줄은 rtsg의 tcp 포트 1023이 csam의 포트 로그인 에 패킷을 보냈다는 것입니다. S 는 SYN 플래그가 설정되었음을 나타냅니다. 패킷 시퀀스 번호는 768512이고 데이터가 없습니다. (표기법은 'first : last (nbytes)'이며 이는 ' nbytes bytes of user data'인 마지막부터 마지막 까지 포함하지 않는 시퀀스 번호를 의미합니다.) 피기 백 ack가 없으며 사용 가능한 수신 창은 4096 바이트이고 1024 바이트의 mss를 요청하는 max-segment-size 옵션이있었습니다.
Csam은 rtsg의 SYN에 대해 piggy-backed ack를 포함한다는 점을 제외하면 비슷한 패킷으로 응답합니다. 그런 다음 Rtsg는 csam의 SYN을 확인합니다. `. ' 플래그가 설정되지 않았 음을 의미합니다. 패킷에 데이터가 없으므로 데이터 시퀀스 번호가 없습니다. 확인 시퀀스 번호는 작은 정수 (1)입니다. tcpdump 는 tcp`conversation '을 처음으로 보았을 때 패킷의 시퀀스 번호를 출력합니다. 대화의 후속 패킷에서 현재 패킷의 시퀀스 번호와이 초기 시퀀스 번호 간의 차이가 인쇄됩니다. 즉, 첫 번째 바이트 이후의 시퀀스 번호는 대화의 데이터 스트림에서 상대적인 바이트 위치로 해석 될 수 있습니다 (첫 번째 데이터 바이트는 각 방향이 '1'임). `-S '는이 기능을 오버라이드 (override) 해 원래의 순서 번호를 출력합니다.
6 번째 줄에서 rtsg는 csam에 19 바이트의 데이터 (rtsg -> csam 쪽에서 바이트 2에서 20까지)를 보냅니다. PUSH 플래그가 패킷에 설정됩니다. 일곱 번째 줄에서 csam은 rtsg에 의해 바이트 21까지 포함하여 수신 된 데이터를 수신했다고 말합니다.이 데이터의 대부분은 csam의 수신 창이 19 바이트 작아 졌기 때문에 분명히 소켓 버퍼에 있습니다. 또한 Csam은이 패킷에서 1 바이트의 데이터를 rtsg로 전송합니다. 8 번째 줄과 9 번째 줄에서 csam은 rtsg에 2 바이트의 긴급 푸시 된 데이터를 보냅니다.
스냅 샷이 작아서 tcpdump 가 전체 TCP 헤더를 포착하지 못하면 가능한 한 많은 헤더를 해석 한 다음``[| tcp ] ''를 사용하여 나머지를 해석 할 수 없음을 나타냅니다. 헤더에 가짜 옵션 (길이가 너무 작거나 헤더의 끝을 초과하는 옵션)이 있으면 tcpdump 는이를``[ 나쁜 선택 ] ''으로보고하고 더 이상의 옵션을 해석하지 않습니다. 어디에서 시작하는지). 헤더 길이가 옵션이 있지만 IP 데이터 그램 길이가 실제로 옵션이 존재할만큼 길지 않다면 tcpdump 는 그것을``[ bad hdr length ] ''라고보고합니다.
특정 플래그 조합 (SYN-ACK, URG-ACK 등)을 사용하여 TCP 패킷 캡처
TCP 헤더의 제어 비트 섹션에는 8 비트가 있습니다.
CWR | ECE | URG | ACK | PSH | RST | SYN | 지느러미
TCP 연결을 설정하는 데 사용되는 패킷을 보려고한다고 가정 해 봅시다. 새로운 연결을 초기화 할 때 TCP는 3 방향 핸드 셰이크 프로토콜을 사용합니다. TCP 제어 비트에 관한 접속 순서는
1) 발신자는 SYN
2) 수신자가 SYN, ACK로 응답합니다.
3) 호출자가 ACK를 보낸다.
이제 SYN 비트 만 설정된 패킷 캡처에 관심이 있습니다 (1 단계). 우리는 2 단계 (SYN-ACK) 패킷을 원하지 않는다는 것을 알아두기 바란다. 우리가 필요로하는 것은 tcpdump에 대한 올바른 필터 표현입니다.
옵션없이 TCP 헤더의 구조를 상기하자.
0 15 31 ----------------------------------------------- ------------------ | 소스 포트 | 대상 포트 | -------------------------------------------------- --------------- | 시퀀스 번호 | -------------------------------------------------- --------------- | 확인 번호 | -------------------------------------------------- --------------- | HL | rsvd | C | E | U | A | P | R | S | F | 창 크기 | -------------------------------------------------- --------------- | TCP 체크섬 | 긴급 포인터 | -------------------------------------------------- ---------------TCP 헤더는 옵션이없는 한 일반적으로 20 옥텟의 데이터를 저장합니다. 그래프의 첫 번째 라인은 옥텟 0 - 3을 포함하고, 두 번째 라인은 옥텟 4 - 7을 보여줍니다.
0으로 계산되기 시작한 관련 TCP 제어 비트는 옥텟 13에 포함됩니다.
0 7 | 15 | 23 | 31 ---------------- | --------------- | --------------- | ---------------- | HL | rsvd | C | E | U | A | P | R | S | F | 창 크기 | ---------------- | --------------- | --------------- | - --------------- | | 13 번째 옥텟 | | |옥텟 번호를 더 자세히 살펴 보겠습니다. 13 :
| | | --------------- | | C | E | U | A | P | R | S | F | | --------------- | | 7 5 3 0 |우리가 관심있는 TCP 제어 비트입니다. 우리는이 옥텟의 0에서 7까지 번호를 매겼으며, PSH 비트는 비트 3이고 URG 비트는 5입니다.
SYN 만 설정된 패킷을 캡처하려고한다는 것을 상기하십시오. 헤더에 SYN 비트가 설정된 TCP 데이터 그램이 도착하면 13 번 옥텟에 어떤 일이 발생하는지 봅시다.
| C | E | U | A | P | R | S | F | | --------------- | | 0 0 0 0 0 0 1 0 | | --------------- | | 7 6 5 4 3 2 1 0 |제어 비트 섹션을 살펴보면 비트 번호 1 (SYN) 만 설정된다는 것을 알 수 있습니다.
옥텟 번호 13이 네트워크 바이트 순서의 8 비트 부호없는 정수라고 가정하면이 옥텟의 이진 값은
00000010
십진수 표현은
7 6 5 4 3 2 1 0 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 = 2SYN 만 설정하면 TCP 헤더의 13 번째 옥텟 값이 네트워크 바이트 순서에서 8 비트 부호없는 정수로 해석 될 때 정확하게 2이어야한다는 것을 알기 때문에 거의 완료되었습니다.
이 관계는 다음과 같이 표현 될 수있다.
tcp [13] == 2
이 표현식을 SYN이 설정된 패킷을보기 위해 tcpdump 의 필터로 사용할 수 있습니다 :
tcpdump -i xl0 tcp [13] == 2
이 표현식은 "TCP 데이터 그램의 13 번째 옥텟에 10 진수 값 2가 있어야합니다."라고 말하면서 우리가 원하는 바로 그 것이다.
이제 SYN 패킷을 캡처해야한다고 가정 해 보겠습니다. 그러나 ACK 또는 다른 TCP 제어 비트가 동시에 설정되는지는 신경 쓰지 않습니다. SYN-ACK 세트를 가진 TCP 데이터 그램이 도착할 때 옥텟 13에 어떤 일이 일어나는지 봅시다.
| C | E | U | A | P | R | S | F | | --------------- | | 0 0 0 1 0 0 1 0 | | --------------- | | 7 6 5 4 3 2 1 0 |이제 비트 1과 4는 13 번째 옥텟에 설정됩니다. 옥텟 13의 이진 값은 다음과 같습니다.
00010010
십진수로 변환됩니다.
7 6 5 4 3 2 1 0 0 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 = 18이제는 tcpdump 필터 표현식에서 'tcp [13] == 18'을 사용할 수 없습니다. SYN-ACK 세트가있는 패킷 만 선택하기 때문에 SYN 세트 만있는 패킷은 선택하지 않기 때문입니다. SYN이 설정되어있는 한 ACK 또는 다른 제어 비트가 설정되어 있는지 신경 쓰지 않습니다.
목표를 달성하기 위해서는 옥텟 13의 이진 값과 SYN 비트를 보존하기 위해 다른 값을 논리적으로 AND해야합니다. 우리는 어떤 경우에도 SYN이 설정되기를 원한다는 것을 알고 있으므로, 13 번째 옥텟의 값과 SYN의 이진 값을 논리적으로 AND합니다.
00010010 SYN-ACK 00000010 SYN과 00000010 (SYN이 필요함)과 00000010 (SYN이 필요함) -------- -------- = 00000010 = 00000010이 AND 연산은 ACK 또는 다른 TCP 제어 비트가 설정되었는지 여부에 관계없이 동일한 결과를 제공합니다. 이 연산의 결과뿐만 아니라 AND 값의 십진수 표현은 2 (이진 00000010)이므로 SYN이 설정된 패킷의 경우 다음 관계가 true이어야합니다.
((옥텟 13의 값 AND (2)) == (2)
이것은 tcpdump 필터 표현을 가리킨다.
tcpdump -i xl0 'tcp [13] & 2 == 2'
쉘에서 AND ( '&') 특수 문자를 숨기려면 표현식에 작은 따옴표 또는 백 슬래시를 사용해야합니다.
UDP 패킷
UDP 형식은이 rwho 패킷에 의해 설명됩니다.
actinide.who> 방송. 누가 : udp 84이것은 호스트 actinide 에 포트 누가 호스트 방송 , 인터넷 방송 주소 누가 포트에 UDP 데이터 그램을 보냈다는 것을 말한다. 패킷에는 84 바이트의 사용자 데이터가 포함되어 있습니다.
일부 UDP 서비스는 소스 또는 대상 포트 번호에서 인식되고 상위 프로토콜 정보가 인쇄됩니다. 특히 NFS에 대한 도메인 이름 서비스 요청 (RFC-1034 / 1035) 및 Sun RPC 호출 (RFC-1050).
UDP 이름 서버 요청
(주의 : 다음 설명은 RFC-1035에 설명 된 도메인 서비스 프로토콜에 익숙하다고 가정합니다. 프로토콜에 익숙하지 않은 경우 다음 설명이 그리스어로 작성된 것으로 보입니다.)
이름 서버 요청은 다음 형식으로 지정됩니다.
src> dst : id op? 플래그 qtype qclass 이름 (len) h2opolo.1538> helios.domain : 3+ A? ucbvax.berkeley.edu. (37)호스트 h2opolo 는 helios 의 도메인 서버에 ucbvax.berkeley.edu 라는 이름과 연관된 주소 레코드 (qtype = A)를 요청했습니다. 쿼리 ID는 '3'입니다. `+ '는 재귀 원하는 플래그가 설정되었음을 나타냅니다. 쿼리 길이는 37 바이트이며 UDP 및 IP 프로토콜 헤더는 포함되지 않았습니다. 쿼리 작업은 정상적인 쿼리 (Query )이므로 op 필드가 생략되었습니다. op가 다른 것이었다면`3 '과`+'사이에 출력되었을 것이다. 마찬가지로, qclass는 정상적인 값인 C_IN 이며 생략되었습니다. 다른 qclass는`A '바로 다음에 인쇄되었습니다.
몇 가지 예외가 확인되고 대괄호 안에 추가 필드가 표시 될 수 있습니다. 쿼리에 답변이 포함 된 경우 전거 레코드 또는 추가 레코드 섹션 인 ancount , nscount 또는 arcount 는`[ n a] ', [ n n ] '또는`[nu]'여기서 n 은 적절한 수입니다. 응답 비트 중 하나 (AA, RA 또는 rcode)가 설정되거나 '반드시 0이어야'비트 중 하나가 바이트 2와 3으로 설정되면`[b2 & 3 = x ] '가 인쇄됩니다. 여기서 x 는 16 진수 값입니다. 헤더 바이트 2와 3.
UDP 이름 서버 응답
이름 서버 응답은 다음과 같이 형식이 지정됩니다.
src> dst : id에 rcode 플래그 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)첫 번째 예에서 helios 는 3 개의 응답 레코드, 3 개의 이름 서버 레코드 및 7 개의 추가 레코드로 h2opolo의 쿼리 ID 3에 응답합니다. 첫 번째 응답 레코드는 유형 A (주소)이고 데이터는 인터넷 주소 128.32.137.3입니다. 응답의 전체 크기는 UDP 및 IP 헤더를 제외한 273 바이트입니다. op 레코드 (쿼리)와 응답 코드 (NoError)는 A 레코드의 클래스 (C_IN)와 마찬가지로 생략되었습니다.
두 번째 예에서 helios는 응답이없고 존재하지 않는 도메인 (NXDomain)의 응답 코드, 이름 서버 한 개와 권한 레코드가없는 쿼리 2에 응답합니다. `* '는 신뢰할 수있는 응답 비트가 설정되었음을 나타냅니다. 응답이 없었기 때문에 유형, 클래스 또는 데이터가 인쇄되지 않았습니다.
나타날 수있는 다른 플래그 문자는`- '(재귀 사용 가능, RA, 설정 되지 않음 ) 및`|' (잘린 메시지, TC, 세트). `question '섹션에 정확히 하나의 항목이 없으면`[ n q]'가 출력됩니다.
이름 서버 요청 및 응답은 크기가 크고 68 바이트의 기본 스냅 샷은 인쇄 할 패킷을 충분히 캡처하지 못할 수 있습니다. 이름 서버 트래픽을 심각하게 조사해야하는 경우 -s 플래그를 사용하여 snaplen을 늘리십시오. ` -s 128 '은 나에게 잘 돌아갔다.
SMB / CIFS 디코딩
tcpdump 에는 UDP / 137, UDP / 138 및 TCP / 139에 대한 데이터를위한 상당히 광범위한 SMB / CIFS / NBT 디코딩이 포함됩니다. IPX 및 NetBEUI SMB 데이터의 일부 기본 디코딩도 수행됩니다.
기본적으로 상당히 최소한의 디코드가 수행되며 -v가 사용되면 훨씬 더 상세한 디코드가 수행됩니다. -va 단일 SMB 패킷을 사용하면 한 페이지 이상을 차지할 수 있으므로주의 깊게 모든 세부 정보를 원할 경우에만 -v를 사용하십시오.
유니 코드 문자열을 포함하는 SMB 세션을 디코딩하는 경우 환경 변수 USE_UNICODE를 1로 설정할 수 있습니다. 유니 코드 srings 자동 검색 패치가 환영받을 것입니다.
SMB 패킷 형식 및 모든 te 필드의 의미는 www.cifs.org 또는 pub / samba / specs / 디렉토리의 samba.org 미러 사이트를 참조하십시오. SMB 패치는 Andrew Tridgell (tridge@samba.org)에 의해 작성되었습니다.
NFS 요청 및 응답
Sun NFS (Network File System) 요청 및 응답은 다음과 같이 인쇄됩니다.
src.xid> dst.nfs : len op args src.nfs> dst.xid : 답장 결과보기 sushi.6709> wrl.nfs : 112 readlink fh 21,24 / 10.73165 wrl.nfs> sushi.6709 : 답장 확인 40 readlink "../var"sushi.201b> wrl.nfs : 144 조회 fh 9,74 / 4096.6878 "xcolors"wrl.nfs> sushi.201b : 회신 확인 128 조회 fh 9,74 / 4134.3150첫 번째 행에서 호스트 초밥 은 ID가 6709 인 트랜잭션을 wrl 로 보냅니다 (src 호스트 다음의 숫자는 소스 포트가 아니라 트랜잭션 ID 임). 요청은 UDP 및 IP 헤더를 제외한 112 바이트입니다. 작업은 파일 핸들 ( fh ) 21,24 / 10.731657119에 대한 읽기 링크 (기호 링크 읽기)였습니다. (이 경우처럼 운이 좋다면 파일 핸들은 메이저, 마이너 장치 번호 쌍, inode 번호 및 세대 번호로 해석 될 수 있습니다.) Wrl 은`ok '를 링크 내용으로 응답합니다.
세 번째 줄에서 sushi 는 wrl로 하여금 디렉토리 파일 9,74 / 4096.6878에서` xcolors '라는 이름을 찾도록 요청합니다. 출력되는 데이터는 작업 유형에 따라 달라집니다. 이 형식은 NFS 프로토콜 스펙과 함께 읽으면 자명 한 내용입니다.
-v (자세한 정보 표시) 플래그가 제공되면 추가 정보가 인쇄됩니다. 예 :
sushi.1372a> wrl.nfs : 148 읽기 fh 21,11 / 12.195 8192 바이트 @ 24576 wrl.nfs> sushi.1372a : reply ok 1472 읽기 REG 100664 ID 417/0 sz 29388(이 예에서 생략 된 IP 헤더 TTL, ID, 길이 및 단편화 필드도 인쇄합니다.) 첫 번째 줄에서 sushi 는 wrl 이 21,11 / 12.195 파일에서 8192 바이트를 바이트 오프셋으로 읽도록 요청합니다 24576. Wrl가 `ok '라고 대답했다. 두 번째 줄에 표시된 패킷은 회신의 첫 번째 조각이므로 1472 바이트 길이입니다 (다른 바이트는 후속 조각에서 따라 오지만 이러한 조각에는 NFS 또는 UDP 헤더가 없으므로 인쇄되지 않을 수도 있습니다. 사용 된 필터 표현식에 따라 다름). -v 플래그가 주어지기 때문에, 파일 유형 (정규 파일의 경우``REG ''), 파일 유형의 경우 파일 모드 (8 진수), 파일 유형 uid와 gid, 그리고 파일 크기.
-v 플래그가 두 번 이상 주어지면 더 많은 세부 사항이 인쇄됩니다.
NFS 요청은 매우 크며 snaplen 이 증가하지 않으면 세부 사항 대부분이 인쇄되지 않습니다. ` -s 192 '를 사용하여 NFS 트래픽을보십시오.
NFS 회신 패킷은 RPC 작업을 명시 적으로 식별하지 않습니다. 대신, tcpdump 는``최근 ''요청을 추적하여 트랜잭션 ID를 사용하여 응답과 일치시킵니다. 회신이 해당 요청과 밀접하게 따르지 않으면 구문 분석 할 수 없습니다.
AFS 요청 및 응답
Transarc AFS (Andrew File System) 요청 및 응답은 다음과 같이 인쇄됩니다.
src.sport> dst.dport : rx packet-type src.sport> dst.dport : rx 패킷 유형 서비스 호출 call-name args src.sport> dst.dport : rx 패킷 유형 서비스 응답 call-name args elvis. 7001> pike.afsfs : rx data fs rename old fid 536876964/1/1 ".newsrc.new"새 fid 536876964/1/1 ".newsrc"pike.afsfs> elvis.7001 : rx data fs reply rename첫 번째 줄에서 호스트 elvis는 RX 패킷을 pike로 전송합니다. 이것은 fs (파일 서버) 서비스에 대한 RX 데이터 패킷이었으며 RPC 호출의 시작입니다. RPC 호출은 이전 디렉토리 파일 ID가 536876964/1/1이고 이전 파일 이름이`.newsrc.new '이고 새 디렉토리 파일 ID가 536876964/1/1이고 새 파일 이름이`rename이었습니다. newsrc '. 호스트 파이크는 이름 바꾸기 호출에 대한 RPC 응답으로 응답합니다 (데이터 패킷이었고 중단 패킷이 아니기 때문에 성공했습니다).
일반적으로 모든 AFS RPC는 적어도 RPC 호출 이름으로 디코딩됩니다. 대부분의 AFS RPC는 해독 된 인수 중 적어도 일부를 가지고 있습니다 (흥미로운 정의에 대해서는 일반적으로 '흥미로운'인수 만 사용).
이 형식은 자체 설명을 목적으로하지만 AFS 및 RX의 작동에 익숙하지 않은 사용자에게는 유용하지 않습니다.
-v (자세한 정보 표시) 플래그가 두 번 주어지면 RX 호출 ID, 호출 번호, 시퀀스 번호, 일련 번호 및 RX 패킷 플래그와 같은 승인 패킷과 추가 헤더 정보가 인쇄됩니다.
-v 플래그를 두 번 지정하면 RX 호출 ID, 일련 번호 및 RX 패킷 플래그와 같은 추가 정보가 인쇄됩니다. MTU 협상 정보는 RX ACK 패킷에서도 인쇄됩니다.
-v 플래그가 세 번 주어지면 보안 색인 및 서비스 ID가 인쇄됩니다.
오류 코드는 Ubik 비컨 패킷을 제외하고 중단 패킷에 대해 인쇄됩니다 (중단 패킷은 Ubik 프로토콜에 대해 예 투표를 나타내는 데 사용되므로).
AFS 요청은 매우 크며 snaplen 이 증가하지 않으면 많은 인수가 인쇄되지 않습니다. AFS 트래픽을보기 위해` -s 256 '을 사용해보십시오.
AFS 응답 패킷은 RPC 조작을 명시 적으로 식별하지 않습니다. 대신 tcpdump 는``최근 ''요청을 추적하고 호출 번호와 서비스 ID를 사용하여 응답과 일치시킵니다. 회신이 해당 요청과 밀접하게 따르지 않으면 구문 분석 할 수 없습니다.
KIP Appletalk (UDP의 DDP)
Appletalk UDP 데이터 그램에 캡슐화 된 DDP 패킷은 캡슐화 해제되고 DDP 패킷으로 덤프됩니다 (즉, 모든 UDP 헤더 정보가 삭제됩니다). /etc/atalk.names 파일은 appletalk net 및 node number를 이름으로 변환하는 데 사용됩니다. 이 파일의 행은 다음과 같은 형식을가집니다.
번호 이름 1.254 에테르 16.1 icsd-net 1.254.110 에이스처음 두 줄은 appletalk 네트워크의 이름을 제공합니다. 세 번째 줄은 특정 호스트의 이름을 제공합니다 (호스트는 번호의 세 번째 옥텟으로 그물과 구별됩니다 - 그물 번호는 두 옥텟 이어야 하고 호스트 번호는 세 옥텟 이어야합니다 ). 번호와 이름은 분리되어야합니다 공백 (공백 또는 탭). /etc/atalk.names 파일은 공백 행이나 주석 행 (`# '으로 시작하는 행)을 포함 할 수 있습니다.
Appletalk 주소는 다음 형식으로 인쇄됩니다.
net.host.port 144.1.209.2> icsd-net.112.220 office.2> icsd-net.112.220 jssmag.149.235> icsd-net.2( /etc/atalk.names 가 존재하지 않거나 appletalk 호스트 / 넷 번호에 대한 항목을 포함하지 않는 경우 주소는 숫자 형식으로 인쇄됩니다.) 첫 번째 예에서 net 144.1의 NBP (DDP 포트 2) 노드 (209)는 네트 ID 노드 (112)의 포트 (220)를 청취하고있는 것이 무엇이든 전송한다. 두 번째 라인은 소스 노드의 성명이 알려져 있다는 것을 제외하고는 동일하다 ( '사무실'). 세 번째 줄은 넷 jssmag 노드 149의 포트 235에서 icsd-net NBP 포트로 브로드 캐스트하기위한 것입니다 (브로드 캐스트 주소 (255)는 호스트 번호가없는 넷 이름으로 표시됨). 이러한 이유로 좋은 아이디어입니다 /etc/atalk.names에서 노드 이름과 네트 이름을 구분해야 함).
NBP (이름 바인딩 프로토콜) 및 ATP (Appletalk 트랜잭션 프로토콜) 패킷은 해당 내용을 해석합니다. 다른 프로토콜은 프로토콜 이름 (또는 프로토콜에 이름이 등록되지 않은 경우 번호)과 패킷 크기를 덤프합니다.
NBP 패킷 의 형식은 다음과 같습니다.
icsd-net.112.220> jssmag.2 : nbp-lkup 190 : "= : LaserWriter @ *"jssmag.209.2> icsd-net.112.220 : nbp-reply 190 : "RM1140 : LaserWriter @ *"250 techpit.2> icsd -net.112.220 : nbp-reply 190 : "techpit : LaserWriter @ *"186첫 번째 줄은 net icsd 호스트 112가 전송하고 net jssmag에서 브로드 캐스트하는 레이저 라이저의 이름 조회 요청입니다. 검색을위한 nbp id는 190입니다. 두 번째 줄에는 호스트 jssmag.209의 "RM1140"이라는 레이저 라이저 리소스가 포트 250에 등록되어 있다는 내용의 요청 (이 ID는 동일 함)에 대한 응답이 표시됩니다. 세 번째 라인은 호스트 techpit이 포트 186에 등록 된 레이저 기술자 "techpit"를 가지고 있다고 말하는 동일한 요청에 대한 또 다른 대답입니다.
ATP 패킷 포맷은 다음 예제에 의해 설명됩니다.
jssmag.209.165> helios.132 : atp-req 12266 <0-7> 0xae030001 helios.132> jssmag.209.165 : atp-resp 12266 : 0 (512) 0xae040000 helios.132> jssmag.209.165 : atp-resp 12266 : 1 (512) 0xae040000 helios.132> jssmag.209.165 : atp-resp 12266 : 2 (512) 0xae040000 helios.132> jssmag.209.165 : atp-resp 12266 : 3 (512) 0xae040000 helios.132> jssmag.209.165 : atp- resp 12266 : 4 (512) 0xae040000 helios.132> jssmag.209.165 : atp-resp 12266 : 5 (512) 0xae040000 helios.132> jssmag.209.165 : atp-resp 12266 : 6 (512) 0xae040000 helios.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 12266 : 3 (512) 0xae040000 helios .132> jssmag.209.165 : atp-resp 12266 : 5 (512) 0xae040000 jssmag.209.165> helios.132 : atp-rel 12266 <0-7> 0xae030001 jssmag.209.133> helios.132 : atp-req * 12267 <0 -7> 0xae030002Jssmag.209는 최대 8 개의 패킷 (`<0-7> ')을 요청하여 호스트 helios와 트랜잭션 ID 12266을 시작합니다. 줄 끝의 16 진수는 요청의 'userdata'필드의 값입니다.
Helios는 8 개의 512 바이트 패킷으로 응답합니다. 트랜잭션 ID 다음의`: digit '은 트랜잭션의 패킷 시퀀스 번호를 제공하고 괄호 안의 숫자는 atp 헤더를 제외한 패킷의 데이터 양입니다. 패킷 7의`* '는 EOM 비트가 설정되었음을 나타냅니다.
Jssmag.209는 패킷 3 & 5가 재전송되도록 요청합니다. Helios가 다시 보낸 다음 jssmag.209가 트랜잭션을 릴리스합니다. 마지막으로 jssmag.209가 다음 요청을 시작합니다. 요청의 '*'는 XO ( '정확히 한 번')가 설정 되지 않았 음을 나타냅니다.
IP 단편화
단편화 된 인터넷 데이터 그램은 다음과 같이 인쇄됩니다.
(frag id : size @ offset +) (frag id : size @ offset )첫 번째 형식은 조각이 더 있음을 나타내며 두 번째 형식은 마지막 조각임을 나타냅니다.
Id 는 프래그먼트 ID입니다. 크기 는 IP 헤더를 제외한 조각 크기 (바이트)입니다. Offset 은 원본 데이터 그램에서이 부분의 오프셋 (바이트)입니다.
각 프래그먼트에 대한 프래그먼트 정보가 출력됩니다. 첫 번째 조각에는 상위 수준의 프로토콜 헤더가 포함되어 있으며, frag 정보는 프로토콜 정보 뒤에 인쇄됩니다. 첫 번째 이후의 조각에는 더 높은 수준의 프로토콜 헤더가없고 frag 정보는 원본 및 대상 주소 뒤에 인쇄됩니다. 예를 들어, 다음은 576 바이트 데이터 그램을 처리하지 않는 CSNET 연결을 통해 arizona.edu에서 lbl-rtsg.arpa로가는 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 :. 성공 1536 승리 2560여기서 주목해야 할 몇 가지 사항이 있습니다. 첫째, 두 번째 줄의 주소는 포트 번호를 포함하지 않습니다. 이는 TCP 프로토콜 정보가 모두 첫 번째 조각에 있기 때문에 나중에 조각을 인쇄 할 때 포트 또는 시퀀스 번호가 무엇인지 알지 못하기 때문입니다. 두 번째로, 첫 번째 줄의 TCP 시퀀스 정보는 실제로 512 바이트 (첫 번째 frag에는 308, 두 번째에는 204)가있는 것처럼 308 바이트의 사용자 데이터가있는 것처럼 인쇄됩니다. 시퀀스 공간에서 구멍을 찾거나 패킷과 일치하는 것을 찾으려한다면, 이것은 당신을 속일 수 있습니다.
IP do not fragment 플래그가있는 패킷은 후행 (DF)으로 표시됩니다.
타임 스탬프
기본적으로 모든 출력 행에는 시간 소인이옵니다. 타임 스탬프는 양식의 현재 시계 시간입니다.
hh : mm : ss.frac커널의 클럭만큼 정확합니다. 타임 스탬프는 커널이 패킷을 처음 보았던 시간을 반영합니다. 이더넷 인터페이스가 패킷을 와이어에서 제거한 시점과 커널이 '새 패킷'인터럽트를 서비스 한 시점 사이의 시간 지연을 고려하지 않습니다.
관련 항목
트래픽 (1C), nit (4P), bpf (4), pcap (3)
중요 : man 명령 ( % man )을 사용하여 특정 컴퓨터에서 명령이 어떻게 사용되는지보십시오.