openSUSE 13.2/42.1: vsftpd - Virtual users mit pam_pwdfile und sicher (sic!) gehashtem Passwort (als Ersatz für pam_userdb oder SQL)

      openSUSE 13.2/42.1: vsftpd - Virtual users mit pam_pwdfile und sicher (sic!) gehashtem Passwort (als Ersatz für pam_userdb oder SQL)

      Moinsen,

      Vor kurzem wollte ich jemandem einen kleinen FTP-Server fürs LAN aufsetzen, der (u.a. auch auf meinen Vorschlag) folgende Eigenschaften haben sollte.

      - FTP über SSL/TLS

      - Authentifizierung mit Benutzername/Passwort (also KEIN anonymous-ftp)

      - Obige Nutzer haben je nach Benutzername verschiedene Zugriffsrechte (Nur Download oder Upload und Download)

      - Benutzernamen für FTP sollen unabhängig von den Nutzern des Betriebssystem sein (sog. "Virtual Users")

      Das Ganze habe ich schon mehrfach aufgesetzt und deshalb war der Vorschlag mein "bewährtes" Setup hierfür zu verwenden, bestehend aus

      1) vsftpd

      2) Virtuelle Nutzer werden mittels pam_userdb und einer Berkley DB für die Nutzernamen/Passworte verwaltet

      Die grundlegende Einrichtung von vsftpd mit TLS soll hier nicht Gegenstand der Ausführungen sein, dazu findet sich massenweise Kram im Netz und daran hakte es ja auch nicht, wie der/die geneigte Leser(in) gleich bemerken wird.

      So weit, so gut, also vsftpd&co. genau so wie schon einge Male zuvor aufgesetzt und dann kam die böse Überraschung, kein einziger Nutzer konnte sich anmelden.

      Nach einiger Suche (und dem dazu passenden Gefluche) fand ich den entscheidenden Hinweis:

      Quellcode

      1. failed to load /lib64/security/pam_userdb.so


      Das PAM-Modul für die Datenbankverwaltung wurde nicht gefunden und dann kann das natürlich nichts werden.

      OK, das letzte Mal, als ich das aufgesetzt hatte, war die Basis openSUSE 13.1, hier handelte es sich um eine 42.1, also mal nachsehen, was der Changelog das Paketes "pam" zu sagen hat.

      * Mo Jan 27 2014 kukuk<ätttt>suse.de
      - Update to current git (Linux-PAM-git-20140127.diff), which
      obsoletes pam_loginuid-part1.diff, pam_loginuid-part2.diff and
      Linux-PAM-git-20140109.diff.
      - Fix gratuitous use of strdup and x_strdup
      - pam_xauth: log fatal errors preventing xauth process execution
      - pam_loginuid: cleanup loginuid buffer initialization
      - libpam_misc: fix an inconsistency in handling memory allocation errors
      - pam_limits: fix utmp->ut_user handling
      - pam_mkhomedir: check and create home directory for the same user
      - pam_limits: detect and ignore stale utmp entries
      - Disable pam_userdb (remove db-devel from build requires)


      OK, das erklärt Einiges, klarer Fall von "fällt aus wegen ist nicht" (und gilt übrigens auch für 13.2).

      Der erste Lösungsansatz wäre gewesen das entsprechende Paket (pam) selbst zu bauen und dort "pam_userdb.so" wieder zu aktivieren, aber vielleicht gibt es ja gute Gründe für das Entfernen dieses Moduls?

      Kleine Suche förderte das zu Tage:

      bugzilla.opensuse.org/show_bug.cgi?id=929711

      But yes, pam_userdb was broken by design and insecure.


      Eindeutiges und hartes Urteil, aber ja, leider nachvollziehbar, denn diese Berkley-DB Datenbanken bieten wirklich keinerlei Schutz der Nutzerdaten.

      Zwar handelt es sich um ein binäres Datenbankformat, aber mit einem einfachen "strings $DATEINAME_DER_DATENBANK" fallen einem die Passworte/Benutzernamen im Klartext entgegen, in sofern kann man sich dem Urteil dann wohl anschließen.

      Bei den bisherigen Anwendungsfällen war ich immer davon ausgegangen den Zugriff auf die Passwortdatenbank so weit wie möglich einzuschränken (600 root:root), denn wenn ein Angreifer so weit gekommen ist darauf zugreifen zu können, dann hat er eh schon Rootzugriff auf die Kiste und kann so ziemlich alles machen.
      Zusätzlich sollte aber vor allem auch übermäßiger Aufwand vermieden werden und die Nutzung der Berkley-DB für das Einrichten virtueller Nutzer war der Standardweg der vsftpd-Dokumentation, ich kam also ehrlicherweise auch nie auf die Idee großartig nach Alternativen zu suchen.

      Nun denn, dann mal die Suchmaschine meines geringsten Misstrauens angeworfen und man findet durchaus eine ganze Menge von Tutorials, die eine SQL-Datenbank als Backend für die Nutzerverwaltung verwenden, zum Beispiel diese hier:

      howtoforge.com/tutorial/virtua…nd-mysql-on-ubuntu-15.10/

      howtoforge.com/virtual_hosting_vsftpd_postgresql_freebsd

      Aber das ist irgendwie dann doch alles extremer Overkill, wenn es eh nur um eine Handvoll Nutzer geht und diese auch händisch vom Admin verwaltet werden sollen.

      Geht das nicht einfacher und trotzdem vielleicht sicherer als mit der grottigen Berkley-DB?

      Die Antwort findet sich dann hier und sie lautet (natürlich) Ja:

      howto.gumph.org/content/setup-…nd-directories-in-vsftpd/

      Das ist nicht nur einfacher sondern auch sicherer, da die Passworte gehasht und auf Wunsch auch gesalzen abgespeichert werden, man hat im Prinzip die selbe Sicherheit wie bei den Passworten der lokalen Systembenutzer.

      Kurze Suche im OBS, und siehe da:

      software.opensuse.org/package/…e?search_term=pam_pwdfile

      Gibt es also schon fertig, ich habe mir zwar mein eigenes Päckchen gebaut, aber das ist meine eigene Bastelleidenschaft und keine Notwendigkeit.

      Das obige Tutorial so weit abgearbeitet (den Debian-spezifischen Teil muss man natürlich anpassen, aber den Teil für die Einrichtung der /etc/pam.d/vsftpd kann man so übernehmen) et voilà .....

      Das war schon mal nicht so übel, aber so ganz zufrieden war ich damit noch nicht, denn htpasswd ist jetzt nicht wirklich "high security" was das Hashen von Passworten anbetrifft:

      Hashfunktion = DES (autsch)

      Maximale Passwortlänge 8 Zeichen (No-Go)

      Nun gut, das geht aber besser, da wäre zuerst mal "openssl passwd":


      openssl passwd --help
      Usage: passwd [options] [passwords]
      where options are
      -crypt standard Unix password algorithm (default)
      -1 MD5-based password algorithm
      -apr1 MD5-based password algorithm, Apache variant
      -salt string use provided salt
      -in file read passwords from file
      -stdin read passwords from stdin
      -noverify never verify when reading password from terminal
      -quiet no warnings
      -table format output as table
      -reverse switch table columns


      Naja, ausser DES (das wäre das "crypt") hat man also auch noch MD5, aber das ist jetzt auch nicht wirklich der Hammer.

      Nach einiger Sucherei stieß ich dann auf die Lösung, das Programm "mkpasswd", welches (und das hat die Suche wohl auch etwas erschwert) sich seltsamerweise im Paket "whois" befindet.

      mkpasswd --help
      Aufruf: mkpasswd [OPTIONEN] ... [PASSWORT] [SALT]]
      Verschlüsselt das PASSWORT mit »crypt(3)«.

      -m, --method=TYP wählt die Methode TYP aus.
      -5 wie --method=md5
      -S, --salt=SALT benutzt angegebenes SALT.
      -R, --rounds=ANZAHL benutzt angegebene ANZAHL von Runden.
      -P, --password-fd=NUM liest das Passwort vom Dateideskriptor NUM anstatt
      von /dev/tty
      -s, --stdin wie --password-fd=0
      -h, --help zeigt diese Hilfe an und beendet sich.
      -V, --version zeigt Versionsinformationen an und beendet sich.

      Falls das PASSWORT fehlt, wird es interaktiv erfragt.
      Falls SALT nicht angegeben wurde, wird ein zufälliges erzeugt.
      Wenn der TYP »help« ist, werden die verfügbaren Methoden ausgegeben
      .


      OK, es wird also automatisch ein zufälliges SALT erzeugt, aber das ist doch nicht wirklich ein großer Fortschritt, oder?

      Stimmt, aber man beachte die letzte von mir fett markierte Zeile, also mal nachsehen, was so geboten wird:


      mkpasswd --method=help
      Verfügbare Methoden:
      des standard 56 bit DES-based crypt(3)
      md5 MD5
      sha-256 SHA-256
      sha-512 SHA-512


      Na DAS ist doch mal ein Wort, das sind Hashfunktionen, mit denen man noch einigermaßen leben kann.

      Einziger Haken, im Gegensatz zu "htpasswd" muss man den Eintrag von Hand zusammenstöpseln, aber naja, das ist Kleinkram.

      Hier ein Beispiel, der Nutzername ist "Ichbins" und das hochsichere Passwort ist "password":

      Zunächst erzeugt man das gehashte Passwort mit einer ordentlichen Hashfunktion und einem zufälligen SALT (letzteres geht ja automatisch).

      Quellcode

      1. mkpasswd -m sha-512
      2. Passwort:
      3. $6$6LugzUOZm$5d6qJYjXD21GHM.4GJweFY5ne73LUa0pemUHO11evvtCGAhQDoEtk1TUrTMCz.g3MSN4AsEAj2muK./r3lP7T/


      Daraus wird dann folgende Zeile in der Datei mit den Benutzerdaten:

      Quellcode

      1. Ichbins:$6$6LugzUOZm$5d6qJYjXD21GHM.4GJweFY5ne73LUa0pemUHO11evvtCGAhQDoEtk1TUrTMCz.g3MSN4AsEAj2muK./r3lP7T/


      Einfach nur "$BENUTZERNAME:" davor stellen und fertig ist die Laube.

      Im Vergleich zur alten Methode mit der Berkley-DB ist diese Vorgehensweise nicht nur sicherer sondern auch viel einfacher einzurichten.

      Greetz,

      RM
      "Programming today is a race between software engineers striving to build better & bigger idiot-proof programs and the Universe trying to produce bigger & better idiots. So far, the Universe is winning." (Rick Cook)

      Dies ist ein _öffentliches_ Supportforum, keinerlei Support per PN, EMail oder Instant Messenger.

      openSUSE Leap 42.2 - Kernel 4.12.x - fluxbox 1.3.7

      Bitmessage: BM-2D8h8QZmvHfgbixWeiG1NDZHG1iXAhBz8K