Howto: Server Config

Diese Anleitung basiert auf zwei englischen Anleitung von Castaglia:

www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-ConfigFile.html

www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-BCP.html

 

 

 




Die Konfiguration

Die config Datei liegt bei einer normalen Installation aus dem Quelltext in /usr/local/etc/. Je nachdem wie die configure Optionen gesetzt waren oder bei Installation eines RPM Files kann die Config auch an einem anderen Ot wie z.B. /etc/ liegen. Bei Start von ProFTPD kann mittels der "-c" Option eine Konfiguration explizit angegeben werden. ProFTPD benötigt im Prinzip keine (!) Config, da jeder Wert per Default gesetzt ist.


Server User/Gruppe

Der Server selbst mit als Root gestartet werden, damit Port 21 verwendet werden darf und FTP Sessions "geCHROOTed" (eingesperrt) werden können. Es ist jedoch grundsätzlich keine gute Idee, den Server als Root laufen zu lassen. Daher kann mit der "User" und "Group" Anweisung angegeben werden unter welchen Benutzer der Server laufen soll, nachdem die Startprozedur beendet war. Aus Sicherheitsgründen sollte dieses ein "nicht priviligierter" User sein. Viele Server benutzen daher den User "nobody". Historisch gesehen wurde dieser Account für NFS prozesse benutzt, inzwischen benutzen viele Programme diesen Account. Dieses hat den Nebeneffekt, dass auch die Dateien dieser Programme für den User erreichbar sind. Wer daher ganz sicher gehen möchte, der sollte einen neuen User speziell für ProFTPD anlegen (in vielen Distributionen existiert bereits eine User/Gruppe "ftp")

 

In der ProFTPD Default Config wird nobody/nogroup verwendet. Falls beim start die Fehlermeldung "no such group 'nogroup'" erscheint, dann existiert diese Gruppe einfach nicht. Da es keinen wirklichen Grund gibt, diese Gruppe unbedingt zu verwenden, kann man einfach eine andere Gruppe verwenden oder eine spezielle anlegen.


Grundlagen

Standardmässig liest der ProFTPD die /etc/passwd Datei ein, um User zu authentifizieren. Das bedeutet, dass jeder man einfach einen neuen System User anlegen braucht, damit sich dieser per FTP anmelden kann.

 

Manchmal jedoch benötigt man virtuelle User, die nicht am System existieren. Diese werden durch die "AuthUserFile" Anweisung unterstützt, die hier näher erklärt wird: www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-AuthFiles.html

 

Neben diesen beiden Möglichkeiten stehen noch andere, wie z.B. SQL oder LDAP als Möglichkeiten zur Verfügung, diese Möglichkeiten werden durch die Module mod_sql, mod_ldap, mod_radius usw. zur Verfügung gestellt.

 

Um anonymen Zugang zu ermöglichen wird der <Anonymous> Bereich der Config benutzt. Ist kein <Anonymous> Bereich in der config enthalten, ist der anonyme Zugang nicht möglich. Wie in der Beschreibung der <Anonymous> Direktive beschrieben, gibt die User Angabe in der Sektion an, welcher Username als anonymer Zugang benutzt wird. Anonyme Zugänge werden grundsätzlich automatisch geCHROOTed.

 

Für normalen, nicht anonymen Zugang, können User gechrooted (also eingesperrt) werden durch die Defaultroot Anweisung. Dieses sperrt die User in ein angegebenes Verzeichnis ein und verhindert das hochgehen in der Verzeichnisstruktur.

 

Bei der Verwendung von <VirtualHost> Bereichen muss auf zwei Sachen geachtet werden. Zum einen muss sichergestellt werden, das bei Verwendung von DNS Namen, der DNS Name auf eine andere IP als der Defaultserver verweist. Oft wird angenommen, dass virtuelle Server unter ProFTPD ähnlich der von Apache sind. Das ist leider nicht da Fall, da das FTP Protokoll keine Namen basierenden virtuellen Server unterstützt. Daher sind Virtuelle Server nur bei unterschiedlichen IPs möglich oder wenn man unterschiedliche Ports verwendet. Bei Verwendung von unterschiedlichen Ports sollte man beachten, dass bei aktiven Transfer der Kontrollport-1 als Datenport verwendet wird, also bei Port 21 der Port 21-1=20. Eine Konfiguration wie im folgenden Beispiel würde also nicht funktionieren, da der Datenport vom zweiten Server identisch mit dem Kontrollport des ersten Servers ist:

 

<VirtualHost a.b.c.d>

Port 2121

...

</VirtualHost>

 

<VirtualHost a.b.c.d>

Port 2122

...

</VirtualHost>

 


Zugriffs Beschränkungen

Viele Seiten haben bestimmte Verzeichnisse für Upload bzw. Download, andere erlauben kein Listen der Verzeichnisse etc. Dieses Verhalten kann man durch Kombination der <Directory> und <Limit> Direktiven erreichen. Für diese Thema existiert ein eigenes HowTo: www.proftpd.de/43.0.html

 


Resourcen beschränken

Einer der häuftigsten Fragen ist der Mailingliste ist das beschränken der Verbindungen in unterschiedlicher Art und Weise. Es gibt verschiedene Direktiven um dieses zu erreichen, abhängig von der Situation:

 

MaxInstances: Beschränkt die Gesamtzahl der Verbindungen
MaxClients: Beschränkt die Anzahl der Verbindungen pro Server/virtuellen Host
MaxClientsPerHost: Beschränkt die Anzahl der Clients die sich von einem Host anmelden können
MaxClientsPerUser: Beschränkt die Anzahl der Verbindungen die gleichzeitig unter dem gleichen Usernamen aufgebaut werden können
MaxHostsPerUser: Beschränkt die Anzahl der Rechner, von denen sich jemand mit dem gleichen Usernamen einloggen kann

 

Falls inetd als Servertype verwendet wird, dann muss man ebenfalls auf die dort festgesetzte maximale Anzahl der Verbindungen achten (siehe Bug#1243). Bei xinetd, können die "per_source" und "cps" Attribute benutzt werden, um die Anzahl der Verbindungen zu beschränken. Falls der Servertype "Standalone" ist, kann die "MaxConnectionRate" Anweisung benutzt werden um die Anzahl der Verbindungen zu beschränken.

 

Intensive Belastung der CPU und/oder des Arbeitsspeichers pro FTP Verbindung können durch "RLimitCPU" und "RLimitMemory" beschränkt werden. Hier ist ein Beispiel:

 

RLimitCPU session 10

RLimitMemory session 4096

 

Dieses beschränkt die Benutzung der CPU und des Speichers auf die einzelnen Sessions. Um den Serverprozess selbst zu beschränken, kann man folgende Syntax benutzen:

 

RLimitMemory daemon 8192 max

 

Generell sollte man kein RLimitCPU limit auf den Serverprozess setzen, da ein permanent laufender Daemon (was ja der Fall sein sollte) dieses Limit unter Umständen erreich kann. Die Limits variieren übrigens von Seite zu Seite - also nicht einfach die Beispiel blind kopieren.

 

Ein oft erwähntes Problem in Verbindung mit der unbeschränkten Verwendung von Resourcen ist das "globbing" (im Deutschen etwa "suchen mit Platzhaltern"). Diese Thema wird sehr ausführlich hier behandelt: www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-Globbing.html

 

Einige Seiten möchten ausserdem den verwendeten Plattenplatz oder die Grösse der upgeloadeten oder downgeloadeten Files. Um die Grösse der Files zu beschränken gibt es die beiden Direktiven "MaxRetrieveFileSize" sowie "MaxStoreFileSize".

 

Ausserdem sind weitere Module verfügbar, die die Resourcen des FTP Servers sehr detailliert beschränken können:

mod_diskuse
mod_load
mod_quotatab

 

Zugangskontrolle:

ProFTPD erlaubt mit Hilfer der <Limit> und <Directory> Direktiven eine genaue Zugangskontrolle für einzelne Bereiche sowie welche Befehle ein User verwenden darf. Host basierte Zugangskontrolle durch /etc/hosts.allow und /etc/hosts.deny Dateien können durch das Modul mod_wrap erreicht werden. mod_wrap unterstützt auch die Möglichkeit, Zugangsbeschränkungen in SQL Datenbanken abzulegen.

 

Performance Tuning:

Es gibt verschiedene Möglichkeiten die Leistung von ProFTPD zu tunen. Zunächst sollte man sicherstelen, das Ident und DNS Abfragen abgeschaltet sind:

IdentLookups off

UseReverseDNS off

 

Defaultmässig wird versucht bei jeder neuen Verbindung diese Werte abzufragen. Je nach Antwortzeit des Identd und DNS Server kann dieses das einloggen relativ lange Verzögern (im schlimmsten Fall bis zum Timeout, der mehrere Sekunden dauern kann).

 

Eine weitere Möglichkeit für langeVerzögerung beim einloggen sind sehr grosse /etc/passwd oderfile /etc/group Dateien. Da die standard Bibliotheken diese Dateien Zeilen für Zeilen abarbeiten kann es bei grossen Dateien relativ lange dauern. In diesem Fall bietet sich die User Verwaltung per LDAP oder SQL an.

 

In einigen Fällen kann auch die PAM Abfrage schuld an Verzögerungen sein. Dieses kann man ausprobieren, in dem man PAN deaktiviert:

<IfModule mod_auth_pam.c>

AuthPAM off

</IfModule>

 

Das Auflisten von Verzeichnissen innerhalb einer FTP Session kann ausserdem die I/O des Servers belasten. Dieses insbesondere durch das rekursive Listen der Verzeichnis, gerade bei vielen Unterverzeichnissen. Dieses kann man wie folgt unterbinden:

ListOptions +R strict

 

Diese Einstellung blockiert die Verwendung der "-R" Option beim Listen der Verzeichnisse. Die Angabe "strict" gibt an, dass Clients diese Angabe nicht überschreiben können. Ausserdem gibt es ab ProFTPD 1.2.9rc1 einige "ListOptions"  Optionen, die die Tiefe der Rekursion beschränken:

 

ListOptions "" maxdepth 3

ListOptions "" maxdirs 10

ListOptions "" maxfiles 1000

 

Die erste Zeile gibt die maximale tiefe der Rekursion, die zweite Zeile beschränkt die max. Anzahl von Verzeichnissen die auf einmal gelistet werden können. Die dritte Zeile hingegen beschränkt die maximale Anzahl der Dateien, die auf einmal gelistet werden können.

 

Ein weiterer Weg das Listen von Verzeichnissen zu beschleunigen ist das abschalten der Überprüfung auf ".ftpaccess" Dateien in den einzelnen Verzeichnissen, da dieses relativ viel Disk I/O benötigt.  Diese Überprüfung wird nämlich bei jedem Verzeichniswechsel durchgeführt. Dieses kann durch folgenden Befehl erreicht werden:

AllowOverride off

 

Die Art des loggens hat ebenfalls Einfluss auf die Performance des Servers. Per Default loggt der ProFTPD per Syslog. Syslog ist aber bekannt dafür, dass er nicht sonderlich skaliert und unter hoher Last kann das Loggen auch zusammenbrechen. In diesen Fällen kann es Sinn machen direkt in Files statt durch Syslog zu loggen. Die Direktiven "ServerLog" und "SystemLog" können dafür verwendet werden. Ausserdem kann es ggf. Sinn machen das utmp/wtmp loggen zu deaktivieren um den Overhead zu reduzieren, besonders bei ausschliesslich anonymen Zugriff oder per alternativen (nicht /etc/passwd) Userverwaltungen:

WtmpLog off

 

Abschliessend können noch einige Configure Optionen benutzt werden, um ProFTPD zu optimieren. Es stehen einige ./configure Optionen zur Verfügung, speziell die --enable-tunable-buffer-size und --enable-sendfile sind von Interesse. Die Sendfile Option wird nicht unbedingt den Download Speeed erhöhen, jedoch die Disk I/O reduzieren. "Sendfile" implementiert dabei den "zero-copy" transfer, das bedeutet, dass der Kernel die Daten in den Socket liest (alles im Kernel Space). Normalerweise wird bei read() erst vom Kernel Space in den application Space kopieren (das File lesen), dann zurück in den Kernel space (in den Socket schreiben).

Durch erhöhung der Buffer Grösse durch die "--enable-buffer-size" Option liest und schreibt ProFTPD die Daten in grösseren Portionen und benötigt so weniger aufwändige Systemaufrufe. Es wurde berichtet, dass die Erhöhung dieses Wertes auf 8092 Byte (8 kb) die Übertragungsgeschwindigkeit dramatisch erhöht hat.

 

Configuration Delegieren:

Eine Config wird als "delegiert" bezeichnet, wenn eine "Include" Anweisung innerhalb der config eine weitere Config einbindet. Dieses wird oft gemacht, wenn man viele Virtuelle Server Verwaltung und dem Verwalter eine virtuellen Domain die Configuration seines Servers überlassen will. Diese Situation sollte man möglichst vermeiden. Der Grund liegt darin, dass innerhalb des Virtuellen Servers z.B. auf ein AuthUserFile verwiesen wird, in dem ein User die UID 0 hat. So könnte dieser User sich ggf. als Root einloggen. Man kann natürlich alle Include Dateien sehr früh in der Config einbinden, so dass gefährliche Werte noch später in der Config überschrieben werden können, jedoch ist dieses Vorgehen sehr unsicher.