Crecimiento de internautas en México

This section discusses the use of network protocol analyzers or packet sniffers to debug communications between client and server applications. When you are trying to debug a network application, you often do not have access to the source code, making it like a black box. When you eavesdrop on the communications between these black boxes, you can often find information or see errors that are not normally exposed to you. For example, you might find application errors or authentication failures in the network trace, but the application will not give any indications of failures. A common method for problem determination is to take a network trace from a known working operation and compare it to the trace from a a non-working operation. This allows you to compare the two operations and determine at what point the operation failed.

Attention: Before using a network packet sniffer, ensure that the use of this tool is not restricted in your organization or illegal in your locality. While packet sniffers are legitimate and useful tools, they can also be used by malicious hackers to capture sensitive information in the network.

Attention: When using SSL to encapsulate the LDAP protocol, all details of the network conversation are encrypted and not useful for debugging. The only nonencrypted packet will be the initial SSL handshake. One suggestion is to disable the use of SSL until your problem is solved.

In order to capture a packet trace, you must run the tcpdump command and either capture and display the packets in real-time or write the captured packets to a file for later analysis. When using the tcpdump command to view a packet trace, information about the captured packets can be displayed with varying levels of detail. The following examples do not use the real-time display of captured packets, as tcpdump can only display the captured data and not decode network protocols such as LDAP.

The biggest limitation with the tcpdump command is extremely limited support for decoding network protocols. The best option is to take a network trace with tcpdump and then use either an open source or commercial network protocol analyzer. Ethereal is an open source network protocol analyzer that is licensed under the GNU General Public License (GPL). For more information about and to download the Ethereal package please use the following Web site:

http://www.ethereal.com/

Example 4-36 shows how to use the tcpdump command to capture a network trace for later analysis by a network protocol analyzer. The options specified in the following tcpdump command are as follows:

-c 40 This option specifies that tcpdump should exit after capturing 40 packets. If no packet count is specified, tcpdump will continue to capture packets until it is interrupted.

-s 1600 This option specifies that tcpdump should capture the first 1600 bytes of the packet rather than the default of 68 bytes. While the default snap length is sufficient to capture most IP, TCP, UDP, and ICMP headers, protocol information might be truncated if the snap length is too small.

-w /tmp/tcpdump.out This option specifies the file name to write the captured network packets into.

port ldap This option specifies the expression used to restrict capturing packets that match certain requirements. You are often interested only in conversations between specific machines or using certain protocols. The expression port ldap will capture all packets to and from the local machine that have the LDAP port in the source or destination port number.

Example 4-36 Using the tcpdump command to capture packets for later analysis

# tcpdump -c 40 -s 1600 -w /tmp/tcpdump.out port ldap

tcpdump: listening on en1, link-type 1, capture size 1600 bytes 111 packets received by filter

0 packets dropped by kernel

#

# ls -l /tmp/tcpdump.out

-rw-rw-r-- 1 root system 1530 Oct 20 02:07 /tmp/tcpdump.out

#

Example 4-37, Example 4-38 on page 149, and Figure 4-2 on page 150 all illustrate different views of the network trace captured in the previous example.

The LDAP packets were generated by telneting as the test03 user into the local machine.

Example 4-37 shows the basic output from the tcpdump command, displaying the list of captured packets and their capture time, protocol, source and destination host name, source and destination port numbers, and other flags. The packets on lines 7 and 8 are highlighted, as we will limit our future packet analysis to only those two packets to conserve space.

Example 4-37 Displaying summary of captured packets using the tcpdump command

# tcpdump -r /tmp/tcpdump.out

reading from file /tmp/tcpdump.out, link-type 1

02:06:48.196130 IP bs01b08.example.com.1023 > bs01b06.example.com.ldap: P 1889799466:1889799564(98) ack 4039034172 win 65535

02:06:48.196558 IP bs01b06.example.com.ldap > bs01b08.example.com.1023: P 1:23(22) ack 98 win 64954

02:06:48.344932 IP bs01b08.example.com.1023 > bs01b06.example.com.ldap: . ack 23 win 65535 02:06:50.747088 IP bs01b08.example.com.34038 > bs01b06.example.com.ldap: S

654831232:654831232(0) win 65535 <mss 1460>

02:06:50.747176 IP bs01b06.example.com.ldap > bs01b08.example.com.34038: S 4146056382:4146056382(0) ack 654831233 win 16384 <mss 1460>

02:06:50.747209 IP bs01b08.example.com.34038 > bs01b06.example.com.ldap: . ack 1 win 65535 02:06:50.747331 IP bs01b08.example.com.34038 > bs01b06.example.com.ldap: P 1:60(59) ack 1 win 65535

02:06:50.748948 IP bs01b06.example.com.ldap > bs01b08.example.com.34038: P 1:23(22) ack 60 win 65476

02:06:50.749065 IP bs01b08.example.com.34038 > bs01b06.example.com.ldap: P 60:67(7) ack 23 win 65535

02:06:50.749085 IP bs01b08.example.com.34038 > bs01b06.example.com.ldap: F 67:67(0) ack 23 win 65535

02:06:50.749170 IP bs01b06.example.com.ldap > bs01b08.example.com.34038: . ack 68 win 65469 02:06:50.749272 IP bs01b06.example.com.ldap > bs01b08.example.com.34038: F 23:23(0) ack 68 win 65469

02:06:50.749295 IP bs01b08.example.com.34038 > bs01b06.example.com.ldap: . ack 24 win 65535 02:06:53.055463 IP bs01b08.example.com.1023 > bs01b06.example.com.ldap: P 98:153(55) ack 23 win 65535

02:06:53.055681 IP bs01b06.example.com.ldap > bs01b08.example.com.1023: P 23:68(45) ack 153 win 64899

02:06:53.145587 IP bs01b08.example.com.1023 > bs01b06.example.com.ldap: . ack 68 win 65535

#

The first highlighted packet is the LDAP client attempting to bind to the LDAP server using a DN and password of

CN=test03,CN=Users,DC=example,DC=com and passw0rd!. The second highlighted packet is the LDAP server’s reply to the bind request. Example 4-38 shows the tcpdump command’s output using the -X command-line option to display the packet information in both hexadecimal and in ASCII. The bind DN and password were transmitted in clear text and are visible in the captured packet. Since the LDAP protocol elements are encoded before transmission, visualizing most of the LDAP protocol using ASCII or hexadecimal is not very useful.

Example 4-38 Displaying ASCII and hexadecimal packet dump using tcpdump command

# tcpdump -r /tmp/tcpdump.out -X

reading from file /tmp/tcpdump.out, link-type 1

<output removed>

02:06:50.747331 IP bs01b08.example.com.34038 > bs01b06.example.com.ldap: P 1:60(59) ack 1 win 65535

02:06:50.748948 IP bs01b06.example.com.ldap > bs01b08.example.com.34038: P 1:23(22) ack 60 win 65476

Figure 4-2 on page 150 shows the use of the Ethereal package to decode packet number 7, the LDAP bind operation with the server. The default screen for Ethereal is split up into three sections: the packet list, details, and bytes. The packet list section displays the list of all of the packets in the packet trace. The packet detail section displays the detailed protocol information about the current

packet. The packet bytes section displays the hexadecimal and ASCII bytes, similar to the -X option on tcpdump.

Figure 4-2 Decoding LDAP operations using the Ethereal Network Protocol Analyzer