[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 27 Sep 2008 07:31:22 +0400
From: Solar Designer <solar@...nwall.com>
To: popa3d-users@...ts.openwall.com
Subject: Re: rate limiting popa3d
On Fri, Sep 26, 2008 at 11:35:25AM +0200, Wouter Callewaert wrote:
> Lately, our popa3d based pop server suffers from people checking their
> mail every 5 seconds.
> Is there a way to rate limit pop checking (based on username / time
> period for example) with popa3d or should I use a proxy pop3 server for
> this?
You can achieve similar rate limiting, per source IP address rather than
per username, using the MAX_SESSIONS_PER_SOURCE and MIN_DELAY settings
in popa3d's params.h. These only have effect when running popa3d as a
standalone server, not via inetd. popa3d assumes that sessions are
"active" for at least MIN_DELAY seconds for the purpose of counting the
number of "simultaneous" sessions. The default settings of
MAX_SESSIONS_PER_SOURCE = 50 and MIN_DELAY = 10 are quite relaxed,
allowing, in theory, for up to 5 sessions per second, on average, to be
started from the same source address. (Since some of the sessions will
likely have non-negligible duration, only a smaller number of sessions
per second, on average, will be allowed in practice.) You can try
changing these settings to, say, MAX_SESSIONS_PER_SOURCE = 5 and
MIN_DELAY = 120, which won't allow sessions to be started more often
than 5 in 120 seconds (2 minutes).
Unfortunately, I am not aware of equivalent functionality in an inetd
clone. xinetd's per_source and cps settings get quite close, but they
are not quite it because they are applied independently of each other.
Thus, when cps kicks in, the entire service is affected, for all source
addresses, which is usually undesirable. A workaround would be to use
per_source only and to artificially extend the process' lifetime by
starting popa3d via a wrapper script that would "sleep" for a second
when popa3d terminates - but that wastes memory. If you choose to do
this with xinetd anyway, then you could also make use of banner_fail,
which you'd set to a file with a valid POP3 protocol error response
line, terminated with CR-LF.
Speaking of per source address limiting, please note that some of your
users might be on networks behind NAT. Thus, multiple users would
appear to come from the same IP address. This is one reason why you
might need to have the limits somewhat more relaxed than what you'd use
for a single user.
Alternatively, rate limiting can be implemented in a PAM module (if
popa3d is compiled to use PAM) - then it will apply after the client
supplies the username and password. Such rate limiting is not as
effective against resource consumption attacks (whether deliberate or
not), but it can be applied per-user, which avoids the "NAT problem".
No, I am not aware of an existing PAM module that would implement
per-user rate limiting.
Similarly, on systems that might not use PAM but do use NSS (e.g.,
Slackware Linux), this can be implemented in an NSS module - although
the drawback is that NSS modules typically have to be enabled
system-wide, and thus would affect services other than popa3d as well.
> If someone has a patch for this, that would be very helpful.
I am not aware of a relevant patch to popa3d. If you like, we could
develop a popa3d patch and/or a PAM or NSS module, as well as consult
you on this as it relates to your specific circumstances, as a paid
service of Openwall. Please contact me via private e-mail if interested.
Thanks,
Alexander Peslyak <solar at openwall.com>
GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15
http://www.openwall.com - bringing security into open computing environments
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
