Having a firewall is important for overall security, but it’s equally important to regularly monitor its logs. Log monitoring helps you track possible access problems, provides data on the effectiveness of your rule sets, and documents hack attempts.

Monitoring such activity provides an excellent means to check out what’s hitting your server and fix problems before they get out of hand. However, firewall logs tend to contain verbose network information in as compact a message as possible, which can be rather tedious to sift through. This is where firelogd comes in handy. The firelogd program monitors Linux firewall logs and e-mails summarized alerts to an administrator’s e-mail address. In this article, I’ll explain how to set it up and use this open source daemon.

Learn about firewalls

Read these articles to find out more about Linux firewalls:

Downloading and installing firelogd
The firelogd program isn’t a firewall in itself. It merely processes logs from an ipchains or iptables firewall. You can obtain firelogd in source and RPM versions from the official Web site.

Once you’ve downloaded the program, unpack it into its own directory using the tar command. It is a good idea to glance through the README file that is provided. The latest version of firelogd also has a QUICKSTART file that gives a brief overview of the installation.

You should be able to install firelogd with the following commands:
make setup
make
make install

The build target make setup performs a few commands necessary to get firelogd completely installed on your machine. First, it creates /var/log/kernelpipe. This is a FIFO buffer file written to by the system logger (syslog). For messages to actually be written to it, the following entry is also added to /etc/syslog.conf:
kern.info   |/var/log/kernelpipe

The syslog daemon (syslogd) is then restarted and firelogd can then read the firewall logs. The make command then compiles the source code and make install copies the binaries and libraries to their appropriate system locations. Of course, if you downloaded an RPM, simply executing rpm –Uvh <filename> should get you up and running.

Running firelogd
The firelogd program operates in a number of modes. Starting the program by itself with the command firelogd will log information to the console. Adding a -d option when starting the program loads it into the background as a daemon, watching and buffering messages in real time. It can also be run against an existing file to parse firewall logs. The program accepts and understands both ipchains and iptables syntax, although it will cease watching for one after it identifies the other. If you are running a system with mixed logging, specifying the -m switch will tell firelogd to continue watching for both. The option –e<admin@domain.com> sets the e-mail address where alerts are sent (the default is root@localhost).

The program will queue up a certain number of messages—the default is 10, but you can modify it—and then it will mail filtered logs to a user-defined e-mail address. These messages help you stay informed of security events on your firewall without even needing to log in. You can also use them to obtain data to help you tweak your rule sets.

An example of how this works might go something like this: You start firelogd and soon receive e-mails stating HTTP access is being denied. You have your firewall set to allow HTTP to only a few requests every second. You can then look into what’s causing the problem, be it increased demand for your content or a denial of service (DoS) attack.

Or maybe alerts start filtering in that SMTP is being denied to a certain IP address. After some research, you find out this IP address belongs to the new office that just opened across town. Before a help desk ticket or phone call is even generated, you can fix the problem and avoid the further troubleshooting steps.

There are many situations where firelogd can help you pinpoint problems and keep track of security events. The best thing to do is to play with your firewall rules and your firelogd settings until you’re happy with the results of both.

Creating templates
With firelogd, you can also create templates to filter the raw firewall logs through. This lets you control the level of information provided in your e-mails and its formatting. It also permits you to add text to be printed with the filtered message. This can be useful in sorting messages later or for adding HTML tags for Web-based output. Before I further explain the templates, let’s look at a couple of log entries from firelogd. Below, you will find one entry directly from iptables and one firelogd interpretation of that entry.

iptables version 
May 9 04:49:37 linux_firewall kernel: IN=eth0 OUT= MAC=00:50:da:d5:bb:82:00:10:67:00:b1:86:08:00 SRC=10.0.0.1
DST=192.168.1.1 L EN=60 TOS=0x10 PREC=0x00 TTL=56 ID=50377
DF PROTO=TCP SPT=2938 DPT=23 WINDOW=16060 RES=0x00 SYN URGP=0

firelogd version 
04:49:37/May-9 ******S* TCP *D*  eth0 ***|D**** ttl:56
 remote.server -> telnet(23)
   10.0.0.1:2938 -> linux_firewall:23

The firelogd version, which used the default syntax, is much cleaner and easier to read. It also resolves DNS names for the source and destination IP addresses, and it lists the service name and port number. In the situation above, remote.server (10.0.0.1) attempted a telnet connection to linux_firewall (192.168.1.1). The connection was denied and logged using the following iptables rules:
iptables -A INPUT -j LOG -p tcp –destination-port telnet
iptables -A INPUT -p tcp –destination-port telnet -j DROP

Since firelogd processes logs based on input from the firewall, configuring logging on your firewall rules is very important. If you don’t have a rule that logs events, firelogd will never see them. In the example above, the placement of the LOG rule is very important because it needs to come before the one containing the DROP target. Doing this ensures that the LOG rule is reached and a message written before the packet is dropped.

An example template file is provided with firelogd, usually located at /etc/firelog.conf. It contains a number of templates you can modify for your own needs. The templates are basically plain text files with variables separated by spaces. They also contain a set of predefined variables that you may use. The basic ones are nl for printing a new line, sp for printing a space, srcip for printing the source IP address of the machine that attempted to access your system, and r_srcip for printing its resolved hostname.

The following is a sample template:
Host sp r_srcip sp with sp IP sp srcip nl attempted sp access sp on sp month sp   day sp at sp time sp **WARNING** nl

There are quite a few more that make up everything you would want to output from a log entry, so check the documentation for a full list.

The output that would be e-mailed based on an example match would look like this:
Host remote_server with IP 10.0.0.1
Attempted access on May 15 at 16:20:04 **WARNING**

This is a rather simple example, but templates can be as complex as necessary, depending on the level of information you require, which makes firelogd extremely flexible.

Keep on top of your system security
While having a firewall is important, it can be even more effective if its log files are monitored on a regular basis. The firelogd program makes this task simple. The program takes logged messages from ipchains or iptables, processes them through a filter, buffers them until a certain number have been received, and then e-mails the information to an administrator. This allows you to stay on top of your system’s security and services and greatly simplifies the process of doing so.