Firewalls like iptables(1) usually offer POSTROUTING (source network address translation, snat) facilities changing the source address of a host behind the firewall to the address of the host before the firewall. With snat the following combinations of IP addresses and port numbers are encountered:
Source natting usually uses sport for fwport, but fwport may already be in use, in which case the firewalling host must use another, available port to forward communication from IPsrc, sport to IPdst, dport.
The general scheme that applies to source natting, therefore, looks like this:
IPsrc:sport is translated by the firewall to IPfw:fwport;
IPfw:fwport is used when communicating with IPdst:dport.
From the perspective of the destination host the communication originates
at IPfw::fwport and consequently all communication (e.g., and incident
report) sent by the systems administrator maintaining IPdst to IPfw's
systems administrator will refer to IPfw:fwport, rather than to
IPsrc::sport.
The standard log facilities provided by iptables do not easily allow us to relate IPfw:fwport to IPsrc:sport, and natlog was developed to fill in that particular niche.
When running natlog, messages are sent to the syslog daemon (e.g., rsyslogd(1)) and/or the standard output stream showing the essential characteristics of the connection using source natting. Here is an example:
NATLOG: (TCP) From 1338990672:55588 until 1338990747:807100:
192.168.19.72:4467 (via: 129.125.90.132:4467) to 200.49.219.180:443
In this example the values 1338990672:55588 and 1338990747:807100
represent time stamps showing the begin- and end-times in seconds:microseconds
of a TCP connection since Jan 1, 1970, 0:00 UTC. Natlog offers the
--datetime option, resulting in time representations like Nov 2
13:29:11 rather than time representations using seconds and micro seconds.
The next value (192.168.19.72:4467) represents IPsrc::sport. This is followed by 129.125.90.132:4467, representing IPfw:fwport. The third pair of values (200.49.219.180:443) represents IPdst:dport.
In this example, host 192.168.19.72, using port 4467, connected to host 200.49.219.180, port 443. To this latter host the connection appeared to have originated from 129.125.90.132 port 4467. The provided log message easily allows us to related this to the `real' host and port from which the connection originated: 192.168.19.72:4467.
When natlog terminates natlog can no longer track connections that are still open. If natlog was terminated by a SIGTERM signal, then it sends a `terminating' line to syslog, followed by an overview of all still open connections. The end-microseconds values of connections that are no longer tracked are shown as 0000.
All options, except for config, help and verbose can also be specified in the configuration file. The configuration file ignores empty lines and all information on lines beginning with a hash-mark (#). In the configuration file option names do not use initial hyphens, and may immediately be followed by a colon. Multi-word arguments should not be surrounded by quotes. Examples:
stdout
syslog-facility: LOCAL0
Command-line options override configuration file options.
- Monitoring the TCP layer four protocol;
- Displaying real-time event logs (-E);
- Displaying time stamps (-o timestamp);
- Logging all new and destroyed (ended) events (-e
NEW,DESTROY);
The protocols to monitor can separately be configured using the --protocol option.
The conntrack program must be available when requesting natlog's conntrack command. Layer four protocols other than TCP, UDP and ICMP are currently not supported. A subset of the supported protocols may be requested using conntrack's -p tcp, -p udp or -p icmp options.
If the conntrack-command option is specified, the protocol option is ignored.
NATLOG: From 1338990672:55588 until 1338990747:807100
These time stamps indicate times in seconds:microseconds since the
beginning of the epoch, January 1, 1970, 0:00 UTC. This option can be
used to change the seconds part of the time stamps to more
conventional representations.
When using rsyslogd(1) property based filters may be used to filter syslog messages and write them to a file of your choice. E.g., to filter messages starting with the syslog message tag (e.g., NATLOG) use
:syslogtag, isequal, "NATLOG:" /var/log/natlog.log
:syslogtag, isequal, "NATLOG:" stop
Note that the colon is part of the tag, but is not specified with the
syslog-tag option.
This causes all messages having the NATLOG: tag to be written on /var/log/natlog.log after which they are discarded. More extensive filtering is also supported, see, e.g., http://www.rsyslog.com/doc/rsyslog_conf_filter.html and http://www.rsyslog.com/doc/property_replacer.html
Examples of natlog activations:
Here is natlog's default configuration file. Empty lines and lines starting with hash-marks (#) are ignored. Options adhere to the following syntax:
option value
Option and value are separated by white space, a colon may be appended to
option names, and option values may consist of multiple words.
# This configuration file shows the default option values.
# all options and values are case sensitive
# see `man natlog' for further details
# the path and options of the conntrack program:
# when no filtering options are specified, the tcp
# protocol is monitored
# the default command is shown:
#conntrack-command: /usr/sbin/conntrack -p tcp -E -n -o timestamp -e NEW,DESTROY"
# the protocols that are scanned with the 'conntrack' command:
# protocol: all - monitors tcp, udp, icmp
# protocol: udp:tcp - monitors upd and tcp (any non-empty subset,
# possibly including icmp is OK)
# ignored when conntrack-command is specified
#protocol: tcp
# the default syslog tag:
#syslog-tag: NATLOG
# the default syslog facility:
#syslog-facility: DAEMON
# the default syslog priority:
#syslog-priority: NOTICE
# the time specification:
#time: raw
# the path to the pid-file of natlog's daemon process
#pid-file: /var/natlog.pid
# end of the configuration file
conntrack(1), iptables(1), rsyslogd(1), syslog(3)
The conntrack command currently only supports the TCP, UDP and ICMP layer four protocols.
The indevice outdevice command currently only supports the TCP protocol.
Frank B. Brokken (f.b.brokken@rug.nl).