Rejecting outside "root" and "administrator" messages

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?


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

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.
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.


cls

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 |

In article <toho95-vus.ln1@zoogz.gregorie.org>, Martin Gregorie wrote:
> 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.

It does, from the time the guy connects, to the time he sees my
552, thinks about it for a while, and disconnects.
That's milliseconds to seconds.
The attack repetition rate is higher than that, so over
time at least one smtpd is tied up.
Of course it doesn't tie it up between attempts.

I want to protect Postfix from seeing the repeated attempts at all.
Rejecting an SYN packet in netfilter takes microseconds, no trip to
userland, no log traffic, and no DNS queries.


>
> 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.

There's no performance improvement in that. In fact, it's worse,
because after a 451 he comes back again for the same name.
It's cheaper to reject the nonexistent name with a 550.


>
> Genuine mail will be retried because SMTP is an unreliable transport
> method, but spam generators usually don't retry at all,

So the graylisting advocates say. But in practice, the
junk that is getting through here is coming from real MTAs,
not from driveby residential spamware bots. I already took
care of the vast majority of the latter with a private version
of something like pbl.spamhaus.org.

The real MTAs retry, and
graylisting does not stop them. Aside from the dictionary
attack, we get a lot of Herbal King and Yambo Financials spam
that way. In the traffic I'm seeing, the percentage of spam
sent by driveby bots, which is the only kind graylisting affects,
has been declining for two years.
The biggest spammers are breaking into well connected servers
and using the legitimate MTAs they find there or installing
their own.



> let alone an
> hour or so later. See http://projects.puremagic.com/greylisting/ for
> more detail.

That's four years old. The traffic pattern has changed quite
a bit since then.

Cameron

Cameron L. Spitzer wrote:
>
> That's four years old. The traffic pattern has changed quite
> a bit since then.
>
Fair comment. I hadn't realized it was so old either.

I've seriously considered greylisting but not actually tried it to date,
mainly because SA is doing a good enough job for me.


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

In article <rj11a5-met.ln1@zoogz.gregorie.org>, Martin Gregorie wrote:
> Cameron L. Spitzer wrote:
>>
>> That's four years old. The traffic pattern has changed quite
>> a bit since then.
>>
> Fair comment. I hadn't realized it was so old either.
>
> I've seriously considered greylisting but not actually tried it to date,
> mainly because SA is doing a good enough job for me.

No two recipients see the same traffic pattern. I expect
you're getting a lot less traffic than I am.
Spamassassin takes about 0.7 seconds to process a 30 KB
message on my Athlon. That's CPU time, not counting a few
seconds of waiting for remote block lists. I get at least
fifteen SMTP-starts per second. I'd need to dedicate a dozen
CPUs to have Spamassassin handle it all, with no headroom
for bursts and attacks. And another to cache its various
DNS answers locally. Spamassassin is the very last
layer of my defense, because it's the most expensive.
I've already stopped 95%+ of junk messages before it
gets there.

Returning to the original question, how do I tell Postfix
to reject messages to postmaster from a certain CIDR if
they have no rDNS, but accept the ones with valid rDNS?


Cameron

Cameron L. Spitzer wrote:
>
> Returning to the original question, how do I tell Postfix
> to reject messages to postmaster from a certain CIDR if
> they have no rDNS, but accept the ones with valid rDNS?
>
My setup is a lot different to yours and, as you guessed, I have a lot
less traffic. I put SA on my inbound message flow upstream of Postfix:

ISP--POP3-->fetchmail|SA|spamkiller|sendmail--SMTP-->Postfix

with outbound mail going directly to my ISP's mail server via SMTP and
SA,spamkiller and sendmail all connected by pipes in a script driven by
fetchmail's 'mta' facility.

Spamkiller is my own toy and is dead simple. If a message isn't spam it
pipes it to sendmail for forwarding to Postfix. If it IS spam it gets
thrown in the bit bucket. Either way spamkiller returns a zero exit code
to fetchmail to signal that the message was delivered OK. This causes
fetchmail to delete it from the ISP's mailbox. Spamkiller's logic is:

read the message headers into a buffer
if (the message is spam)
discard the headers
read, discarding input, until EOF
exit with status = 0
else
start sendmail via popen()
send it the headers
copy the message body to it
pclose()
exit with status returned by sendmail
endif

I've described this at length because I think you could use the same
technique in a Postfix service. If your program makes sure that the
service always reports "good delivery" it could probably get away with
chucking objectionable messages in the bit bucket rather than
re-injecting them into the SMTP input queue.

HTH


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