Release notes for slfm-0.3

1. Slfm now has proper module support. Input, processing and output modules are supported. The program can
   currently have at most ONE input module, but many processing and output modules. The input module gets
   packet information and passes it on to the processing modules. This information travels from processing
   module to processing module, in the order they were loaded. Each processing module sends the results to
   the output modules. Again, the program can have one or more output modules. It's possible to do things like
   have one module log to syslog and another display nice, neat output on the console. The input and processing
   is done in the same way as it was in slfm-0.2 (except now it's modular). Data is read from iptables log
   messages and processed with the services module. The information can be sent to syslog (syslog module),
   standard output (stdout module) and/or the new, fancier ncurses interface (curses module).

2. The name of the pipe from which to read iptables log messages must now be specified in fw.conf. 
   It is no longer allowed on the command line. See point 3 below.

3. fw.conf layout has been altered slightly. "section globals" has 3 new options: inputModules, processingModules
   and outputModules. Each of these take a comma seperated list of module names as values. eg. 

   inputModules=logmessage
   processingModules=services
   outputModules=syslog,curses

  currently, logmessage and service are the only input and processing modules. syslog, curses and stdout are
  the three output modules. one or more of them must be used in the outputModules line.

  A new section has been added: "section logmessage". It has one option, the name of the pipe
  to read iptables log messages from. The default looks like this: 

  section logmessage
  filename=/usr/adm/iptables.pipe
  endSection

  This option was removed from the command line as it is now specific to the logmessage module.

  the "services" section no longer supports the logServices and logServicesConsole options in light
  of the outputModules line above

4. A ncurses interface has been added. It works well on the console. In rxvt/xterm, it attempts to set
   the default terminal type to "xterm-color", unless the "term" value is set in "section curses" of
   fw.conf. The ncurses message buffer displays
   more output than the old, ugly, console output. Trojan alerts appear in red. The "up arrow" key
   scrolls up one line, "page Up" can be used to scroll up half a page (the opposite for the down arrow 
   key and page down). About 100 messages can be buffered.

5. The consec and max rules can now be used on dynamic IP addresses. I must've been stoned or sumting when I
   wrote the original code cos it's just 2 steps up from totally useless. But for some reason, it all made
   perfect sense to me when I was doing it. Anyways, rather than explicitly specifying and ip or ip range,
   you can just specify $SRC eg.

   if (dpt=20,21) then doWhois(1,1 $SRC) end

   this will apply the action defined by doWhois at most once to any packet trying to connect to your ftp 
   server. Things like $SRC/24 and $SRC/12 and $SRC/16 are also allowed. Obviously, specifying a range
   involving $SRC makes no sense since $SRC is, by definition, dynamic. So something like $SRC/23-$SRC is not
   allowed.

   *************READ THIS***************READ THIS******************READ THIS****************READ THIS*********
   A word of caution. using $SRC requires the program to remember the addresses it has already seen. So when
   using $SRC, each packet coming into your system needs to be checked against a list of previously seen packets to
   see if the user-specified action (like doWhois) should be taken for that packet (if the expression evaluates
   to true of course). So, more packets means more memory and more processor usage. Tracking each address takes
   very little memory, and the extra processor usage to check one extra packet is negligible. But you may notice
   things slowing down if you track thousands or tens of thousands of different packets. For this reason, 
   i recommend using things like $SRC/24 rather than just $SRC. $SRC will use a few bytes of memory to 
   track ONE address. $SRC/24 will use exactly the same amount of memory but will track 256 addresses. $SRC/16
   will also use exactly the same memory (and use the same processing power), but will track 65536 addresses and
   so on. I realize that in many situations, it will be necessary to use $SRC, but whereever possible, I 
   strongly recommend using $SRC/xx instead.

6. Extending the program is now very easy. I've included a module programming guide in the doc/ directory
   to get anyone who's interested started.