Checkpoint - Critical error messages and logs

These messages may appear in one of the following locations:

* Console

* SmartView Tracker

* messages or dmesg file

If and when encountered, please contact Check Point Support.



"Out of Memory: Killed process ()"


This message appears in the dmesg file and in /var/log/messages files on SecurePlatform.

It means that no more memory is available to Linux in the user space. As a result, Linux starts to kill processes.

"FW-1: Capacity problem detected

Memory consumption has exceeded X%" (Console message)

"Capacity notification: Memory consumption has exceeded X%" (SmartView Tracker message)

These messages indicate that the memory consumption has increased beyond what was defined as the Aggressive Aging threshold (for more details about Aggressive Aging, refer to 'NGX R65 What's New' document, under 'Firewall & SmartDefense', page 2).


"FW-1: Capacity problem detected"

"Connections table capacity has exceeded X%" (Console message)

"Connections table capacity has exceeded X%" (SmartView Tracker message)

These messages indicate that the Connections table capacity has increased beyond what was defined as the Aggressive Aging threshold.

For more details about Aggressive Aging, refer to 'NGX R65 What's New' document, under 'Firewall & SmartDefense', page 2.

"Main database file <(database file name)> is missing - cannot start fwm. If you wish to reset the DB please run 'cpdb new'." (Console message)

The appearance of this error message might indicate a corruption in $FWDIR/conf/objects_5_0.C. As a result, fwm will not start.

"State synchronization is in risk. Please examine your synchronization network to avoid further problems" (in /var/log/messages file)

This message may indicate that the sync network is overloaded. Overloading the sync network can cause traffic loss, unsynchronized kernel tables, and connectivity problems. For more information, refer to sk23695.



"fwlddist_adjust_buf: record too big for sync" (in /var/log/messages file and on the Console)

This message may indicate problems with the sync network. It can cause traffic loss, unsynchronized kernel tables, and connectivity problems. For more information, refer to sk35466.

"Cluster_info: (ClusterXL) member is down" (in SmartView Tracker)

This log message may indicate that the ClusterXL failed over. You can check the member's status and the failed device using the commands cphaprob stat, cphaprob list and cphaprob -a if. For more information regarding the usage of these commands, refer to CheckPoint NGX ClusterXL User Guide.pdf.

If this failover was not initiated on purpose, please contact Check Point Technical Support (as described above).

"Dead loop on virtual device sync, fix it urgently" (in dmesg file)

This message is a SecureXL notification on the outbound connection that may cause the gateway to lose sync traffic. For more information, refer to sk32765.



"FW-1: bpush: push block size error..." (Console message)

For more information, refer to sk32753 , sk59124.


"FW-1: fw_runfilter: illegal kfunc" (Console message)

These message may indicate system instability and should not be ignored.



"FW-1: fw_runfilter: stack overflow" (Console message)


This message may indicate that the number of rules in the firewall has exceeded its limit. If more rules are required, please contact Check Point Technical Support (as described above).

"FW-1: fw_runfilter: stack underflow" (Console message)

This message may indicate memory corruption problems detected by the system. System stability may be impacted.

"FW-1: fw_runfilter: wrong number of arguments..." (Console message)

This message may occur after an unsuccessful upgrade and could precede a system panic.

"FWD Error: Log(s) discarded due to unification process failure" (in SmartView Tracker)

A single "unified" log record is produced by the FireWall-1 kernel driver from a number of "basic" log records. If for some reason the building process (unification process) fails, there is a log discard followed by this error message.

This means that logs are discarded from the system and therefore will be lost.



"Database space check failed. There may not be enough disk space or it may have failed to obtain database capacity information" (in Eventia Reporter's $RTDIR/opt/CPrt-R65/log_consolidator_engine/log/lc_rt.log file).

This message means that the process is not communicating with the mysql process or there might be a problem identifying the disk. The logs will be consolidated once the problem is solved. Please check the disk capacity. Check Point also recommends checking disk sanity (for example, by using the check disk utilities).

"FW-1: panic <(x)>: " (Console message)

<(x)> represents the level of panic induced. represents the message that is associated in the code with this panic.

This error message indicates that fw_panic was called.

"FW-1: fw_kfree: memory already freed at 0x. caller is sz=" (Console message)

represents the pointer. represents the name of the function where the error happened.
This error message indicates that released memory is trying to be released again.

This is forbidden and might lead to a potential panic event.

"FW-1: fw_kfree: wrong magic number at tail end of 0x (0x) caller is sz=" (Console message)

"FW-1: fw_kfree: wrong magic number at 0x. caller is sz=" (Console message)

represents the pointer. represents the name of the function where the error happened.
These error messages might indicate an error in the way memory was handled, which might lead to a potential panic event.



"FW-1: hmem_init: unable to allocate the minimum <(x)>" (Console message)

represents the minimum memory size that is needed.

This error message indicates that the firewall's memory management module is not loaded.



"FW-1: b_create: fw_kmalloc(x) failed" (Console message)

represents the pointer.

This message may indicate an error in memory allocation for binary tables. System stability may be impacted.

"ex_init_timer: Failed to initialize timer" (Console message)

This message might indicate an error in the timer mechanism initialization. This may impact system infrastructures and cause inconsistent behavior.

"FW-1: b_create: fw_kmalloc(x) failed" (Console message)

This message might indicate a critical error in allocating a table. System stability may be impacted.

"FW-1: b_create: fw_kmalloc(x) failed" (Console message)

This message may indicate memory allocation problems. System stability may be impacted.

"fwconn_get_bits: invalid bit category: (x)" (Console message)

This error may indicate a critical error in reading the connections table. It may have a serious impact on connectivity.

"fwconn_set_bits: failed to get bit value for bit category (x)" (Console message)

This error may indicate a critical error in writing to the connections table. It may have a serious impact on connectivity.

"fwconn_chain_fill_bits: invalid bit category: (x)" (Console message)

This error might indicate a memory corruption.



"FW-1: : data connection "FWCONN6_FMT" already exists in connections table" (Console message)

This error might indicate synchronization problems between clusters.



"FW-1: : failed to get info from %s table" (Console message)

This error might indicate memory management problems.

"FW-1: : fwconn_chain_lookup failed" (Console message)

This error might indicate an inconsistency within the connection table. This may lead to connectivity problems.

"FW-1: illegal access to connections table" (Console message)

This error might indicate connectivity problems.



"FW-1: : Cannot change aggressive timeout without setting the timeout (timeout=, aggr_timeout=)" (Console message)

This error might indicate a program error that might cause Aggressive Aging not to work properly.

"Failed to build the objects schema while initializing database manager with error 0x% ('')" (Console message)

represents internal value of a pointer.

This message can indicate that there is a problem with the schema file that could prevent the fwm process from starting.

fwm not running on the system may lead to problems with connecting with the GUI client and installing the policy.

"fwhandle_get(vpn_tag.c:1275): Table kbufs - Invalid handle f5139a5c (bad pool)" (Console message)

This error message might indicate an error in the way memory was handled. It may cause RemoteAccess Connectivity issues.

"Policy install commit function was unsuccessful due to timeout" (Console message)

This error message appears during security policy installation. It indicates that policy installation on the gateway takes too much time. There is no way to know whether policy was successfully installed or not.

"Failed to get password for connection RT_Database, reason: Could not find path to database socket" (Console message)

This error means that the location of the mysql.sock file is missing. It will prevent the Eventia Reporter from connecting to the database. This problem can be fixed by doing the following:

1. Open the file $RTDIR/Database/conf/my.cnf and copy the directory that the "datadir" is referring to.

2. Run rmdstop (make sure that the database processes are down).

3. Run cd $RTDIR/Database/ .

4. Run the following commands:

bin/mysqld_safe --basedir="$RTDIR/Database"

--ledir="$RTDIR/Database/bin"

--datadir=""

--socket="$RTDIR/Database/mysql.sock" --user=root --log-error=$RTDIR/Database/err.log &

If mysql is not starting up, check the file $RTDIR/Database/err.log for errors.

Note that mysqld_safe and my_print_defaults are not part of the installation. You can download them (in WinZip format) here:

* mysqld_safe
* my_print_defaults

Checkpoint Logging Issue

The following article is a list of steps one should go through when troubleshooting logging related issues in a distributed setup.

1. Ensure that you have not run out of disk space on the hard disk that the logs are being sent to. If this is the case, delete or move the logs to an external storage device.

2. Is there communication between the MS and the Module? Test using ping to the MS from the module and then from the Module to the MS (your rules must allow for this). If this fails, and your rules allow for this, then it is most likely a routing issue.

3. Check to see if the fw.log file is growing on the module. It should be if the logs are not going to the MS. From the console run these commands:

cd $FWDIR/log

ls -la

ls -la

Verify that the fw.log file is increasing. If it is increasing then the modules are logging locally instead of forwarding the traffic to the MS. This could be a connectivity issue, or it could be the way the logging is setup. Check the FW object to ensure it is setup to send logs to the MS.


4. Can you fetch a policy? Verify that you can fetch using the hostname and IP address. If this fails then you probably have a SIC issue. To test this run the following commands:

fw fetch hostname_of_MS

fw fetch IP_Addr_of_MS (fetch by IP address also to ensure it is not a DNS issue)

5. Check the masters file. The hostname or IP address of the management station should be listed in there. To check this run the following commands:

cd $FWDIR/conf

cat masters

It should be look like this:

[Policy]

hostname_of_MS

[Log]

hostname_of_MS

[Alert]

hostname_of_MS

6. Run tcpdumps on the module, listening for port 257 on the interface facing the MS, to see if it is attempting to send logs. To check this run the following command:

tcpdump -i eth-facing-MS port 257 (use the Ctrl+C to break out of the dump)

You should see traffic leaving the FW and heading to the IP address of the MS.

You should also see traffic coming back from the MS.


7. The log file may have gotten corrupt. Run a log switch on the MS and reboot the MS to create a new log file. If logswitch does not work, move all contents of the log directory (do not move the directory itself) to a temp folder outside of the log directory. Reboot and see if the logs start again.

8. Delete the $FWDIR/log files and $FWDIR/state directory files on the module; reboot the module.

Reboot and see if the logs start again.

9. Look to see if there is a listening port for logging. Run the following command on the MS and the module:

netstat -na

You should see the *.257 LISTEN for logging connections. You should also see the IP address of the MS :257 associated with the IP address of each module, and showing an ESTABLISHED connection.

10. Check the log settings for the FW object and make sure the 'Log Server' is set to the MS that should be receiving the logs. This is usually done by default, but may have been changed by a user.


If after going through these steps you are still experiencing logging issues, please open a ticket with Corresponding TAC for further troubleshooting and ofcoz try your way with help of our all time Gaint Mr. Google.. :-)

Checkpoint Troubleshooting - Debugging

Checkpoint Common debugging


Kernel debugging

Usage

% fw ctl debug -buf [buffer size]
% fw ctl debug [-x] [-m ] [+|-]
% fw ctl kdebug –f >

To disable the Kernel debugging, execute:
% fw ctl debug –buf 0
% fw ctl debug x
Common Syntax
% fw ctl debug –buf 12288
% fw ctl debug –m fw conn drop ld packet if
% fw ctl kdebug –f >

The ld option may cause high CPU usage. It is advised to use it for short session debugging
only.
To execute the kernel you can also use fw ctl zdebug to allocate the buffer (where the
buffer can only be 1024).

% fw ctl zdebug
% fw ctl kdebug -f >

TDERROR_ALL_ALL=
CPD is treated differently from the other User Mode processes and will be executed
differently

Debugging CPD

CPD is a high in the hierarchichal chain and helps to execute many services, such as Secure
Internal Communcation (SIC), Licensing and status report.
For CPD debug, execute: % cpd_admin debug on TDERROR_ALL_ALL=5
The debug file is located under $CPDIR/log/cpd.elg
To stop the CPD debug, execute: % cpd_admin debug off TDERROR_ALL_ALL=1

Debugging FWM

The FWM process is responsible for the execution of the database activities of the
SmartCenter server. It is; therefore, responsible for Policy installation, Management High
Availability (HA) Synchronization, saving the Policy, Database Read/Write action, Log
Display, etc.

For FWM debug, execute:

% fw debug fwm on TDERROR_ALL_ALL=5
% fw debug fwm on OPSEC_DEBUG_LEVEL=9
The debug file is located under $FWDIR/log/fwm.elg
To stop the FWM debug, execute:
% fw debug fwm off TDERROR_ALL_ALL=1
% fw debug fwm off OPSEC_DEBUG_LEVEL=1

Debugging FWD

The FWD process is responsible for logging. It is executed in relation to logging, Security
Servers and communication with OPSEC applications.
For FWD debug, execute: % fw debug fwd debug on TDERROR_ALL_ALL=5
The debug file is located under $FWDIR/log/fwd.elg
To stop the FWD debug, execute: % fw debug fwd off TDERROR_ALL_ALL=1

FireWall Monitor Network Capturing

The FireWall Monitor is responsible for packet flow analysis.
To execute: % fw monitor –e “accept;” –o

Security Server debugging

Debugging User Authentication

Usage

Debugging is done on the service itself (in.ahttpd, in.atelnetd, in.aftpd etc.)
% fw debug on TDERROR_ALL_ALL=5
The debug file is located under: $FWDIR/log/ahttpd.elg* or $FWDIR/log/aftpd.elg* or
$FWDIR/log/atelnetd.elg* depending on the service that you are debugging.

HTTP Security Server

For HTTP Security Server debug, execute:
% fw debug in.ahttpd on TDERROR_ALL_ALL=5
% fw debug in.ahttpd on OPSEC_DEBUG_LEVEL=3
The debug file is located under: $FWDIR/log/ahttpd.elg*
If more than one HTTP Security Server process is running, execute:
% fw kill fwd
% setenv TDERROR_ALL_ALL=5
% setenv OPSEC_DEBUG_LEVEL=3
% fwd –d >&

&
Note - The setenv commands used above correlate with Unix environment. For other platforms, execute
the relevant command.

SMTP Security Server

To debug the SMTP Security Server, execute:
% fw debug in.asmtpd on TDERROR_ALL_ALL=5.
The debug file is located under $FWDIR/log/asmtpd.elg*
To debug the mdq, execute the following commands:
% fw debug mdq on TDERROR_ALL_ALL=5.
The debug file is located under $FWDIR/log/mdq.elg*

Debugging Session Authentication

To debug Session Authentication, execute:
% fw debug in.asessiond on TDERROR_ALL_ALL=5
The debug file is located under: $FWDIR/log/asessiond.elg*

Debugging Client Authentication

For HTTP to port 900, execute:
Check Point Troubleshooting and Debugging Tools for Faster Resolution. Last Update — January 24, 2006 5
% fw debug in.ahclientd on TDERROR_ALL_ALL=5
For Telnet to port 259, execute:
% fw debug in.aclientd on TDERROR_ALL_ALL=5
The debug file is located under: $FWDIR/log/ahclientd.elg*

VPN debugging

On the Module

To start, execute:

% vpn debug trunc.
This command is equivalent to these two commands: vpn debug on, vpn debug ikeon.
To stop, execute:
% vpn debug off; vpn debug ikeoff.
The debug file is located under $FWDIR/log/ike.elg and $FWDIR/log/vpnd.elg

FireWall Monitor for packet flow analysis
% fw monitor –e “accept;” –o

Client Side

The Client side can only run under the root directory (C :/…)
To start, execute:
% sc debug on
To stop, execute:
% sc debug off
The debug file is located under sr_service_tde.log, under the SecuRemote installation
folder, for example: C:\Program files\CheckPoint\SecuRemote.
For packet capture from the Client side, execute:
% srfw monitor -e "accept;" -o

Provider-1 debugging

MDS Level

Most of the MDS actions are performed by the MDS’s fwm process, execute:
% mdsenv
% fw debug mds on TDERROR_ALL_ALL=5
% fw debug mds on OPSEC_DEBUG_LEVEL=9
The debug file is located under /opt/CPsuit-R60/fw1/log/mds.elg
Check Point Troubleshooting and Debugging Tools for Faster Resolution. Last Update — January 24, 2006 6

ClusterXL debugging

For ClusterXL debugging for Clustering, Synchronization, High Availability, Fail-over,
execute:
% cphaprob state
% cphaprob -ia list
% cphaprob -a if
% fw ctl pstat
Kernel debug for packet filter analysis
% fw ctl debug –buf 12288
% fw ctl debug –m fw conn drop packet if sync
% fw ctl debug –m cluster all
% fw ctl kdebug –f >

Connectra debugging

For Connectra debugging issues relating to Web, files, Webmail, OWA, iNotes, Citrix, the
httpd process should be debugged:
To turn the debug on, under: $CVPNDIR/conf/httpd.conf change LogLevel to debug.
You should execute the process: cvpnrestart
The output is located at: $CVPNDIR/log/httpd.log
For debugging authentication issues, execute: Debug cvpnd
Run: cvpnd_admin debugset TDERROR_ALL_ALL=5
To start, execute: % cvpnrestart
The debug file is located under $CVPNDIR/log/cvpnd.elg
To stop debug, run:
% cvpnd_admin debug off

FireWall-1 GX debugging

Kernel debug for packet filter analysis
Check Point Troubleshooting and Debugging Tools for Faster Resolution.

% fw ctl debug –buf 12288
% fw ctl debug –m fw conn drop ld packet filter
% fw ctl kdebug –T –f >

InterSpect debugging

Kernel debug for packet filter analysis
% fw ctl debug –buf 12288
% fw ctl debug –m fw conn drop packet if
% fw ctl kdebug –f >

Additional kernel debug options for InterSpect:
• portscan, for port scanning issues
• dynlog, for dynamic logging
• mail, for mail security in the kernel
• sam, for SAM IP address blocking
Kernel debug for Packet Drop, execute:
% fw ctl zdebug + drop
Kernel debug for SmartDefense TCP Streaming, execute:
% fw ctl zdebug + tcpstr + cifs
Kernel debug for Dynamic list (SAM), execute:
% fw tab -t sam_requests_v2 -u -f
% fw samp

SNX – SSL Network Extender debugging

Server Side

% vpn debug trunc
% vpn debug on slim=5
Debug can be found at $FWDIR/log/vpnd.elg.
You should execute vpn debug on [DEBUG_TOPIC=5]. The relevant debug topics are:
proxy, rasta, rasta_protocol and slim.)

Client Side

For the service:
Type regedit at the command prompt and set:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\cpextender\parameters\d
bg_level to 5
Open the Command Line interface window and execute:
Check Point Troubleshooting and Debugging Tools for Faster Resolution. Last Update — January 24, 2006 8
% net stop cpextender
% net start cpextender (or kill slimsvc.exe)
The debug file is located under:
%Program Files%\CheckPoint\SSL Network Extender\slimsvc.log
For the ActiveX: (only when using ActiveX with Internet Explorer), type regedit at the
command prompt and set the following:
% set HKEY_CURRENT_USER\Software\CheckPoint\SSL Network
Extender\parameters\dbg_level to 5
The debug file is located under %APPDATA%\Check Point\extender\activex.log.
For the Applet: (when using the Applet version) SNX can be used by Microsoft JVM or by
other vendors (SUN, IBM…). To view the Java console when using Microsoft JVM you
need to check Java console enabled (requires restart) in the Internet Options Advanced tab
and restart Internet Explorer. You can also switch between the different JVMs (in case you
have two or more) in the same tab.

Further Debugging – Memory Diagnostics

The following utilities applies to all non-Windows systems supported by Check Point:
% free
% vmstat 2 10
% sar –k 2 10
% top
% ps -auxw
% cat /proc/meminfo
% cat /proc/slabinfo

Routing information

% arp –a
% netstat –ie

Alw@ys Knw Wh@ts Happening inside your KERNEL - “A CHEAT SHEET”

FW MONITOR - Monitor your KERNEL..
---------------------------------

Purpose:

Many People have problems with their daily life, is just bcoz they dont know what is/was happening INSIDE, I could never trouble shoot the KERNEL of Mine, but definitely did in my Favorite Product CheckPoint..

Yes.. Always monitor the each points (don't simply believe ALL IZZZ WELL..) Nothing gonna be Well untill and unless you have the control on each point of the Process..

Here we go,, FW Monitor,

Why fw monitor?

The fw monitor utility is similar to ‘snoop’ and ‘tcpdump’ in being able to capture and display packet information. Unlike snoop or tcpdump, fw monitor is always available on FW-1, can show all interfaces at once and can have insertion points between different Check Point modules. The fw monitor commands are the same on every platform.

Fw monitor syntax:

There are many options for the fw monitor command and these can be seen by typing fw monitor –h on the command line;



fw monitor -h

Usage: fw monitor [- u|s] [-i] [-d] <{-e expr}+|-f > [-l len] [-m mask] [-x offset[,len]] [-o ] <[-pi pos] [-pI pos] [-po pos] [-pO pos] | -p all [-a ]> [-ci count] [-co count]

Each option is fully explained in the Check Point document How to use fw monitor.

Brief option description:

-u|s, is used to show the uuid which is the same number during the entire connection
-i, is used to make sure that all info is written to standard output immediately
-d|D, is used to put fw monitor in debug or more Debug modes
-e, is used for the user defined expressions
-f, for the filter file
-l, is used to limit the packet length captured
-m, is a mask of interface such as the default mask of iIoO
-x, prints the packet data to the screen
-o, output file
-p[x] pos, is used to set the insertion point of the monitor
-p all, places insertion points between each module
-ci count, is used to break out of fw monitor after incoming packets
-co count, is used to break out of fw monitor after outgoing packets

Reading the output:

El59x1:i[48]: 10.10.10.20 -> 192.168.10.95 (TCP) len=48 id=944



TCP: 1034 -> 21 .S.... seq=78caaa74 ack=00000000

Filter expressions:

A great reference for filter expressions is the tcpip.def file located at $FWDIR/lib.
In this document we will just describe a few and how they work.
#define ip_tos [ 1 : 1]
#define ip_len [ 2 : 2, b]
#define ip_id [ 4 : 2, b]
#define ip_off [ 6 : 2, b]
#define ip_ttl [ 8 : 1]
#define ip_p [ 9 : 1]
#define ip_sum [ 10 : 2, b]
#define ip_src [ 12 , b]
#define ip_dst [ 16 , b]
#define PROTO_icmp 1
#ifdef IPV6_ENABLED
#define PROTO_icmp6 58
#endif
#define PROTO_tcp 6
#define PROTO_udp 17

This sample of the tcpip.def file shows how the macros used in the firewall are defined.
For example ip_src is [ 12, b]. This means that at offset 12 bytes data is read in big endian to gain the source ip address.

ip_len is defined as [ 2 :2, b]. This means that at offset 2 bytes, a 2 byte length is read in big endian to determine the ip length field.

These expressions can be used in an fw monitor command to filter on whatever is needed.
For example to capture packets to and from one ip address of interest we could use,
fw monitor –e “accept [12, b]=192.168.126.1 or [16, b]=192.168.126.1;”
OR you could use the macro definition
fw monitor –e “accept src=192.168.126.1 or dst=192.168.126.1;”

Using the macro definitions is usually easier to remember.

In this doc we will use the macros in the tcpip.def file.

Syntax Examples (cheat sheet);
Basic capture of everything on all interfaces,
fw monitor

To filter on an ip of interest,

-e “accept src=192.168.126.1;”
This will show just source address matching src.

-e “accept src=192.168.126.1 or dst=192.168.126.1;”
This will show both source and destination matching src or dst and is an example of the Or operator in use.

To filter on a particular protocol of interest,

-e “accept ip_p=6;”
This will show TCP packets only.

-e “accept ip_p=17;”
This will show UDP packets only.

-e “accept ip_p=6 or ip_p=50;”
This will show TCP and ESP protocols

Making a slightly more complex expression we will use ip address and protocol type as an example.
-e “accept ip_p=6 and src=192.168.126.1;”
This is an example of the And operator in use. If we used ping to test 192.168.126.1 the fw monitor would not show these packets, but if we used ftp to connect to 192.168.126.1 then all packets with a source of 192.168.126.1 would be shown.

To filter on an packet length

-e “accept ip_len=60;”
This will show all packets with the IP header and Data length of 60 bytes.
A standard Windows ping is 60 bytes total. This is found by adding the IP header of 20 bytes to the 8 bytes ICMP header and 32 bytes of ICMP data.

If we were trying to filter only packets larger or smaller than a certain size we could use;
-e “accept ip_len>512;”
This will show ip packets larger than 512 bytes.
-e “accept ip_len <512;”
This will show packets smaller than 512 bytes.
-e “accept ip_len > 60 and ip_len<70;”
This will show packets between 61 and 69 bytes long.

Note that ip_len is defined as the IP header and Data.

To filter on a source port or destination port

-e “accept sport=21;”
This will show packets from port 21.
-e “accept dport=21;”
This will show destination port 21
-e “accept sport=21 or dport=21;”
This will show source or destination port 21.

Note; that the definitions for sport, th_sport, and uh_sport are all the same [20: 2, b]. The same is true for dport, th_dport and uh_dport [22: 2, b]. This means a filter as set above will show port 21 even if it is a UDP port. If you wanted to filter only TCP ports you would have to add expressions.
-e “accept ip_p=6 and sport=21 or dport=21;”
This would show port 21 and only TCP.


To filter on a port and an IP address

-e “accept sport=21 or dport=21 and src=192.168.126.1 or dst=192.168.126.1;”

To filter flags or TCP states

The th_flags macro can be used in different ways and can get confusing so here is a brief explanation. The definitions below show how the macros for the flags are defined. In the syntax we can use the hexadecimals listed in this manner.
TH_FIN 0x1
TH_SYN 0x2
TH_RST 0x4
TH_PUSH 0x8
TH_ACK 0x10
TH_URG 0x20
-e “accept th_flags=0x1;”
will only see packets that have only the FIN flag set. If any other flag is set also it will not show up.
-e “accept th_flags=0x11;”
This will show packets with FIN and ACK flags set.
As you can see the hex numbers can be added together to reflect the flags you want.
OR we can use the following syntax;
-e “accept th_flags & 0x1;”
This will show packets with the FIN flag set even if other flags are set. This expression basically says look for flags AND if FIN is set show it.
-e “accept th_flags = fin;”
This will show packets with a FIN flag set even if other flags are set since fin is already defined as seen below in this sample of the tcpip.def file. Any of the below can be used.

syn { th_flags & TH_SYN };
fin { th_flags & TH_FIN };
rst { th_flags & TH_RST };
ack { th_flags & TH_ACK };
first { th_flags & TH_SYN, not (th_flags & TH_ACK) };
established { (th_flags & TH_ACK) or ((th_flags & TH_SYN) = 0) };
not_first { not ( th_flags & TH_SYN ) };
last { th_flags & TH_FIN, th_flags & TH_ACK };
tcpdone { fin or rst };


To filter on ICMP types

-e “accept icmp_type=8;”
This will show echo requests.
-e “accept icmp_type=0;”
This will show echo replies.
See the tcpip.def file to see the icmp_type definitions. Here are a couple of examples,
8= echo
0= echo reply
3= unreachable
5= redirect
11= ttl exceeded

To set the mask on filter

-m io
Will show pre-in and pre-out packets
-m IO
Will show post-in and post-out packets
The mask defaults to iIoO and shows all four inspection points. It can be set with the –m option to be whatever you want.

To set the packet capture count

-ci 3
Will show 3 incoming packets and the break out.
-m i –ci 4
Will show 4 incoming packets on the pre-in interface.

To print the packet payload use the –x option

-x 52, 96
This example would show packet data starting at offset 52 and printing 96 bytes to the screen. Output to a file gives all data any way so this is usually not needed.
The offset starts with the IP header. i.e. offset of 40 would give the start of data offset of 55 bytes in an http packet. 20 bytes ip header, 20 bytes tcp header.

To set the monitor position in the fw chain

-pi 3 –po 2
These are relative positions in the fw chain. The chain can be seen by typing fw ctl chain on the command line.




To change the insertion point you can use the relative position ie 1,2,3 etc.
Or you can use the alias such as secxl_sync. All details to usage and syntax can be found in How to use fw monitor.

Default insertion points

In using the relative number use the number after the module where you want it inserted, in other words if relative number 2 is Secxl_sync and you want to insert after this module then use –pi 3. If you use –pi 3 it is inserted after relative number 2. If using the alias then use the alias after where you want it installed. In other words, if you use –pi Secxl_sync then the position will be inserted before Secxl_sync. See Figure below.




NG AI has a new position option –p all which inserts at each point in the chain.

To filter packets that are part of a network or a range of ip addresses

-e “accept netof src=192.168.10.0;”
This will show all packets with an address on network 192.168.10.0
A mask can not be set, it is implied by the address. So if you have subnetted further you will need a different syntax to capture a range of addresses.
-e “internal = {<192.168.10.0, 192.168.10.128>}; accept (192.168.10.0 in internal);”
This will show all packets in the internal definition.

Putting it together with more complex expressions;
-e “accept not (src=192.168.126.1);”
To see all but src above.
-e “accept sport=21 and not (src=192.168.126.1);”
To see source port 21 but not from 192.168.126.1.

-e “accept src=192.168.126.1 or dst=192.168.126.1 and not (sport=22 or dport=22);”
To see everything to and from ip except ssh.

-e “accept src=192.168.126.1 or dst=192.168.126.1 and not (sport=21 or dport=21) and not (sport=22 or dport=22);”
To show all to an from ip except ssh and ftp.

-ci 200 –m iI –pi Secxl_sync –e “accept ip_p=6 and netof src=192.168.10.0 and not (sport=22 or dport=22);”
This will show 200 incoming packets before breaking out, with a mask of iI showing both pre-in and post-in with the monitor insertion point being before the Secxl_sync module in the chain. In addition it will only show TCP packets that have an ip address that is part of 192.168.10.0 network but not the ssh protocol.

This may be more complex than is reasonable but it shows what can be done with fw monitor.


I hope this is explanatory.. Pls write to me in case of quries.. :-)

....K@rthik