Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
ngrep
ngrep is used for watching network traffic. It is based with the libpcap library, which provides packet-capturing functionality. ngrep allows regular expression style filters to be used to select traffic to be displayed.
ngrep is the first utility discussed that doesn't ship on most Linux systems.We'll talk about how to get and install it, how to start it up and use it, and more advanced use.
Getting and Installing ngrep
Source code for ngrep is available from http://ngrep.sourceforge.net/, as are some binary packages. I'll only review installing the source code because the binary packages are fairly straightforward.
On a Red Hat 6.2 system, you'll need to install libpcap before you can install ngrep. This package is available from http://www.tcpdump.org/release. As of this writing, the most recent version is libpcap-0.5.2.tar.gz. After download, I put things like this into /usr/local/src; you should do something like Listing 11.
Listing 11 Building libpcap
$ tar xvzf libpcap-0.5.2.tar.gz $ cd libpcap_0_5rel2 $ ./configure $ make $ su Password:******** # make install-incl # make install-man # exit
Your next step is to build ngrep itself. ngrep source code can be downloaded from http://www.packetfactory.net/Projects/ngrep. After downloading it, follow the steps in Listing 12.
Listing 12 Building ngrep
$ tar xzvf ngrep-1.38.tar.gz $ cd ngrep $ ./configure $ make $ su Password:******** # make install # exit
Congratulations! At this point, you should have a working copy of ngrep installed on your system.
Using ngrep
To start using ngrep, you'll need to decide what pattern you want to search for. These can be either libpcap-style descriptions of network traffic or GNU grep-style regular expressions describing the contents of traffic. In the following example, you'll grab any packet containing the pattern ssword and display it in the alternative format (which I think is a lot more readable). The results are shown in Listing 13.
Listing 13 Looking for Something with ngrep
[root@cherry /root]# ngrep -x ssword interface: eth0 (192.168.1.0/255.255.255.0) match: ssword ################################ T 192.168.1.20:23 -> 192.168.1.10:1056 [AP] 50 61 73 73 77 6f 72 64 3a 20 Password: #########################exit 59 received, 0 dropped [root@cherry /root]#
Each hash mark in this example represents a packet not containing the pattern you're searching for; any packets containing the pattern are displayed. In this example, you followed the basic syntax of ngrep: ngrep <options>[pattern]. You used only the -x option, which sets the alternative display format.
Doing More with ngrep
A number of additional twists are available for the way that you can use ngrep. Chief among them is the capability to include libpcap-style packet filtering. libpcap provides a fairly simple language for filtering traffic.
Filters are written by combining primitives with conjunctions (and and or). Primitives can be preceded with the term not.
Primitives are normally formed with an ID (which can be numeric or a symbolic name preceded by one or more qualifiers). There are three kinds of qualifiers: type, direction, and protocol.
Type qualifiers describe what the ID refers to. Allowed options are host, net, and port. If no type is given, the primitive defaults to host. Examples of type primitives are host crashtestdummy, net 192.168.2, or port 80.
Directional qualifiers indicate which direction traffic is flowing in. Allowable qualifiers are src and dst. Examples of direction primitives are src cherry, dst mango, and src or dst port http. This last example shows two qualifiers being used with a single ID.
Protocol qualifiers limit the captured packets to those of a single protocol. In the absence of a protocol qualifier, all IP packets are captured (subject to other filtering rules). Protocols that can be filtered are TCP, UDP, and ICMP.You might use a protocol qualifier such as icmp or tcp dst port telnet.
Primitives can be negated and combined to develop more complex filters. If you want to see all traffic to rose except Telnet and FTP data, you could use the filter host dst rose and not port telnet and not port ftp-data.
Some command-line switches are worth noting as well. Table 3 shows the command-line switches likely to be of the most use. As usual, check the man page for more detail.
Table 3 Command-Line Switches for ngrep
|
Switch |
Description |
|
-e |
Shows empty packets |
|
-n [num] |
Matches num packets and then exits |
|
-i [expression] |
Searches for the regular expression without regard to case |
|
-v [expression] |
Searches for packets not containing the regular expression |
|
-t |
Prints a YYYY/MM/DD HH:MM:SS.UUUUUU timestamp on each matched packet |
|
-T |
Displays a +S.UUUUUU timestamp on each matched packet |
|
-x |
Shows the packets in the alternate hex and ASCII style |
|
-I [filename] |
Reads from a pcap-style dump named filename instead of live traffic |
|
-O filename |
Writes output to a pcap-style file named filename |
|
-D |
Mimics real time by printing matched packets at their recorded timestamp |
Wrapping Up ngrep
Using ngrep can help you quickly match and display packets during your troubleshooting. If you've got an application level problem, ngrep can help you isolate the problem.
For example, if I was trying to make a connection from cherry (192.168.1.10) to cuke (192.168.2.10) and the connection was failing, I might troubleshoot the problem like this:
Describe the symptoms—Cherry cannot make a connection to hosts on remote network, but it can connect to hosts on other networks. Other hosts on cherry's network can connect to hosts on the remote network.
Understand the environment—The hosts involved are cherry, rhubarb (the gateway to the remote network), and cuke.
List hypotheses—My problems might be a misconfiguration of cherry or of an intervening router.
Prioritize hypothesis and narrow focus—Because cuke seems to be the only host affected, start looking there. If you can't solve the problem on cuke, move to rhubarb.
Create a plan of attack—I can try to ping cuke from cherry while using ngrep to see what traffic I am sending, like this: ngrep host cherry.
Act on the plan—As you start pinging cuke, you can see the results of the ngrep session in Listing 14.
Listing 14 Results of an ngrep Session
[root@cherry /root]# ngrep -e -x host 192.168.1.10 interface: eth0 (192.168.1.0/255.255.255.0) filter: ip and ( host 192.168.1.10 ) # I 192.168.1.10 -> 192.168.2.10 8:0 eb 07 00 00 31 86 a7 39 5e cd 0e 00 08 09 0a 0b ....1..9 ^....... 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b ................ 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b .... !"#$%&'()*+ 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ,-./01234567 # I 192.168.1.1 -> 192.168.1.10 5:1 c0 a8 01 0b 45 00 00 54 25 f2 00 00 40 01 d0 52 ....E..T%...@..R c0 a8 01 0a c0 a8 02 0a 08 00 dc 67 eb 07 00 00 ...........g.... 31 86 a7 39 5e cd 0e 00 08 09 0a 0b 0c 0d 0e 0f 1..9^........... 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................ 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./ 30 31 32 33 34 35 36 37 b4 04 01 00 06 00 00 00 01234567........ 00 10 00 00 01 00 00 00 e8 40 00 00 .........@.. exit 2 received, 0 dropped [root@cherry /root]#
This shows two packets. The first is an ICMP packet of Type 8 and Code 0, a ping request. It is destined for cuke. The second is an ICMP packet of Type 5 and Code 1 and ICMP Redirect.This is coming from mango, the gateway to the rest of the world.
Test the results—You shouldn't expect to see mango involved at all. If you look at the ICMP Redirects being sent (using the -v switch), you can see that you're being redirected to the 192.168.1.11 address, not rhubarb.
Apply results of the test to the hypothesis—If you're not sending your traffic to the right gateway, it will never get to the right place.You should be able to solve this by adding a route to the 192.168.2.0/24 network on cherry (a quick check of working hosts shows that this is the way they're configured).You'll probably want to fix the bad route on mango as well.
Iterate as needed—When you've made the change and tested it, you know that it works and don't need to go any further.