Hello Howard
On 2016-02-21 17:48, Howard Chu wrote:
Bruncko Michal wrote:
Hello list
We use ppolicy overlay for enforcing password lifecycle. Recently we
faced
with following issue and now I am trying to do some countermeasures to
minimize risk of issue reoccurring.
We use openldap server for user authentication. Here we store objects
of real
users as well as system users (for daemons and so on). We use
redundant setup
with two openldap servers running in mirror mode (multi-master).
- Few days ago I find out that I wasn't able to log into service which
uses
this LDAP as authentication backend.
- I find out that BOTH openldap servers are down (simply process
wasn't
listening)
- checked LDAP database partition (dedicated partition for storing
both DB and
LOG BDB transaction files) and it was exhausted on both servers
- reason of this exhaustion was a couple of BDB log files created just
within
last few minutes before daemon went down
- based on slapd logs it seems that one system user (used by Nagios)
had
expired password - for which I forgot to set no password expiration
- and it seems that those failed authentication tries caused this
transaction
logs to exhaust partition, as because for each failed bind, new
"pwdFailureTime" value was added into object which is basically normal
ldap
modify operation causing transaction log to involve.
- and as because that system user was used by Nagios for various
purposes and
LDAP BIND rate was really high, it effectively behave like DoS to kill
my ldap
servers due partition space exhausting
obviously I have fixed policy for that system user to keep password
with
unlimited expiration time. but anyway this DoS can be basically
reproduced by
any real user from outside to effectively kill those ldap servers.
Redundancy
with multiple servers does not provide any benefit as modifying
pwdFailureTime
is propagated over all cluster servers with same result to disk space.
Also
expanding partition will not help - it only extends service
availability based
on allocated space - and bdb log consuming was really huge - 15 log
files
(each with 10MB size) was created just within two minutes!!
now the question: did anybody considered this "effect" of using
"pwdFailureTime" attribute? If so, what can I do to avoid this
behavior to
occur? Or how you are facing with this potential kind of issues? On
one side
it is fine to see some failure attempt history. Also keeping
pwdFailureTime
limited to some max number of values will not help as the LDAP modify
operation have to be done anyway. For me the only useful possibility
is to NOT
use this attribute pwdFailureTime at all, but how to do it? I haven't
found
any possibility to disable using this attribute.
This is ITS#8327. The fix is released in 2.4.44.
You should upgrade.
You should not be using any BerkeleyDB-based backends, use back-mdb
which does not need transaction log files.
many thanks for this. this is a bit odd that even in latest centos7
(what we wanted to use for upgrade) there is old version. so the only
option would be to build from scratch.
is there any option to stop using pwdFailureTime attribute? if I set
global ACL rule like this:
access to attrs=pwdFailureTime
by * none
...will it work? or I assume not as overlay ppolicy is not represented
by any DN during modification.
thanks
michal
openldap-2.4.40/Centos6
many thanks for help
michal
