technicalwhitepaper_fwmonitoring

8/9/2019 technicalwhitepaper_fwmonitoring

1/11

White Paper:

Fw MonitorA troubleshooting tool

May 2005


2/11


3/11

1

White Paper: fw Monitoring May2005

Table of ContentsIntroduction............................................................................................................................................................................................................. 2

The OSI Model a troubleshooting framework........................................................................................................................................... 2

Running fw monitor ............................................................................................................................................................................................. 2

Anatomy of a filter expression.................................................................................................................................................................3Output of fw monitor..................................................................................................................................................................................3

The 4 Capture Points....................................................................................................................................................................................3

Limitations of fw monitor ......................................................................................................................................................................... 4

Commonly Used Options ..................................................................................................................................................................................... 4

Write output to file [-o ]..................................................................................................................................................................4

Limit the packet length [-l len].................................................................................................................................................................4

Capture masks [-m mask] .......................................................................................................................................................................... 5

Example Scenarios.................................................................................................................................................................................................5

Capturing all traffic to or from a host....................................................................................................................................................5

Capturing VRRP traffic ................................................................................................................................................................................. 5

Creating complex filters..............................................................................................................................................................................5

Alternate versions of the Complex Filter...............................................................................................................................................6

Troubleshooting a NATed Connection...................................................................................................................................................6

Advanced filter expressions: using lists................................................................................................................................................7

References.......................................................................................................................................................................................................7


4/11

2

White Paper: Push to Talk Technology March 2005

Introduction

fw monitor is a useful packet capture tool provided by

Check Point as a part of VPN-1/FireWall-1. It allows a

network troubleshooter to capture packets as they passthrough the VPN-1/FireWall-1 Enforcement Module. In

order to use the tool, however, the prospective networktroubleshooter must first understand the fundamentals

of computer networking. We discuss the basics of usingthe fw monitor utility, including some common optional

parameters, which can be very useful. Finally, we endwith a series of examples illustrated networktroubleshooting.

The OSI Model a troubleshooting

framework

As all Students of Networking know, it is mandatory thatwe discuss the OSI Model before diving into a packet

capture tool.

The OSI Model provides the framework for our

troubleshooting efforts. It is a theoretical model, and

while it is very useful in organizing our thinking about

data communications, it does not map one-to-one with

current popular protocols. The important thing the model

shows us is that network communications are modular

each layer performs a subset of the functions needed for

two devices to communicate. The protocols are then

linked together to enable the communication.

The Physical Layer handles the bits on the wire. A PhysicalLayer Protocol specification will define how bits are

encoded into electrical signals and how devices should

interpret bit patterns as bytes. For example, the IEEE

802.3 specification for Ethernet mandates that 100BASE-

TX Ethernet will use a 4B5B binary encoding mechanism

to convert bits into electrical signals.

A Data Link Protocol provides the specifications that allow

a network interface card (NIC) to communicate with

another NIC. For example, Ethernet defines the MAC

address and how to craft a data frame so that a NIC can

transmit the frame and that a receiving NIC can receive

and interpret the frame of data.

The Transport Layer provides for program-to-program

communication. For example, my client may have a web

session and a terminal session with the same server host.

At the network layer, the communications look the same

packets between my client IP address and the server IP

Address. At the Transport Layer, however, we see TCP Port

numbers, which identify which packets belong to which

sessions.

The remaining layers, Session, Presentation and

Application, are less important in the TCP/IP suite of

protocols and, therefore, are less important to most

network troubleshooting. It should be pointed out that

the Application Layer is not the application itself, for

example a web server. Rather, the Application Layer

Protocol is often like an API for the client and server

applications. The web client sets an HTTP GET request,

and the web server returns data, and the HTTP Protocol

specifies how the GET request is formatted and how the

data should be returned.

Following the data as it passes through the TCP Stack of

the web server illustrates the second key OSI Model

concept of Encapsulation. Each layer takes the output ofthe previous layer and encapsulates it, wrapping the data

in its header. At the other end, the recipient simply peels

off each layer like an onion and passes the data up to the

next Layer.

Figure 1: The OSI Model and its mapping to TCP/IP protocols


5/11

2


As shown in Figure 2, the web server has a chunk of data,

for example, the text of a web page. The application

wraps the data in an HTTP data unit and passes to the TCP

layer, which resides in the kernel. The TCP layer processes

the entire HTTP data unit by segmenting the data into

chunks and placing a TCP header on the front of each

chunk. TCP then hands its data to the IP layer, which does

the same thing, treating the entire TCP data unit as one

data payload, appending an IP header and passing the

entire thing to the Ethernet driver. The Ethernet driver

appends its header and, in the case of Ethernet, a trailing

checksum and passes the frame to the physical NIC for

transmission on the wire.

Thus the frame on the wire contains each protocolheader in succession and then finally the chunk of data

being transferred from server to client. We can capture

this frame with a packet capture tool and see what the

headers and data are. In order to understand what we

are looking at, we need to know the protocol which is

being used. A Protocol is just a set of rules that both

sides understand. For example, because of the IP Protocol

Specification, hosts know which 4 bytes of the 20 byte IP

header is the destination address.

Basically, network troubleshooting reduces to mapping,

at each layer, where the data unit is going to and where

is it coming from. That information is then comparedagainst expectations until the problem is identified. Our

expectations are built from our knowledge of how the

protocols are specified to work and from our

understanding of the network topology at each OSI layer.

Most network connectivity issues can be resolved byanalyzing the behavior of network communications at

the first 4 layers of connectivity. The network

troubleshooter should start at the bottom and work

her way up. Check that the wire is plugged in or that

the WEP keys have been typed correctly. Check that thehost is able to find the MAC address needed to transmita frame. Check that the router is forwarding the packetout of the correct NIC to reach the end host. Check that

the correct port number is being used. NetworkTroubleshooting by protocol analysis is rarely that

hard, but it can be time consuming to discern eachcommunication session from the individual packets

and frames.

Running fw monitor

The fw monitor command is relatively straightforward to

use. One can just run the command by itself

firewall[admin]# fw monitorand the utility will flood you with data. To end the

capture, simple press Ctrl-C (i.e., the Control key and the c

key simultaneously).

In most situations, there is simply too much data to

analyze. fw monitor uses short VPN-1/FireWall-1 Inspect

scripts to determine which data to capture and present.

Inspect scripts use an offset notation to match specific

bytes within a packet. Luckily, Check Point has defined a

number of keywords to represent these offset notation

entries. These definitions can be found in the various$FWDIR/lib/*.def files, especially $FWDIR/lib/tcpip.def.One example is the src keyword, which is equivalent tothe ip_src keyword which is equivalent to the offset [12,b]. The src keyword matches the given parameter againstthe IP Source address in the packets. For example, to

match all packets coming from a particular host, we could

use

Figure 2: Encapsulation of the data by each layer of the Network Stack


6/11

3


firewall[admin]# fw monitor e acceptsrc=10.10.10.51;and the output would show every packet received by

firewall with an IP Source address of 10.10.10.51.

Anatomy of a filter expressionIn the above command, the e tells the fw monitor utilityto expect a filter expression. The filter expression must be

isolated from the shell by quotes so that the entire

expression is passed to the fw monitor utility.

The first part of the quoted expression tells fw monitor toaccept packets that match the following expression. Theexpression src=10.10.10.51 describes only packets with aSource IP Address of 10.10.10.51. No packets coming

from any other source nor packets destined for

10.10.10.51 will be included in the output. Finally, the

ending semicolon ( ; ) is critical. Frequently, when filterexpressions are suggested using a sans-serif orproportional font, the semicolon becomes invisible next

to the quotation mark. More than one engineer has spent

hours trying different filter expressions in vain only to

finally realize that the semicolon was missing.

Output of fw monitorBy default, fw monitor provides 4 lines of decode for each

packet passed by VPN-1/FireWall-1. If the packet is

carrying a TCP, UDP or ICMP data unit, as in Figure 3, fw

monitor will display a second line decoding that protocol.

The first element of the decode is the interface on which

the packet is either being received or being sent. Next, we

have the Capture Point identifier ( i, I,o, O) followed by

the length as Check Point sees the datagram. This length

comes from Check Points Virtual Defragmentation Engine

and can be different from the length as reported in the IP

Header for the packet. The line ends with a decode of the

IP header: Source IP to Destination IP, decode of the IP

Protocol field, display of the IP Length field and of the ID

field of the IP Header.

The 4 Capture Points

As mentioned above, the default fw monitor output

includes four lines for each packet passed by the firewall.

The four lines correspond to the four main capture points

provided by the Enforcement Module:

pre-inbound inspection ( i )

post-inbound inspection ( I )

pre-outbound inspection ( o )

post-outbound inspection ( O ).The inclusion of the Capture Point in the decode is,

perhaps, the most import feature of fw monitor for the

network troubleshooter. VPN-1/FireWall-1, by default,

compares network traffic against its policy and state

tables both when the packet is received (inbound) as well

as immediately

before the packet is

transmitted

(outbound). The four

primary capture

points correspond to

points immediatelybefore and after the

VPN-1/FireWall-1

inspection points. If

we see that a packet

was captured only

prior to an

inspection but not

after and inspection,

we can conclude

that some aspect of

firewall policy is the

cause of our network problem.

For example, if a packet only generates one line of output

marked with the pre-inbound inspection ( i ) identifier,

we can be confident that the VPN-1/FireWall-1 policy is

causing the packet to be dropped. The VPN-1/FireWall-1

policy and log viewer should be used to figure out which

rule is causing the problem.

Figure 3: Default output of fw monitor command


7/11

4


Another example would be if only lines for inbound

inspection ( i, I ) are shown but outbound inspection ( o,

O ) are missing. This would indicate that the packet is

either terminating at the firewall itself or that routing

has been misconfigured and the routing engine of

thedevice is blackholing the packet.

If the expected packet doesnt even produce any inbound

inspection decode lines, this means either that the filter

expression is incorrect or that the packet is never making

it to the Enforcement Module for inspection. Other tools

would then be needed to see what is going on outside

the firewall device.

Limitations of fw monitor

Unlike many packet capture utilities, fw monitor cannot

show Data Link Layer or lower protocol information. The

NIC strips the Data Link Layer information before handing

the packet to the VPN-1/FireWall-1 module. On the up

side, fw monitor can, as we have seen, show the packet

at different inbound and outbound capture points along

the way.

Using the OSI model as our troubleshooting guide, it

would be wise to first verify that the network traffic is

flowing correctly at the Data Link Layer before using fw

monitor to analyze traffic at the Network Layer. Tools

like tcpdump, snoop and 3rd party protocol analyzers can

be used to check the transmission of data at the Data Link

Layer. Many 3rd party analyzers can even detect Physical

Layer problems.

Misconfigured Proxy ARP is an example of a problem that

fw monitor simply cannot solve. If hosts are not even

transmitting the frames to the NIC of the firewall, VPN-

1/FireWall-1 will never inspect the packet and fw monitor

will never provide and lines of decode to analyze.

Tcpdump, however, can capture traffic not transmitted

directly to the firewalls NIC and can display the incorrect

hardware addressing.

Commonly Used Options

The following options extend the usefulness of fwmonitor.

Write output to file [-o ]

The o option is very useful for getting the data out

of the terminal window and into a full featured protocol

analyzer like Ethereal. Ethereal can decode a far greater

array of Transport, Session, Presentation and Application

layer protocols. It provides various views of the packet

data as well as more advanced filtering options, thereby

making it easier to figure out what is going on.

Instead of outputting decoded packets to the terminal,

fw monitor writes the raw packet binary data to a file.

There are several limitations to this output, however:

1. Because fw monitor never sees the Data Link Layer

data, it cannot capture the Data Link Layer data. fw

monitor, however, uses the bytes reserved for Data

Link Layer header information to encode the

Interface and Capture Point information presented in

the normal fw monitor output. To quote Check

Points How to use fw monitor 10-Jul-2003

Alfred Kbler ([email protected] ) wrote anaddition to Ethereal which enables Ethereal to

display not MAC addresses but the fw monitorinformation. This addition is part of the standard

Ethereal distribution since version 0.9.9. It can beactivated usingEdit/Preferences/Protocols/Ethernet/Interpret asFireWall-1 monitor

2. Packet capture files can become quite large. Care

must be taken to limit the traffic captured by

carefully using filter expressions. The Limit the packetlength [-l len] option can also help reduce thisproblem.

3. Unless the Limit the packet length option is used,packet capture files will contain potentially sensitive

data from the network connections being captured.

Care must be taken with the resulting file

4. In order for the packet capture to be useful, it must

first be transferred off the firewall.

It is good practice to chose a file name that ends in a

.pcap or .dmp extension. This makes it easier for

Ethereal on a Windows platform to open the file directly.

fw-1[admin]# fw monitor o monitor.pcap e acceptsrc=10.10.10.51;

Limit the packet length [-l len]

The Limit the packet length option can help overcomesome of the problems with using the Write output to fileoption. Usually the network troubleshooter is only

interested in the header data. The actual data being

transferred can cause the packet capture file to swell to


8/11

5


enormous size and frequently contains sensitive

information. By carefully choosing a packet length (len)

value to capture, both of the problems can be reduced.

The question then is, what len value to use? The

parameter defines the number of bytes of the captured

frame which should be included in the packet capture file.The IP header is usually contained within the first 38

bytes of the frame, and the TCP header is usually within

the first 58 bytes. NetBios related protocols, such as

Microsofts SMB implementation, and RPC (Remote

Procedure Call) related protocols, such as Suns NFS

(Network File System) protocol, can frequently require

more that 200 bytes of frame data. Experience and trial

and error become the usually ways a network

troubleshooter decides which len values to use.

As a starting point, try a value of 300 if capturing

Microsoft or Sun implemented protocols. Try a value of

128 if capturing standard IETF defined protocols likeHTTP, as in the following example:

fw-1[admin]# fw monitor o monitor.pcap l 128 eaccept src=10.10.10.51;Capture masks [-m mask]

This option is particularly useful when analyzing standard

fw monitor output on the command line. Frequently we

only care if the packet made it through the firewall, and

the post-inbound inspection ( I ) and the pre-outbound

inspection ( o ) decode lines just make the output harder

to read.

The mask parameter in its simplest form is just a

sequence of the the iIoO characters used to identify the

desired capture points. Therefore, if we only want to

capture output from the pre-inbound inspection ( i ) and

post-outbound inspection ( O ) Capture Points, we could

modify our fw monitor command like so:

firewall[admin]# fw monitor e acceptsrc=10.10.10.51; m iO

Example ScenariosIn this section, we will describe a number of scenarios,

the filter expression needed to capture the relevant traffic

and an explanation of the analysis. Troubleshooting of

network problems requires an understanding both of the

network topology as well as of the protocols being used.

A full discussion of the relevant protocols is outside the

scope of this tutorial, but relevant facts regarding the

protocols will be provided.

Capturing all traffic to or from a host

The simple filter example used previously will only

capture traffic from the host 10.10.10.51. If you need to

see all traffic to or from a particular host use:e accept src=10.10.10.51 or dst=10.10.10.51;

Notice the use of the Logical Operator or. We want to seetraffic in both directions, i.e., packets either destined for

10.10.10.51 or coming from 10.10.10.51. A common

mistake is to use the logical operator and. Such aconstruction, however, results in no packets being

matched, because ordinarily there are no network

packets from a particular IP address destined for that

same IP address .

Capturing all traffic of a specific service

To capture all traffic related to a specific service, the

correct identifier must be know. For example, to capture

all web traffic, which uses TCP Port 80, the following filter

can be used:

-e accept sport=80 or dport=80;Likewise, DNS traffic uses UDP Port 53, so to capture all

DNS traffic we can use:

-e accept sport=53 or dport=53;Capturing VRRP traffic

The VRRP protocol header immediately follows the IP

header. The IP Protocol value of 112 has been assigned

to VRRP. To filter on an IP Protocol value, the ip_p macromust be used. The following expression will capture all

VRRP traffic:

-e accept ip_p = 112;Creating complex filters

In addition to the logical operator or, fw monitorprovides several additional logical operators:

or Logical OR, and Both the comma and the keyword andwork as a

Logical AND

xor Logical XOR (not commonly used)Not Logical NOT (not commonly used)


9/11

6


In addition to the relational operator =, fw monitorprovides several additional logical operators:

= oris

Both the equals sign and the keyword iswork as the relational operator EQUAL

!= oris

not

Both the exclamation point/equals sign combination

and the keyword is not work as the relational

operator NOT EQUAL

< Relational operator LESS THAN

> Relational operator GREATER THAN

= Relational operator GREATER THAN OR EQUALTO

Lets take the scenario where we need to examine all

web traffic between two hosts. To limit the traffic to only

the two hosts in question we need an expression that

captures only traffic between the two hosts

(src=10.10.10.51 and dst=192.168.0.101) or(src=192.168.0.101 and dst=10.10.10.51)Now we must add an expression to capture only web

traffic between the two hosts (note, we are using the

backslash character ( \ ) to escape a newline character

inserted to make the line readable)

((src=10.10.10.51 anddst=192.168.0.101)or(src=192.168.0.101 anddst=10.10.10.51)) \and (sport=80 or dport=80)In a UNIX csh environment, the final command to capture

only port 80 web traffic between hosts 10.10.10.51 and

192.168.0.101 would be:

fw1[admin]# fw monitor e ((src=10.10.10.51 and

dst=192.168.0.101) \ or(src=192.168.0.101 and

dst=10.10.10.51)) and (sport=80 or dport=80) ;

The importance of using parentheses in complex filters

cannot be overestimated.

Alternate versions of the Complex Filter

Check Points Inspect scripting language is very versatile.

One example would be to use multiple accept statementsin a single filter expression. The same expression to

capture all port 80 web traffic between hosts 10.10.10.51

and 192.168.0.101 can be written as:

-e accept src=10.10.10.51 and dst=192.168.0.101 andsport=80 ; \accept src=192.168.0.101 and dst=10.10.10.51 anddport=80) ;

As the logical operator and can be replaced with acomma ( , ), original statement can be written even more

confusingly as:

fw1[admin]# fw monitor e((src=10.10.10.51,dst=192.168.0.101) \or(src=192.168.0.101,dst=10.10.10.51)),(sport=80 ordport=80) ;

Troubleshooting a NATed Connection

If one of the hosts is NATed at the firewall, the above

complex filter expression will not capture the packet at

all four inspection capture points. After the NAT takesplace, the packet will no longer match the expression and

will no longer be captured by fw monitor.

In the case of Static NAT, a solution is obvious: just add

the static NAT address to the expression. If the server

10.10.10.51 is NATed to 172.16.10.51, then the filter

expression becomes:

fw1[admin]# fw monitor e (((src=10.10.10.51 or

src=172.16.10.51) \

and dst=192.168.0.101) or (src=192.168.0.101 and

(dst=172.16.10.51 or \

dst=10.10.10.51))) and (sport=80 or dport=80)

As the examples inscrutability demonstrates, just adding

additional parameters may not be the best way to

proceed. When dealing with Hide NAT, the potential for

capturing unrelated packets becomes greater as many

hosts are translated to the Hide NAT address.

Perhaps we dont need to see the missing packet,

because the existence of the other packets implies its

existence. In that case, the statement remains the same

as presented in the Complex Filter example.

Perhaps we can limit the packet capture sufficiently by

only filtering on the remote host IP address. For example,

if our client is the only local client connecting to the

remote server, we can filter on the remote server IP

address or remote server IP address and TCP Port

numbers and only capture the desired communications,


10/11

7


including NATed traffic. In this case, we can actually

simplify the filter expression:

fw1[admin]# fw monitor e (src=10.10.10.51 ordst=10.10.10.51) and \(sport=80 or dport=80)

In truly complicated situations, such as where many hosts

and many servers are all using the same Application Layer

protocol to exchange data, the use of multiple acceptstatements, as illustrated in the section Alternative

versions of the complex filter, can become a necessity.

Advanced filter expressions: using lists

Check Point provides a list feature that allows both for

the definition of specific hosts as well as the definition of

address ranges in filter expressions. A list is first defined,

and then that list can be used by name in later IP address

matching.

For example, say we need to find out if any address in a

particular subnet is accessing a commonly used server.

We could define a list that includes the subnet by using

the to define a range of addresses:fw1[admin]# fw monitor e [troubleNet] = { } ; \accept (src in troubleNet and dst=10.10.10.51) ;

We can also define multiple hosts or multiple networks in

a list definition:e [badHosts] = { 192.168.10.53, 192.168.21.18,192.168.101.186 } ; \accept (src in badHosts and dst=10.10.10.51) ;

Saving output to a text file

Rather then using the Write output to file [-o ] tocapture raw packet data, simple shell redirection can be

used to capture the default fw monitor output to a file.

On a UNIX type system, simply use the redirection

operator > like so:fw1[admin]# fw monitor e accept src=10.10.10.51; >monoutput.txtand the file monoutput.txt will be created with thestandard output of the command.

References

Check Point, How to use fw monitor, Jul 10, 2003.

Available from the Next Generation Utilities page

(http://www.checkpoint.com/techsupport/downloadsng

/utilities.html).


11/11

About NokiaNokia is the world leader in mobile communications, driving the growth and sustainability of the broadermobility industry. Nokia is dedicated to enhancing people's lives and productivity by providing easy-to-useand secure products like mobile phones, and solutions for imaging, games, media, mobile networkoperators and businesses. Nokia is a broadly held company with listings on five major exchanges.

For more information, please visit http://www.nokia.com/forbusiness

AmericasNokia

313 Fairchild Drive, Mountain View, CA 94043Tel: 1 877 997 9199

Email: [email protected]

Europe, Middle East and AfricaNokia

Nokia House, Summit AvenueSouthwood, Hampshire, GU14 ONG, UK

Tel UK: +44 161 601 8908Tel France: +33 170 708 166

Email: [email protected]

Asia PacificNokia

438B Alexandra Road#07-00 Alexandra Technopark, Singapore 119968

Tel: +65 6588 3364Email: [email protected]

www.nokia.com

Copyright 2005 Nokia. All rights reserved. Nokia and Nokia Connecting People are registered trademarks of Nokia Corporation. Other trademarks mentioned are theproperty of their respective owners. Nokia operates a policy of continuous development. Therefore we reserve the right to make changes and improvements to any ofthe products described in this document without prior notice. Under no circumstances shall Nokia be responsible for any loss of data or income or any direct, special,incidental, consequential or indirect damages howsoever caused.

Documents

technicalwhitepaper_fwmonitoring