Work-in-progress: trickle attack defense

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Work-in-progress: trickle attack defense

Wietse Venema
I added the following entry to the wip.html file on the Postfix website.

        Wietse

Trickle attack defense

Trickle attacks are old, but have received attention recently in
the context of web servers. The idea is that an attacker sends a
request slowly, for example, one byte at a time. Since many servers
implement per-read time limits, instead of per-transaction time
limits, an attacker can keep a connection busy for a very long
time. Namely, the maximum number of seconds before a read operation
times out, multiplied by the maximum number of bytes per transaction,
multiplied by the maximum number of transactions.

The postscreen daemon, available with Postfix 2.8 and later, already
implements time limits to receive one complete SMTP command line.
Postscreen uses a default time limit of 300s for RFC compliance,
but it will switch to a 10s limit under overload conditions.
Postscreen never receives mail, so this is a complete solution.

The rest of Postfix still uses per-read time limits, instead of
per-line time limits. Support for per-line time limits is currently
tested in Postfix 2.9. This solves most of the problem; it limits
the time to receive one complete SMTP command line, but it does
not yet limit the total amount of time to receive the content of
an email message. Instead, use the existing spam blocking mechanisms
to reject mail before the SMTP "DATA" command.

Once the code has proven itself it will be made available with
Postfix 2.8.1. Optional patches may be made available for earlier
Postfix releases. The whole thing is implemented in very little
code in the lowest-layer Postfix routines. With per-line time
limits, Postfix behaves exactly in the same way as before, except
when someone trickles the bytes.
Reply | Threaded
Open this post in threaded view
|

Re: Work-in-progress: trickle attack defense

Randy Ramsdell-2
Wietse Venema wrote:

> I added the following entry to the wip.html file on the Postfix website.
>
> Wietse
>
> Trickle attack defense
>
> The postscreen daemon, available with Postfix 2.8 and later, already
> implements time limits to receive one complete SMTP command line.
> Postscreen uses a default time limit of 300s for RFC compliance,
> but it will switch to a 10s limit under overload conditions.
> Postscreen never receives mail, so this is a complete solution.
>

> The rest of Postfix still uses per-read time limits, instead of
> per-line time limits. Support for per-line time limits is currently
> tested in Postfix 2.9. This solves most of the problem; it limits
> the time to receive one complete SMTP command line, but it does
> not yet limit the total amount of time to receive the content of
> an email message. Instead, use the existing spam blocking mechanisms
> to reject mail before the SMTP "DATA" command.

300s for each line as in: mail from: blah ---> 300s?
Reply | Threaded
Open this post in threaded view
|

Re: Work-in-progress: trickle attack defense

Randy Ramsdell-2
Randy Ramsdell wrote:

> Wietse Venema wrote:
>> I added the following entry to the wip.html file on the Postfix website.
>>
>>     Wietse
>>
>> Trickle attack defense
>>
>> The postscreen daemon, available with Postfix 2.8 and later, already
>> implements time limits to receive one complete SMTP command line.
>> Postscreen uses a default time limit of 300s for RFC compliance,
>> but it will switch to a 10s limit under overload conditions.
>> Postscreen never receives mail, so this is a complete solution.
>>
>
>> The rest of Postfix still uses per-read time limits, instead of
>> per-line time limits. Support for per-line time limits is currently
>> tested in Postfix 2.9. This solves most of the problem; it limits
>> the time to receive one complete SMTP command line, but it does
>> not yet limit the total amount of time to receive the content of
>> an email message. Instead, use the existing spam blocking mechanisms
>> to reject mail before the SMTP "DATA" command.
>
> 300s for each line as in: mail from: blah ---> 300s?

What I am getting at here is that the attack will still succeed if using
it for DOS. I am not trying trivialize this work, but understand how
this will stop an attack vs. increase the time before the system is
fully hosed.

rcr
Reply | Threaded
Open this post in threaded view
|

Re: Work-in-progress: trickle attack defense

Victor Duchovni
On Thu, Jan 27, 2011 at 12:04:26PM -0500, Randy Ramsdell wrote:

>> 300s for each line as in: mail from: blah ---> 300s?
>
> What I am getting at here is that the attack will still succeed if using it
> for DOS. I am not trying trivialize this work, but understand how this will
> stop an attack vs. increase the time before the system is fully hosed.

With the new code Postfix timeouts will closely match the reasonable
naive expectations of system administrators. You can now make intuitive
estimates of how long a client can hog an SMTP connection, and keep
in mind that under load stress=yes, and the timers are shorter.

Yes, SMTP servers are not DDoS proof, nothing is, but this evolution
makes Postfix behaviour more deterministic and intuitive. This work does
not stop DDoS attacks, but remember that many DoS issues are from poorly
written clients, rather than deliberate large scale attacks.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

postfix sasl auth (SMTP auth)

Leonel Florin Selles
hi friend, I have a postfix server install on my work, and I have too
configured a sasl auth mechanismus, my question is, how can I say to
postfix tha use only the SMTP auth mechanismus.

Why i ask this question. Because if i use a mail client without any
autentication machanismus to send mails the server sends the mails, and I
need that the only way to send mails be the SMTP auth.



Reply | Threaded
Open this post in threaded view
|

Re: postfix sasl auth (SMTP auth)

Victor Duchovni
On Thu, Jan 27, 2011 at 04:08:20PM -0500, Leonel Florin Selles wrote:

> ... if I use a mail client without any
> authentication mechanisms to send mails the server sends the mails, and I
> need that the only way to send mails be the SMTP auth.

To enable SASL:

    http://www.postfix.org/SASL_README.html#server_sasl

To enforce SASL

    http://www.postfix.org/SMTPD_ACCESS_README.html

For a pure MSA (authenticated clients only) the Postfix master.cf
file contains a commented-out submission service with essentially
all the settings you need.

--
        Viktor.