IntroductionNetworks have become so ubiquitous that in many cases we take the use of the network to communicate with different machines, inside and outside of our network, for granted. Most of the time this isn't an issue, but there are times when you need to take a closer look at your network and find out what is going on.
There are a number of reasons to take a closer look at the contents of the network traffic. The first is that you may simply be debugging an existing network application or one you are developing, and want to monitor the traffic going past on your network. The second reason is to identify traffic on your network that may be using up bandwidth and resources. For the former, you probably already know the contents of the protocol, but you may want to get a more detailed look at the actual data being transferred, for example, when using web services. For the latter, identifying the contents of the packets requires some extensive knowledge of the protocols being used.
With both TCP/IP and UDP/IP communications, the key elements are the IP addresses used to identify the hosts and the port number. The port number is used to provide additional communication channels so that you can support multiple connections between two hosts. There are some standards in the port definitions. For example, port 25 is for email (SMTP) traffic, and most websites operate on port 80 (HTTP). These conventions are used to allow programs to communicate with each other over a known channel in the same way as you would choose a phone or fax number.
While these conventions exist, there is no limit or restriction on what ports you use. In fact, in many cases, subversive network applications and some security methods will deliberately use non-standard ports. For example, some will hide content by misusing a standard port with a different protocol, like using HTTP over port 25. Other examples include using a different port from the standard so that it is not obvious which port is being used for the traffic (like using port 99 for HTTP), or by encapsulating specific protocol traffic within another protocol. This last method is actually the one used by network tunneling and virtual private networks (VPNs).
Regardless of the reasons or complexities of the network traffic, the first step is always to start recording the data.Recording raw dataThere are a number of different tools available if you want to record the raw network data so that you can examine the information yourself. Most of the network sniffers will also decode and decipher specific packet contents, which will help you when you want to study the content of a recognized protocol.
Under Solaris you can use the snoop tool, or under AIX the iptrace tool. You can also try the cross-platform tcpdump tool, which is supported on most UNIX and Linux operating systems. These provide a combination of both capturing and decoding content for you, often performing the bulk of the protocol analysis process for you. Note that with modern switches the Ethernet packets are not echoed to every port, which often limits the information you can extract to the current host. Many modern switches provide a management port that often carries a copy of all packets for exactly this type of monitoring.
The primary complexity behind decoding network transmission is the levels of information that are provided within the network packets. In addition, much of this information is also sent encoded in binary format, and capturing pure raw packets off of the network requires a significant amount of work to pick out the data that you need. By using a tool that provides some of the processing, you can simplify the process of decoding network data. Read more: IBM
There are a number of reasons to take a closer look at the contents of the network traffic. The first is that you may simply be debugging an existing network application or one you are developing, and want to monitor the traffic going past on your network. The second reason is to identify traffic on your network that may be using up bandwidth and resources. For the former, you probably already know the contents of the protocol, but you may want to get a more detailed look at the actual data being transferred, for example, when using web services. For the latter, identifying the contents of the packets requires some extensive knowledge of the protocols being used.
With both TCP/IP and UDP/IP communications, the key elements are the IP addresses used to identify the hosts and the port number. The port number is used to provide additional communication channels so that you can support multiple connections between two hosts. There are some standards in the port definitions. For example, port 25 is for email (SMTP) traffic, and most websites operate on port 80 (HTTP). These conventions are used to allow programs to communicate with each other over a known channel in the same way as you would choose a phone or fax number.
While these conventions exist, there is no limit or restriction on what ports you use. In fact, in many cases, subversive network applications and some security methods will deliberately use non-standard ports. For example, some will hide content by misusing a standard port with a different protocol, like using HTTP over port 25. Other examples include using a different port from the standard so that it is not obvious which port is being used for the traffic (like using port 99 for HTTP), or by encapsulating specific protocol traffic within another protocol. This last method is actually the one used by network tunneling and virtual private networks (VPNs).
Regardless of the reasons or complexities of the network traffic, the first step is always to start recording the data.Recording raw dataThere are a number of different tools available if you want to record the raw network data so that you can examine the information yourself. Most of the network sniffers will also decode and decipher specific packet contents, which will help you when you want to study the content of a recognized protocol.
Under Solaris you can use the snoop tool, or under AIX the iptrace tool. You can also try the cross-platform tcpdump tool, which is supported on most UNIX and Linux operating systems. These provide a combination of both capturing and decoding content for you, often performing the bulk of the protocol analysis process for you. Note that with modern switches the Ethernet packets are not echoed to every port, which often limits the information you can extract to the current host. Many modern switches provide a management port that often carries a copy of all packets for exactly this type of monitoring.
The primary complexity behind decoding network transmission is the levels of information that are provided within the network packets. In addition, much of this information is also sent encoded in binary format, and capturing pure raw packets off of the network requires a significant amount of work to pick out the data that you need. By using a tool that provides some of the processing, you can simplify the process of decoding network data. Read more: IBM
Posts
0 comments:
Post a Comment