For example suppose that we have an FTP proxy protecting an FTP server. This proxy ensures that the clients to the FTP server are actually using the FTP protocol. In addition the administrator may also specify a small subset of FTP commands that are allowed, for example no uploads are allowed etc. The best feature about this is that the administrator can deploy the proxy on the perimeter and have the security policy apply to any machines that may be installed inside.
Such a fine level of control is great, but in practice most proxies do not really offer that level of contol, and if they do its difficult to configure.
The REAPOFF site will have a library of rules, each adding new functionality to the proxy or protecting against a newly announced vulnerability exploitation, in much the same way as IDS or anti-virus vendors include new signatures in response to new vulnerabilities.
Condition
Action .....
Action .....
Action .....
Condition
Action .....
etc.
A job is defined as a collection of actions associated with a condition. The actions are only executed if the condition is met. Each job is executed in turn and then the buffer is passed onto its destination. The full reference manual for writing configuration files can be found here. Typically a feature of the proxy is defined by one or more of such jobs. It is therefore easy to add or remove features by simply modifying the configuration files.
Since REAPOFF is written in C and has such a tiny footprint, it is ideal for embedded firewall applications. It is entirely possible to run a fully configured and operational firewall on a TRINUX machine with no hard disk at all, or on any of the many floppy based distribution. A mini-distribution specifically designed to run REAPOFF will appear on the download site shortly. Because REAPOFF consists of a self contained deployement directory, it may be used in conjunction with any other firewall distribution, or even be deployed on standard workstation platforms such as RedHat Linux or Debian.
REAPOFF was written from the outset to be an industrial strength firewall product. Great care was taken during coding to prevent buffer overruns and similar coding errors. Features such as dropping of user and group IDs are supported as well as a chroot prison environment. Usually REAPOFF does not require any libraries or other executables to be installed within its chroot prison (only a read only version of its configuration files), and so it is extremely easy to run in such an environment. In fact the REAPOFF distribution contains a script which automatically runs all the proxies inside a chroot prison.
Intrusion Detection has become a very hot topic lately. The basic idea of an intrusion detection system is that it listens to all network traffic promiscuously detecting particular attack signatures. The problem with this basic design is that if the IDS is successfully evaded, the attack will arrive at the target host without any alerts. In a way IDS does not really offer any protection to the servers, rather it provides detection (see for example Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection ). There are a number of projects aimed at using IDS technology to provide real protection to servers, probably the most famous of these is hogwash.
REAPOFF intercepts all communications between the client and the server. Further, because REAPOFF is a proxy, any low level packet injection attacks are guaranteed to not reach the target server. REAPOFF will simply create a new connection and pass the data onto the server. In this way REAPOFF can protect servers with weak TCP/IP stacks. Low level network attacks (such as IP fragmentation attacks etc) are no longer effective.
In addition REAPOFF has a powerful regular expression matching engine. This can be used to detect attack signatures, in a similar way to SNORT. For example, signatures have been written to detect complex CGI scanning attacks, such as used by whisker. Not only does REAPOFF detect such attacks, but it can take immediate action, like terminating the connection. This ensures that attacks never reach the destination.
Currently a host of attack pattens are implemented for each relevant proxy, drawing heavily from the SNORT project.