proftpd-mysql, systeemgebruikers weigeren

[sPENKMAN]

Ik heb al enige tijd een FTP server draaien welke gebruikers auth op basis van MySQL. Dit werkt zonder problemen maar systeemgebruikers kunnen momenteel inloggen wat ik wil voorkomen.

Op zich zou je dit eenvoudig kunnen doen door middel door "RequireValidShell" op "on" te zetten en de gebruikers een shell als /etc/nologin te geven wat op zich ook goed werkt.

Echter zijn er een aantal systeem gebruikers aanwezig zoals de backup gebruiker welke standaard wordt aangemaakt waar geen wachtwoord voor aanwezig zou zijn (dit wordt weergegeven als een * in /etc/shadows). Zie hiervoor ook tldp.org

Het stomme is echter dat het * letterlijk als wachtwoord wordt gezien en ik zonder problemen kan inloggen met de username backup met als wachtwoord "*".

Een voor de hand liggende oplossing zou dan neerkomen op het instellen van een sterk wachtwoord voor de user "backup" maar aangezien er ook andere gebruikers zijn en ik niet weet wat de impact hiervan zou kunnen zijn heb ik liever dat de users in /etc/passwd compleet worden genegeerd. Ik kan hier echter geen oplossing voor vinden

Nou heb ik eigenlijk twee vragen:
1) Waarom wordt het "*" letterlijk als wachtwoord gezien?
2) Hoe kan ik ervoor zorgen dat proftpd de /etc/passwd negeert?

Distributie: Debian etch
Proftpd versie: 1.3.0

[Osiris]

sPENKMAN schreef op vrijdag 25 januari 2008 @ 19:58:
1) Waarom wordt het "*" letterlijk als wachtwoord gezien?

Omdat ie waarschijnlijk zo letterlijk overgenomen is als password in je MySQL-DB? Want je zegt dat je een MySQL-DB als authenticatie-methode gebruikt.

[sPENKMAN]

Osiris schreef op vrijdag 25 januari 2008 @ 20:05:
Omdat ie waarschijnlijk zo letterlijk overgenomen is als password in je MySQL-DB? Want je zegt dat je een MySQL-DB als authenticatie-methode gebruikt.

De betreffende gebruiker backup is een systeem gebruiker, deze bestaat dus alleen in /etc/passwd en /etc/shadow. Hij komt niet voor in mijn MySQL database

code:

# cat /etc/passwd |grep backup
backup:x:34:34:backup:/var/backups:/bin/sh

# cat /etc/shadow |grep backup
backup:*:13837:0:99999:7:::

[Confusion]

Blijkbaar staat de FTP server twee authenticatiemethoden toe: via MySql en via PAM.

Ik denk dat je hier moet zijn: http://www.proftpd.org/lo...d/config_ref_AuthPAM.html

[deadinspace]

sPENKMAN schreef op vrijdag 25 januari 2008 @ 19:58:
1) Waarom wordt het "*" letterlijk als wachtwoord gezien?

Als dat echt gebeurt dan is dat een ernstige bug.

• Weet je echt zeker dat je daar succesvol mee in kunt loggen? Kun je ook een file uploaden naar bijvoorbeeld /tmp ?
• Zo ja, welke stappen heb je doorlopen om in de huidige situatie te komen? Wat heb je geinstalleerd en wat heb je hoe geconfigureerd? Ik wil wel proberen dat probleem te reproduceren namelijk.
• Gebeurt het ook met proftpd zonder mysql connector?

Ik kan het probleem hier tot dusver in ieder geval niet reproduceren onder de volgende omstandigheden:

• Debian 4.0, up to date
• proftpd (niet -mysql) 1.3.0-19
• Vrij standaard proftpd config

[Verwijderd]

Zo wie is dit altijd wel handig om te doen bij ftp servers zoals proftpd en wuftpd:

# cat /etc/passwd | cut -d: -f1 > /etc/ftpusers

Gebruikers die in het bestand /etc/ftpusers staan kunnen niet op het systeem inloggen. Zie ook man ftpusers.

[sPENKMAN]

Confusion schreef op vrijdag 25 januari 2008 @ 21:39:
Blijkbaar staat de FTP server twee authenticatiemethoden toe: via MySql en via PAM.

Ik denk dat je hier moet zijn: http://www.proftpd.org/lo...d/config_ref_AuthPAM.html

De AuthPAM parameter was niet opgenomen in mijn proftpd.conf, ook al ik deze hard uitschakel blijft het mogelijk om in te loggen met de systeemuser backup.

deadinspace schreef op zaterdag 26 januari 2008 @ 01:31:
[...]

Als dat echt gebeurt dan is dat een ernstige bug.
[ul]• Weet je echt zeker dat je daar succesvol mee in kunt loggen? Kun je ook een file uploaden naar bijvoorbeeld /tmp ?

De gebruikers wordt vastgezet in hun homedir, ik kan dus niet naar de /tmp gaan met bijv de user backup maar ik kom uit in /var/backups. De owner van de bestanden is root dus ik kan ook niet uploaden. Ik had in het verleden een normale user ftp toegevoegd met als homedir /home/ftp welke kon inloggen met ftp / * en ook kon uploaden. Deze heb ik een ongeldige shell toegewezen waarbij RequireValidShell op on staat om te voorkomen dat hij kan inloggen.

• Zo ja, welke stappen heb je doorlopen om in de huidige situatie te komen? Wat heb je geinstalleerd en wat heb je hoe geconfigureerd? Ik wil wel proberen dat probleem te reproduceren namelijk.

De installatie is standaard volgens de tutorial op howtoforge.com. Als kernel draai ik een eigen compilatie van 2.6.18 met de OpenVZ patch (www.openvz.org) en VMware server. Verder is er weinig bijzonders, op het host systeem draait DHCPd en ProFTPd maar dat is dan ook gelijk alles.

• Gebeurt het ook met proftpd zonder mysql connector?[/ul]
Ik kan het probleem hier tot dusver in ieder geval niet reproduceren onder de volgende omstandigheden:

• Debian 4.0, up to date
• proftpd (niet -mysql) 1.3.0-19
• Vrij standaard proftpd config

Ik kan vanmiddag/vanavond even proberen het MySQL gedeelte eruit te halen, zoals eerder aangehaalt kon ik met een systeemgebruiker ftp inloggen en uploaden. Ik verwacht dus dat het uitschakelen geen verschil uitmaakt maar hier kom ik nog even op terug.

Verwijderd schreef op zaterdag 26 januari 2008 @ 03:11:
Zo wie is dit altijd wel handig om te doen bij ftp servers zoals proftpd en wuftpd:

# cat /etc/passwd | cut -d: -f1 > /etc/ftpusers

Gebruikers die in het bestand /etc/ftpusers staan kunnen niet op het systeem inloggen. Zie ook man ftpusers.

Dat zorgt er in ieder geval voor dat backup niet kan inloggen inderdaad, thnx


Mijn proftpd.conf ziet er als volgt uit:

code:

Include /etc/proftpd/modules.conf

UseIPv6                         off

IdentLookups                    off
UseReverseDNS                   off
SocketBindTight                 off

ServerName                      "ftp.domein.nl"
ServerType                      standalone
DeferWelcome                    off

MultilineRFC2228                on
DefaultServer                   on
ShowSymlinks                    on

TimeoutNoTransfer               600
TimeoutStalled                  600
TimeoutIdle                     1200

DisplayLogin                    welcome.msg
DisplayFirstChdir               .message
ListOptions                     "-l"

DenyFilter                      \*.*/

Port                            21


MaxInstances                    30

User                            proftpd
Group                           nogroup

Umask                           022  022
AllowOverwrite                  on



AuthPAM                         off

TransferLog /var/log/proftpd/xferlog
SystemLog   /var/log/proftpd/proftpd.log

<IfModule mod_tls.c>
TLSEngine off
</IfModule>

<IfModule mod_quota.c>
QuotaEngine on
</IfModule>

<IfModule mod_ratio.c>
Ratios on
</IfModule>


<IfModule mod_delay.c>
DelayEngine on
</IfModule>

<IfModule mod_ctrls.c>
ControlsEngine        on
ControlsMaxClients    2
ControlsLog           /var/log/proftpd/controls.log
ControlsInterval      5
ControlsSocket        /var/run/proftpd/proftpd.sock
</IfModule>

<IfModule mod_ctrls_admin.c>
AdminControlsEngine on
</IfModule>

DefaultRoot ~


SQLAuthTypes            Plaintext Crypt
SQLAuthenticate         users* groups*

SQLConnectInfo  database@host user pass

SQLUserInfo     ftpuser userid passwd uid gid homedir shell

SQLGroupInfo    ftpgroup groupname gid members

SQLMinID        500

SQLHomedirOnDemand on

SQLLog PASS updatecount
SQLNamedQuery updatecount UPDATE "count=count+1, accessed=now() WHERE userid='%u'" ftpuser

RootLogin off
RequireValidShell on

[Confusion]

Verwijderd schreef op zaterdag 26 januari 2008 @ 03:11:
Zo wie is dit altijd wel handig om te doen bij ftp servers zoals proftpd en wuftpd:

# cat /etc/passwd | cut -d: -f1 > /etc/ftpusers

Gebruikers die in het bestand /etc/ftpusers staan kunnen niet op het systeem inloggen. Zie ook man ftpusers.

Dan moet je dat minstens in een cronjob zetten die regelmatig draait, anders kunnen je nieuwe users onverwacht wel inloggen. Dit is het soort oplossing dat vereist dat je weet dat hij aanwezig is, zodat je iemand zelf handmatig voor de lopende dag kan toevoegen aan ftpusers. Liever een oplossing die automatisch werkt, zodat je hem niet kan vergeten.

Eventueel kan je alleen systeem users toestaan die in een bepaalde groep, bijvoorbeeld ftpusers, zitten. Dan heeft een nieuwe user geen ftp toegang via /etc/passwd, tenzij je hem handmatig toevoegd aan de ftpusers groep. Vereist handwerk, maar leidt in ieder geval niet tot vergissingen.

[ Voor 16% gewijzigd door Confusion op 26-01-2008 10:30 ]

[sPENKMAN]

deadinspace schreef op zaterdag 26 januari 2008 @ 01:31:
• Gebeurt het ook met proftpd zonder mysql connector?

Zoals belooft heb ik het even geprobeerd zonder de MySQL meuk erin... en waarempel ik kan niet meer inloggen met backup / *. Ik heb het even dubbelgechecked door de MySQL config weer terug te zetten en dan kan ik weer zonder problemen inloggen.

Inloggen kan niet wanneer:

• /etc/ftpusers leeg is
• /etc/shadow de regel "backup:*:......" bevat
• /etc/proftpd/proftpd.conf geen MySQL configuratie bevat

Inloggen kan wel wanneer:

• /etc/ftpusers leeg is
• /etc/shadow de regel "backup:*:......" bevat
• /etc/proftpd/proftpd.conf wel de MySQL configuratie bevat

Naar aanleiding hiervan ben ik nog even verder gaan kijken naar de oorzaak. Dit blijkt dus in de volgende regel te zitten.

code:

SQLAuthTypes            Plaintext Crypt

Wanneer ik hier Plaintext weg haal en het wachtwoord in de usertabel encrypt kan ik inloggen met de MySQL user uit de tabel maar niet met de systeemuser! Het wachtwoord in /etc/shadow werd dus Plaintext uitgelezen waardoor dit mogelijk was

[deadinspace]

sPENKMAN schreef op zondag 27 januari 2008 @ 18:35:
Naar aanleiding hiervan ben ik nog even verder gaan kijken naar de oorzaak. Dit blijkt dus in de volgende regel te zitten.

code:

SQLAuthTypes            Plaintext Crypt

Wanneer ik hier Plaintext weg haal en het wachtwoord in de usertabel encrypt kan ik inloggen met de MySQL user uit de tabel maar niet met de systeemuser! Het wachtwoord in /etc/shadow werd dus Plaintext uitgelezen waardoor dit mogelijk was

Ik heb het probleem ook verder onderzocht en was inmiddels ook tot die conclusie gekomen

Maar dit is dus wel een bug vind ik, al is het maar vanwege de naam van de directive; "SQLAuthTypes" suggereert dat dit alleen invloed heeft op users uit de SQL database, niet uit /etc/passwd.

Dit probleem is ook bekend als CVE-2007-2165, en is gerapporteerd als Debian bug #419255.

Voor Debian is dit gefixt in proftpd 1.3.0-22, maar er is nooit een security update voor Etch uitgebracht voor dit probleem. Omdat ik vind dat dit wel degelijk een security update rechtvaardigt heb ik contact opgenomen met het Debian security team hierover, eens kijken wat zij ervan vinden.

Het probleem is trouwens ook te omzeilen door de volgende directive in je proftpd config op te nemen:

code:

AuthOrder mod_sql.c

Proftpd gebruikt dan alleen MySQL voor users, en negeert /etc/passwd helemaal. Misschien is dat voor jouw situatie zelfs nog beter dan plaintext uitzetten?

[sPENKMAN]

deadinspace schreef op zondag 27 januari 2008 @ 19:33:
Ik heb het probleem ook verder onderzocht en was inmiddels ook tot die conclusie gekomen

Maar dit is dus wel een bug vind ik, al is het maar vanwege de naam van de directive; "SQLAuthTypes" suggereert dat dit alleen invloed heeft op users uit de SQL database, niet uit /etc/passwd.

Dit probleem is ook bekend als CVE-2007-2165, en is gerapporteerd als Debian bug #419255.

Voor Debian is dit gefixt in proftpd 1.3.0-22, maar er is nooit een security update voor Etch uitgebracht voor dit probleem. Omdat ik vind dat dit wel degelijk een security update rechtvaardigt heb ik contact opgenomen met het Debian security team hierover, eens kijken wat zij ervan vinden.

Het probleem is trouwens ook te omzeilen door de volgende directive in je proftpd config op te nemen:

code:

AuthOrder mod_sql.c

Proftpd gebruikt dan alleen MySQL voor users, en negeert /etc/passwd helemaal. Misschien is dat voor jouw situatie zelfs nog beter dan plaintext uitzetten?

De directive suggereert inderdaad dat het enkel om de MySQL user gaat. Het is toch eigenlijk bizar dat een dergelijke bug al openstaat sinds april 2007.

Ik heb hem zelf pas in oktober 2007 ontdekt toen er inene perl scripts op mijn ftp stonden in een aangemaakte map public_html. Sindsdien ben ik eigenlijk afwisselend op zoek geweest naar een oplossing of andere gebruikers welke dit probleem hadden.

Ik heb in oktober ook de auteur van de gevolgde tutorial op howtoforge.com op de hoogte gebracht van mijn probleem. In september had ik nog geen antwoord en heb ik hem nogmaals getracht te mailen maar een reactie is tot op heden uitgebleven.

Er zullen toch aardig wat FTP servers met dit probleem draaien neem ik aan

[Verwijderd]

Er zullen toch aardig wat FTP servers met dit probleem draaien neem ik aan

Nu moet ik eerlijk zeggen dat ik proftpd nooit zo´n fijne ftp server heb gevonden: diverse beveiligingsgaten in het verleden, zwaar en log, officiele documentatie is niet up to date enz enz. Persoonlijk gaat mijn voorkeur uit naar of pureftpd of anders vsftpd. Pureftpd werkt trouwens perfect met users in een mysql database: http://www.howtoforge.com/pureftpd_mysql_virtual_hosting

[sPENKMAN]

deadinspace heb je nog iets gehoord van het Debian security team?

[jealma]

Verwijderd schreef op zondag 27 januari 2008 @ 22:49:
[...]


Nu moet ik eerlijk zeggen dat ik proftpd nooit zo´n fijne ftp server heb gevonden: diverse beveiligingsgaten in het verleden, zwaar en log, officiele documentatie is niet up to date enz enz. Persoonlijk gaat mijn voorkeur uit naar of pureftpd of anders vsftpd. Pureftpd werkt trouwens perfect met users in een mysql database: http://www.howtoforge.com/pureftpd_mysql_virtual_hosting

Ik draai op dit moment PureFTPd op een Debian Etch server. Lang geleden heb ik ProFTPd gedraaid, maar ben daar vanaf gestapt ivm tijden in UTC in de logfiles, waarbij ProFTPd niets uitdoet op de timezone GMT/UTC setting. Nu zit ik al een tijdje te twijfelen om van PureFTPd te switchen naar vsftpd, vooral omdat er al in jaren geen updates voor PureFTPd meer uitkomen. Het lijkt een beetje alsof het project "dood" is, terwijl vsftpd nog springlevend is.
Het enige wat me atm tegen houdt is dat PureFTPd heel makkelijk is te gebruiken met virtual users en het pure-pw commando, iets wat vsftpd volgens mij niet heeft. Nog mensen die daar hun mening over kwijt willen?

[Verwijderd]

Ik zou gewoon Pureftpd blijven gebruiken. Dat er niet steeds nieuwe release van een stukje software komt wil niet zeggen dat het buggy of onveilig is. Misschien is pureftpd wel helemaal af en valt er niets meer aan te fixen of te ontwikkelen

[Verwijderd]

Helaas zit er een megabug in proftpd die mysql 5 authenticatie onmogelijk maakt. Mocht je mysql 4 gebruiken dan werkt alles prima maar met mysql 5 werkt het gewoon niet. Dit zit er al vanaf het begin van mysql 5 in. Sterker nog het heeft nog nooit gewerkt met mysql 5.

Gewoon weg een blunder van de proftpd team of diegene die de mysql module geschreven heeft.

[sPENKMAN]

Verwijderd schreef op dinsdag 25 maart 2008 @ 10:07:
Helaas zit er een megabug in proftpd die mysql 5 authenticatie onmogelijk maakt. Mocht je mysql 4 gebruiken dan werkt alles prima maar met mysql 5 werkt het gewoon niet. Dit zit er al vanaf het begin van mysql 5 in. Sterker nog het heeft nog nooit gewerkt met mysql 5.

Gewoon weg een blunder van de proftpd team of diegene die de mysql module geschreven heeft.

ow?

code:

# proftpd -v
 - ProFTPD Version 1.3.0

Server version:         5.0.45-Debian_1 Debian etch distribution

Werkt toch echt zonder problemen?

[Verwijderd]

Bij mij werkt het niet i.c.m mysql 5. Als ik mysql 5 weggooi, mysql 4 instaleer dan werkt het in 1 keer. Er zijn ook andere mensen op Internet die dit probleem hebben. Heeft volgens mij met de authenticatie te maken die proftpd-mysql gebruikt maar dat weet ik niet zeker. Het zou het wel verklaren omdat mysql 5 nieuwe authenticatie gebruikt t.o.v mysql 4 als ik het goed heb.

[Confusion]

Er is weinig nieuws aan die authenticatie; enkel een sterkere hash en je kan hem zo instellen dat de oude hashes gebruikt/geaccepteerd worden.

[Verwijderd]

Beste is natuurlijk om helemaal geen ftp meer te gebruiken maar sftp. En ja je kunt tegenwoordig ook met de standaard open-ssh server sftp gebruikers jailen in hun homedir zonder gebruiken te maken van allerlei vage patches.