Firewall Reporter

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.

Program Features

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 firewall.

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 calls).

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 hog.

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.

Sample Usage

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

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:

http://www.schnarff.com

Thanks

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.