Free filter software for linux

webfilt is not a spam filter, but provides a generic web-based interface for Bayesian-style UNIX filters that need occasional training and corrections. It has been tested with SpamProbe and SpamBayes, but should work with other command-line filters too.

The webfilt system works with existing UNIX accounts, and consists of three distinct components that operate independently:

Users procmail recipes and cron jobs. The storelast.sh shell script is invoked by a users .procmailrc and simply saves a size-limited copy of each incoming e-mail message. The destination directory is determined by spam-state, done by procmail processing. A cron job periodically cleans old message copies.

webfiltd, daemon. The daemon component is invoked by inetd, and responds to a number of commands that allow a connecting client to authenticate, read files, and execute remote commands. This is all done with the authenticated users permissions. This daemon accepts just localhost connections.

webfilt.cgi, web interface The CGI program creates the web interface. Running with low privileges, it communicates with the webfiltd daemon over a socket to guarantee privilege isolation. The user logs in using their web browser and can then view recent emails and run commands on certain files (to train the filter).

Units-filter is a basic standalone filter written in C, flex, and bison.
It inputs strings like "1.5e3 nN.m.s^-1" (which could be the time growth ratio of a torque) and outputs the value in standard SI units, followed by the physical dimension of this value.
units-filter can be embedded in educational test systems, in order to analyze a students answer to a problem of physics or chemistry.
Enhancements:
- The support for quantities with a particular number of significative digits was added.
- For example, the entry "1.02m#5" or "1.0200m" are equivalent and signify a distance measurement precise at the sub-millimeter scale.
- Both would yield the output "1.0200e+00 m".

ip-filter-cgi is a set of perl script to modify rules of IP Filter (IP Filter is a TCP/IP packet filter cf: http://coombs.anu.edu.au/~avalon/ip-filter.html). If you make any improvement, correction send it back to. The scripts is not complete and is provided for testing purpose.
adulau@metatix.com .
Main features:
- Perl 5.0 (+CGI.pm)
- a HTTP server (Apache)

IM-Filter is a daemon for GNU/Linux firewall hosts written in C which is able to analyze and filter the ICQ protocol. The daemon runs in userspace and fetches packets of the ICQ protocol by using the libnetfilter_queue mechanism.
IM-Filters main purpose is to run at a gateway, so all ICQ-related traffic of users in the LAN runs over IM-Filter. Nevertheless the daemon could also be used directly on end users computers. The following diagram shows, how the daemon is integrated in a GNU/Linux system.
One of the design goals of IM-Filter was modularity. So plugins for other protocols like MSN or IRC could be written easily. The source code already contains skeleton code for an IRC module.
Together with the source code, adequate iptables scripts are provided so that only packets which belong to ICQ traffic get in the netfilter queue of IM-Filter.
Main features:
Logging of messages sent via ICQ
IM-Filter is able to identify and log messages which have been sent via the ICQ protocol. These messages contain a timestamp, an IP-address, the appropriate UIN and - of course - the message itself. A logged message could look like this:
[2007-07-27 11:24:21] IP "10.0.0.1" sent following message to #123456789: "hello, this is a test"
Blacklists for messages and UINs
IM-Filter handles two different blacklists: for messages and for UINs. The message blacklist holds strings which must not occur in text messages. When such a string is detected in a message, it gets censored in the logfiles.
The UIN blacklist contains UINs of users which are not allowed to connect to the ICQ network. Those blacklists can be re-read by the daemon during runtime by sending signals.
Detection and blocking of file transfers
Since file transfers are not always welcome, they can be blocked by invoking the daemon with a specific command line argument. Then, users in the LAN can not send files to other users anymore. Beside blocking, the daemon logs file transfers. Such a log entry can look like this:
[2007-07-06 17:01:26] FILTRANSFER detected (outgoing): receiver uin: #123456789 || filename: test.txt || size: 143360B
List with currently logged in users
To be able to know which users are currently logged in, IM-Filter manages a text file which holds all necessary information. By default, the file is placed in /var/log/imfilter.users and contains IP-address and UIN of the users which are currently logged in. The file could look like this:
UIN=123456789, IP=10.0.0.1
UIN=234567890, IP=10.0.0.22
UIN=345678901, IP=10.0.0.4

Compact Filter is a network packet filter for Linux. It features an easy-to-use compact filter representation and high performance.
The main features are: easy to use interface, compact filter representation (memory efficient), and very high performance.
A difference between CF and other firewalls, such as Netfilter, is its representation of the ruleset. In CF the user writes a filter which is then compiled and optimized in user-space. The optimized filter is then loaded into the kernel (using netlink). Consequently the in kernel packet filtering code only needs funtionality for setting up a filter and filtering packets, while the more complex code of optimizing the filter remains in user-space.
Because of the continuous increase of the bandwidth and the security threats, firewalls have to evolve towards more efficient filtering schemes. The truth is that the existing scheme does not scale so well with the combined growth of bandwidth and rulesets.
Our aim is to try another approach to perform packet filtering where we minimize the complexity of the filtering process. This result in, both, a reduction of the required CPU power to filter packets and a simpler (and smaller) kernel code. Of course, we are pushing all the smart and complex part out to the user-space, but, developing in user-space is much simpler and safer.
Enhancements:
- changed -d option to delete all filters
- added -D option to delete a specific filter
- changed default policy to permit rather than deny
- added -l option on flex to support --yylineno on older versions of flex
- new and improved install guide

IOLib-Filters is a filter package for IOLib. IOLib-Filters is mainly an example of how to write filters for IOLib.

IOLib is a portable universal data IO library. Implementations exist in C, C++ and Objective C and for many different platforms (including Linux, Win32, MacOS X and .NET).

IOLib provides a unified interface for accessing different types of data streams. It currently supports file IO, BSD sockets, memory buffers and SOCKS4/5 connections and can be extended with drivers easily.

It has support for different binary formats (Intel, Motorola, PDP) and it supports filters. You can write your own filters (e.g. for encryption or compression) and use them with IOLib.

Filter::decrypt Perl module contains a template for a decrypt source filter.

SYNOPSIS

use Filter::decrypt ;

This is a sample decrypting source filter.

Although this is a fully functional source filter and it does implement a very simple decrypt algorithm, it is not intended to be used as it is supplied. Consider it to be a template which you can combine with a proper decryption algorithm to develop your own decryption filter.

WARNING

It is important to note that a decryption filter can never provide complete security against attack. At some point the parser within Perl needs to be able to scan the original decrypted source. That means that at some stage fragments of the source will exist in a memory buffer.

Also, with the introduction of the Perl Compiler backend modules, and the B::Deparse module in particular, using a Source Filter to hide source code is becoming an increasingly futile exercise.

The best you can hope to achieve by decrypting your Perl source using a source filter is to make it unavailable to the casual user.

Given that proviso, there are a number of things you can do to make life more difficult for the prospective cracker.

Strip the Perl binary to remove all symbols.

Build the decrypt extension using static linking. If the extension is provided as a dynamic module, there is nothing to stop someone from linking it at run time with a modified Perl binary.

Do not build Perl with -DDEBUGGING. If you do then your source can be retrieved with the -Dp command line option.

The sample filter contains logic to detect the DEBUGGING option.

Do not build Perl with C debugging support enabled.

Do not implement the decryption filter as a sub-process (like the cpp source filter). It is possible to peek into the pipe that connects to the sub-process.

Check that the Perl Compiler isnt being used.

There is code in the BOOT: section of decrypt.xs that shows how to detect the presence of the Compiler. Make sure you include it in your module.

Assuming you havent taken any steps to spot when the compiler is in use and you have an encrypted Perl script called "myscript.pl", you can get access the source code inside it using the perl Compiler backend, like this

perl -MO=Deparse myscript.pl

Note that even if you have included the BOOT: test, it is still possible to use the Deparse module to get the source code for individual subroutines.

Do not use the decrypt filter as-is. The algorithm used in this filter has been purposefully left simple.

If you feel that the source filtering mechanism is not secure enough you could try using the unexec/undump method. See the Perl FAQ for further details.