Re: [exim] cross connection message tracking - Was: exim all…

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Peter Bowyer
Datum:  
To: Exim Mailing List
Betreff: Re: [exim] cross connection message tracking - Was: exim allowed someone to slam my mail server for 3 hours
On 28/06/05, Kelley Reynolds <schnozzy@???> wrote:
> On Jun 27, 2005, at 6:27 PM, Peter Bowyer wrote:
>
> > My next enhancement is to count invalid recipients across connections
> > from a single IP, and DNSBL the connecting IP once it reaches a
> > threshold.
> >
>
> One thing we've used with success is using a simple lookup using
> SQLite (you can use whatever storage mechanism you want, it's the
> same difference) to determine if the last X messages from a host are
> failures. A format as simple as (ip, ts) would be sufficient for this
> purpose. Whenever a host is denied, toss and entry in there. Whenever
> a host is accepted, clean it out. Then at whichever point you feel
> like denying mail (like acl_connect or an smtp_max_* expansion), you
> can lookup to see whether or not they have had x failures in the last
> y minutes. If so, defer (or defer with delay, or deny, or deny and
> blacklist, or napalm, whatever makes you happy; we choose defer since
> no legit mail will be lost (in theory))


Yes, that's pretty much what I'm intending to implement. Working on
the interface to do it - will probably use readsocket and a daemon
process to handle the db writes.

> The cleaning of something like this is equally flexible. You can
> clean out old entries past Y minutes every time something is added,
> every time it's rejected, ever time a random number is > something,
> in a cron job, whatever. This kind of thing beats back a DOS or dict
> attack awfully quickly.
>
> If you want to be uber swank, you can have a network-accessible data
> store and do cross-mx/connection/message/tracking/fu with a local
> cache of the lookup results for speeeeeed. Of course, only a madman
> would try that....


That madman must be me, then - everything here is in a MySQL db which
replicates around the geographically-dispersed front-end MXs.
Including the shared SA Bayes db :-)

Peter

--
Peter Bowyer
Email: peter@???
Tel: +44 1296 768003
VoIP: sip:peter@???