Overview | Motivation | Description | Download | Author
fwlog is a program that receives IP packets from the Linux firewalling code (commonly called iptables) and logs the information of the packet headers (IPv4, ICMP, UDP and TCP). IP addresses, protocol ids and TCP and UDP port numbers are translated into human-readable textual names. fwlog receives packets via the ULOG kernel module from the iptables system and is similar to the ulog daemon provided by Harald Welte.The current version of fwlog is 0.8 and it is considered alpha software, although it has been quite stable on my system. fwlog is distributed under the GNU General Public License.
PKT: mark 0, hook 1, received 2003-11-10 12:46:29.352959, indev ppp0 IP(41): [df], ttl 111, proto 6 (tcp), from 188.8.131.52 (h21n2fls23o1059.bredband.comhem.se) to 184.108.40.206 (dialin-145-254-034-035.arcor-ip.net) TCP: src port 3531, dst port 3220, seq 0x891a0627, flags [psh], winsz 63525, ack 0x363a3b9e PKT: mark 0, hook 1, received 2003-11-10 12:46:33.661828, indev ppp0 IP(40): [df], ttl 112, proto 6 (tcp), from 220.127.116.11 (d515382DE.kabel.telenet.be) to 18.104.22.168 (dialin-145-254-034-035.arcor-ip.net) TCP: src port 3875, dst port 3422, seq 0x72750f61, flags [fin], winsz 63652, ack 0x5d1b04da
Currently (November 2003) fwlog has only been tested with kernel version 2.4. The latest release is 0.8, which is the first public release.
Ever since starting to use the packet filtering code in kernel 2.2 I found the information provided by the kernel about packets a bit terse. The LOG target dumps only the most important fields in numerical form, so while analyzing the log, one had always remember that for example protocol 17 is UDP, port 9 is "discard" or that protocol 1 is ICMP, type 8 (or was it code?) is "echo request", and so on.
The translation of these numbers into the familiar names in a program is pretty simple and straightforward. The main exception is the resolution of IP addresses into the associated hostnames via DNS. In any case, it was clear that such functionality did not belong inside the kernel but rather into a userspace program. For kernel version 2.2 there was no obvious way to achieve that. However, some time after the initial release of kernel 2.4, the ipt_ULOG module appeared, which provided the necessary interface for transferring packets directly from the iptables code to userspace for detailed analysis and logging.
The author of the ipt_ULOG module (Harald Welte) also provided a userspace program to go along with the kernel module, which is called simply "ulogd". It is available from http://www.gnumonks.org/projects/ulogd. After finding that early releases of the ulog daemon did not offer the desired functions, the fwlog project started, but progressed only slowly and with long pauses. The program has now reached a state where I consider it adequate for running it on my private systems and releasing it to others.
After the reception of a packet from the kernel, the main task is to resolve the source and destination addresses into the hostnames registered in the DNS. The simplistic approach via gethostbyaddr(3) was considered inadequate, because the program would block for each IP address, i.e. 2 times for each packet. Each call could potentially block for a very long time if a recursive query would have to be initiated by the local name server. In situations where the firewall would log a large number of packets over short periods of time this could lead to a considerable queue of packets waiting to be logged by the program. fwlog therefore performs asynchronous DNS queries and caches the results in memory for better performance.
This means that fwlog generally accepts packets from the kernel as fast as they can be transferred from kernel space. After receiving a packet, DNS queries are initiated for source and destination address and fwlog continues to wait for further packets from the kernel. In other words, the packets are queued in memory while they wait until the query results arrive.
As pointed out before, DNS queries can take any length of time, up to several seconds. If the system crashed in the meantime, for example due to a denial of service attack, the packet data would be irretrievably lost. But the queued packets could have provided important clues about the attacker or the nature of the attack.
In order to prevent this information loss, each packet is written out to disk by fwlog, immediately after receiving it from the kernel. Each packet is written to a separate file in a designated directory. After a packet's contents have been logged it is deleted.
During the startup initialization, fwlog checks if there are leftover packet files in the directory. If it finds any, they are enqueued for logging as if they just have been received from the kernel. Note that the packet format from ipt_ULOG provides a timestamp so that the reception time in the log reflects the time when the packet was received by the kernel, not when fwlog accepted it into its queue.
In its current state fwlog has not been widely tested and is thus considered alpha software that should not deployed in a live environment. In particular it cannot be ruled out that fwlog itself opens the host it is running on to a denial of service attack, for example by trying to overload its packet queue.
|Source||fwlog-0.8.tar.gz||GPG signature||Debian 3.0 (woody) package||fwlog_0.8-1_i386.deb||GPG signature|
fwlog has been written by Klaas Teschauer. Comments and questions are welcome. My email address is klaas /\ kite ? ping ? de. My public key is available here for verification of the file signatures (and private email, if necessary).