Univention Bugzilla – Full Text Bug Listing |
Summary: | backend side rate limiting for password reset self service | ||
---|---|---|---|
Product: | UCS | Reporter: | Daniel Tröder <troeder> |
Component: | Self Service | Assignee: | Daniel Tröder <troeder> |
Status: | CLOSED FIXED | QA Contact: | Florian Best <best> |
Severity: | normal | ||
Priority: | P5 | CC: | damrose, gohmann, walkenhorst |
Version: | UCS 4.1 | ||
Target Milestone: | UCS 4.1-0-errata | ||
Hardware: | Other | ||
OS: | Linux | ||
What kind of report is it?: | --- | What type of bug is this?: | --- |
Who will be affected by this bug?: | --- | How will those affected feel about the bug?: | --- |
User Pain: | Enterprise Customer affected?: | ||
School Customer affected?: | ISV affected?: | ||
Waiting Support: | Flags outvoted (downgraded) after PO Review: | ||
Ticket number: | Bug group (optional): | ||
Max CVSS v3 score: |
Description
Daniel Tröder
2015-11-03 08:04:05 CET
I suggest to use memcached for persistence of a request count, as it does not incur any I/O. It'd store IP-date pairs with a UCR configurable decay. u-s-s-umc must then add a Depend: on 'memcached' and 'python-memcache' and bring its own conf file for memcached (the init script reads /etc/memcached_*.conf). Thoughts? In the UMC module we cannot know the IP address of a user that connects through a web frontend. IMHO that is not necessary, rules should be configurable that limit: * total requests per {day, hour, min} * request per user per {day, hour, min} * Limiting total requests (tr) per min protects the server owner against DOS on the server. * Limiting total requests (tr) per day protects the server owner against a high phone bill. * Limiting requests per user (ur) per d+h+m protects users mailboxes/mobiles. Multiple rules configurable in UCRVs are necessary. I suggest as a safe default: * tr: 60/min (DOS DB) * tr: 100/h (DOS self-service) * tr: 100/d (phone bill) * ur: 1/min * ur: 6/h * ur: 10/d Code + YAML: r65809 This adds UCRVs umc/self-service/passwordreset/limit/total/.* umc/self-service/passwordreset/limit/per_user/.* umc/self-service/passwordreset/token_validity_period with the following default values: umc/self-service/passwordreset/limit/total/min: 60 umc/self-service/passwordreset/limit/total/hour: 100 umc/self-service/passwordreset/limit/total/day: 100 umc/self-service/passwordreset/limit/per_user/min: 1 umc/self-service/passwordreset/limit/per_user/hour: 6 umc/self-service/passwordreset/limit/per_user/day: 10 umc/self-service/passwordreset/token_validity_period: 3600 At the beginning of each request counters for all requests and for those of the connecting user are incremented. When they reach the configured amount, at error is returned. A scipt is installed in /usr/lib/univention-self-service/univention-self-service-request-count (by accident currently not executable) that will display the request count stored in the memcached database. BTW: this does not limit the request rate to the password _change_ service. ... just saw, that a current code change seems to have broken the check, it is counting but not stopping... not fixed yet... Commit 65839 adds the missing str→int conversion. It also raises the request limits, because for a single password reset process at least 3 requests are necessary. YAML was updated with r65840. pylibmc 1.2.2-1 (for binary package python-pylibmc) built to errata4.1-0 I receive the message after some requests (e.g. 15?): """The allowed maximum number of connections to the server has been reached. Please retry later.""" Please tell how long one should have to wait. I waited about 15 minutes and still no luck. Memcached runs as root, I am not sure it this is the best idea, even when using UNIX sockets: http://blog.couchbase.com/memcached-security "Die erlaubte maximale Anzahl an Verbindungen zum Server wurde erreicht.Bitte versuchen Sie es später noch einmal." Missing space between the two sentences. "noch einmal" → "erneut". (In reply to Florian Best from comment #6) > I receive the message after some requests (e.g. 15?): > """The allowed maximum number of connections to the server has been reached. > Please retry later.""" > > Please tell how long one should have to wait. I waited about 15 minutes and > still no luck. How exact do you wish the message to be? "Please wait one {minute, hour, day}." or "Please wait {one minute, 34 minutes, 18 hours}."? If multiple limits were hit, it would alway only display the largest one. 66053: run memcached as non-privileged user 66068: return waiting time if request limit is reached and a lot of other fixes 66069: update yaml Please don't use 0 as default value when evaluating the UCR variables. Use the values which are also set in postinst. That is intentional. The implicit default for the unset UCRV is 0, as that does the same as deactivating the limit. The values in the postinst are just meant as suggestions, not defaults. I have amended the UCRV description to reflect this. Text change: 66120 YAML adaption: 66121 (→ 1.0.3-7.54.201512071030) (In reply to Daniel Tröder from comment #12) > That is intentional. The implicit default for the unset UCRV is 0, as that > does the same as deactivating the limit. No it doesn't. Having a value of 0 causes the limit to always show "Please retry in 24 hours.". Works now with the latest changes. I wrote a test case in svn r66129. YAML: adjusted in svn r66131. python-pylibmc was not announced to maintained with the initial release of erratum 24. It will be released via Bug #40209 |