Monitor /dev/ipl for logged packets
ipmon [-abDFhnpstvxX] [-N device] [-o [NSI]]
[-O [NSI]] [-P pidfile] [-S device] [-f device]
- Open all device logfiles for reading log
entries. All entries are displayed to the
same output "device" (stderr or syslog).
- Generate hex output representing the packet contents after the headers.
- Turn ipmon into a daemon, so it can run indefinitely.
- -f device
- Specify an alternative device or file from which to read the log information for normal IP filter log records.
- Flush the current packet log buffer, in bytes -- even if the result
- Map IP addresses and port numbers, where possible, into hostnames and service names.
- -N device
- Open the logfile to read NAT log records from device.
- Specify log files to actually read data from:
- NAT logfile.
- State logfile.
- Normal IP filter log file.
||The -a option is equivalent to using -o NSI.|
- Specify log files you don't wish to read
from. This is most sensibly used with the -a option.
Letters available as parameters to this are the
same as for -o.
- Print the port number (in log messages) as a number and never attempt to
look it up from /etc/services.
- -p pidfile
- Write the pid of the ipmon process to a file. By
default, we use
- Send packet information read through syslogd
instead of saving to a file. The default facility when compiled
and installed is local0.
The following levels are used:
- Logged packets use the "log" keyword as the action rather
than passed or blocked.
- Logged packets logged that are also passed.
- Logged packets that are also blocked.
- Logged packets that are considered "short".
- -S device
- Open the log file reading state log
records from device.
- Read the input device or file similar to tail.
- Show TCP window, acknowledge and sequence fields.
- Show the packet data in hex.
- Show the log header record data in hex.
The ipmon utility opens /dev/ipl
for reading and saving data from the packet filter.
The binary data read from the device is reprinted in
human readable form. The IP numbers, however,
are not mapped back to hostnames, nor are ports mapped back
to service names. The output goes to standard
output by default or to a filename, if given on the command
line. For -s, output is sent to syslogd.
Messages sent via syslog include time (in microseconds) but
don't have the day, month, and year.
Messages generated by ipmon consist of
whitespace-separated fields. Fields common to all messages are:
- The date of packet receipt. This is suppressed when the
message is sent to syslog.
- The time of packet receipt. This is in the form
HH:MM:SS.F for hours, minutes, seconds, and fractions of a
second (which can be several digits long).
- The name of the interface the packet was processed on
- The group and number of the rule, e.g. @0:17 that is viewed with
- The action: p for passed, b for blocked,
a short packet, n did not match any rules, L for a log rule. The
order of precedence in showing flags is: S, p,
b, n, L. When P or
B is used, it implies that the packet has been logged due
to a global logging setting, not a particular rule.
- The addresses. This is actually three fields: the
source address and port (separated by a comma), the ->
symbol, and the destination address and port. e.g.:
220.127.116.11,80 -> 18.104.22.168,1722
- PR followed by the protocol name or number, e.g. PR tcp.
- len followed by the header length and total length of
the packet, e.g. len 20 40.
If the packet is a TCP packet, there will be an additional field starting with a
hyphen followed by letters corresponding to any flags that were set. See
the ipf.conf page for a list of letters and their flags.
If the packet is an ICMP packet, there will be two fields at the end:
- ICMP message and the submessage type, seperated by a slash.
For example, icmp 3/3 is for a "port unreachable"
In order to log events, your filter rules must include the log
parameters in the filter configuration file rules. A sample filter rule
looks like this:
block in log ...
The ipmon utility expects data to be consistent with how
it is saved and will abort if it fails an assertion detecting an anomaly in
the recorded data.
"Setting up a firewall"
in the Securing Your System chapter of the Neutrino User's Guide