TÊN
tcpdump - kết xuất lưu lượng truy cập trên mạng
TÓM TẮC
tcpdump [ -adeflnNOpqRStuvxX ] [ -c count ]
[ -C tệp_size ] [ -F tệp ]
[ -i giao diện ] [ -m module ] [ -r file ]
[ -s snaplen ] [ -T type ] [ -U người dùng ] [ -w tệp ]
[ -E algo: secret ] [ biểu hiện ]
SỰ MIÊU TẢ
Tcpdump in ra các tiêu đề của các gói trên một giao diện mạng phù hợp với biểu thức boolean. Nó cũng có thể được chạy với cờ -w , làm cho nó lưu dữ liệu gói vào một tệp để phân tích sau, và / hoặc với cờ -r , làm cho nó đọc từ tệp gói đã lưu thay vì đọc gói từ giao diện mạng. Trong mọi trường hợp, chỉ các gói phù hợp với biểu thức mới được xử lý bởi tcpdump .
Tcpdump sẽ, nếu không chạy với cờ -c , tiếp tục nắm bắt các gói cho đến khi nó bị gián đoạn bởi tín hiệu SIGINT (được tạo ra, ví dụ, bằng cách gõ ký tự ngắt, thường là điều khiển-C) hoặc tín hiệu SIGTERM (thường được tạo ra với lệnh giết (1) lệnh); nếu chạy với cờ -c , nó sẽ nắm bắt các gói tin cho đến khi nó bị gián đoạn bởi tín hiệu SIGINT hoặc SIGTERM hoặc số gói đã chỉ định đã được xử lý.
Khi tcpdump kết thúc việc thu thập các gói, nó sẽ báo cáo số lượng của:
các gói `` nhận bởi bộ lọc '' (ý nghĩa của điều này phụ thuộc vào hệ điều hành mà bạn đang chạy tcpdump , và có thể trên hệ điều hành được cấu hình - nếu một bộ lọc được chỉ định trên dòng lệnh, trên một số hệ điều hành các gói tin bất kể chúng được khớp với biểu thức lọc hay không và trên các hệ điều hành khác, nó chỉ đếm các gói được khớp với biểu thức lọc và được xử lý bởi tcpdump );
các gói tin `` bị giảm bởi hạt nhân '' (đây là số lượng các gói tin bị loại bỏ, do thiếu bộ nhớ đệm, bởi cơ chế capture gói trong hệ điều hành mà tcpdump đang chạy, nếu hệ điều hành báo cáo thông tin đó cho các ứng dụng; nếu không, nó sẽ được báo cáo là 0).
Trên các nền tảng hỗ trợ tín hiệu SIGINFO, như hầu hết các BSD, nó sẽ báo cáo số lượng khi nhận được tín hiệu SIGINFO (được tạo ra, ví dụ, bằng cách nhập ký tự `` status '', thường là control-T) và tiếp tục bắt gói .
Đọc các gói từ một giao diện mạng có thể yêu cầu bạn có các đặc quyền đặc biệt:
Dưới SunOS 3.x hoặc 4.x với NIT hoặc BPF:
Bạn phải có quyền truy cập đọc vào / dev / nit hoặc / dev / bpf * .
Dưới Solaris với DLPI:
Bạn phải có quyền truy cập đọc / ghi vào thiết bị giả mạng, ví dụ / dev / le . Trên ít nhất một số phiên bản của Solaris, tuy nhiên, điều này là không đủ để cho phép tcpdump chụp ở chế độ promiscuous; trên các phiên bản của Solaris, bạn phải là root, hoặc tcpdump phải được cài đặt setuid thành root, để capture ở chế độ promiscuous. Lưu ý rằng, trên nhiều giao diện (có thể là tất cả), nếu bạn không chụp ở chế độ promiscuous, bạn sẽ không thấy bất kỳ gói dữ liệu gửi đi nào, do đó việc chụp không được thực hiện trong chế độ promiscuous có thể không hữu ích lắm.
Trong HP-UX với DLPI:
Bạn phải là root hoặc tcpdump phải được cài đặt setuid thành root.
Dưới IRIX với snoop:
Bạn phải là root hoặc tcpdump phải được cài đặt setuid thành root.
Trong Linux:
Bạn phải là root hoặc tcpdump phải được cài đặt setuid thành root.
Dưới nền tảng UNIX và Tru UNIX / Tru64 kỹ thuật số:
Bất kỳ người dùng nào cũng có thể nắm bắt lưu lượng truy cập mạng bằng tcpdump . Tuy nhiên, không người dùng nào (thậm chí không có siêu người dùng) có thể chụp ở chế độ promiscuous trên một giao diện trừ khi super-user đã kích hoạt chế độ promiscuous-mode trên giao diện đó bằng cách sử dụng pfconfig (8) và không có người dùng nào (thậm chí không phải là siêu người dùng) ) có thể chụp lưu lượng unicast nhận được hoặc được gửi bởi máy trên giao diện trừ khi siêu người dùng bật hoạt động sao chép tất cả chế độ trên giao diện đó bằng pfconfig , vì vậy việc tải gói hữu ích trên giao diện có thể yêu cầu chế độ hoặc sao chép gián tiếp Hoạt động ở mọi chế độ, hoặc cả hai chế độ hoạt động, được bật trên giao diện đó.
Trong BSD:
Bạn phải có quyền truy cập đọc vào / dev / bpf * .
Đọc một tập tin gói đã lưu không yêu cầu đặc quyền đặc biệt.
TÙY CHỌN
-a
Cố gắng chuyển đổi địa chỉ mạng và phát sóng thành tên.
-c
Thoát sau khi nhận được gói tin.
-C
Trước khi viết một gói thô vào một tệp lưu trữ, hãy kiểm tra xem tệp có lớn hơn tệp_size hay không và nếu có, hãy đóng tệp lưu hiện tại và mở tệp mới. Savefiles sau khi savefile đầu tiên sẽ có tên được chỉ định với cờ -w , với một số sau nó, bắt đầu từ 2 và tiếp tục trở lên. Các đơn vị của file_size là hàng triệu byte (1.000.000 byte, không phải 1.048.576 byte).
-d
Kết xuất mã phù hợp với gói được biên dịch trong biểu mẫu có thể đọc được của con người với đầu ra tiêu chuẩn và dừng.
-dd
Kết xuất mã phù hợp với gói dưới dạng đoạn chương trình C.
-ddd
Kết xuất mã khớp với gói dưới dạng số thập phân (trước số đếm).
-e
In tiêu đề cấp liên kết trên mỗi dòng kết xuất.
-E
Sử dụng algo: bí mật để giải mã các gói tin IPsec ESP. Thuật toán có thể là des-cbc , 3des-cbc , blowfish-cbc , rc3-cbc , cast128-cbc hoặc không . Giá trị mặc định là des-cbc . Khả năng giải mã các gói tin chỉ xuất hiện nếu tcpdump được biên dịch với mật mã được kích hoạt. bí mật văn bản ascii cho khóa bí mật ESP. Chúng tôi không thể nhận giá trị nhị phân tùy ý tại thời điểm này. Tùy chọn giả định RFC2406 ESP, không phải là RFC1827 ESP. Tùy chọn này chỉ dành cho mục đích gỡ lỗi và việc sử dụng tùy chọn này với khóa 'bí mật' thực sự không được khuyến khích. Bằng cách trình bày khóa bí mật IPsec lên dòng lệnh, bạn có thể hiển thị nó với người khác thông qua ps (1) và các dịp khác.
-f
In các địa chỉ internet 'nước ngoài' bằng số chứ không phải tượng trưng (tùy chọn này nhằm tránh tổn thương não nghiêm trọng trong máy chủ yp của Sun-- thường nó treo vĩnh viễn dịch các số internet không phải địa phương).
-F
Sử dụng tệp làm đầu vào cho biểu thức lọc. Một biểu thức bổ sung được đưa ra trên dòng lệnh bị bỏ qua.
-tôi
Nghe trên giao diện . Nếu không xác định, tcpdump sẽ tìm kiếm danh sách giao diện hệ thống cho giao diện được định cấu hình, được đánh số thấp nhất (không bao gồm vòng lặp). Quan hệ bị phá vỡ bằng cách chọn trận đấu sớm nhất.
Trên các hệ thống Linux có hạt nhân 2.2 hoặc mới hơn, một đối số giao diện của `` any '' có thể được sử dụng để nắm bắt các gói từ tất cả các giao diện. Lưu ý rằng các ảnh chụp trên thiết bị `` any '' sẽ không được thực hiện trong chế độ promiscuous.
-l
Làm cho dòng stdout đệm. Hữu ích nếu bạn muốn xem dữ liệu trong khi chụp. Ví dụ,
`` tcpdump -l | tee dat '' hoặc `` tcpdump -l> dat & tail -f dat ''.
-m
Tải các định nghĩa mô-đun SMI MIB từ mô-đun tập tin. Tùy chọn này có thể được sử dụng nhiều lần để tải một số mô-đun MIB vào tcpdump .
-n
Không chuyển đổi địa chỉ máy chủ thành tên. Điều này có thể được sử dụng để tránh tra cứu DNS.
-nn
Không chuyển đổi các giao thức và số cổng, vv thành tên.
-N
Không in tên miền của tên máy chủ. Ví dụ, nếu bạn đưa cờ này thì tcpdump sẽ in `` nic '' thay vì `` nic.ddn.mil ''.
-O
Không chạy trình tối ưu hóa mã phù hợp với gói. Điều này chỉ hữu ích nếu bạn nghi ngờ một lỗi trong trình tối ưu hóa.
-p
Không đặt giao diện vào chế độ promiscuous. Lưu ý rằng giao diện có thể ở chế độ promiscuous vì một số lý do khác; do đó, `-p 'không thể được sử dụng làm từ viết tắt cho` ether host {local-hw-addr} hoặc ether broadcast'.
-q
Nhanh (yên tĩnh?) Đầu ra. In ít thông tin giao thức hơn để các dòng đầu ra ngắn hơn.
-R
Giả sử các gói ESP / AH được dựa trên đặc tả cũ (RFC1825 đến RFC1829). Nếu được chỉ định, tcpdump sẽ không in trường phòng ngừa phát lại. Vì không có trường phiên bản giao thức trong đặc tả ESP / AH, tcpdump không thể suy ra phiên bản của giao thức ESP / AH.
-r
Đọc các gói từ tệp (được tạo bằng tùy chọn -w). Đầu vào tiêu chuẩn được sử dụng nếu tệp là `` - ''.
-S
In tuyệt đối, chứ không phải là số thứ tự TCP tương đối.
-S
Các byte dữ liệu snaplen của dữ liệu từ mỗi gói thay vì mặc định là 68 (với NIT của SunOS, mức tối thiểu là 96). 68 byte là đủ cho IP, ICMP, TCP và UDP nhưng có thể cắt bớt thông tin giao thức từ máy chủ tên và gói NFS (xem bên dưới). Các gói bị cắt bớt vì ảnh chụp giới hạn được chỉ ra trong đầu ra với `` [| proto ] '', trong đó proto là tên của cấp độ giao thức mà tại đó việc cắt xén đã xảy ra. Lưu ý rằng việc chụp nhanh các bức ảnh lớn hơn sẽ làm tăng lượng thời gian cần thiết để xử lý các gói và, có hiệu quả, giảm lượng bộ đệm gói. Điều này có thể khiến các gói bị mất. Bạn nên hạn chế snaplen thành số nhỏ nhất sẽ nắm bắt thông tin giao thức mà bạn quan tâm. Cài đặt snaplen thành 0 có nghĩa là sử dụng độ dài cần thiết để nắm bắt toàn bộ các gói.
-T
Buộc các gói được chọn theo " biểu thức " để diễn giải loại được chỉ định. Các loại đã biết hiện nay là cnfp (giao thức NetFlow của Cisco), rpc (Remote Procedure Call), rtp (Giao thức ứng dụng thời gian thực), rtcp (Giao thức điều khiển ứng dụng thời gian thực), snmp (Giao thức quản lý mạng đơn giản), vat (Visual Audio Tool) ), và wb (phân phối Bảng Trắng).
-t
Đừng in dấu thời gian trên mỗi dòng kết xuất.
-tt
In dấu thời gian không định dạng trên mỗi dòng kết xuất.
-U
Giảm đặc quyền root và thay đổi ID người dùng thành ID người dùng và nhóm thành nhóm người dùng chính .
Chú thích! Red Hat Linux tự động giảm các đặc quyền cho người dùng `` pcap '' nếu không có gì khác được chỉ định.
-ttt
In một đồng bằng (tính bằng micro giây) giữa dòng hiện tại và dòng trước trên mỗi dòng kết xuất.
-tttt
In dấu thời gian ở định dạng mặc định được tiến hành theo ngày trên mỗi dòng kết xuất.
-u
In các xử lý NFS chưa được mã hóa.
-v
(Hơi hơn) sản lượng tiết ra. Ví dụ, thời gian để sống, nhận dạng, tổng chiều dài và các tùy chọn trong một gói IP được in. Cũng cho phép kiểm tra tính toàn vẹn gói bổ sung như xác minh IP và kiểm tra tiêu đề ICMP.
-vv
Sản lượng tiết ra nhiều hơn. Ví dụ, các trường bổ sung được in từ các gói trả lời NFS, và các gói SMB được giải mã đầy đủ.
-vvv
Sản lượng tiết ra nhiều hơn. Ví dụ, telnet SB ... SE tùy chọn được in đầy đủ. Với tùy chọn -net telnet cũng được in dưới dạng hex.
-w
Viết các gói thô vào tệp chứ không phải phân tích cú pháp và in chúng ra. Sau đó chúng có thể được in bằng tùy chọn -r. Đầu ra tiêu chuẩn được sử dụng nếu tệp là `` - ''.
-x
In mỗi gói (trừ tiêu đề cấp liên kết) trong hex. Nhỏ hơn của toàn bộ gói hoặc các byte snaplen sẽ được in. Lưu ý rằng đây là toàn bộ gói liên kết lớp, do đó, đối với các lớp liên kết mà pad (ví dụ như Ethernet), byte đệm cũng sẽ được in khi gói lớp cao hơn ngắn hơn yêu cầu đệm.
-X
Khi in hex, in ascii quá. Vì vậy, nếu -x cũng được thiết lập, gói được in bằng hex / ascii. Điều này rất tiện lợi cho việc phân tích các giao thức mới. Ngay cả khi -x cũng không được thiết lập, một số phần của một số gói có thể được in bằng hex / ascii.
biểu hiện
chọn gói nào sẽ được bán phá giá. Nếu không có biểu thức nào được đưa ra, tất cả các gói trên mạng sẽ được bán phá giá. Nếu không, chỉ các gói mà biểu thức là `true 'sẽ được bán phá giá.
Biểu thức bao gồm một hoặc nhiều nguyên thủy. Nguyên thủy thường bao gồm một id (tên hoặc số) đứng trước bởi một hoặc nhiều vòng loại. Có ba loại vòng loại khác nhau:
kiểu
vòng loại nói loại tên hoặc số id nào đề cập đến. Các loại có thể là máy chủ , mạng và cổng . Ví dụ: `host foo ',` net 128.3', `port 20 '. Nếu không có loại vòng loại, máy chủ được giả định.
dir
vòng loại chỉ định một hướng chuyển cụ thể đến và / hoặc từ id . Các hướng có thể là src , dst , src hoặc dst và src và dst . Ví dụ: `src foo ',` dst net 128.3', `src hoặc dst port ftp-data '. Nếu không có vòng loại dir, src hoặc dst được giả định. Đối với các lớp liên kết `null '(tức là các giao thức điểm tới điểm như trượt), các vòng loại trong và ngoài có thể được sử dụng để xác định hướng mong muốn.
proto
vòng loại giới hạn trận đấu với một giao thức cụ thể. Các protos có thể là: ether , fddi , tr , ip , ip6 , arp , rarp , decnet , tcp và udp . Ví dụ, `ether src foo ',` arp net 128.3', `tcp port 21 '. Nếu không có vòng loại proto, tất cả các giao thức phù hợp với loại được giả định. Ví dụ, `src foo 'có nghĩa là` (ip hoặc arp hoặc rarp) src foo' (ngoại trừ cú pháp thứ hai không phải là cú pháp pháp), `net bar 'có nghĩa là thanh net (' ip hoặc arp hoặc rarp ') và` port 53' có nghĩa là `(tcp hoặc udp) cổng 53 '.
[`fddi 'thực sự là một bí danh cho` ether'; Các tiêu đề FDDI chứa các địa chỉ nguồn và đích giống Ethernet, và thường chứa các loại gói giống như Ethernet, vì vậy bạn có thể lọc trên các trường FDDI này. giống như với các trường Ethernet tương tự. Các tiêu đề FDDI cũng chứa các trường khác, nhưng bạn không thể đặt tên chúng một cách rõ ràng trong một biểu thức lọc.
Tương tự, `tr 'là một bí danh cho` ether'; các câu lệnh của đoạn trước về tiêu đề FDDI cũng áp dụng cho các tiêu đề Token Ring.]
Ngoài những điều trên, có một số từ khóa 'nguyên thủy' đặc biệt không tuân theo mẫu: gateway , broadcast , less , lớn hơn và các biểu thức số học. Tất cả những điều này được mô tả dưới đây.
Các biểu thức lọc phức tạp hơn được xây dựng bằng cách sử dụng các từ và , hoặc không kết hợp các nguyên thủy. Ví dụ: 'lưu trữ foo và không phải cổng ftp và không phải cổng ftp-data'. Để lưu tính năng nhập, danh sách vòng loại giống hệt nhau có thể bị bỏ qua. Ví dụ, `tcp dst port ftp hoặc ftp-data hoặc domain 'giống hệt như` tcp dst port ftp hoặc tcp dst port ftp-data hoặc tcp dst port domain'.
Nguyên thủy cho phép là:
dst máy chủ lưu trữ
Đúng nếu trường đích IPv4 / v6 của gói là máy chủ lưu trữ , có thể là địa chỉ hoặc tên.
src máy chủ lưu trữ
Đúng nếu trường nguồn IPv4 / v6 của gói là host .
máy chủ lưu trữ
Đúng nếu nguồn IPv4 / v6 hoặc đích của gói là host . Bất kỳ biểu thức máy chủ nào ở trên có thể được thêm vào trước bằng các từ khóa, ip , arp , rarp hoặc ip6 như sau:
máy chủ lưu trữ iptương đương với:
ether proto \ ip và máy chủ lưu trữNếu máy chủ lưu trữ là tên có nhiều địa chỉ IP, mỗi địa chỉ sẽ được kiểm tra cho phù hợp.
ether dst ehost
Đúng nếu địa chỉ đích ethernet là ehost . Ehost có thể là một tên từ / etc / ethers hoặc một số (xem ethers (3N) cho định dạng số).
ether src ehost
Đúng nếu địa chỉ nguồn ethernet là ehost .
ether host ehost
Đúng nếu nguồn ethernet hoặc địa chỉ đích là ehost .
máy chủ cổng
Đúng nếu gói sử dụng máy chủ làm cổng. Tức là, nguồn ethernet hoặc địa chỉ đích đã được lưu trữ nhưng không phải nguồn IP cũng như đích IP được lưu trữ . Máy chủ phải là tên và phải được tìm thấy cả bằng cơ chế phân giải địa chỉ host-name-IP của máy (tệp tên máy chủ lưu trữ, DNS, NIS, v.v.) và độ phân giải địa chỉ host-to-Ethernet của máy cơ chế (/ etc / ete, vv). (Biểu thức tương đương là
ether host ehost và không lưu trữ hostcó thể được sử dụng với tên hoặc số cho host / ehost .) Cú pháp này không hoạt động trong cấu hình cho phép IPv6 tại thời điểm này.
dst net net
Đúng nếu địa chỉ đích IPv4 / v6 của gói có số mạng lưới . Net có thể là tên từ / etc / networks hoặc số mạng (xem mạng (4) để biết chi tiết).
src net net
Đúng nếu địa chỉ nguồn IPv4 / v6 của gói có số mạng lưới .
net net
Đúng nếu nguồn IPv4 / v6 hoặc địa chỉ đích của gói có số mạng lưới .
net net mặt nạ netmask
Đúng nếu địa chỉ IP khớp với lưới với mặt nạ mạng cụ thể. Có thể đủ điều kiện với src hoặc dst . Lưu ý rằng cú pháp này không hợp lệ cho mạng IPv6.
net net / len
Đúng nếu địa chỉ IPv4 / v6 khớp với lưới với một mặt nạ mạng len rộng. Có thể đủ điều kiện với src hoặc dst .
cổng cổng dst
Đúng nếu gói là ip / tcp, ip / udp, ip6 / tcp hoặc ip6 / udp và có giá trị cổng đích của cổng . Cổng có thể là số hoặc tên được sử dụng trong / etc / services (xem tcp (4P) và udp (4P)). Nếu tên được sử dụng, cả số cổng và giao thức đều được chọn. Nếu một số hoặc tên mơ hồ được sử dụng, chỉ số cổng được chọn (ví dụ, cổng dst 513 sẽ in cả lưu lượng truy cập tcp / đăng nhập và lưu lượng truy cập udp / người và tên miền sẽ in cả lưu lượng truy cập tcp / domain và udp / tên miền).
cổng cổng src
Đúng nếu gói tin có giá trị cổng nguồn của cổng .
cổng cảng
Đúng nếu cổng nguồn hoặc đích của gói là cổng . Bất kỳ biểu thức cổng nào ở trên có thể được thêm vào trước bằng các từ khóa, tcp hoặc udp , như sau:
tcp src cổng cảngchỉ khớp với các gói tcp có cổng nguồn là cổng .
chiều dài ít hơn
Đúng nếu gói tin có độ dài nhỏ hơn hoặc bằng chiều dài . Điều này tương đương với:
len <= chiều dài .chiều dài lớn hơn
Đúng nếu gói tin có độ dài lớn hơn hoặc bằng chiều dài . Điều này tương đương với:
len> = chiều dài .ip proto giao thức
Đúng nếu gói tin là gói IP (xem ip (4P)) của giao thức kiểu giao thức . Giao thức có thể là một số hoặc một trong các tên icmp , icmp6 , igmp , igrp , pim , ah , esp , vrrp , udp hoặc tcp . Lưu ý rằng số nhận dạng tcp , udp và icmp cũng là từ khóa và phải được thoát qua dấu gạch chéo ngược (\), là \\ trong C-shell. Lưu ý rằng nguyên thủy này không đuổi theo chuỗi tiêu đề giao thức.
ip6 giao thức proto
Đúng nếu gói là gói giao thức kiểu giao thức IPv6. Lưu ý rằng nguyên thủy này không đuổi theo chuỗi tiêu đề giao thức.
ip6 giao thức protochain
Đúng nếu gói tin là gói IPv6, và chứa tiêu đề giao thức với giao thức kiểu trong chuỗi tiêu đề giao thức của nó. Ví dụ,
ip6 protochain 6phù hợp với bất kỳ gói IPv6 nào với tiêu đề giao thức TCP trong chuỗi tiêu đề giao thức. Gói tin có thể chứa, ví dụ, tiêu đề xác thực, tiêu đề định tuyến, hoặc tiêu đề tùy chọn hop-by-hop, giữa tiêu đề IPv6 và tiêu đề TCP. Mã BPF được phát ra bởi nguyên thủy này là phức tạp và không thể được tối ưu hóa bởi mã tối ưu hóa BPF trong tcpdump , do đó, điều này có thể hơi chậm.
ip giao thức protochain
Tương đương với giao thức protochain ip6 , nhưng đây là cho IPv4.
phát sóng ether
Đúng nếu gói tin là gói phát sóng ethernet. Từ khóa ether là tùy chọn.
ip phát sóng
Đúng nếu gói tin là gói phát sóng IP. Nó kiểm tra cả các quy ước và tất cả các phát sóng, và tìm kiếm mặt nạ mạng con cục bộ.
ether multicast
Đúng nếu gói tin là gói multicast ethernet. Từ khóa ether là tùy chọn. Đây là viết tắt của ` ether [0] & 1! = 0 '.
ip multicast
Đúng nếu gói tin là gói IP multicast.
ip6 multicast
Đúng nếu gói là gói đa hướng IPv6.
giao thức proto ether
Đúng nếu gói là giao thức kiểu ether. Giao thức có thể là một số hoặc một trong các tên ip , ip6 , arp , rarp , atalk , aarp , decnet , sca , lat , mopdl , moprc , iso , stp , ipx hoặc netbeui . Lưu ý các số nhận dạng này cũng là từ khóa và phải được thoát qua dấu gạch chéo ngược (\).
[Trong trường hợp FDDI (ví dụ, ' fddi protocol arp ') và Token Ring (ví dụ, ' tr protocol arp '), đối với hầu hết các giao thức đó, nhận dạng giao thức xuất phát từ tiêu đề 802.2 Logical Link Control (LLC), thường được xếp chồng lên đầu tiêu đề FDDI hoặc Token Ring.
Khi lọc cho hầu hết các định danh giao thức trên FDDI hoặc Token Ring, tcpdump chỉ kiểm tra trường ID giao thức của tiêu đề LLC trong định dạng SNAP có Mã định danh đơn vị tổ chức (OUI) là 0x000000, cho Ethernet đóng gói; nó không kiểm tra xem gói có định dạng SNAP với OUI 0x000000 hay không.
Các trường hợp ngoại lệ là iso , nó kiểm tra các trường DSAP (Điểm truy cập dịch vụ đích) và SSAP (Các điểm truy cập dịch vụ nguồn) của tiêu đề LLC, stp và netbeui , nơi nó kiểm tra DSAP của tiêu đề LLC và atalk , nơi nó kiểm tra gói định dạng SNAP với OUI 0x080007 và etlet Appletalk.
Trong trường hợp Ethernet, tcpdump sẽ kiểm tra trường loại Ethernet cho hầu hết các giao thức đó; các trường hợp ngoại lệ là iso , sap và netbeui , nó kiểm tra khung 802.3 và sau đó kiểm tra tiêu đề LLC như nó cho FDDI và Token Ring, atalk , tại đây nó kiểm tra cả cho Appletalk etype trong khung Ethernet và Gói định dạng SNAP giống như đối với FDDI và Token Ring, aarp , ở đó nó kiểm tra thông số nhập liệu ARP Appletalk trong khung Ethernet hoặc khung SNAP 802.2 với OUI 0x000000 và ipx , nơi nó kiểm tra thông tin nhập IPX một khung Ethernet, IPX DSAP trong tiêu đề LLC, gói đính kèm tiêu đề 802.3 không có LLC của IPX và đồng bộ IPX trong khung SNAP.]
decnet src host
Đúng nếu địa chỉ nguồn DECNET là máy chủ , có thể là địa chỉ của biểu mẫu `` 10.123 '' hoặc tên máy chủ DECNET. [Hỗ trợ tên máy chủ DECNET chỉ khả dụng trên các hệ thống Ultrix được cấu hình để chạy DECNET.]
decnet dst host
Đúng nếu địa chỉ đích DECNET là máy chủ lưu trữ .
máy chủ lưu trữ decnet
Đúng nếu cả nguồn DECNET hoặc địa chỉ đích là host .
ip , ip6 , arp , rarp , atalk , aarp , decnet , iso , stp , ipx , netbeui
Các từ viết tắt cho:
ether proto ptrong đó p là một trong các giao thức trên.
lat , moprc , mopdl
Các từ viết tắt cho:
ether proto ptrong đó p là một trong các giao thức trên. Lưu ý rằng tcpdump hiện không biết cách phân tích các giao thức này.
vlan [vlan_id]
Đúng nếu gói tin là một gói VLAN IEEE 802.1Q. Nếu [vlan_id] được chỉ định, chỉ đúng là gói có vlan_id được chỉ định. Lưu ý rằng từ khóa vlan đầu tiên gặp phải trong biểu thức thay đổi độ lệch giải mã cho phần còn lại của biểu thức trên giả định rằng gói tin là một gói VLAN.
tcp , udp , icmp
Các từ viết tắt cho:
ip proto p hoặc ip6 proto ptrong đó p là một trong các giao thức trên.
iso giao thức proto
Đúng nếu gói là gói giao thức kiểu giao thức kiểu OSI . Giao thức có thể là một số hoặc một trong các tên clnp , esis hoặc isis .
clnp , esis , isis
Các từ viết tắt cho:
iso proto ptrong đó p là một trong các giao thức trên. Lưu ý rằng tcpdump thực hiện một công việc không hoàn chỉnh để phân tích các giao thức này.
expr relop expr
Đúng nếu quan hệ nắm giữ, trong đó relop là một trong số>, <,> =, <=, =,! = Và expr là một biểu thức số học bao gồm các hằng số nguyên (được thể hiện trong cú pháp C chuẩn), toán tử nhị phân bình thường [+ , -, *, /, &, |], một toán tử độ dài và các trình truy cập dữ liệu gói đặc biệt. Để truy cập dữ liệu bên trong gói, sử dụng cú pháp sau:
proto [ expr : size ]Proto là một trong ether, fddi, tr, ppp, trượt, liên kết, ip, arp, rarp, tcp, udp, icmp hoặc ip6 , và chỉ ra lớp giao thức cho hoạt động chỉ mục. ( ether, fddi, tr, ppp, phiếu và liên kết đều đề cập đến lớp liên kết.) Lưu ý rằng tcp, udp và các loại giao thức tầng trên chỉ áp dụng cho IPv4, không phải IPv6 (điều này sẽ được khắc phục trong tương lai). Độ lệch byte, tương ứng với lớp giao thức được chỉ định, được đưa ra bởi expr . Kích thước là tùy chọn và cho biết số byte trong trường quan tâm; nó có thể là một, hai hoặc bốn, và mặc định là một. Nhà điều hành độ dài, được chỉ ra bởi từ khóa len , cho độ dài của gói tin.
Ví dụ, ` ether [0] & 1! = 0 'bắt tất cả lưu lượng multicast. Biểu thức ` ip [0] & 0xf! = 5 'bắt tất cả các gói IP với các tùy chọn. Biểu thức ` ip [6: 2] & 0x1fff = 0 'chỉ bắt được các gói dữ liệu không bị phân mảnh và số không mảnh của các gói dữ liệu phân mảnh. Kiểm tra này được áp dụng ngầm cho các hoạt động chỉ mục tcp và udp . Ví dụ, tcp [0] luôn có nghĩa là byte đầu tiên của tiêu đề TCP, và không bao giờ là byte đầu tiên của một đoạn xen kẽ.
Một số giá trị bù trừ và giá trị trường có thể được biểu thị dưới dạng tên chứ không phải là giá trị số. Các trường đầu trang giao thức sau có sẵn: icmptype (trường loại ICMP), icmpcode (trường mã ICMP) và tcpflags (trường cờ TCP).
Các giá trị trường kiểu ICMP sau đây có sẵn: icmp-echoreply , icmp-unreach , icmp-sourcequench , chuyển hướng icmp , icmp-echo , icmp-routeradvert , icmp-routersolicit , icmp-timxceed , icmp-paramprob , icmp-tstamp , icmp -tstampreply , icmp-ireq , icmp-ireqreply , icmp-maskreq , icmp-maskreply .
Các giá trị trường cờ TCP sau đây có sẵn: tcp-fin , tcp-syn , tcp-rst , tcp-push , tcp-push , tcp-ack , tcp-urg .
Nguyên thủy có thể được kết hợp bằng cách sử dụng:
Một nhóm các toán tử và toán tử được ngoặc đơn (dấu ngoặc đơn là đặc biệt cho Shell và phải được thoát).
Phủ định (` ! 'Hoặc' không ').
Kết hợp (` && ' hoặc` và ').
Luân phiên (` || 'hoặc` hoặc ').
Phủ định có quyền ưu tiên cao nhất. Luân phiên và nối có ưu tiên bằng nhau và liên kết từ trái sang phải. Lưu ý rằng rõ ràng và thẻ, không phải juxtaposition, bây giờ là cần thiết cho nối.
Nếu một từ định danh được đưa ra mà không có từ khóa, từ khóa gần đây nhất được giả định. Ví dụ,
không tổ chức vs và acelà viết tắt của
không tổ chức vs và host acekhông nên nhầm lẫn với
không (máy chủ vs hoặc ace)Đối số biểu thức có thể được chuyển tới tcpdump dưới dạng một đối số hoặc nhiều đối số, tùy theo điều nào thuận tiện hơn. Nói chung, nếu biểu thức chứa các siêu ký tự Shell, thì việc chuyển nó thành một đối số được trích dẫn dễ dàng hơn. Nhiều đối số được nối với các dấu cách trước khi được phân tích cú pháp.
VÍ DỤ
Để in tất cả các gói đến hoặc rời khỏi mặt trời lặn :
tcpdump host sundownĐể in lưu lượng giữa các helios và nóng hoặc ace :
tcpdump máy chủ lưu trữ và \ (nóng hoặc ace \)Để in tất cả các gói IP giữa ace và bất kỳ máy chủ nào ngoại trừ helios :
tcpdump ip host ace và không phải là heliosĐể in tất cả lưu lượng truy cập giữa máy chủ lưu trữ cục bộ và máy chủ tại Berkeley:
tcpdump net ucb-etherĐể in tất cả lưu lượng truy cập ftp thông qua cổng kết nối Internet: (lưu ý rằng biểu thức được trích dẫn để ngăn trình bao (hiểu sai dấu ngoặc đơn):
tcpdump 'cổng snup và (cổng ftp hoặc ftp-dữ liệu)'Để in lưu lượng truy cập không có nguồn gốc từ cũng không mệnh cho máy chủ địa phương (nếu bạn cổng vào mạng khác, công cụ này không bao giờ nên làm cho nó vào mạng nội bộ của bạn).
tcpdump ip và không phải net localnetĐể in các gói bắt đầu và kết thúc (gói SYN và FIN) của mỗi cuộc hội thoại TCP liên quan đến một máy chủ không cục bộ.
tcpdump 'tcp [tcpflags] & (tcp-syn | tcp-fin)! = 0 và không src và dst net localnet 'Để in các gói IP dài hơn 576 byte được gửi qua cổng snup :
tcpdump 'cổng snup và ip [2: 2]> 576'Để in các gói IP broadcast hoặc multicast không được gửi qua broadcast ethernet hoặc multicast:
tcpdump 'ether [0] & 1 = 0 và ip [16]> = 224'Để in tất cả các gói ICMP không phải là các yêu cầu / trả lời echo (tức là, không phải các gói ping):
tcpdump 'icmp [icmptype]! = icmp-echo và icmp [icmptype]! = icmp-echoreply'ĐỊNH DẠNG ĐẦU RA
Đầu ra của tcpdump phụ thuộc vào giao thức. Phần sau đây mô tả ngắn gọn và ví dụ về hầu hết các định dạng.
Tiêu đề cấp liên kết
Nếu tùy chọn '-e' được đưa ra, tiêu đề cấp liên kết sẽ được in ra. Trên ethernets, địa chỉ nguồn và đích, giao thức và độ dài gói được in.
Trên các mạng FDDI, tùy chọn '-e' làm cho tcpdump in trường 'điều khiển khung', địa chỉ nguồn và đích, và độ dài gói. (Các trường `frame control 'điều chỉnh việc giải thích phần còn lại của gói tin. Các gói thông thường (như gói dữ liệu IP) là các gói' async ', với giá trị ưu tiên từ 0 đến 7, ví dụ,' async4 '. các gói tin được giả định chứa một gói tin Kiểm soát liên kết lôgic (LLC) 802.2, tiêu đề LLC được in nếu nó không phải là một gói dữ liệu ISO hoặc một gói SNAP được gọi là.
Trên mạng Token Ring, tùy chọn '-e' làm cho tcpdump in các trường 'điều khiển truy cập' và 'điều khiển khung', địa chỉ nguồn và đích và độ dài gói. Như trên các mạng FDDI, các gói tin được giả định chứa một gói LLC. Bất kể tùy chọn '-e' có được chỉ định hay không, thông tin định tuyến nguồn được in cho các gói được định tuyến nguồn.
(NB: Mô tả sau đây giả định sự quen thuộc với thuật toán nén SLIP được mô tả trong RFC-1144.)
Trên các liên kết SLIP, một chỉ báo hướng (`` I '' cho inbound, `` O '' cho outbound), loại gói và thông tin nén được in ra. Loại gói được in trước. Ba loại là ip , utcp và ctcp . Không có thêm thông tin liên kết được in cho các gói ip . Đối với các gói TCP, mã định danh kết nối được in theo loại. Nếu gói được nén, tiêu đề được mã hóa của nó sẽ được in ra. Các trường hợp đặc biệt được in ra dưới dạng * S + n và * SA + n , trong đó n là số tiền mà theo đó số thứ tự (hoặc số thứ tự và ack) đã thay đổi. Nếu nó không phải là một trường hợp đặc biệt, không có hoặc nhiều thay đổi được in. Một thay đổi được biểu thị bằng U (con trỏ khẩn cấp), W (cửa sổ), A (ack), S (số thứ tự) và I (ID gói), theo sau là một delta (+ n hoặc -n) hoặc một giá trị mới (= n). Cuối cùng, số lượng dữ liệu trong gói và độ dài tiêu đề nén được in.
Ví dụ, dòng sau đây cho thấy một gói TCP được nén đi, với một mã định danh kết nối ngầm định; ack đã thay đổi 6, số thứ tự là 49 và ID gói là 6; có 3 byte dữ liệu và 6 byte tiêu đề được nén:
O ctcp * A + 6 S + 49 I + 6 3 (6)Gói ARP / RARP
Đầu ra Arp / rarp hiển thị loại yêu cầu và đối số của nó. Định dạng này nhằm mục đích tự giải thích. Dưới đây là một mẫu ngắn lấy từ đầu của một 'rlogin' từ máy chủ rtsg đến máy chủ csam :
arp ai-có csam nói rtsg arp trả lời csam là-tại CSAMDòng đầu tiên nói rằng rtsg gửi một gói tin arp yêu cầu địa chỉ ethernet của csam máy chủ internet. Csam trả lời bằng địa chỉ ethernet của nó (trong ví dụ này, địa chỉ ethernet có dạng mũ và địa chỉ internet trong trường hợp thấp hơn).
Điều này sẽ trông ít dư thừa hơn nếu chúng ta đã thực hiện tcpdump -n :
arp người có 128.3.254.6 nói 128.3.254.68 trả lời arp 128.3.254.6 là lúc 02: 07: 01: 00: 01: c4Nếu chúng ta đã thực hiện tcpdump -e , thực tế là gói tin đầu tiên được phát và thứ hai là điểm-điểm sẽ được hiển thị:
RTSG Broadcast 0806 64: arp người có csam nói rtsg CSAM RTSG 0806 64: trả lời arp csam là tại CSAMĐối với gói tin đầu tiên, địa chỉ nguồn ethernet là RTSG, đích là địa chỉ phát sóng ethernet, trường kiểu chứa hex 0806 (loại ETHER_ARP) và tổng chiều dài là 64 byte.
Gói TCP
(NB: Mô tả sau đây giả định sự quen thuộc với giao thức TCP được mô tả trong RFC-793. Nếu bạn không quen thuộc với giao thức này, không mô tả này cũng như tcpdump sẽ được sử dụng nhiều cho bạn.)
Định dạng chung của dòng giao thức tcp là:
src> dst: flags data-seqno ack cửa sổ tùy chọn khẩn cấp Src và dst là các địa chỉ IP và cổng nguồn và đích. Cờ là một số kết hợp của S (SYN), F (FIN), P (PUSH) hoặc R (RST) hoặc một `. ' (không có lá cờ). Data-seqno mô tả phần không gian trình tự được bao phủ bởi dữ liệu trong gói này (xem ví dụ bên dưới). Ack là số thứ tự của dữ liệu tiếp theo dự kiến hướng khác trên kết nối này. Cửa sổ là số byte của không gian bộ đệm nhận có sẵn hướng khác trên kết nối này. Urg cho biết có dữ liệu 'khẩn cấp' trong gói. Các tùy chọn là các tùy chọn tcp được đính kèm trong các dấu ngoặc nhọn (ví dụ,
Src, dst và flags luôn hiện diện. Các trường khác phụ thuộc vào nội dung của tiêu đề giao thức tcp của gói và chỉ xuất ra nếu thích hợp.
Đây là phần mở đầu của một rlogin từ host rtsg đến host csam .
rtsg.1023> csam.login: S 768512: 768512 (0) giành chiến thắng 4096Dòng đầu tiên nói rằng cổng tcp 1023 trên rtsg đã gửi một gói đến đăng nhập cổng trên csam. S chỉ ra rằng cờ SYN đã được thiết lập. Số thứ tự gói là 768512 và không chứa dữ liệu. (Ký hiệu là `đầu tiên: last (nbytes) 'có nghĩa là` số thứ tự đầu tiên lên đến nhưng không bao gồm cuối cùng là nbyte byte dữ liệu người dùng'.) Không có con heo đất được hỗ trợ, cửa sổ nhận sẵn là 4096 byte và có một tùy chọn kích thước tối đa phân đoạn yêu cầu một mss 1024 byte.
Csam trả lời với một gói tương tự, ngoại trừ nó bao gồm một ack heo được hỗ trợ cho SYN của rtsg. Rtsg sau đó acks csam SYN. `. ' có nghĩa là không có cờ nào được đặt. Gói không chứa dữ liệu nên không có số thứ tự dữ liệu. Lưu ý rằng số thứ tự ack là một số nguyên nhỏ (1). Lần đầu tiên tcpdump thấy một tcp `cuộc hội thoại ', nó in số thứ tự từ gói. Trên các gói tiếp theo của cuộc hội thoại, sự khác biệt giữa số thứ tự của gói tin hiện tại và số thứ tự ban đầu này được in. Điều này có nghĩa rằng các số thứ tự sau lần đầu tiên có thể được hiểu là vị trí byte tương đối trong luồng dữ liệu của cuộc hội thoại (với byte dữ liệu đầu tiên mỗi hướng là `1 '). `-S 'sẽ ghi đè lên tính năng này, làm cho các số thứ tự ban đầu được xuất ra.
Trên dòng thứ 6, rtsg gửi csam 19 byte dữ liệu (byte 2 đến 20 ở phía rtsg -> csam của cuộc hội thoại). Cờ PUSH được đặt trong gói. Trên dòng 7, csam nói rằng nó nhận được dữ liệu được gửi bởi rtsg lên đến nhưng không bao gồm byte 21. Hầu hết dữ liệu này dường như đang nằm trong bộ đệm socket vì cửa sổ nhận của csam đã nhận được 19 byte nhỏ hơn. Csam cũng gửi một byte dữ liệu tới rtsg trong gói này. Trên dòng thứ 8 và thứ 9, csam gửi hai byte khẩn cấp, đẩy dữ liệu lên rtsg.
Nếu ảnh chụp đủ nhỏ để tcpdump không nắm bắt được tiêu đề TCP đầy đủ, nó sẽ giải thích phần lớn tiêu đề như nó có thể và sau đó báo cáo `` [| tcp ] '' để cho biết phần còn lại không thể diễn giải được. Nếu tiêu đề chứa tùy chọn không có thật (một phần có độ dài quá nhỏ hoặc quá đầu của tiêu đề), tcpdump báo cáo nó là `` [ bad opt ] '' và không giải thích bất kỳ tùy chọn nào khác (vì không thể nói nơi họ bắt đầu). Nếu chiều dài tiêu đề cho biết các tùy chọn có mặt nhưng chiều dài datagram IP không đủ dài để các tùy chọn thực sự có, tcpdump báo cáo nó là `` [ bad hdr length ] ''.
Chụp các gói TCP với các kết hợp cờ cụ thể (SYN-ACK, URG-ACK, v.v.)
Có 8 bit trong phần bit điều khiển của tiêu đề TCP:
CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
Giả sử rằng chúng ta muốn xem các gói được sử dụng trong việc thiết lập kết nối TCP. Nhớ lại rằng TCP sử dụng giao thức bắt tay 3 chiều khi nó khởi tạo một kết nối mới; chuỗi kết nối liên quan đến các bit điều khiển TCP là
1) Người gọi gửi SYN
2) Người nhận phản hồi với SYN, ACK
3) Người gọi gửi ACK
Bây giờ chúng ta quan tâm đến việc nắm bắt các gói chỉ có bộ bit SYN (Bước 1). Lưu ý rằng chúng ta không muốn các gói từ bước 2 (SYN-ACK), chỉ là một SYN ban đầu đơn giản. Những gì chúng ta cần là một biểu thức lọc chính xác cho tcpdump .
Nhớ lại cấu trúc của một tiêu đề TCP mà không có các tùy chọn:
0 15 31 ----------------------------------------------- ------------------ | cổng nguồn | cổng đích | -------------------------------------------------- --------------- | số thứ tự | -------------------------------------------------- --------------- | số xác nhận | -------------------------------------------------- --------------- | HL | rsvd | C | E | U | A | P | R | S | F | kích thước cửa sổ | -------------------------------------------------- --------------- | Kiểm tra TCP | con trỏ khẩn cấp | -------------------------------------------------- ---------------Một tiêu đề TCP thường chứa 20 octet dữ liệu, trừ khi có các tùy chọn. Dòng đầu tiên của biểu đồ chứa octet 0 - 3, dòng thứ hai hiển thị octet 4 - 7, v.v.
Bắt đầu đếm với 0, các bit điều khiển TCP có liên quan được chứa trong octet 13:
0 7 | 15 | 23 | 31 ---------------- | --------------- | --------------- | ---------------- | HL | rsvd | C | E | U | A | P | R | S | F | kích thước cửa sổ | ---------------- | --------------- | --------------- | - --------------- | | Thứ mười tám | | |Chúng ta hãy xem xét kỹ hơn octet no. 13:
| | | --------------- | | C | E | U | A | P | R | S | F | | --------------- | | 7 5 3 0 |Đây là các bit điều khiển TCP mà chúng ta quan tâm. Chúng ta đã đánh số bit trong octet này từ 0 đến 7, phải sang trái, do đó bit PSH là bit số 3, trong khi bit URG là số 5.
Nhớ lại rằng chúng ta muốn capture các gói chỉ với SYN. Hãy xem điều gì xảy ra với octet 13 nếu một gói dữ liệu TCP đến với bit SYN được đặt trong tiêu đề của nó:
| C | E | U | A | P | R | S | F | | --------------- | | 0 0 0 0 0 0 1 0 | | --------------- | | 7 6 5 4 3 2 1 0 |Nhìn vào phần bit điều khiển, chúng ta thấy rằng chỉ bit số 1 (SYN) mới được thiết lập.
Giả sử rằng số octet 13 là một số nguyên không dấu 8 bit trong thứ tự byte mạng, giá trị nhị phân của octet này là
00000010
và biểu diễn thập phân của nó là
7 6 5 4 3 2 1 0 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 = 2Chúng ta gần như hoàn thành, bởi vì bây giờ chúng ta biết rằng nếu chỉ SYN được thiết lập, giá trị của octet thứ 13 trong tiêu đề TCP, khi được hiểu là số nguyên không dấu 8 bit trong thứ tự byte mạng, phải chính xác là 2.
Mối quan hệ này có thể được diễn tả như
tcp [13] == 2
Chúng ta có thể sử dụng biểu thức này làm bộ lọc cho tcpdump để xem các gói chỉ có bộ SYN:
tcpdump -i xl0 tcp [13] == 2
Biểu thức nói "để cho octet thứ 13 của một gói dữ liệu TCP có giá trị thập phân 2", đó chính xác là những gì chúng ta muốn.
Bây giờ, giả sử rằng chúng ta cần nắm bắt các gói SYN, nhưng chúng ta không quan tâm nếu ACK hoặc bất kỳ bit điều khiển TCP nào khác được đặt cùng một lúc. Hãy xem điều gì sẽ xảy ra với octet 13 khi một gói tin TCP với bộ SYN-ACK đến:
| C | E | U | A | P | R | S | F | | --------------- | | 0 0 0 1 0 0 1 0 | | --------------- | | 7 6 5 4 3 2 1 0 |Bây giờ bit 1 và 4 được đặt trong octet thứ 13. Giá trị nhị phân của octet 13 là
00010010
dịch thành số thập phân
7 6 5 4 3 2 1 0 0 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 = 18Bây giờ chúng ta không thể chỉ sử dụng 'tcp [13] == 18' trong biểu thức bộ lọc tcpdump , bởi vì điều đó sẽ chỉ chọn những gói có bộ SYN-ACK, nhưng không chỉ những gói có bộ SYN. Hãy nhớ rằng chúng tôi không quan tâm nếu ACK hoặc bất kỳ bit điều khiển nào khác được thiết lập miễn là SYN được đặt.
Để đạt được mục tiêu của chúng ta, chúng ta cần logic và giá trị nhị phân của octet 13 với một số giá trị khác để bảo toàn bit SYN. Chúng ta biết rằng chúng ta muốn SYN được đặt trong mọi trường hợp, vì vậy chúng ta sẽ logic và giá trị trong octet thứ 13 với giá trị nhị phân của một SYN:
00010010 SYN-ACK 00000010 SYN VÀ 00000010 (chúng tôi muốn SYN) VÀ 00000010 (chúng tôi muốn SYN) -------- -------- = 00000010 = 00000010Chúng ta thấy rằng thao tác AND này mang lại kết quả tương tự bất kể ACK hoặc bit điều khiển TCP khác đã được thiết lập hay chưa. Biểu diễn thập phân của giá trị AND cũng như kết quả của phép toán này là 2 (nhị phân 00000010), vì vậy chúng ta biết rằng đối với các gói có SYN, mối quan hệ sau đây phải đúng:
((giá trị của octet 13) AND (2)) == (2)
Điều này chỉ cho chúng ta biểu thức bộ lọc tcpdump
tcpdump -i xl0 'tcp [13] & 2 == 2'
Lưu ý rằng bạn nên sử dụng dấu nháy đơn hoặc dấu gạch chéo ngược trong biểu thức để ẩn ký tự đặc biệt AND ('&') khỏi trình bao.
Gói UDP
Định dạng UDP được minh họa bằng gói rwho này:
actinide.who> broadcast.who: udp 84Điều này nói rằng cổng trên máy chủ lưu trữ actinide đã gửi một gói dữ liệu udp đến cổng lưu trữ trên máy chủ, địa chỉ phát sóng Internet. Gói chứa 84 byte dữ liệu người dùng.
Một số dịch vụ UDP được nhận dạng (từ số cổng nguồn hoặc đích) và thông tin giao thức mức cao hơn được in. Đặc biệt, các yêu cầu dịch vụ tên miền (RFC-1034/1035) và các cuộc gọi Sun RPC (RFC-1050) tới NFS.
Yêu cầu máy chủ tên UDP
(NB: Mô tả sau đây giả định sự quen thuộc với giao thức Dịch vụ miền được mô tả trong RFC-1035. Nếu bạn không quen thuộc với giao thức, mô tả sau đây sẽ được viết bằng tiếng Hy Lạp.)
Yêu cầu máy chủ tên được định dạng là
src> dst: id op? cờ qtype tên qclass (len) h2opolo.1538> helios.domain: 3+ A? ucbvax.berkeley.edu. (37)Host h2opolo đã yêu cầu máy chủ miền trên helios cho một bản ghi địa chỉ (qtype = A) liên kết với tên ucbvax.berkeley.edu. Id truy vấn là `3 '. Dấu '+' cho biết cờ mong muốn đệ quy đã được thiết lập. Độ dài truy vấn là 37 byte, không bao gồm tiêu đề giao thức UDP và IP. Các hoạt động truy vấn là một trong những bình thường, truy vấn , do đó, các lĩnh vực op đã được bỏ qua. Nếu op đã được bất cứ điều gì khác, nó sẽ được in giữa `3 'và` +'. Tương tự như vậy, các lớp học là một bình thường, C_IN , và bỏ qua. Bất kỳ lớp qclass nào khác sẽ được in ngay sau chữ 'A'.
Một vài dị thường được kiểm tra và có thể dẫn đến các trường được thêm vào trong dấu ngoặc vuông: Nếu một truy vấn chứa câu trả lời, bản ghi quyền hoặc phần bản ghi bổ sung, số an , nscount hoặc số được in dưới dạng `[ n a] ',` [ n n ] 'hoặc `[ n au]' trong đó n là số đếm thích hợp. Nếu bất kỳ bit đáp ứng nào được đặt (AA, RA hoặc rcode) hoặc bất kỳ bit `phải là số không 'nào được đặt theo byte hai và ba,` [b2 & 3 = x ]' được in, trong đó x là giá trị hex của byte tiêu đề hai và ba.
Phản hồi của máy chủ tên UDP
Các phản hồi của máy chủ tên được định dạng là
src> dst: id op cờ rcode a / n / au kiểu dữ liệu lớp (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)Trong ví dụ đầu tiên, helios đáp ứng với truy vấn id 3 từ h2opolo với 3 bản ghi câu trả lời, 3 bản ghi máy chủ tên và 7 bản ghi bổ sung. Bản ghi câu trả lời đầu tiên là loại A (địa chỉ) và dữ liệu của nó là địa chỉ internet 128.32.137.3. Tổng kích thước của phản hồi là 273 byte, ngoại trừ các tiêu đề UDP và IP. Mã truy vấn (Query) và mã phản hồi (NoError) bị bỏ qua, cũng như lớp (C_IN) của bản ghi A.
Trong ví dụ thứ hai, helios đáp ứng với truy vấn 2 với mã phản hồi của miền không tồn tại (NXDomain) không có câu trả lời, máy chủ tên và không có bản ghi quyền hạn. `* 'Chỉ ra rằng bit trả lời có thẩm quyền đã được thiết lập. Vì không có câu trả lời, không có loại, lớp hoặc dữ liệu nào được in.
Các ký tự cờ khác có thể xuất hiện là `- '(đệ quy có sẵn, RA, không được đặt) và` |' (tin nhắn đã cắt ngắn, TC, được đặt). Nếu phần `câu hỏi 'không chứa chính xác một mục,` [ n q]' được in.
Lưu ý rằng các yêu cầu và phản hồi của máy chủ tên có xu hướng lớn và snaplen mặc định là 68 byte có thể không nắm bắt đủ gói để in. Sử dụng cờ -s để tăng snaplen nếu bạn cần điều tra nghiêm túc lưu lượng máy chủ tên. ` -s 128 'đã làm việc tốt cho tôi.
Giải mã SMB / CIFS
tcpdump hiện bao gồm giải mã SMB / CIFS / NBT khá rộng rãi cho dữ liệu trên UDP / 137, UDP / 138 và TCP / 139. Một số giải mã nguyên thủy của dữ liệu IPX và NetBEUI SMB cũng được thực hiện.
Theo mặc định, một giải mã khá nhỏ được thực hiện, với một giải mã chi tiết hơn được thực hiện nếu v được sử dụng. Được cảnh báo rằng với gói SMB đơn -va có thể mất một trang hoặc nhiều hơn, vì vậy chỉ sử dụng -v nếu bạn thực sự muốn tất cả các chi tiết đẫm máu.
Nếu bạn đang giải mã các phiên SMB có chứa các chuỗi unicode thì bạn có thể đặt biến môi trường USE_UNICODE thành 1. Một bản vá để tự động phát hiện các chuỗi sicode sẽ được chào đón.
Để biết thông tin về các định dạng gói SMB và tất cả các trường của te có nghĩa là xem www.cifs.org hoặc thư mục pub / samba / specs / trên trang mirror samba.org yêu thích của bạn. Các bản vá lỗi SMB được viết bởi Andrew Tridgell (tridge@samba.org).
Yêu cầu và trả lời của NFS
Các yêu cầu và trả lời của Sun NFS (Hệ thống tệp mạng) được in dưới dạng:
src.xid> dst.nfs: len op args src.nfs> dst.xid: trả lời stat len op kết quả sushi.6709> wrl.nfs: 112 readlink fh 21,24 / 10,73165 wrl.nfs> sushi.6709: trả lời ok 40 readlink "../var" sushi.201b> wrl.nfs: 144 tra cứu fh 9,74 / 4096,6878 "xcolors" wrl.nfs> sushi.201b: trả lời ok 128 tra cứu fh 9,74 / 4134.3150Trong dòng đầu tiên, máy chủ lưu trữ sẽ gửi một giao dịch với id 6709 đến wrl (lưu ý rằng số sau máy chủ src là một id giao dịch, không phải là cổng nguồn). Yêu cầu là 112 byte, không bao gồm tiêu đề UDP và IP. Các hoạt động là một readlink (đọc liên kết tượng trưng) trên tập tin xử lý ( fh ) 21,24 / 10.731657119. (Nếu một người may mắn, như trong trường hợp này, xử lý tệp có thể được hiểu là cặp số thiết bị lớn, tiếp theo là số inode và số thế hệ.) Wrl trả lời 'ok' với nội dung của liên kết.
Trong dòng thứ ba, sushi hỏi wrl tra cứu tên ' xcolors ' trong thư mục tập tin 9,74 / 4096,6878. Lưu ý rằng dữ liệu được in phụ thuộc vào loại hoạt động. Định dạng này được thiết kế để tự giải thích nếu đọc cùng với một đặc tả giao thức NFS.
Nếu cờ -v (tiết) được đưa ra, thông tin bổ sung sẽ được in. Ví dụ:
sushi.1372a> wrl.nfs: 148 đọc fh 21,11 / 12.195 8192 byte @ 24576 wrl.nfs> sushi.1372a: trả lời ok 1472 đọc REG 100664 ids 417/0 sz 29388(-v cũng in các tiêu đề IP, các trường ID, chiều dài và phân mảnh IP, mà đã được bỏ qua trong ví dụ này.) Trong dòng đầu tiên, sushi yêu cầu wrl đọc 8192 byte từ tệp 21,11 / 12.195, tại byte offset 24576. Wrl trả lời 'ok'; gói tin được hiển thị trên dòng thứ hai là đoạn đầu tiên của câu trả lời và do đó chỉ dài 1472 byte (các byte khác sẽ theo sau các đoạn tiếp theo, nhưng các đoạn này không có NFS hoặc thậm chí là tiêu đề UDP và có thể không được in, tùy thuộc vào biểu thức lọc được sử dụng). Vì cờ -v được đưa ra, một số thuộc tính tệp (được trả về ngoài dữ liệu tệp) được in: loại tệp (`'REG' ', đối với tệp thông thường), chế độ tệp (trong bát phân), uid và gid, và kích thước tập tin.
Nếu cờ -v được cho nhiều hơn một lần, thậm chí nhiều chi tiết hơn sẽ được in.
Lưu ý rằng các yêu cầu NFS rất lớn và nhiều chi tiết sẽ không được in trừ khi snaplen được tăng lên. Hãy thử sử dụng ` -s 192 'để xem lưu lượng truy cập NFS.
Gói trả lời NFS không xác định rõ ràng hoạt động RPC. Thay vào đó, tcpdump theo dõi các yêu cầu `` gần đây '' và so khớp chúng với các câu trả lời bằng cách sử dụng ID giao dịch. Nếu câu trả lời không tuân theo yêu cầu tương ứng, nó có thể không được phân tích cú pháp.
Yêu cầu và trả lời của AFS
Các yêu cầu và trả lời của Transarc AFS (Andrew File System) được in dưới dạng:
src.sport> dst.dport: rx packet-type src.sport> dst.dport: rx gói-dịch vụ kiểu gọi call-name args src.sport> dst.dport: rx gói kiểu dịch vụ trả lời gọi tên args elvis. 7001> pike.afsfs: rx dữ liệu fs gọi đổi tên cũ fid 536876964/1/1 ".newsrc.new" new fid 536876964/1/1 ".newsrc" pike.afsfs> elvis.7001: rx dữ liệu fs trả lời đổi tênTrong dòng đầu tiên, máy chủ lưu trữ elvis gửi một gói tin RX đến pike. Đây là gói dữ liệu RX cho dịch vụ fs (fileserver) và là khởi đầu của cuộc gọi RPC. Cuộc gọi RPC là một sự đổi tên, với id tệp thư mục cũ là 536876964/1/1 và một tên tệp cũ là `.newsrc.new 'và một tệp thư mục mới là 536876964/1/1 và một tên tệp mới là`. newsrc '. Các pike máy chủ đáp ứng với một RPC trả lời cuộc gọi đổi tên (mà đã thành công, bởi vì nó là một gói dữ liệu và không phải là một gói hủy bỏ).
Nói chung, tất cả RPC AFS được giải mã ít nhất bằng tên cuộc gọi RPC. Hầu hết các RPC AFS có ít nhất một số đối số được giải mã (thường chỉ có các đối số 'thú vị', đối với một số định nghĩa thú vị).
Định dạng này được thiết kế để tự mô tả, nhưng nó có thể sẽ không hữu ích cho những người không quen thuộc với các hoạt động của AFS và RX.
Nếu cờ -v (verbose) được cho hai lần, các gói xác nhận và thông tin tiêu đề bổ sung được in, chẳng hạn như ID cuộc gọi RX, số cuộc gọi, số thứ tự, số sê-ri và cờ gói RX.
Nếu cờ -v được cung cấp hai lần, thông tin bổ sung sẽ được in, chẳng hạn như ID cuộc gọi RX, số sê-ri và cờ gói RX. Thông tin thương lượng MTU cũng được in từ gói RX ack.
Nếu cờ -v được đưa ra ba lần, chỉ mục bảo mật và id dịch vụ được in.
Mã lỗi được in cho các gói dữ liệu bị hủy bỏ, ngoại trừ các gói beacon Ubik (vì các gói hủy bỏ được sử dụng để biểu thị một phiếu bầu cho giao thức Ubik).
Lưu ý rằng các yêu cầu AFS rất lớn và nhiều đối số sẽ không được in trừ khi snaplen được tăng lên. Hãy thử sử dụng ` -s 256 'để xem lưu lượng truy cập AFS.
Các gói trả lời AFS không xác định rõ ràng hoạt động RPC. Thay vào đó, tcpdump theo dõi các yêu cầu `` gần đây '' và so khớp chúng với các câu trả lời bằng cách sử dụng số gọi và ID dịch vụ. Nếu câu trả lời không tuân theo yêu cầu tương ứng, nó có thể không được phân tích cú pháp.
KIP Appletalk (DDP trong UDP)
Các gói DDP appletalk được gói gọn trong các gói dữ liệu UDP được bỏ gói và được bán thành các gói DDP (nghĩa là tất cả các thông tin tiêu đề UDP bị loại bỏ). Tập tin /etc/atalk.names được sử dụng để dịch các số mạng và số nút của appletalk thành các tên. Các dòng trong tệp này có dạng
tên số 1,254 ête 16,1 icsd-net 1,254,10 aceHai dòng đầu tiên cung cấp tên của các mạng appletalk. Dòng thứ ba cung cấp tên của một máy chủ cụ thể (một máy chủ được phân biệt với một mạng bằng octet thứ 3 trong số đó - một số net phải có hai octet và một số máy chủ phải có ba octet.) Số và tên nên được tách ra bởi khoảng trắng (khoảng trống hoặc tab). Tệp /etc/atalk.names có thể chứa các dòng trống hoặc dòng chú thích (các dòng bắt đầu bằng `# ').
Các địa chỉ Appletalk được in dưới dạng:
net.host.port 144.1.209.2> icsd-net.112.220 office.2> icsd-net.112.220 jssmag.149.235> icsd-net.2(Nếu /etc/atalk.names không tồn tại hoặc không chứa mục nhập cho một số máy chủ lưu trữ appletalk / số net, địa chỉ được in ở dạng số.) Trong ví dụ đầu tiên, NBP (DDP port 2) trên mạng 144.1 nút 209 đang gửi đến bất cứ điều gì đang lắng nghe trên cổng 220 của nút icsd net 112. Dòng thứ hai là như nhau ngoại trừ tên đầy đủ của nút nguồn được biết (`office '). Dòng thứ ba là gửi từ cổng 235 trên nút net jssmag 149 để phát trên cổng NBP icsd-net (lưu ý rằng địa chỉ quảng bá (255) được biểu thị bằng tên net không có số máy chủ - vì lý do này, đó là ý tưởng hay để giữ tên node và tên mạng riêng biệt trong /etc/atalk.names).
NBP (giao thức ràng buộc tên) và gói ATP (giao thức giao thức Appletalk) có nội dung của chúng được diễn giải. Các giao thức khác chỉ đổ tên giao thức (hoặc số nếu không có tên được đăng ký cho giao thức) và kích thước gói.
Gói NBP được định dạng giống như các ví dụ sau:
icsd-net.112.220> jssmag.2: nbp-lkup 190: "=: LaserWriter @ *" jssmag.209.2> icsd-net.112.220: nbp-trả lời 190: "RM1140: LaserWriter @ *" 250 techpit.2> icsd -net.112.220: nbp-trả lời 190: "techpit: LaserWriter @ *" 186Dòng đầu tiên là một yêu cầu tra cứu tên cho các máy ghi âm được gửi bởi máy chủ icsd mạng 112 và được phát trên mạng jssmag. Các nbp id cho tra cứu là 190. Dòng thứ hai cho thấy một trả lời cho yêu cầu này (lưu ý rằng nó có cùng một id) từ máy chủ jssmag.209 nói rằng nó có một nguồn tài nguyên laserwriter tên là "RM1140" đăng ký trên cổng 250. Thứ ba dòng là một trả lời cho cùng một yêu cầu nói rằng techpit chủ có laserwriter "techpit" đăng ký trên cổng 186.
Định dạng gói ATP được thể hiện bằng ví dụ sau:
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 khởi tạo id giao dịch 12266 với máy chủ lưu trữ bằng cách yêu cầu tối đa 8 gói (`<0-7> '). Số hex ở cuối dòng là giá trị của trường `userdata 'trong yêu cầu.
Helios đáp ứng với 8 gói 512 byte. Chữ số ':' sau id giao dịch cung cấp số thứ tự gói trong giao dịch và số trong parens là lượng dữ liệu trong gói, ngoại trừ tiêu đề atp. `* 'Trên gói 7 chỉ ra rằng bit EOM đã được thiết lập.
Jssmag.209 sau đó yêu cầu các gói 3 & 5 được truyền lại. Helios gửi lại chúng sau đó jssmag.209 phát hành giao dịch. Cuối cùng, jssmag.209 khởi tạo yêu cầu tiếp theo. `* 'Trên yêu cầu chỉ ra rằng XO (` chính xác một lần') không được thiết lập.
Phân mảnh IP
Các gói dữ liệu Internet bị phân mảnh được in dưới dạng
(frag id : size @ offset +) (frag id : size @ offset )(Biểu mẫu đầu tiên cho biết có nhiều mảnh hơn. Biểu mẫu thứ hai cho biết đây là đoạn cuối cùng.)
Id là id phân đoạn. Kích thước là kích thước phân đoạn (tính bằng byte), không bao gồm tiêu đề IP. Offset là phần bù đắp của mảng (tính bằng byte) trong datagram gốc.
Thông tin phân đoạn là đầu ra cho từng đoạn. Phân đoạn đầu tiên chứa tiêu đề giao thức cấp cao hơn và thông tin frag được in sau thông tin giao thức. Các phân đoạn sau lần đầu tiên không chứa tiêu đề giao thức cấp cao hơn và thông tin frag được in sau địa chỉ nguồn và đích. Ví dụ, đây là một phần của ftp từ arizona.edu đến lbl-rtsg.arpa qua kết nối CSNET không xuất hiện để xử lý datagrams 576 byte:
arizona.ftp-data> rtsg.1170:. 1024: 1332 (308) ack 1 giành chiến thắng 4096 (frag 595a: 328 @ 0 +) arizona> rtsg: (frag 595a: 204 @ 328) rtsg.1170> arizona.ftp-data:. ack 1536 giành chiến thắng 2560Có một vài điều cần lưu ý ở đây: Thứ nhất, địa chỉ trong dòng thứ 2 không bao gồm số cổng. Điều này là do thông tin giao thức TCP là tất cả trong đoạn đầu tiên và chúng tôi không biết cổng hoặc số thứ tự là gì khi chúng tôi in các đoạn sau. Thứ hai, thông tin chuỗi tcp trong dòng đầu tiên được in như thể có 308 byte dữ liệu người dùng khi, trên thực tế, có 512 byte (308 trong frag đầu tiên và 204 trong giây thứ hai). Nếu bạn đang tìm kiếm các lỗ hổng trong không gian chuỗi hoặc cố gắng kết hợp các gói với các gói, điều này có thể đánh lừa bạn.
Một gói với cờ IP không phân đoạn được đánh dấu bằng dấu (DF) .
Dấu thời gian
Theo mặc định, tất cả các dòng đầu ra được đặt trước bởi dấu thời gian. Dấu thời gian là thời gian đồng hồ hiện tại trong biểu mẫu
hh: mm: ss.fracvà chính xác như đồng hồ của hạt nhân. Dấu thời gian phản ánh thời gian hạt nhân đầu tiên nhìn thấy gói. Không có nỗ lực nào được thực hiện để giải thích thời gian trễ giữa khi giao diện ethernet loại bỏ gói tin khỏi dây và khi hạt nhân phục vụ ngắt gói mới.
XEM THÊM
giao thông (1C), nit (4P), bpf (4), pcap (3)
Quan trọng: Sử dụng lệnh man ( % man ) để xem cách một lệnh được sử dụng trên máy tính cụ thể của bạn.