View Single Post

  #13 (permalink)  
Old 03-01-2008
Martin Gregorie
 
Posts: n/a
Default Re: Rejecting outside "root" and "administrator" messages

Cameron L. Spitzer wrote:
> In article <ncch95-rkt.ln1@zoogz.gregorie.org>, Martin Gregorie wrote:
>> Cameron L. Spitzer wrote:
>>> They come from everywhere, but when one hits it hits over and
>>> over on and off for several hours. Then I never see that IPA again.
>>> I'd love to be able to, e.g., block those in the netfilter for a few
>>> hours after they've tried e.g. eight bad addresses and no good ones
>>> within a minute or two. But that gets to be a database app that
>>> I don't want on the same host as Postfix.
>>>

>> Could this be a good case for greylisting, especially if you can find a
>> greylister that can be steered recognise and block spam?

>
> I can't see how. If the zombie hits eight times, the greylist
> will block the first and let the next seven through, and all
> eight of them tie up an smtpd process.
>

But thats not what greylisting does: it doesn't tie up an SMTP process
and doesn't work on a connection attempt count.

Greylisting immediately rejects the connection with 552 or similar, so
your SMTP process isn't tied up, and records the MTA details along
envelope sender and receiver details tagged with the initial connection
time. It will continue reject connections which match the details with a
temporary failure (451) until a configurable expiry period is exceeded.
20-60 mins is recommended.

Genuine mail will be retried because SMTP is an unreliable transport
method, but spam generators usually don't retry at all, let alone an
hour or so later. See http://projects.puremagic.com/greylisting/ for
more detail.

That sounds pretty much like it provides the end effect you described below:

> I want a database app whose input is some kind of log digest,
> and whose output is a dynamically maintained netfilter table.
> I'm already logging and rejecting the things. I want to block
> them in netfilter so they don't use any user CPU cycles
> or clutter up the log. That is, move rejecting the repeat
> hits from user space to kernel space. Reject them in
> microseconds, not milliseconds.
>


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Reply With Quote