On Thu, Feb 01, 2007 at 07:10:52PM +0000, Eric Van Buggenhaut wrote: > Francesco P. Lovergine wrote: > >On Mon, Jan 29, 2007 at 06:24:38PM +0100, Eric Van Buggenhaut wrote: > > > >>Package: proftpd > >>Version: 1.2.10-15sarge4 > >>Severity: grave > >> > >>I have proftpd installed on one of our production server. It seems like > >>any user registered with the system can initiate a ftp session whether > >>he correctly enters his password. I've been investigating this for a > >>while without finding any explanation. Here is /etc/pam.d/proftd: > >> > >>#%PAM-1.0 > >>auth required pam_listfile.so item=user sense=deny > >>file=/etc/ftpusers > >>onerr=succeed > >>@include common-auth > >> > >># This is disabled because anonymous logins will fail otherwise, > >># unless you give the 'ftp' user a valid shell, or /bin/false and add > >># /bin/false to /etc/shells. > >>auth required pam_shells.so > >> > >> > >>and /etc/pam.d/common-auth: > >> > >>auth sufficient pam_unix.so nullok_secure > >>auth sufficient pam_ldap.so try_first_pass > >> > >> > >>Would that explain why a registered unix user can initiate a session > >>without providing any password ? > >> > >> > > > >Providing your proftpd.conf is mandatory before opening > >silly grave bugs for a server which is in production since 2005 > >on sarge and at least 2 years before that on testing. > > > >Anyway, authoritativeness of any pam module is controlled by > >AuthPAMOrder and by default failing a PAM auth does not imply > >a denied access necessarily. It depends on your configuration. > >The default configuration does not allow unauthenticated users > >to login, so the problem is definitively on your side. > > > > > Hi, > > Thank for your reply. The /etc/pam.d/proftpd used is the default one > shipped with proftpd > > Attached is proftpd.conf > > As I mentioned, to be able to open a ftp session a user needs to exist > in /etc/passwd but thenhe can > connect with any password. > > >
It has no reason to behavioring so. http://www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-Debugging.html You can easily tracking the auth phase to find out where is the problem. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
