Re: [exim] flood protection

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Ted Cooper
Fecha:  
A: exim-users @ exim. org
Asunto: Re: [exim] flood protection
Klauss Fumuldavijus wrote:
> hello,
>
> imagine a situation when certain spam hosts are flooding exim 4.66 mail server with thousands of email messages per minute.
> all of those rcps are rejected because of presence in the gray-lists.
>
> Some questions realated to solving the problem:
>
> is exim able to limit message rate from a certain host?
> or...maybe it is possible to give kind of ban on certain ip address depending on spam-list information?
>
> sadly, google seems to give no answers on this problem...
>
> please, share your opinion on this matter, because damn spammers are eating server's bandwidth and hardware resources.
>
> currently i am using exim's log analyzer and firewall deny rule generator, but rule count is increasing in geometrical proggression and server gets to low on resources...
>
> thank you


First of all, I would recommend an update to 4.67 - 4.66 has a nasty
retry bug in it.

If you have some way of identifying who you want to slow down, you can
either use the delay = 60s sort of thing in the ACL's, or I believe
there is now rate limiting built into exim but you still have to tell it
who and how to do it. Check the docs for info
If you have some way to know the annoying IP addresses, you can always
delay them at connect time (you have 5 minutes to say 220 hello), MAIL
time (5 minutes), each RCPT time (5 minutes), DATA (2 minutes). Of
course, you should keep well clear of the maximum limit as even good
servers will time out if the wait is too long.

I have some protection written into my greylisting (custom - yucky).
Based on the number of times a specific IP has attempted to send to a
different sender/recipient combination, I delay the response by a number
of seconds, up to 30 seconds below the limit specified in the RFC's. It
doesn't cost me anything to have them sitting there waiting for a reply,
and if they repeatedly disconnect without using QUIT they are even more
harshly treated next time.

This also prevents exceedingly stupid "legit" mail servers (Postfix,
Exchange) from hammering the crap out of my servers when they get a 4xx
error at a strange time - pre-DATA time first time around, RCPT time all
subsequent times. I do it at pre-data so I don't break callouts, I know
who they are sending from/to, and so I have to take the body until it
has a chance of being accepted. They are just slowed down enough that it
doesn't fill the logs with crap, but they get their mail through if it's
a real server.

Unfortunatly I wrote my greylist daemon in a language that I should be
shot for even thinking about writing a daemon in it so it's never
heading out into the public domain until I rewrite it in a real
language. I use ${readsocket to communicate with it as ${run kept on
getting killed with signal 9 for some strange reason which I never
looked into.

Have fun in the war against spammers!

Ted.