ipfauth - controlling TCP connections in auth rules (fwd)

[Stephen Swaney]

> -----Original Message-----
> From: mailscanner-bounces at lists.mailscanner.info [mailto:mailscanner-
> bounces at lists.mailscanner.info] On Behalf Of Jeff A. Earickson
> Sent: Wednesday, March 22, 2006 9:21 AM
> To: mailscanner mailing list
> Subject: ipfauth - controlling TCP connections in auth rules (fwd)
> 
> Julian et al,
> 
> This is from the author of ipfilter, a kernel-level firewall code
> for Solaris, BSD and other UNIX systems.  I have used ipfilter for
> a long time on my Solaris boxes and it is great.  This is probably
> of interest to the MailScanner community too.
> 
> Jeff Earickson
> Colby College
> 
> ---------- Forwarded message ----------
> Date: Sun, 19 Mar 2006 09:41:19 +1100 (EST)
> From: Darren Reed <darrenr at reed.wattle.id.au>
> To: ipfilter at coombs.anu.edu.au
> Subject: ipfauth - controlling TCP connections in auth rules
> 
> 
> For a while now I've been thinking about using IPFilter and auth rules
> combat the problem of spam.  In the last two weeks I've written a tool
> (and debugged ipf :) to give me some ability in this area.
> 
> The idea behind using ipfauth is that real mail servers will retry in
> sending an email.  This paradigm seems to work well (for now) but in
> looking at my logs, I can see spam software reconnecting within an
> hour or so (whether or not it is the same spam, I do not know.)
> 
> To this end ipfauth lets you define queues to put hosts in that attempt
> to connect, with the pause timeout and open window behing individually
> seperate.  It also allows the number of connections made during the
> window to be defined.  During the 'pause timeout' remote nodes cannot
> connect ("Connection refuse".)  I took this path because if email is
> spam I don't want to waste _any_ of my resources (TCP socket, disk,
> CPU, etc) dealing with it if I can help it.
> 
> The configuration is currently all with IP addreses, no hostnames are
> currently looked up except to see if a host is in a black list map
> (these too can be defined.)
> 
> So far this is all pretty ordinary, I suppose.
> 
> The next part I want to do is to make it possible to learn about
> whether a host is good or bad.  For this it allows you open up
> "voting" sockets using either TCP or unix domain sockets.  In the
> tar ball is a perl script called "addvote.pl" that can connect to
> the daemon and send a "black" or "white" vote command.  There is no
> security in the protocol (yet) because it is largely experimental
> at this stage.  The idea is that it should be simple enough for any
> spam-filtering software (like spamassassin, etc) to easily send a
> vote saying "good" or "bad" back to ipfauth.
> 
> My setup is to use a heavily modified version of smap that receives
> an email (after the connection has been allowed by ipfauth) and it
> then passes it through spamassassin.  If the verdict returned from
> that exercise (or any of its other checks) is that the email is a
> spam, it sends a "black" vote back to ipfauth for the originating
> IP address.  Likewise if smap successfully delivers it locally,
> it sends a "white" vote to ipfauth.  At present no amount of black
> votes will over ride a host explicitly allowed or in a white list.
> 
> So anyway, this can be downloaded from:
> 
> http://coombs.anu.edu.au/~avalon/ipfauth_1_2.tgz
> 
> It's very rough, no docs and is very experimental.  I'm curious
> about how well the voting will improve things (or make them
> worse in terms of false positives.)  It does require IPFilter
> 4.1.11 to work (although it may also on 3.4.xx - have not tried.)
> 
> Darren

Just some thoughts.

If the SpamAssassin MySQL lite DB store the IP of the message, this process
would only need to query the SpamAssassin MySQL lite DB to find out what
SpamAssassin thinks about the message. 

Might also be an alternate way to Implement the IPBlock Custom function.

Steve

Stephen Swaney
Fort Systems Ltd.
stephen.swaney at fsl.com
www.fsl.com