Index: [Article Count Order] [Thread]

Date:  Thu, 8 May 2008 23:22:36 +0900
From:  Hisao SHIBUYA <shibuya (at mark) alpha.or.jp>
Subject:  [coba-e:12764] Re: [testing] dovecot udpate
To:  coba-e (at mark) bluequartz.org
Message-Id:  <8FBC9FEF-EAAA-4F46-84A9-A19A62D82298 (at mark) alpha.or.jp>
In-Reply-To:  <7853B509BA765D40B8DACAEA2F64B2A4023890F9 (at mark) es005.gramtel.office>
References:  <327DE0A0-4C10-47A0-B6F7-71D79103911B (at mark) alpha.or.jp> <5fa041b20805060033t6b2551e6l46f710fc664f9943 (at mark) mail.gmail.com> <1d4c951a0805060646t2f5824eal999403f55697c73b (at mark) mail.gmail.com> <7A304A11-98EE-49B3-AB64-2D64109BF7F1 (at mark) alpha.or.jp> <033501c8b041$da2c2c70$6400a8c0 (at mark) HPPAVILION> <450AA6B0-4436-492D-BDEF-4D35ACE43CD5 (at mark) alpha.or.jp> <7853B509BA765D40B8DACAEA2F64B2A4023890F9 (at mark) es005.gramtel.office>
X-Mail-Count: 12764

Hi Rusty and all,

>>> First, let me say thank you for all you do.
>>>
>>> Second, let me ask a question: is converting BQ from PAM to flat
> files
>>> going backwards?  It doesn't appear to be a step forward, but a step
>>> backward.
>>> Shudder the word, but has anyone looked at Zeffie's recommendation  
>>> to
>
>>> see if it had any value before moving backwards?
>>
>> Changing flat file from pwdb will be performance down.
>> On some point, changing flat file means to be a step back.
>>
>> I read Zeffie's post as coba-e:12183 again.
>> If it is true, and the pwdb isn't the cause of the issue with  
>> dovecot.
>> That issue is cause of dovecot pwdb implementation, we don't need to
> change back to flat file.
> <...>
>>
>> Any comment?
>>
>> Regards,
>> Hisao
>
> I've been playing around with the "login_max_processes_count" option  
> in
> dovecot.conf, and while it seems to work great preventing issues when
> there is a dictionary-attack against POP3, it obviously had no  
> affect on
> a recent FTP dictionary-attack... pwdb still flaked out, and you would
> have to login with root (since root is in shadow vs pwdb) to manually
> fix or wait for sometime after the attack has stopped (time enough for
> db_recover to do its thing).
>
> I see shadow vs pwdb as a step back also, but would be a step towards
> stability and reliability.

Yes, pwdb has hung up issue with dictionary attack.
And one more reason, that is compatibility.
I checked pam and pwdb package of CentOS5, it has pam 0.99.
It doesn't have pwdb library.
Does anyone know why pwdb library was removed?

On performance point, we can use db file for nsswitch as same as
current database.
So, if somebody would like to use db file for pam, they can
install nss_db and make on /var/db directory, it makes db file
from flat file.


> I know BQ made the change from vsftpd to proftpd, so does proftpd  
> have a
> similar config setting as dovecot that may reduce issues with pwdb
> during dictionary attacks? But, is this a bad direction to head;  
> tuning
> the individual services instead of replacing the underlying
> authentication mechanism?

There is no specific reason to use proftpd, I just ported the original
code to RH based linux, and original code supported proftpd.
That is why I use proftd.

I understood somebody said that vsftpd configuration file is almost
same as proftpd one.
If it is true, it isn't difficult to migrate to vsftpd.
It means, we don't release update package for proftpd.
It is very good point for us.

Anyway, I will fix the pwdb and dovecot issue in a couple of weeks.

Thanks,
Hisao