SunScreen EFS Release 3.0 Reference Manual

Network Monitoring and Maintenance

The following describes how to monitor and maintain your SunScreen EFS 3.0.

Installing a Patch

If and when patches are necessary, follow the instructions accompanying the patch.

Examining Logged Packets (`ssadm logdump`)

SunScreen EFS 3.0 provides flexible logging of packets. A packet can be logged when it matches a rule, or SunScreen EFS 3.0 can be configured to log packets that do not match any particular rule. Most frequently, packets matching Fail rules or packets that are dropped because they do not match any rule are logged. The action definition of a rule controls whether a packet is logged and whether the logging is detailed or summary.

To set the logging type of packets being dropped because they do not match any rule, use the administration GUI.

Examining logged packets can be a very useful tool in troubleshooting problems in setting up configurations. For example, when first creating configurations, make the default Fail action "log packets." This way, the logs can be reviewed to discover forgotten protocols that then can be added to the configuration. A system administrator can also use logging to capture any attempts to break in.

Logs are retrieved and cleared using the Logs page of the administration GUI. Once a log is retrieved, it can be examined using the ssadm logdump command.

Using the `ssadm logdump` Command

ssadm logdump is based on the Solaris snoop program and has similar characteristics. In addition to the packet information available with snoop, ssadm logdump also adds additional information such as the interface on which the packet was received and the reason that the packet was logged.

For details on the ssadm logdump command, refer to the ssadm logdump man page, by typing:

man logdump < log_file

to run ssadm logdump and display packets in the log. log_file is a log file that is downloaded from the Screen.

Session Records

When the ssadm logdump program is run with the loglvl sess filter expression, it outputs the data about sessions in the log files.

Sessions can be either TCP sessions (connections), UDP sessions (request/response pairs), or IP sessions (traffic of a particular IP type between a pair of hosts).

These session data track the state saved in the state tables in the firewall. Session data are enabled by setting the log type to "session" for encryption and pass rules.

The format of the log entries is as follows:

TCP session: IDid SRC srcaddr:srcport DST dstaddr:dstport FWD fwdpackets:fwdbytes REV revpackets:revbytes TIME starttime:stoptime STATE finalstate

UDP session: IDid SRC srcaddr:srcport DST dstaddr:dstport FWD fwdpackets:fwdbytes REV revpackets:revbytes TIME starttime:stoptime

IP session: IDid SRC srcaddr DST dstaddr PROTO proto FWD fwdpackets:fwdbytes REV revpackets:revbytes TIME starttime:stoptime

where:

Table B-7 S ession Record Arguments


`Argument`	Description
`id`	ID for the session. If two sessions have the same ID, then they are somehow associated with each other. For example, an FTP control and data session, or a RealAudio(TM) control and audio session.
`srcaddr`	IP source address of the session either as a name or address.
`srcport`	Source port of the session.
`dstaddr`	IP destination address of the session either as a name or address.
`dstport`	Destination port of the session.
`proto`	IP protocol for IP sessions; for example, 6 = TCP.
`fwdpackets`	Number of packets sent in the forward direction. That is, packets from the source address to the destination address.
`fwdbytes`	Number of bytes sent in the forward direction. That is, packets from the source address to the destination address.
`revpackets`	Number of packets sent in the reverse direction. That is, packets from the destination address to the source address.
`revbytes`	Number of bytes sent in the reserve direction. That is, packets from the destination address to the source address.
`starttime`	Start time of the session in seconds since midnight GMT Jan 1, 1998.
`stoptime`	Stop time for the session in seconds since midnight GMT, Jan 1, 1998. You can calculate total session elapsed time by subtracting `starttime` from `stoptime`.
`finalstate`	Binary value representing the final state of TCP connections. The following values are possible: A connection was not established because no response to SYN packet was received from the server. A connection was not established because no response to the SYN/ACK packet was received from the client. A large number of these sessions could indicate a SYN attack. A connection timed out due to lack of traffic. A connection closed successfully or was reset.

Using the `ssadm debug_level` Command

If you have access to the console on your SunScreen EFS 3.0 (through a serial line or directly connected CRT), you can use the ssadm debug_level command to control the printing of debugging information from the SunScreen EFS 3.0 kernel.

If you type ssadm debug_level with no arguments, it displays the current debug-level mask. By default, this mask is "1," which means it only reports significant errors.

If you specify a hex number as an argument for ssadm debug_level, it sets the kernel debugging mask to that level. To get a list of debugging bit choices type

ssadm debug_level -h

You select a ssadm debug_level mask by setting all of the debugging bits in which you are interested.

Probably the most useful of the ssadm debug_level debugging bit is DEFAULT_DROP. For example, if you type:

ssadm debug_level 1001

any packets being dropped by SunScreen EFS 3.0 because they do not match any rule are reported. This is a quick way to see if the SunScreen EFS 3.0 is passing packets that you expect it to pass. You can also achieve this same result by setting the default action for the interface to "log summary" or "log detail" and examine the logs.

Another useful debugging bit to set is STATE_CHANGE. This causes the kernel to report any additions or deletions from its internal state tables.

Some of the debugging bits produce a very large amount of output on a production Screen and should be used with caution. An example is ACTION, which reports execution of any PFL action.

Gathering Information From Your System to Report Support Issues

If you have any support issues, call your authorized service provider. For further information about support, use the following URL to contact Enterprise Services: http://www.sun.com/service/contacting.

It is helpful to first gather information describing your configuration. This information can be collected by saving the output of the following SunScreen EFS 3.0 support commands. You invoke these commands for infomation that is useful in troubleshooting through the ssadm lib/support command.

The support command has the form:

ssadm [ -r Name_of_the_Screen ] lib/support function parameters ...

See the Unstable Command section earlier in this appendix.