Explanation of tcpdump usage and case analysis

Explanation of tcpdump usage and case analysis
[Root @ linux ~] # Tcpdump [-nn] [-I interface] [-w storage file name] [-c times] [-AE] [-qX] [-r file] [retrieve data content] Parameters

Number:-nn: the IP address and port number are displayed directly, instead of the Host Name and service name-I: the network interface to be listened to, such as eth0, lo, ppp0 and so on.-w: If you want to store the packet data from the listener, use this parameter! Followed by the file name-c: Number of listening packets. Without this parameter, tcpdump continuously listens until the user inputs [ctrl]-c. -A: The content of the packet is displayed in ASCII format. It is usually used to capture the webpage package information of WWW. -E: Use the MAC packet data of the Data Connection layer (OSI Layer 2) for display.-q: only the brief packet information is displayed, and the content of each row is simplified-X: it can list hex and ASCII packet content, which is useful for listening to the packet content-r: Read the packet data from the subsequent files. The "ARCHIVE" is an existing archive, and the "ARCHIVE" is created by-w. Data retrieved by the consumer: We can perform packet capture for certain communication protocols or IP sources,

 

The output results can be simplified and the most useful information can be obtained. Common Representation Methods: 'host foo', 'host 127.0.0.1 ': capture packets for a single host 'net 123456': capture packets for a domain; 'src host 127.0.0.1 ''dst net 100': A source (src) or destination (dst) Restriction 'tcp port 21' is added. It can also be used for communication protocol detection, such as tcp, udp, arp, ether, and so on can also use and or for Integrated Display of Packet Data!

Example 1: capture packets on the eth0 network card with IP and port number for 3 seconds [root @ linux ~] # Tcpdump-I eth0-nntcpdump: verbose output suppressed, use-v or-vv for full protocol decodelistening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes01: 33: 40.41 IP 192.168.1.100.22> 192.168.1.11.1190: P :232 (116) ack 1 win 964801: 33: 40.41 IP 192.168.1.100.22> 192.168.1.11.1190: P 232: 364 (132) ack 1 win 9648 <= Press [ctrl]-c and end 6680 packets captured <= The number of captured packets: 14250 packets receiv Ed by filter <= Total number of packets obtained by filtering: 7512 packets dropped by kernel <= The number of packets discarded by the core. If this is the first time you read the man page of tcpdump, the first two are big, because tcpdump is mostly used to analyze the packet header data. If you do not have a simple network packet basis, it is difficult to understand the problem! Therefore, at least you have to go back to the basic network to understand the header data of the TCP packet! ^_^! In the output example produced by example 1, we can roughly distinguish several fields. Let's explain the special font in Example 1:

 

01:33:40. 41: this is the time when the packet was captured. Unit: hour: minute: Second. IP: the communication protocol used by the packet is IP; 192.168.1.100.22>: the IP address 192.168.1.100 is sent to the packet, the shipping port number is 22. You must understand that the greater than (>) symbol refers to the packet transmission direction! 192.168.1.11.1190: the IP address of the acceptor is 192.168.1.11, and port 1190 is enabled for the host to receive the data. P :232 (116): This packet carries the PUSH data transmission mark, and the transmitted data is 116 ~ 232 bytes, so this packet contains 116 bytes of data; ack 1 win 9648: ACK and Window size information. The simplest statement is that the packet is transmitted from 192.168.1.100 to 192.168.1.11, the port through is 22 to 1190, and the data volume with 116 bytes is used as the PUSH flag, it is not an active online sign such as SYN. Haha! It's not easy to understand! Therefore, you must take a look at the data in the TCP header!

Again, if you want to obtain data packets from a host that is busy in the network, you can use tcpdump in combination with pipeline commands and regular notation, after all, it is hard to catch! By using the tcpdump notation, we can easily extract the required data independently. In example 1 above, we only listen to eth0, so the data on the entire eth0 interface will be displayed on the screen, so it is difficult to analyze it! Can we simplify it? For example, to retrieve only the online packet of port 21, you can do this:

 

[root@linux ~]# tcpdump -i eth0 -nn port 21tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes01:54:37.96 IP 192.168.1.11.1240 > 192.168.1.100.21: . ack 1 win 6553501:54:37.96 IP 192.168.1.100.21 > 192.168.1.11.1240: P 1:21(20) ack 1 win 584001:54:38.12 IP 192.168.1.11.1240 > 192.168.1.100.21: . ack 21 win 6551501:54:42.79 IP 192.168.1.11.1240 > 192.168.1.100.21: P 1:17(16) ack 21 win 6551501:54:42.79 IP 192.168.1.100.21 > 192.168.1.11.1240: . ack 17 win 584001:54:42.79 IP 192.168.1.100.21 > 192.168.1.11.1240: P 21:55(34) ack 17 win 5840

In this way, we only propose port 21 information. If you look at it carefully, you will find that packet transmission is bidirectional. The client sends a "request" and the server sends a "response 』, so, of course there is a go back! We can also see the packet operation process through the flow of this package. For example, input the "tcpdump-I lo-nn" listener in a terminal window, and then open a terminal window to connect the Local Machine (127.0.0.1) log on to "ssh localhost". What is the output?

[root@linux ~]# tcpdump -i lo -nn 1 tcpdump:verbose output suppressed, use -v or -vv for full protocol decode 2 listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes 3 11:02:54.253777 IP 127.0.0.1.32936 > 127.0.0.1.22: S 933696132:933696132(0)    win 32767 <mss 16396,sackOK,timestamp 236681316 0,nop,wscale 2> 4 11:02:54.253831 IP 127.0.0.1.22 > 127.0.0.1.32936: S 920046702:920046702(0)    ack 933696133 win 32767 <mss 16396,sackOK,timestamp 236681316 236681316,nop,   wscale 2> 5 11:02:54.253871 IP 127.0.0.1.32936 > 127.0.0.1.22: . ack 1 win 8192 <nop,   nop,timestamp 236681316 236681316> 6 11:02:54.272124 IP 127.0.0.1.22 > 127.0.0.1.32936: P 1:23(22)ack 1 win 8192 <nop,nop,timestamp 236681334 236681316> 7 11:02:54.272375 IP 127.0.0.1.32936 > 127.0.0.1.22: . ack 23 win 8192 <nop,   nop,timestamp 236681334 236681334>

The first two rows shown in the table above are the basic descriptions of tcpdump, and then:

The first line shows the "packets from the client with SYN active connection", and the second line shows the "packets from the server, in addition to ACK ), the SYN line is also marked as active online. The client starts to transfer data after the client responds to the server's confirmation of online establishment (ACK) line 5th. If we use tcpdump to listen for "plaintext" transmission data on the router, such as the FTP transmission protocol, we first issue "tcpdump-I lo port 21-nn-X" on the host end, then log on to the local machine using ftp, and enter the account and password. Then you can find the following information:

[root@linux ~]# tcpdump -i lo -nn -X 'port 21'   0x0030:  0e2e 0b61 3232 3020 2876 7346 5450 6420  ...a220.(vsFTPd.   0x0030:  0e2e 0b67 5553 4552 2064 6d74 7361 690d  ...gUSER.dmtsai.   0x0030:  0e2e 1b38 5041 5353 206d 7970 6173 7377  ...8PASS.mypassw

 

The above output results FTP software uses vsftpd, and the user enters the account name dmtsai and the password is mypasswordisyou. In order to enable the network interface to allow tcpdump to listen, therefore, when tcpdump is executed, the network interface will start in "promiscuous", so you will see a lot of warning messages in/var/log/messages, inform you that your network card is set to be in disorder! Don't worry, it's normal. For more applications, see man tcpdump example: How to Use tcpdump to listen (1) From eth0 adapter and (2) Communication Protocol: port 22, (3) what are the packets whose target source is 192.168.1.100? Answer: tcpdump-I eth0-nn 'port 22 and src host 192.168.1.100 'arp fault case analysis: Fault Phenomenon: A server A-SERVER with solaris operating system in the LAN network connection is not normal, the server cannot be pinged from any host. Troubleshooting: First, check the system. The system itself works normally. There are no special processes running, cpu and memory usage are normal, no firewall is mounted, and the network cable is normal. At this point we use tcpdump to locate the fault, first we will execute the ping command from the B-CLIENT host, send icmp packet to the A-SERVER, as shown below: [root @ redhat log] # ping A-SERVERPING A-SERVER from B-CLIENT: 56 (84) bytes of data. at this point, tcpdump is started in the A-SERVER to capture packets from the host B-CLIENT. A-SERVER # tcpdump host B-CLIENTtcpdump: listening on hme016: 32: 32.611251 arp who-has A-SERVER tell B-CLIENT16: 32: 33.611425 arp who-has A-SERVER tell B-CLIENT16: 32: 34.611623 arp who-has A-SERVER tell B-CLIENT we see, did not receive the expected ICMP packet, instead captured the arp broadcast packet sent by the B-CLIENT, because the host B-CLIENT can not use arp to get the address of the server A-SERVER, so repeatedly ask the MAC address of the A-SERVER, it seems that the possibility of high-level problems is not big, it is likely that some problems at the link layer, first look up the host A-SERVER arp table: a-SERVER # arp-a Net to Media TableDevice I P Address Mask Flags Phys Addr ------ quit --------------- hme0 netgate limit 255 00: 90: 6d: f2: 24: 00hme0 A-SERVER limit 255 S 00: 03: ba: 08: b2: 83hme0 BASE-ADDRESS.MCAST.NET 240.0.0.0 SM 01: 00: 5e: 00: 00: 00 please pay attention to the Flags position of the A-SERVER, we see only S sign. We know that in the arp Implementation of solaris, the flags of arp must set the P Flag to respond to ARP requests. Manual increase of p-bit A-SERVER # arp-s A-SERVER 00: 03: ba: 08: b2: 83 pub now call arp-a Look At The A-SERVER # arp-a Net to Media TableDevice IP Address Mask Flags Phys Addr ------ -------------------- ------------- hme0 netgate limit 255 00: 90: 6d: f2: 24: 00hme0 A-SERVER 00000000255 SP 00: 03: ba: 08: b2: 83hme0 BASE-ADDRESS.MCAST.NET 240.0.0.0 SM 01: 00: 5e: 00: 00: 00 we can see that the machine has a PS sign, now, test the system's network connection and restore it to normal. The problem is solved! Example 2: netflow software problem: Fault symptom: Install cisco netflow software on the newly installed network management workstation to analyze the traffic of the routing equipment. The router is configured as required, the software is properly installed locally and no error message is reported. However, when netflow collector is started, no traffic information sent from any vro is received, causing the software to fail. Troubleshooting: Check the routes and Software Repeatedly, And the configuration is correct. When using the step-by-step analysis method, first identify the faulty device, whether the router does not send traffic information or the local system receives the error? I suddenly thought that on the vro, we defined the client to receive data from udp port 9998. We can monitor this port to see if the vro actually sent udp data, if the system can receive data packets from the route, the routing problem may be small, and vice versa. Use tcpdump on the network management workstation to see: nms # tcpdump port 9995 tcpdump: listening on hme018: 15: 34.373435 routea> nms.9995: udp 146418: 15: 34.373829 routea.50111> nms.9995: udp 146418: 15: 34.374100 routea.50111> nms.9995, A firewall is installed on the network management workstation, and udp port 9998 is blocked. Adjust the firewall configuration on the workstation to restore netflow to normal and troubleshoot! Example 3: email server troubleshooting: Fault symptom: a new email server with qmail in the background is installed on the LAN. The basic functions of the mail server, such as sending and receiving emails, are normal, however, there is a common strange phenomenon found during use: it takes a long time to connect to the mail server when sending emails on pc machines to start the actual sending work. Troubleshooting: the network connection is normal. The performance of the email server and the following pc is normal. What is the problem? To locate the problem accurately, we send emails to the client on the PC and use tcpdump on the server to capture and analyze the client data packets, as shown below: server # tcpdump host clienttcpdump: listening on hme019: 04: 30.040578 client.1065> server. smtp: S 1087965815: 1087965815 (0) win 64240 <mss 1460, nop, wscale 0, nop, nop, timestamp [| tcp]> (DF) 19:04:30. 040613 server. smtp> client.1065: S 99285900: 99285900 (0) ack 1087965816 win 10136 <nop, nop, timestamp 20468779 0, nop, [| tcp]> (DF) 4: 30. 040960 client.1065> server. smtp :. ack 1 win 64240 (DF) successfully completed three handshakes, so far normal, look down at 19:04:30. 048862 server.33152> client.113: S 99370916: 99370916 (0) win 8760 <mss 1460> (DF) 19:04:33. 411006 server.33152> client.113: S 99370916: 99370916 (0) win 8760 <mss 1460> (DF) 19:04:40. 161052 server.33152> client.113: S 99370916: 99370916 (0) win 8760 <mss 1460> (DF) 19:04:56. 061130 server.33152> client.113: R 993 70917: 99370917 (0) win 8760 (DF) 19:04:56. 070108 server. smtp> client.1065: P 109 (108) ack 1 win 10136 <nop, nop, timestamp 20471382 167656> (DF) there is a problem here, we can see that the server tried to connect to the client's 113 identd port and required authentication. However, the server did not receive a response from the client, and the server tried three times repeatedly. It took 26 seconds to cancel the authentication request, the packet with the reset flag is actively sent, and the data after the push starts, which is exactly the 26 seconds spent in this process, resulting in a long wait time for sending emails. After finding the problem, you can take the right medicine. By modifying the qmail configuration on the server end, it will no longer perform port 113 authentication, and capture packets again. The mail server will no longer perform port 113 authentication attempts, instead, the data is pushed directly after three handshakes. The problem is solved! I access the Internet through Beijing tietong ADSL and use a four-port route for several users. My IP address is 192.168.2.4. The gateway is 192.168.2.11. Some time ago, when the gateway IP address was not changed, the ADSL account stored in the route often disappeared, and the route password I set was changed back to the factory settings. At that time, it was determined that there was a virus in the LAN. Later I changed it to the current IP address. The IP address of the route can be connected to qq, And the webpage is sometimes very slow. In the early morning, I went online by myself, and it was very slow to open a webpage. Packet Capture 44 6.280504 route 192.168.2.4 HTTP Continuation or non-HTTP traffic45 6.280757 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic46 6.403861 192.168.2.4 resume HTTP Continuation or non-HTTP traffic47 6.403903 192.168.2.4 resume HTTP Continuation or non- HTTP traffic48 6.579872 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic49 6.579911 19 20172.4 accept HTTP Continuation or non-HTTP traffic 6.755121 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic51 6.755165 192.168.2.4 resume HTTP Continuation or non-HTTP traffic52 7.543836 255.192.168.2.4 TCP http> 2974 [ACK] Seq = 168 Ack = 23283 Win = 65535 Len = 053 7.543949 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic54 7.543958 192.168.2.4 configure HTTP Continuation or non-HTTP traffic55 7.677383 222.133.100.166 192.168.2.4 TCP http> 2974 [ACK] Seq = 168 Ack = 24880 Win = 65535 Len = 056 7.677488 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic57 7.677497 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic58 7.678653 222.133.100.166 192.168.2.4 HTTP Continuation or non-HTTP traffic59 7.788 499 listen 192.168.2.4 TCP http> 2974 [ACK] Seq = 224 Ack = 26960 Win = 65535 Len = 060 7.788609 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic61 7.788615 192.168.2.4 222.133.100.166 HTTP Continuation or non- HTTP traffic62 8.625733 222.133.100.166 192.168.2.4 TCP http> 2974 [ACK] Seq = 224 Ack = 29840 Win = 65535 Len = 063 8.625848 192.168.2.4 222.133.100.166 HTTP Continuation or non -HTTP traffic64 8.625856 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP trafficIP query result 222.133.100.166 ping timeout nslookup can't find TCP packet output information src> dst: flags data-seqno ack window urgent optionssrc> dst: indicates from the source address to the destination address, flags are the Flag Information in the TCP packet, S is the SYN flag, F (FIN ), P (PUSH), R (RST )". "(not marked); data-seqno is the sequence number of data in the data packet, ack is the sequence number expected next time, window is the size of the window that receives the cache, and urgent indicates whether there is an emergency pointer in the data packet. options is an option. I think it's in my computer There is a virus on the surface. If there is a virus on the broadband route, My QQ will not be able to continue.