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.