Reptor is provided without warranty of any kind, either expressed or implied. Use it at your own risk. It is not developed, packaged, distributed, bought, sold, supported, acknowledged to exist, or in any other way related to or associated with Axent Technologies or Symantec. Okay, so the name is somewhat similar, but that's it. (It's a mangling of the words "report" and "Raptor".)
Raptor Firewall logfiles contain detailed information regarding all connections that are made through the firewall server. Typically, one logfile is generated each day and is given the name logfile.date. Because of the size and complexity of these logfiles, it is difficult to manually obtain any useful information from from. Reptor attempts to address this problem by analyzing the logfile and generating traffic reports and alert messages based on customizable conditions.
Reptor can generate alert messages and traffic reports in an extremely configurable manner.
Alert messages contain detailed information about individual logfile entries that have triggered a predefined condition as specified in a configuration file. For example, you may want to be notified about all telnet sessions that occurred between midnight and 6am, all ftp sessions that lasted longer than fifteen minutes, or all email messages that were larger than two megabytes. If you've really got Big Brother envy, or you're looking for some good blackmail material, you can even be notified whenever anyone browses a URL that contains an "objectionable" word. The list of objectionable words is customizable and can even contain regular expressions. Most alert conditions can be defined separately for each protocol. Alerts can be triggered in six different ways:
A traffic report is a table of statistics that contains information such as number of hits, number of bytes sent, number of bytes received, total number of bytes, and duration of time connected. Reports consider all non-filtered logfile entries, regardless of alert settings. Reptor can generate different types of reports, each individually configurable. Types of reports include:
If your firewall server has more than two network interfaces, Reptor can be configured to process only traffic flowing in certain directions and/or only traffic flowing between certain interfaces.
Reptor is a Perl program. In other words, it will run on just about anything that has a processor. If your target platform is Unix, you probably already have Perl, but you'll need to verify that it is a recent enough version, and that you have the required modules installed. If your target platform is Windows NT, you'll probably need to install Perl. Further details are available in the setup guide.
The primary design goal of Reptor is to generate a daily usage and exception report. It is not intended to provide reporting or analysis for long term activity (although it can, by merging multiple logfiles together). For this reason, it is recommended that Reptor be run automatically by utilizing a task scheduler such as Unix cron or Windows NT at. By default, Reptor will process the the logfile that was generated the previous day.
All options are read from a configuration file at runtime. By default, this file is named reptor.cfg. Before using Reptor, you must create at least one configuration file. A sample reptor.cfg is included in the Reptor distribution, and documentation is available on the configuration page.
Reptor generates HTML output. It can obtain logfiles from STDIN, the local filesystem, or through the remotelog utility that is shipped with the firewall. It can output to STDOUT, the local filesystem, to an FTP server, or to an SMTP server. Interesting combinations of these include, but are not limited to, the following situations:
Command line options override configuration file options.
Indicates Reptor's installation directory. If not specified, Reptor will use the current directory. Use of this option is not always required, but may be necessary when running Reptor from a task scheduler. This option overrides the basedir configuration file option.
The name of the configuration file to use. If not specified, reptor.cfg will be used. Unless a full path name is specified with the --config option, or a base directory is specified with the --basedir option, Reptor will look in the current directory for the configuration file. This means that if you are not running Reptor from the directory where the configuration file is located, you must specify either --basedir or --config even if your configuration file is named reptor.cfg.
The date of the logfile to process. The format for v4 logfiles is YYMMDD and the format for versions 5 and later is YYYYMMDD. If not specified, the logfile that was generated the previous day will be processed.
The directory that the desired logfile resides in. This option overrides the directory configuration file option.
Prints this list.
If you've specified the history_file option in the configuration file, Reptor will normally only update history when the logfile being processed is yesterday's log. Specifying --history will override this behavior, so that Reptor always updates history, regardless of the logfile being processed. It is up to you to ensure that the history file remains in date order.
The log to process has been cut from a larger file or merged from multiple files, so don't look for the datestamp on the first line, or ignore it if it's there.
The full name of the logfile to process. This option overrides --date and --directory.
Verify the correctness of the configuration file, the readability of the logfile, and exit without processing.
Print the Reptor version number and exit.
The speed at which Reptor can process logfiles varies greatly from system to system. Obviously, the most influential factor is the size of the logfiles. On a reasonably fast machine (say, a PIII/700 running Linux), Reptor can process upwards of 1Mb of log per second. By design, Reptor is meant to be run unattended in the wee hours of the morning. Hopefully, this will alleviate any speed issues you may have. If your logfiles are so huge and/or your processor is so slow that processing time becomes an issue, well ... tough. What do you want for free?