Alex Le Fevre
Regardless of whether you're a professional firewall administrator
watching over a network of machines or simply a home enthusiast
who's concerned about security, your best bet in making sure
that your firewall is working is looking at the log files it generates.
These often detailed records contain all the pieces necessary to
tell whether there are intruders attempting to break into your system.
These records can also let you know if you've put in rules
that are causing unnecessary network blockage, or if something else
is wrong with your network's operation.
The problem is that these logs are often much too detailed. Red
flags get buried under piles of successful operations meaning that
you could miss the solution to a potential problem. Further compounding
the problem is the dearth of software available to analyze and report
back on these log files.
I was alerted to this problem several months ago by a co-worker,
George Johnson, who was complaining to me one day that his management
wanted reports on firewall activity and that he had no way to give
them such reports without creating reporting software himself. As
an aspiring programmer looking to expand my C/C++ skills, I told
him I'd take a stab at writing such a reporting program; he
provided me with some sample log files from CheckPoint Software's
FW-1 package and gave me an idea of what might be required. I wrote
the program this article describes, Fwreport. See Listing 1.
My aim in creating this program was to make a tool that would
allow network administrators running FW-1 not only to generate reports
on demand, but also provide them with automatic notification of
potential problems on their network. (Currently, Fwreport only supports
FW-1; administrators interested in using it for other packages are
encouraged to send me sample log files so that I can expand its
capabilities.) I intended to make the software very easy to use,
but at the same time fairly customizable, particularly for those
with some C/C++ programming experience who don't mind popping
the hood and making more complex tweaks.
The first order of business for Fwreport was ensuring that it
could report back on both regular log files and archived files (which
have drastically different formats) without any user intervention.
Thus, I included an initial check to see which kind of file the
program is dealing with; it then acts appropriately depending upon
which type of file it sees.
By default, Fwreport provides a very simple yet fairly useful
report. It shows the number of packets that were accepted, dropped,
rejected, or encrypted, along with the percentage of time the firewall
spent performing each type of action, accurate to five decimal places
(as smooth-running firewalls should spend only miniscule amounts
of time rejecting or dropping packets). It also gives the total
number of actions taken by the firewall.
This information is sent out to the file report.txt, which
is generated in the directory from which Fwreport was run. See Table
1 for its format.
This report is useful in several ways. The total number of actions
performed lets you gauge just how busy your firewall box is, which
gives you a good idea of what's going on within your network.
Figures that are too high indicate that you might want to consider
upgrading your firewall machine (and possibly look into what exactly
your employees are doing on the network), and figures that are too
low indicate that there is possible network blockage somewhere,
as the normal number of packets are not getting through to your
Watching the number of dropped and rejected actions provides insight
into both intrusion detection and the functionality of your firewall.
If either of these numbers suddenly jump, either someone is trying
to break into your network (unsuccessfully, of course, meaning that
the firewall is doing its job properly), or that the new rule set
is written incorrectly (and if you don't do something about
it soon, you're going to get a lot of irritated tech-support
The number of encrypted actions helps analyze how hard a particular
application or group of users is working. Chances are good that
you've got only a few bits of your network traffic encrypted.
For example, your accounting department will likely encrypt communications
with banks and if you see a sudden spike here, you know that abnormal
activity is occurring. This can be useful for detecting intruders
who have gained system access and are trying to cover their tracks,
or for determining whether a new software package is being a resource
Of course, further detail would be required to help you get to
the bottom of any of these sorts of problems; Fwreport provides
such detail, both by default and on demand. The next file you may
want to look at is encrypt.txt, also created by default in
Fwreport's working directory. It contains a list of all encryption
failures on the network, along with the reference number of the
action that failed, which allows you to go back to your log files
and look more closely at such failures if you are so inclined. (Note
that in archived log files, FW-1 generates this reference number;
Fwreport simply uses the included number. For regular log files,
Fwreport creates a reference number that corresponds to the line
number of the file.)
Careful analysis of IPPairs.txt (which is generated by
adding "u" to Fwreport's command line) can
help you discover possible intruders. This file simply contains
a list of all unique pairs of IP addresses that connected through
your firewall. Any addresses that are outside the range of your
network, or that you would expect your users to be connecting to,
can be identified.
Users should note, however, that if they are managing a large
network, adding this option can add a considerable amount of time
to Fwreport's processing. Generating this log file with my
sample data added several hours to processing time. Thus, it is
best to only generate this file on a periodic or as-needed basis.
(My primary concern for Fwreport 2.0 is cutting this time significantly.)
Beyond that, you have to specify a small amount of information
for Fwreport to provide you with relevant log files. If you are
worried about dropped or rejected packets on your network, you simply
add a command-line argument specifying a threshold (in percent of
network actions) over which you wish to see more detail. For example,
if you wanted to examine your network more closely when 2% of actions
are rejects, you would run the program as fwreport logfile r
2. This would, whenever rejects account for more than 2% of
your firewall traffic, create reject.txt, which has a format
similar to encrypt.txt. It would also notify you via email
that the threshold you specified had been crossed. See Listing 2.
Further reporting features can be added fairly easily. For example,
since the program analyzes every IP address entered in your log,
a function could be written to trap all activity by a particular
user or group of users by writing to a report file every time their
IP address appears. Additionally, Fwreport does nothing with the
type of packet being transmitted (HTTP, SMTP, etc.); it would be
a simple matter to duplicate, for example, the encryptFail()
function to report on all of a particular kind of traffic, or to
calculate the amount of time the firewall spends processing these
types of packets.
Using Fwreport is a very simple task. (See the sidebar for installation
instructions.) After compiling the source code and specifying an
email address at which you wish to be notified of crossed thresholds
(in the companion Perl script that does the mailing), simply run
the program as follows:
fwreport /path/to/logfile/filename r .5 d .5 u
This will create report.txt, encrypt.txt, and IPPairs.txt
in Fwreport's running directory. The program will create reject.txt
and drop.txt if more than 0.5% of firewall actions are rejects
and/or drops, and notify you via email if either of the last two conditions
While it's easy enough to run Fwreport manually from the
command line, it's a much better idea to make a cron
job out of it. That way, you can have daily log files that you look
at each morning; forget about it entirely until a problem occurs,
at which point you'll automatically be notified; or have weekly
or monthly reports ready for management without any effort.
Since it's written in C/C++, Fwreport is fairly fast; on
my OpenBSD 2.8 system, which runs on an AMD 750-MHz i386 box, it
can parse a 112-MB log in less than 30 seconds. However, it is very
CPU-intensive, and can take much longer on older systems (the aforementioned
George Johnson ran it against the same log file on a P-160 with
OBSD 2.6, and it took about 15 minutes). I suggest that, before
you attempt to install it as a cron job, you run it manually
on a few files of varying sizes and get an idea of how long it takes
to run on your system. You could then set it to run at 2:47 a.m.
or some other ridiculous time when you know nothing else important
will be going on.
To ensure that you are catching all possible intrusion attempts,
vigilantly monitor encrypt.txt and set the reject threshold
very low (under 1%, in most cases) so that all suspicious activity
comes to light. Additionally, check my Web site:
for Fwreport 2.0; I intend to add more detailed reporting features,
as well as reports that cover broader periods of time. Both of these
will help provide a clearer picture of what is going on with your
firewall. The better you know your system, the less likely you are
to have problems with it.
I'd like to thank George Johnson, who gave me the idea of
submitting this program to Sys Admin as well as guidance
on what it should do, and my father, Ken Le Fevre, who spent countless
hours helping me through the coding process.