Wflogs and fwlogwatch: a comparison

I was a fwlogwatch user. It's a cool tool, but it lacked some features that I really needed. So I looked at the code, but I quickly realized that it had not the modular design that I was looking for. So I ended up writing wflogs in C++, so it could be perfectly integrated into the WallFire project (the big picture).

Today, wflogs is not so far from the tool that I was looking for. So here is a little comparison (as objective as possible ;-) between the two tools, and let's see what can still be improved. If you have comments, please let me know.

What wflogs and fwlogwatch both do:

support for ipchains, netfilter/iptables, ipfilter, cisco PIX/FWSM, cisco IOS, and Snort IDS input log files.
text and html log summary.
output can be sorted according to several fields.
reverse DNS and whois lookups (with cache).
allow multiple log formats in one input file.
real-time monitoring.

What wflogs [v0.9.5] does, that fwlogwatch [v0.9.3] cannot do:

when used in conjonction with libadns, wflogs performs asynchronous reverse DNS resolution (sending multiple lookups in parallel), which makes wflogs considerably much faster.
wflogs is completely modular: new input (parsing) or output (report) modules (static or dynamic) can be easily added.
wflogs has other output formats: xml (using the wflogs DTD), human (human readable format), and netfilter, ipchains, ipfilter (translation from one log format to another).
wflogs has an interactive mode, particularly useful with realtime mode, as it acts as a very evolved "tail -f".
log entries can be selected using a filter conditional expression (a la Perl) with regular expressions, powerful date matching criterias, etc. Note that fwlogwatch supports selection and exclusion of specific hosts, ports, chains and branches, but this functionnality is far less powerful than the wflogs conditional filter expression.
obfuscation mode: useful for pushlishing log extracts without revealing too much information (IP addresses, MAC addresses, etc.).
MAC addresses are parsed as well (when available in log format), and the MAC hardware vendor can be displayed (guess from MAC address prefix).
the level of "strictness" in parsing can be determined (warnings, errors).
sort mode supports reverse order.
conditional whois lookup: whois lookup can be done systematically, or only if reverse DNS lookup failed.

What fwlogwatch [v0.9.3] does, that wflogs [v0.9.5] cannot do:

support for ipfw, NetScreen, Windows XP firewall and Elsa Lancom router.
produces customizable incident reports that can be sent via email.
daemon providing realtime monitoring on a web page, with actions using an external program.
HTML output can use external cascading stylesheet.
gzip-compressed logs are supported.
fwlogwatch is internationalized: English, German, Portuguese, Swedish, simplified and traditional Chinese are currently supported.

Somewhat subjective comments on fwlogwatch functionnalities missing in wflogs:

for the moment, both fwlogwatch and wflogs realtime mode are active and synchronous (read every second), which works with every firewalling tool producing a logfile. But some firewalling systems can provide asynchronous logging (-> passive wait) through a device. So wflogs will provide both active and passive (if supported by the firewalling system) real-time modes, to be as efficient as possible.
fwlogwatch realtime mode is a daemon which serves a web page. But web pages are not made for real-time notification, and this is not flexible enough. So wflogs offers an interactive shell mode, as well as the infrastructure for a Web page (see the soon to come phpwflogs), or for a X11 command (that will be called xwflogs), or any other interactive upperlayer.
even more input formats should be supported by wflogs. They will be added in the future, and that can be done very quickly, due to the very modular nature of the wflogs underlying library. Contributions are welcome.
I'm personnally sceptical about the production of customizable incident reports that can be sent automatically via email. I wouldn't do that myself, as false positives can lead to false reports and big annoyances for everyone (I've already seen such cases with fwlogwatch...). So I do not intend to implement this in wflogs for the moment. At least, this is clearly not one of my priorities, but if someone wants to help...
considering the lack of compressed file handling in wflogs, that is not really a big problem since you can use "zcat *.gz | wflogs -".
as far as the i18n is concerned, everything is ready (gettextized), and we're only waiting for translators. Contributors wanted!