Nmap - The Network Mapper
Author: Fyodor
Required: flex, bison
Homepage: http://www.insecure.org/nmap
Current stable release: 2.53
License: GPL
Platform ports: Linux, FreeBSD, NetBSD, OpenBSD, Solaris, IRIX, BSDI, SunOS, HP-UX, AIX, Digital UNIX, Cray UNICOS and Windows NT.
I. Introduction
The intent of this article is to familiarize the reader with the network scanner nmap. As Lamont Grandquist (an nmap contributor/developer) points out, nmap does three things: It will ping a number of hosts to determine if they are up. It will portscan hosts to determine what services they are offering and it will attempt to determine the OS (operating system) of host(s). Nmap allows the user to scan networks as small as a two node LAN (Local Area Network) or as large as a 500 node LAN and even larger. Nmap also allows you to customize your scanning techniques. Sometimes a simple ICMP (Internet Control Message Protocol) ping sweep may be all you need. If not, then maybe you're looking for a stealth scan giving back reports on UDP (User Datagram Protocol) and TCP (Transmission Control Protocol) ports that are available and as to what operating system the host is using? Still want more? You can do all that and log the data into either human-readable or machine-parsable format. In this article I will be covering some basic to intermediate scanning techniques to get you off and running with nmap. If you love it enough then I would suggest reading the the nmap man pages 50 times and then translating it into the foreign language of your choice;)
II. Getting Nmap
Some Linux distributions come with nmap as part of the install. If you do not have nmap then let's begin with grabbing the latest copy and getting it up and running. The version I will be covering here will be the source code tarball, optionally you have both rpm and source-rpm to choose from . The Linux distribution I am using is Red Hat 6.1. Download the nmap-latest.tgz file into your home directory. Once the download is complete perform tar -zxvf nmap-latest.tgz and this will unpack the source code into your home directory. Go into the newly created nmap-latest directory and read both the README and INSTALL files. Ideally the next step would be to perform configure, make and (as root) make install in the top level of the newly created directory. This will install the nmap binary into /usr/local/bin. From here we're ready to run nmap.
III. Using Nmap
Scanning types
Without further ado, let's get down to business with nmap. First we will need an address to scan against. If you are working from a LAN then pick a number of one of your hosts. Let's say that your LAN consists of two machines: Adam and Eve. Adam (192.168.0.1) is the unit we'll be running nmap on. Eve (192.168.0.2) is the machine we will be scanning. From the command line I would type the following:
nmap 192.168.0.1
Here is a sample output from the scan:
Example 1
Starting nmap V. 2.53 by fyodor@insecure.org (www.insecure.org/nmap)
Interesting ports on Eve (192.168.0.2):
(The 1511 ports scanned but not shown below are in state:closed)
Port State Service
21/tcp open ftp
23/tcp open telnet
25/tcp open smtp
79/tcp open finger
80/tcp open http
98/tcp open linuxconf
111/tcp open sunrpc
113/tcp open auth
513/tcp open login
514/tcp open shell
515/tcp open printer
6000/tcp open X11
Interesting ports on Eve (192.168.0.2):
(The 1511 ports scanned but not shown below are in state:closed)
Port State Service
21/tcp open ftp
23/tcp open telnet
25/tcp open smtp
79/tcp open finger
80/tcp open http
98/tcp open linuxconf
111/tcp open sunrpc
113/tcp open auth
513/tcp open login
514/tcp open shell
515/tcp open printer
6000/tcp open X11
Nmap run completed -- 1 IP address (1 host up) scanned in 1 second
What the above example did was run a vanilla TCP scan against the designated address. As we can see from this sample output our host is up and gives us a list of available ports that are listening. This of course is the most basic of all commands and can be run without any special privileges. The disadvantage of this call is that any host running logging software will easily detect this sort of scan. The output of this call would be the same as adding the option -sT to the command line so it would look like this: nmap -sT 192.168.0.2. (Note that this call is allowable by normal users).
Not on a local LAN? Working from a single host dial-up machine? No problem, run ifconfig (or use your favorite text editor to view your /var/log/messages file, look for the last entry in the messages file that contains a remote IP address) to obtain your IP address and go from there. Let's say my IP address is 206.212.15.23, we can use that as a premise to base our scans on. So with that in mind let's check on our "neighbor":
nmap -sT 206.212.15.22
Here is the sample output:
Example 2
Starting nmap V. 2.53 by fyodor@insecure.org (www.insecure.org/nmap)
Interesting ports on find2-cs-4.dial.ISP.net (206.212.15.22):
(1522 ports scanned but not shown below are in state: closed)
Port State Service
139/tcp open netbios-ssn
Interesting ports on find2-cs-4.dial.ISP.net (206.212.15.22):
(1522 ports scanned but not shown below are in state: closed)
Port State Service
139/tcp open netbios-ssn
Nmap run completed -- 1 IP address (1 host up) scanned in 20 seconds
This is a very basic example of nmap's capabilities but it atleast gives the beginner some grounds to work off of if not on a local LAN.
-sS Now let's say that that you wish to use a more stealthy scan to prevent detection, you would then use our previous example only with the -sS (SYN) call so it would look like this: nmap -sS 192.168.0.2.The -sS (SYN) call is sometimes referred to as the "half-open" scan because you do not initiate a full TCP connection. The output will read the same as example 1 only with a lesser chance of detection from the other end. Unlike running the -sT call this call requires root privileges.
-sF -sX -sN Now for the truly paranoid or instances when the target may be running filtering or logging software that detect SYN we can issue a third type of call with the -sF (Stealth FIN), sX (Xmas Tree) or -sN (Null) scan. Note: Since Microsoft insists on doing things their own way, neither the FIN, Xmas or Null scan modes will work on Windows 95/98 or NT boxes. So if we were to get a listing of available ports running either the -sT or -sS options but "All scanned ports are: closed" running the -sF, sX or -sN option, then we can safely assume that the target is probably a Windows box. This really isn't a necessary procedure to verify a Windows machine since nmap has built in OS detection which we will cover later. These three commands also require root privileges.
-sU This option tells nmap to scan for listening UDP (User Datagram Protocol) rather than TCP ports on a target host. Although this can sometimes be slow on Linux machines it runs particularly fast against Window boxes. Using our previous examples of Adam and Eve, let's run (once again root privilege is required) a -sU scan against Eve:
nmap -sU 192.168.0.2
Here is the sample output from the scan:
Example 3
Starting nmap V. 2.53 by fyodor@insecure.org (www.insecure.org/nmap)
Interesting ports on Eve (192.168.0.2):
(The 1445 ports scanned but not shown below are in state: closed)
Port State Service
111/udp open sunrpc
517/udp open talk
518/udp open ntalk
Interesting ports on Eve (192.168.0.2):
(The 1445 ports scanned but not shown below are in state: closed)
Port State Service
111/udp open sunrpc
517/udp open talk
518/udp open ntalk
Nmap run completed -- 1 IP address (1 host up) scanned in 4 seconds
As we can see nmap scanned 1455 ports on Eve and gave us a listing of the UDP ports it found to be listening. We can gather from examples one and two that we are looking at a Linux install. With that in mind if you remember in the introduction I mentioned that nmap performs three things: It pings, it portscan's and it detects the target's (operating system). Now that we've briefly covered the first two uses let's move onto OS detection
IV. OS detection
-O This is the option to be used to determine the operating system of the given target. It can be used in conjunction with our above mentioned scan types or by itself. Nmap uses what is called TCP/IP fingerprinting to try and accurately determine the OS of the given target. For a more complete reading on OS fingerprinting please see Foyer's article titled "Remote OS detection via TCP/IP fingerprinting" found here. Now with that in mind let's get right to our next example. Using our target host (Eve) from Example 1, I would type the following: (Note that the -O option requires root privileges)
nmap -O 192.168.0.2
Here is a the sample output from the scan:
Example 4
Starting nmap V. 2.53 by fyodor@insecure.org (www.insecure.org/nmap)
Interesting ports on Eve (192.168.0.2):
(The 1511 ports scanned but not shown below are in state:closed)
Port State Service
21/tcp open ftp
23/tcp open telnet
25/tcp open smtp
79/tcp open finger
80/tcp open http
98/tcp open linuxconf
111/tcp open sunrpc
113/tcp open auth
513/tcp open login
514/tcp open shell
515/tcp open printer
6000/tcp open X11
Interesting ports on Eve (192.168.0.2):
(The 1511 ports scanned but not shown below are in state:closed)
Port State Service
21/tcp open ftp
23/tcp open telnet
25/tcp open smtp
79/tcp open finger
80/tcp open http
98/tcp open linuxconf
111/tcp open sunrpc
113/tcp open auth
513/tcp open login
514/tcp open shell
515/tcp open printer
6000/tcp open X11
TCP Sequence prediction: Class=random positive increments
Difficulty=1772042 (Good luck!)
Remote operating system guess: Linux 2.1.122 - 2.2.14
Difficulty=1772042 (Good luck!)
Remote operating system guess: Linux 2.1.122 - 2.2.14
Nmap run completed -- 1 IP address (1 host up) scanned in 1 second
Notice that nmap reports the same available port data as it did in example 1 due to the default -sT option, but also the OS of the machine (in this case Linux) and the kernel version...not bad ehh?! Nmap comes equipped with an impressive OS database.
V. More fun with Nmap
Instead of limiting ourselves to scanning just one target., let's broaden our horizon's to bigger and better things. In example 2 we used our IP address to base a scan against. Using that address again we can get a look at numerous targets in our "community". At the command line type the following (substituting a valid address of your choice of course):
nmap -sT -O 206.212.15.0-50
What this does is instruct nmap to scan every host between the IP addresses of 206.212.15.0 and 206.212.15.50. If you happen to find many interesting feedback results from this or a larger scale scan then you can always pipe the output into your choice of a human readable file or a machine parsable file for future reference by issuing the following option:
To create a human readable output file issue the -oN<textfile name> command into your nmap string so that it would look similar to this:
nmap -sT -O -oN sample.txt 206.212.15.0-50
Rather have a machine parsable file? Enter the -oM <textfile name> to pipe the output into a machine parsable file:
nmap -sT -O -oM sample.txt 206.212.15.0-50
*Back when I was becoming aquatinted with all the nmap options, I ran my first large scale scan against 250 consecutive machines using an arbitrary number (nmap -sX -O -oN sample.txt XXX.XXX.XXX.0-250).To my great surprise I was confronted with 250 up and running virgin Linux machines. Another reason why Linux enthusiasts should NEVER become bored.
-I This is a handy little call that activates nmap's TCP reverse ident scanning option. This divulges information that gives the username that owns available processes. Let's take a look (Note that the host has to be running ident). At the command line issue this command against your target, in this case our default Eve running Linux:
-iR Use this command to instruct nmap to scan random hosts for you.
-p Port range option allows you to pick what port or ports you wish nmap to scan against.
-v Use verbosity to display more output data. Use twice (-v -v) for maximum verbosity.
-h Displays a quick reference of nmap's calls
VI. Gleaning the Cube
Now that we have looked at nmap's three basic usage types and some of it's other options, let's mix and match them.
nmap -v -v -sS -O 209.212.53.50-100
This instructs nmap to use a maximum amount of verbosity to run a stealth scan and OS detection against all machines between IP addresses 209.212.53.50 and 209.212.53.100. This command will also require root privileges due to both the -sS and -O calls. Of course this will display a very overwhelming amount of data so let's log our results into a human readable file for future reference:
nmap -v -v -sS -O -oN sample.txt 209.212.53.50-100
Now let's make nmap run a stealth scan and instruct it to look only for machines offering http and ftp services between the addresses of 209.212.53.50 and 209.212.53.100. Once again we will log the output (I'm a log junkie) for future reference into a human readable file called ftphttpscan.txt:
nmap -sS -p 23,80 -oN ftphttpscan.txt 209.212.53.50-100
Remember the -iR option mentioned previously? Let's use it to take a random sampling of Internet web servers using the verbatim example from nmap's man page:
nmap -sS -iR -p 80
Last but certainly not least, while gleaning information, don't forget to nmap yourself. Just type at the command line: nmap 127.0.0.1 This is especially useful and recommended if you're a newcomer to Linux and connected to the Internet via DSL or cable modem.
VII. Nmap GUI's
Now for those of you who would rather not work on the command line (shame on you) there are graphical front ends for nmap.
NmapFE - NmapFE, written by Zach Smith, comes included in the nmap-2.53.rpm and uses the GTK interface. NmapFE can be found at http://codebox.net/nmapfe.html
Kmap - Kmap, written by Ian Zepp, uses the QT/KDE frontend for nmap at can be found at http://www.edotorg.org/kde/kmap/
KNmap - KNmap, written by Alexandre Sagala, is another KDE frontend for nmap and can be found at http://pages.infinit.net/rewind/
VII. Conclusion
This wraps up our quick and dirty look and nmap. I hope you find the application as enjoyable as I do. Comments or questions can be sent to either myself jafgon@bright.net or fyodor@insecure.org. Happy scanning.
Ethereal
Ethereal
Ethereal is a very functional protocol analyzer.1 It has both a GUI (Ethereal) and a command-line interface (Tethereal). Both provide very easy means of finding and watching network traffic.Listing 1 shows cherry ARPing for a nonexistent host. Figure 1 shows Ethereal having captured some Ethernet traffic.
Listing 1Using Tethereal
[root@cherry /root]# tethereal Kernel filter, protocol ALL, raw packet socket Capturing on eth0 00:e0:98:7c:95:21 -> ff:ff:ff:ff:ff:ff ARP Who has 192.168.1.100?Figure 1 Ethereal screen shot.Tell 192.168.1.10 00:e0:98:7c:95:21 -> ff:ff:ff:ff:ff:ff ARP Who has 192.168.1.100?
Ethereal can give you a great deal of insight into the way things are really working on your network, but only in conjunction with a good understanding of the protocols themselves. In this section we'll look at the following topics:
- Getting and installing Ethereal
- Using Ethereal to capture packets
- Using Ethereal to view packets
- Filtering packets during both capture and display to make network diagnostics a bit simpler
- Dealing with bugs in Ethereal
Getting and Installing Ethereal
Ethereal is available for a wide range of platforms, including Linux, Windows, and several UNIX platforms. Although Ethereal has a command-line interface, it requires that GTK+ be installed on the system on which it is being built. Ethereal also relies on libpcap. I'll build it from source on Linux in this section. However, when you install it, it is important to ensure that you have Ethereal and the two software packages that it relies on. It should also be mentioned that although there are binary distributions of Ethereal available for many platforms, they are not always the most recent. You might want to take the extra time to build your own.Downloading Binary Packages
Certainly the easiest way to install Ethereal is with the package-management system of your Linux distribution. The most recent binary packages for Ethereal are available at http://ethereal.zing.org/download.html. In addition to the Ethereal packages themselves, you'll also need to get packages for libpcap and perhaps for ucd-snmp (this will depend on what is installed on your system). After you've located the requisite packages, you're ready to go.Downloading and Building Source
Building Ethereal is a bit more involved, but not too much. The following build instructions are based on a stock GNOME Workstation install of a Red Hat 6.2 box.Don't forget that you'll need to install libpcap before you can build Ethereal. You can do this either with RPMs or by building it from source. Building from source isn't too hard, but you'll need to deal with a couple gotchas when building libpcap on Red Hat 6.2. First you'll need to make the /usr/local/include and /usr/local/include/net directories. You also must remember to do a make install-incl as well as the make install. The proper installation of libpcap is shown in Listing 2.
Listing 2 Installing libpcap
[root@phred src] tar xzvf libpcap-0.5.2.tar.gz [root@phred src] cd libpcap-0.5 [root@phred libpcap-0.5] ./configure [root@phred libpcap-0.5] make [root@phred libpcap-0.5] make install [root@phred libpcap-0.5] mkdir -p /usr/local/lib/net [root@phred libpcap-0.5] make install-inclAfter libpcap is built, you've got smooth sailing in front of you. Ethereal is a three-step build. Building Ethereal is shown in Listing 3.
Listing 3 Building Ethereal
[root@phred src] tar xzvf ethereal-0.8.14.tar.gz [root@phred src] cd ethereal-0.8.14 [root@phred ethereal-0.8.14] ./configure [root@phred ethereal-0.8.14] make [root@phred ethereal-0.8.14] make install
Using Ethereal to Capture Packets
Because the primary use of a protocol analyzer is to capture packets, that's just what we'll do. I'll start off with a simple example, move to some startup options for Ethereal and Tethereal, and wrap up with a more advanced example.A Simple Example
Using Ethereal can be quite simple; typing Ethereal at the command line (as someone with permission to set the NIC into promiscuous mode) will start the GUI. When the GUI has started, you can select Capture, Start, which brings up the Capture Preferences window. This should have valid defaults set, but I like to click the Update List of Packets in Real Time and Automatic Scrolling in Live Capture buttons. Now press the Start button and watch your capture run.While the capture is running, it displays the total number of packets captured in the Ethereal: Capture/Playback window. It also updates the main Ethereal window with each new packet that it grabs. After you've captured what you needed, you can stop the capture by hitting the Stop button in the Ethereal: Capture/Playback window. While the capture is running, you should see something similar to the display shown in Figure 2.
Figure 2 Ethereal capturing packets.
Starting Ethereal
A number of command-line options exist to help make starting Ethereal more pleasant. Table 1 shows some of the more likely candidates.Table 1 Command Line Options for Ethereal
| Option | Meaning |
| -i <interface> | This option sets the interface from which Ethereal will capture. |
| -k | This option causes Ethereal to begin capturing packets immediately upon startup. It must be used with the xs-i option. |
| -S | This option causes Ethereal to display packets as they are captured. |
| -c <count> | This option causes Ethereal to capture only count packets before stopping. It is useful only with the -k option. |
| -D | This option causes Ethereal to treat the TOS field of IP as the original TOS, not like Differentiated Services. |
| -f <capture filter> | This option enables you to set a libpcap-style capture filter. libpcap filter syntax is covered in the "ngrep" section of my previous article, "Troubleshooting Tools." |
| -n | This option disables name resolution; all packets will be displayed with numeric IP addresses, TCP ports, and UDP ports. |
| -r <infile> | This option causes Ethereal to read packets from a saved file instead of an interface. Using previous captures is covered in the upcoming section "Viewing Saved Captures." |
| -R <read filter> | This option enables you to set a read filter. Read filters are discussed in the upcoming section "Filtering Packets to Be Displayed." |
| -t <time stamp format> | This option changes the format of the packet timestamps. The three possible formats are as follows: r—Relative to the first packet (the default) a—Actual date and time of the packet d—Relative to the previous packet |
| -w <savefile> | This option sets the name of the file to which the capture will be saved. Working with saved captures is covered in the upcoming section "Viewing Saved Captures." |
[root@cherry /root]# ethereal -i eth0 -c 100 -D -t a -k -S &This starts Ethereal, begins capturing from eth0 immediately, displays packets as they're captured using the original IPv4 TOS meaning for the TOS field, displays actual times for each packet, and stops capturing after 100 packets have been captured.
Starting Tethereal
Tethereal can be run in instances in which you have no good way to display the GUI for Ethereal or you don't need its extra weight to accomplish the task at hand (for example, you're just doing a file capture). Tethereal can be run like the session shown in Listing 4.Listing 4 Starting Tethereal
[root@cherry /root]# tethereal Kernel filter, protocol ALL, raw packet socket Capturing on eth0 skull.eventloop.com -> 192.168.1.10 IRC Response 192.168.1.10 -> resolver1.level3.net DNS Standard query PTRLike Ethereal, however, Tethereal is often better used with the command-line options listed in Table 1. Some of the options either make no sense in the context of the Tethereal interface (for instance, -t because there is no time display in Tethereal2) or are not allowed (for instance, -S). A good example of a more useful Tethereal command might be this:
[root@cherry /root]# tethereal -i eth0 -c 10 -n -w quickcaptureThis command captures the next 10 packets received on eth0 in the file quickcapture without doing a name resolution.
Viewing Packets with Ethereal
The main window for Ethereal is divided into three sections, called panes. The top pane is the packet list pane, which shows a summary of each packet captured. The middle pane is the tree view pane, which shows a more detailed view of any packet selected in the packet list pane. The bottom pane is the data view pane, which shows a hex breakout and ASCII representation of any packet selected in the packet list pane. There are also menu options of interest when viewing packets; we'll look at these in more detail in the following sections.A Simple Session Revisited
The simple Ethereal session described previously results in the final capture shown in Figure 3.Figure 3 A simple Ethereal capture.
After the data is captured, you can look at it several ways, with a variety of tools.3 One way to look at the data is to review the Ethereal summary data, as shown in Figure 4.
Figure 4 Ethereal summary data.
This summary shows the following:
- Information about the file (which we'll ignore)
- Information about the data (which we'll cover shortly)
- Information about the capture (which we'll cover right after the information about the data)
The capture information provides the context needed to make sense of the capture. It shows what interface the capture is from, what capture filter was used, and what display filter is in use. In the IRC example described in the previous paragraph, the data would be misleading if it also contained HTTP traffic. Looking at the capture information can help ensure that we're looking at just the data we want.
Another way of looking at the packets is to look at only those packets matching certain criteria. To be really effective at this, you'll need to write a display filter, but Ethereal provides a quick mechanism to create a simple filter for you. If you select a field in tree view pane, for example, selecting an Ethernet II Type field containing ARP, then clicking Display, Match Selected creates a display filter matching all packets with an Ethernet II type of ARP. This is shown in Figures 5 and 6.
Figure 5 Selecting content to match.
Figure 6 Ethereal matching selected packets.
Because captured traffic is spread over several packets, it can be difficult to see just what traffic is being pushed around the network. Ethereal provides a way to do this, following a TCP stream. In Figure 7, you can see a TCP stream containing an HTTP session. You can follow a TCP session by selecting a TCP packet in the packet list pane and then clicking Tools, Follow TCP Stream.
Figure 7 A TCP stream.
In this example, the first block of data is an HTTP request sent by the client. The second block of data is an HTTP error message returned by the server.
Saving a Capture File
Having captured a pile of network traffic, you'll probably want to look at it again later. Ethereal enables you to save your capture to a file. This can be done from the command line (the only way to do it with Tethereal), from the Capture Preferences screen, or after you've stopped a capture by selecting File, Save (which is also accessible from the keyboard shortcut Ctrl+S). This brings up the Save Capture File As window.This window enables you to save your capture in a number of formats; it also enables you to save only the currently displayed packets (using the Save Only Packets Currently Being Displayed button).
Viewing Saved Captures
Sometimes you'll want to look at traffic that's no longer moving on the network (either for diagnostics or to review or learn more about a protocol). For these cases, Ethereal provides a convenient method for saving and viewing captured files. In fact, Ethereal even provides the capability to view captures saved from other applications.To view a saved capture, select File, Open, which brings up the Open Capture File interface. This window presents a common file selection tool with which you should select the name of the capture file that you want to view. You can also select the file on startup, using ethereal -r capturefile.
Filtering Packets with Ethereal
Even a small network can have a lot of data running over it. Filters help you cut through the chaff to see just the data you are interested in. Two kinds of filters exist for Ethereal, capture filters and display filters. Capture filters are applied as the data is being read from the network. If traffic doesn't match the filter, it isn't read into Ethereal. Display filters are applied against traffic that Ethereal has already captured. Both styles of filters, with some pros and cons, are covered in the next two sections.Filtering Packets to Be Captured
Capture filters are written in the libpcap syntax, which is covered in more detail in the section "ngrep" in my previous article, "Troubleshooting Tools." A quick overview is provided here as well. Capture filters are nice because they are very fast and because they operate on the raw traffic as it is being captured. This can be a huge benefit on a busy LAN; you'll get only the traffic you're interested in, not the other 8MB of traffic that you'd otherwise have to wade through. Capture filters are not a panacea, though; they may get you only 50% of the way to your goal. That's where display filters come in.libpcap-style filters use the <not>[type]<direction>[id] (such as host src 192.168.1.10). These filters can be combined with the conjunctions and and or. If you want to see all traffic between 192.168.1.1 and 192.168.1.10, you can use a filter such as host 192.168.1.1 and host 192.168.1.10. To look at traffic going from 192.168.1.1 to host 192.168.1.10 and not the return traffic, you can do host src 192.168.1.1 and host dst 192.168.1.10.
Filtering Packets to Be Displayed
The display filter syntax is much more expressive (and capable) than the capture filters described previously. Although capture filters are entered at the start of the capture (either on the command line or in the Capture Preferences window), display filters are entered after the capture is complete. With a capture buffer loaded, you can define a display filter in the filter section of the status bar at the bottom of the Main window. You can clear your active display filter by clicking the Reset button.Display filters have an expressive syntax but can be quite basic. A simple filter to look at all the traffic from 192.168.1.1 to 192.168.1.10 would look like ip.src == 192.168.1.1 && ip.dst == 192.168.1.10.
A much cooler example would be to look at all traffic from 192.168.1.20 or 192.168.1.21 that has the TCP SYN bit set; this would be written as (ip.src==192.168.1.21 or 192.168.1.20) and tcp.flags.syn. If you want to extend the previous section to exclude HTTPS traffic, you could write ((ip.src==192.168.1.21 or 192.168.1.20) and tcp.flags.syn) ! tcp.port==443.
Ethereal provides additional filter comparison operators as well. ==, !=, >, <, >=, and <= are all available in this C-style format or with English-style names. Beyond this, you can use a substring operator to match fields within a value. For example, you might want to match on the first three octets of an Ethernet source address; you could do that with eth.src [0:3] == 00:a0:d2.
Reporting Bugs
If you happen to find a bug in Ethereal, please report it. If you're a C hacker and think you know how to fix it, don't hesitate to send in a patch as well. (Your patch might not be used, but it will likely help the developers see where things are going wrong.)Bug reports can be directed to the ethereal-dev mailing list (you can subscribe through http://ethereal.zing.org/; click the Mailing Lists link on the left side). Your bug report should include the following three things (at a minimum):
- The version of Ethereal that you are using and the versions of software that it is linked against. This can be grabbed from ethereal -v, like so:
[pate@cherry sgml]$ ethereal -v ethereal 0.8.7, with GTK+1.2.7, with libpcap 0.4,
[pate@cherry pate]$ gdb /usr/bin/ethereal core >This will create a file called backtrace.txt, which you can mail in with your bug report.
http://www.informit.com/articles/article.aspx?p=22174
swatch - simple watcherSynopsis
Description
Swatch is designed to monitor system activity. In order for Swatch to be useful, it requires a configuration file which contains pattern(s) to look for and action(s) to perform when each pattern is found.Command Line Options
--config-file=filename or -c filename- Tells swatch where to find its configuration file. The default is ${ HOME }/.swatchrc.
- --help
- Prints usage information and exits.
- --input-record-separator=regular_expression
- Tells swatch to use regular_expression to delineate the boundary of each input record. The default is a carriage return.
- --restart-time=[+]hh:mm[am|pm] or -r [+]hh:mm[am|pm]
- Restart at the specified time where hh is hours and mm is minutes. If the am/pm indicator is omitted, then a 24-hour clock is assumed. If the time is preceeded by the "+" character, then the restart time will be set to the current time plus the specified time and the am/pm indicator will be ignored.
- --script-dir=/path/to/directory
- This switch causes the temporary watcher script to be written to a file in the specified directory rather than the user's home directory. It is highly advised that you do NOT use directories that are writable by others such as /tmp.
- --version or -V
- Prints version information and exits.
- --use-cpan-file-tail
- Use CPAN 's File::Tail module to read the log file instead of the tail(1) command.
- You may specify only one of the following options:
- --tail-file=filename or -t filename
- Examine lines of text as they are added to filename.
- --read-pipe=command or -p command
- Examine input piped in from the command.
- --examine=filename or -f filename
- Use filename as the file to examine. Swatch will do a single pass through the named file.
- The following options are purely for debugging purposes, but are documented here for completeness:
- --dump-script[=filename]
- Instead of running the watcher script after it is generated, it is written to filename or to STDOUT .
- If swatch is called with no options, it is the same as typing the command line
- * "swatch --config-file=~/.swatchrc --tail-file=/var/log/syslog"
- or if /var/log/messages exists "swatch --config-file=~/.swatchrc --tail-file=/var/log/messages"
- If the configuration file doesn't exist then the following configuration is used:
watchfor /.*/ echo
The Configuration File
The configuration file is used by the swatch(8) program to determine what types of expression patterns to look for and what type of action(s) should be taken when a pattern is matched.Each line should contain a keyword and a, sometimes optional, value for that keyword. The keyword and value are separated by space or an equal (=) sign.
watchfor regex
ignore regex
- echo [modes]
- .Echo the matched line. The text mode may be normal, bold, underscore, blink, inverse, black, red, green, yellow, blue, magenta, cyan, white, black_h, red_h, green_h, yellow_h, blue_h, magenta_h, cyan_h, and/or white_h. The _h colors specify a highlighting color. The other colors are assigned to the letters. Some modes may not work on some terminals. Normal is the default.
- bell [N]
- Echo the matched line, and send a bell N times (default = 1).
- exec command
- Execute command. The command may contain variables which are substituted with fields from the matched line. A $N will be replaced by the Nth field in the line. A $0 or $* will be replaced by the entire line.
- mail [addresses=address:address:...][,subject=your_text_here]
- Send mail to address(es) containing the matched lines as they appear (default address is the user who is running the program).
- pipe command[,keep_open]
- Pipe matched lines into command. Use the keep_open option to force the pipe to stay open until a different pipe action is run or until swatch exits.
- write [user:user:...]
- Use write(1) to send matched lines to user(s).
- throttle hours:minutes:seconds,[use=message|regex|<regex]>
- Use this action to limit the number of times that the matched pattern has actions performed on it. The use=regex option will cause throttling to be based on the regular expression instead of the message. You can also specify a perl compliant regular expression as the value for B,use>. The default is use="^\w{3}\s+\d{1,2}\s\d{2}:\d{2}:\d{2}\s+(.*)" causes the key to be the syslog message without the timestamp. This is most useful when throttling non-syslog created files.
- threshold events:seconds,[repeat=no|yes]
- This action limits the actions on a matched pattern based on the number of times it appears in a given time frame. An action like "threshold 4:60" will not perform any actions on that pattern unless it appears 4 times within any 60 second period (4:60 is the arbitrary default value). The repeat=no option will prevent the timer from being reset after the threshold has been reached. By default (repeat=yes), once the pattern has been triggered, a new 60 second period is begun, which means that if the patterns match quickly enough, a threshold of 4:60 could mean that 1 in every 4 messages is reported. By using repeat=no, you indicate that there is not to be more than one match every time interval. Note that this is similar to, but different from, the standard "throttle" command, since "throttle" shows the first line and ignores the rest, while "threshold" shows the last line and ignores the preceeding (and optionally the following). However, an action like "threshold 1:120" should perform similarly to "throttle 0:2:0,use=regex" and has the advantage of not relying on a particular timestamp format in the source log entry.
- continue
- Use this action to cause swatch to continue to try to match other pattern/action groups after it is done with the current pattern/action block.
- quit
- Use this action to cause swatch to clean up and quit immediately.
Special Option
The following may be used as an option for any of the above actions except for throttle and threshold.- when=day_of_week:hour_of_day
- Use this option to specify windows of time and days when the action can be performed. For example: mail=sysad-pager@somehost.somedomain,when=1-6:8-17
For Perl Hacks Only
perlcode [depth] arbitrary_Perl_code- This permits you to easily insert random Perl code into your swatchrc file. The optional depth value tells swatch how deep into the code to put the perl code. (0=outside the main loop, 1=inside the main loop (default), 2=just inside the conditional used by the current watchfor statement, and 3=inside the throttle block). Its intended use is to permit variable substitution through use like. "perlcode $syslog="^\w{3}\s+\d{1,2}\s+\d{2}:\d{2}:\d{2}.*";" watchfor /$syslog hostname pppd/>
- but any valid Perl is permitted. Remember the semicolon, and make judicious use of the --dump-script option if you run into trouble.
Configuration Example
perlcode my $fsf_regex = '\d{2}:\d{2}:\d{2}\s+(.* file system full)';- watchfor /$fsf_regex/ echo bell throttle 01:00,use=$fsf_regex
- In this example, a line which contains the string "file system full" will be echoed and the screen bell will sound. Also, throttle will use what is matched within the parentheses as its key rather than trying to use the log message with its time stamp cut out. Multiple instances of the message will not be echoed if they appear within a minute of the first one. Instead the following message will be acted upon after the time interval has expired. This is what may appear if the message appeared 20 times.
- * "** 20 in 00:01:00 ==" host.domain: /var: file system full>
Tidak ada komentar:
Posting Komentar