Linux mit ProFTPd als FTP-Server

Es gibt zwei Arten von FTP-Servern:

Der anonymus FTP-Server wird hauptsaechlich genutzt, um freie Software fuer jeden zugaenglich zu machen. Der Zugang ist anonym; das heiszt, es ist nicht notwendig einen Account auf dem Server zu haben.

Der restricted FTP-Server stellt Software nur fuer einen bestimmten Personenkreis zur Verfuegung. Das heiszt, man muss sich zuerst einen Account auf diesem Server einrichten, um an diese Software zu kommen.

Beide Systeme haben eins gemeinsam. Der User hat nur beschraenkten Zugriff auf das Dateisystem. Das Wurzelverzeichnis ist naemlich in ein anderes - vom Administrator festgelegtes - Verzeichnis verschoben worden. Auf diesem kann der Nutzer nicht in andere (niedrige) real existierende Systemverzeichnisse wechseln.

Beim anonymen Zugang haben alle Nutzer die gleiche Dateibasis. Der FTP-Daemon erledigt die Verschiebung des Wurzelverzeichnisses mit der Funktion chroot() (dazu aber dazu unter chroot mehr).

Die Auswahl der verwendbaren Serversoftware bezieht sich immer auf den Verwendungszweck des Servers. Folgende Punkte spielen bei der Auswahl eine Rolle:

Linux/Unix besitzt - von Haus aus - einen FTP-Daemon, der theoretisch einen anonymen FTP-Service ermoeglicht. Ich gehe hier nur auf Proftpd ein, da dieser fuer diese Zwecke am geeignetsten ist.

Es kommt immer darauf an, welche Anforderungen man stellt bzw. welche Anforderungen der Server erfuellen soll. Bei der Planung sollte man folgende Hauptkriterien beruecksichtigen.

Bei geringen Bedarf reicht es - wenn man als Basis 30 Sessions nimmt - einen Pentium Rechner mit min. 32 MB Ram und etwa 4 GB Festplattenkapazitaet benutzt. Wenn auf die Moeglichkeit der Kompression verzichtet wird, kann der Arbeitsspeicher noch weiter reduziert werden. Wenn mehr Sessions ermoeglicht werden sollen, sollte man einen schnellen Pentium ab 450 Mhz , mindestens 64 MB Ram und vor allem SCSI-Festplatten verwenden. SCSI deswegen, da diese "schneller" und leichter erweiterbar sind. Auch die Auswahl des Motherboards spielt eine Rolle, da einige nicht in der Lage sind, groeszere Mengen an Arbeitsspeicher aufzunehmen.

Egal, welche Konfiguration man verwendet, es ist immer darauf zu achten, dass diese auch ohne Probleme erweiterbar ist. Als Server dient in diesem Beispiel ein AMD-K6(tm) 3D processor mit 500MHz, 128MB Arbeitsspeicher und 10GB SCSI-HD.

Der FTP-Server benoetigt in der Regel nur ein Basisbetriebssystem ohne Compiler. Die Moeglichkeit, Perl-Scripte ablaufen zu lassen, sollte aber gegeben sein. Auf Tool’s, Games, etc. sollte der Sicherheit wegen verzichtet werden. Das System sollte auf mehrere Partitionen installiert sein, wobei die nicht zu veraendernden Bereiche Read Only gemountet werden sollten. Die Erfahrung hat gezeigt, dasz ein auf Unix basierendes Betriebssystem oder Linuxe hierfuer am besten geeignet sind. Die Vorteile liegen auf der Hand:

In diesem Beispiel wird Linux 2.2.14 mit PitBull 2.0.1 verwenden (auf PitBull wird hier aber nicht weiter eingegangen). Gleichgueltig welches OS man verwendet - man musz sich ueber folgendende Punkte im Klaren sein:

Es macht keinen Sinn - und ist in meinen Augen grob fahrlaeszig - wenn man als total unerfahrener User einen Dienst anbietet. Das gilt nicht nur fuer einen FTP-Server, sondern auch fuer andere Dienste (httpd, smtp, pop, …). Um einen Server zu verwalten gehoert wesentlich mehr dazu, als SuSE 7.3 mit YaSTII installieren zu koennen. Als Server-Admin ist man u. U. (je nach Einsatz des Server`s) fuer die Verwaltung von mehreren Usern zustaendig. Hier kann schon ein kleiner Fehler im System schwerwiegende Folgen haben, fuer die man die Verantwortung tragen musz. Bevor man also einen Dienst im Internet anbietet, musz man sich mindestens die Grundlagen aneignen um sich gegen eventuelle Attacken schuetzten zu koennen. Ein Server, welcher von einem unbedarften Verwalter administriert wird, bietet eine Unzahl von Angriffspunkten an, die nicht nur die Sicherheit des Dienstes, sondern auch die Sicherheit des gesamten Systems beeintraechtigen.

Module sind - einfach ausgedrueckt - Treiber, die bestimmte Zusatzfunktionen bereitstellen. Per Default werden die nachfolgend aufgelisteten Module von ProFTP installiert:

Ich habe hier noch drei weitere Module eingebunden:

Eine Uebersicht der vorhandenen Module findet man entweder auf der Homepage von ProFTPD oder im Verzeichnis proftd-$VERSION/contrib oder proftpd-$VERSION/modules/ (bitte ansehen, da sich diese aendern koennen). Wie diese Module eingebunden werden, wird im Abschnitt Installation von ProFTP beschrieben. Nachfolgend wird "nur" beschrieben, welchen Sinn und Zweck ein bestimmtes Modul erfuellt. Es werden u. a. auch Anwendungsbeispiele gezeigt, welche kommentiert sind.

Mit diesem Modul ist es Moeglich sogenannte "Ratios" zu setzten. Dies ist allerdings nur sinnvoll, wenn man auch den Upload von Datein erlaubt hat. Man kann diese Funktion in folgenden Directiven verwenden:

Ich hab mal Ratios fuer Anonymous gesetzt und vergessen ein Upload-Verzeichnis zu erstellen. Das Ergebnis war, dasz man darauf hingewiesen wurde etwas hochzuladen, man aber nix hochladen konnte, weil die Upload-Verzeichnisse der anderen (regulaeren) User mit chmod 700 versehen waren. Also frei nach dem Motto: Auch wenn Du keine Moeglichkeit hast etwas hochzuaden, so muszt Du es doch tun, weil Du sonst nichts runterladen kannst. Wie Du das machst is mir egal.. mach es einfach!

Damit man dieses Modul ueberhaupt nutzen kann, musz man es zuerst "einschalten", da dieses Modul per Default nicht aktiviert ist. Dies geschieht mit dem Eintrag Ratios on. Wenn man die Ratios speichern will, so kann man dies mit folgenden Anweisungen erreichen:

Die letzten zwei Angaben sind notwendig um Ratios zu speichern! Sobald SaveRatios verwendet wird. Man kann die Ratios wie folgt definieren:

Bei UserRatio ist die Wildcard * erlaubt. iese Wildcard bedeutet, dasz die gesetzten Ratios fuer alle User gelten. Mit HostRatio kann man bestimmte Host’s angeben, fuer die Ratios gelten sollen. Hier sind Wildcards erlaubt, wobei der FQDN "bearbeitet" wird (naeheres weiter unten unter "Beispiele") Die Anweisung GroupRatio weiszt (nur) der angegebenen Gruppe Ratios zu und AnonRatio gilt fuer "Anonymous-Logins".

Die Anweisung UserRatio hat folgendes Format:

Jetzt aber mal einige Beispiele zum UserRatio:

Man kann dieses Modul auch in Zusammenhang mit mod_mysql verwenden, sofern es mit -DMOD_MYSQL_RATIOS kompiliert worden ist.

Dieses Modul ist fuer die Authentifizierung beim Login zustaendlich und wird per Default geladen. Es gibt im Falle falscher Zugangsdaten den Errorcode 530,"Please login with USER and PASS. zurueck. Weiterhin uebernimmt es auch noch folgende Aufgaben:

Fuer mehr (und genauere) Informationen sollte man sich mal die Datei /proftp-$VERSION/modules/mod_auth.c ansehen.

Dieses Modul ist fuer eine Unzahl von Funktionen zustaendig. Darunter fallen u. a.:

Fuer mehr Informationen bitte die Dateil proftpd-$VERSION/modules/mod_core.c einsehen. Wie auch mod_auth wird auch dieses Modul per Default geladen.

Dieses Modul wird per Defaul geladen und ist fuer das Protokollieren von Zugriffen zustaendig. Hierauf gehe ich nicht weiter ein, weil man eine Auflistung der verschiedenen Logformate entweder unter proftpd-$VERSION/doc/Configuration.html oder (falls man es lieber in deutscher Sprache liest) auf Stonki’s Page vorfindet.

Kurz und schmerzlos

Dieses Modul ist fuer PAM (Pluggable Authentication Modules) zustaendig und wird per Default von ProFTP installiert. Um dieses Modul nutzen zu koennen, musz man die Datei /etc/pam.d/ftp bzw. /etc/pam.d abaendern. Die Eintraege sehen hierbei wie folgt aus:

Mit diesem Modul ist es moeglich Quotas zu setzen, die entweder global (also fuer alle User), Anonymous und/oder Virtual Hosts gueltig sind. Man kann also bestimmen, wieviel hochgeladen werden darf. Um dieses Modul zu aktivieren ist der Eintrag Quotas on in der Konfigurationsdatei noetig. Es stehen auch noch weitere Moeglichkeiten der Handhabung von Quotas zur Verfuegung:

Wenn man Quotas aktiviert, wird eine Datei namens .quota generiert, die die Angaben zu den gesetzten Werten enthaelt. Das Problem an der Sache ist, dasz diese Datei beschreibbar ist (bzw. sein musz). Jetzt haette ein User die Moeglichkeit, diese Datei einzusehen, mit neuen Werten zu versehen und erneut hochzuladen. Dem kann man aber entgegenwirken, indem man folgende Eintraege fuer das Verzeichnis setzt, in dem die .quota liegt:

Somit ist sichergestellt, dasz niemand diese Datei sieht, erkennt und herunterladen kann.

Dieses Modul wird per Default eingebunden und ist fuer die Implementation des Kommandos "SITE" zustaendig. Manche Daemonen haben dadurch enorme Sicherheitsluecken. Bei einigen Versionen von wu_ftpd kann man z. B. durch den Aufruf von "SITE <command>" eine Shell erlangen! ProFTP besitzt diesen Bug gluecklicherweise nicht. Man kann sich auszerdem durch Verwendung der Directive <LIMIT> und/oder PathDenyFilter/PathAllowFilter nochmal zusaetzlich absichern.

Dieses Modul sorgt dafuer, dasz auch die Datei /etc/passwd ueberprueft wird und die Passwoerter der Datei /etc/shadow bzw. /etc/security/passwd unter AIX verarbeitet werden kann. Das auch dieses zur Authentifikation sehr wichtige Modul per Default eingebunden wird, erwaehne ich hier nur so nebenbei.

Dieses per Default eingebundene Modul hat die Aufgabe, den Datentransfer zwischen Server <→ Client zu erfassen und somit die Auswertung und Ueberwachung des Datentransfers zu ermoeglichen. Dieses Modul ist wird auch benoetigt, um z. B. die Bandbreitenbeschraenkung zu realisieren.

Mit diesem Modul ist es moeglich, TCP-Wrapper mit ProFTP zu nutzen. Dazu stehen folgende Directiven zur Verfuegung:

Beispiele:

mod_sql ist ein Authentifkations und Logging-Modul fuer ProFTP. Es umfaszt ein Frontend-Modul, mod_sql und Datenbank spezifisische Module (mod_sql_mysq bzw. mod_sql_postgres): http://www.proftpd.de/SQL-Anleitung.30.0.html

Dieses Modul erlaubt es ProFTP eine User-Authentifizierung durchzufuehren, bei der die Namen/UID`s in einer LDAP Datenbank gesucht werden. Die Installation ist relativ einfach: mod_ldap ist bereits bei ProFTP "dabei". Wenn man eine neuere Version von mod_ldap verwenden will, welche nicht bei der vorhandenen ProFTP-Version enthalten ist, reicht es wenn man die Datei mod_ldap.c runterlaedt und anschlieszend mit

in das Verzeichnis kopiert. Danach reicht ein

Von der Installation der .rpm-Pakete wuerde ich abraten, da man hier keinen Einflusz auf die Module hat. Hier wird ProFTP nur mit den Standardmodulen installiert und es ist nicht moeglich, weitere Module per RPM hinzuzufuegen. Der nachfolgende Installationsablauf bezieht sich auf die Sourcen, die als .tar.gz vorliegen. Nachdem man ProFTP runtergeladen hat, geht es an das Installieren. Bevor man das aber machen kann, musz man logischerweise die Sourcen zuerst entpacken. Dazu geht man wie folgt vor:

Hierbei sollte man aber bedenken, dasz ein ./configure ohne zusaetzliche Optionen nur die Standarmodule installiert. Will man jetzt zusaetzliche Module verwenden, dann musz man diese explizit einbinden. Die Syntax hierzu ist denkbar einfach:

Wenn man also z. B. mod_ratio, mod_quota und mod_readme einbinden will, dann waere der Aufruf wie folgt:

Es stehen aber noch weit mehr Parameter fuer ./configure zur Verfuegung:

Die Parameter sind selbsterklaerend. Bsp.: Per Default wird ProFTP nach /usr/local/ installiert. Wenn man das aber nicht moechte, kann man das mit dem prefix selbst bestimmen. So wuerde z. B.:

ProFTP nach /usr/local/bin/software installieren.

Die Konfiguration von ProFTP spielt sich hauptsaechlich in einer Datei ab. Welchen Dateienamen man waehlt bleibt freigestellt. Es ist aber sinnvoll diese Datei proftpd.conf zu nennen und unter /etc/ abzulegen, weil diese von ProFTP per Default verarbeitet wird. Man kann logischerweise den Dateinamen frei waehlen, allerdings musz ProFTp dann explizit mit dieser Datei gestartet werden (naeheres dazu unter Startparameter). Die Aussage "hauptsaechlich" kommt daher, weil es ProFTP dem User erlaubt, in die vorhandene Startdatei weitere Konfigurationsdateien einzubinden. Dies kann man u. a. dann verwenden, wenn man innerhalb eines Verzeichnisbaumes so umfangreiche Konfigurationen einbinden will, ohne die Uebersicht zu verlieren. Bsp.:

Hier wuerd man also die Konfigurationsdatei anonymous-datei, welche die Einstellungen fuer Anonymous-Logins enthaelt, einbinden. Ein weiteres sinnvolles Beispiel waere z. B. folgendes:

So kann man schnell, einfach und uebersichtlicht unzaehlige VirtualHost’s einbinden‥ Die Include - Anweisung steht auch fuer folgende Abschnitte zur Verfuegung:

Man hat also nahezu unbegrenzte Moeglichkeiten und ist nicht gezwungen sich durch eine Konfigurationsdatei zu wuehlen, die mehrere hundert Zeilen enthaelt. Bevor man allerdings ueberhaupt anfangen kann, musz man logischerweise zuerst einmal ein Verzeichnis erstellen, dasz fuer ftp-User zugaenglich sein soll. Normalerweise ist der User ftp schon vorhanden. Sollte dies nicht der Fall sein, kann man ihn mit useradd -u 40 -d /home/ftp -m -s /bin/false erstellen. Ich verwende fuer Server-Dienste (sofern moeglich) immer das Verzeichnis /home/<daemon>/, damit man den Ueberblick nicht verliert. Welches Verzeichnis man letzendlich waehlt bleibt freigestellt.

Eine Standard-Konfigurationsdatei sollte folgende Werte beinhalten:

Wenn man das jetzt in die proftpd.conf uebertraegt, sieht diese wie folgt aus:

Einen Server mit einer solchen Konfigurationsdatei zu betreiben, ist alles andere als sinnvoll. Diese Konfigurationsdatei stellt nur die Funktion des Servers sicher. D. h. sie sorgt nur dafuer das er startet und laeuft. Die Konfigurationsdirectiven von ProFTP sind unzaehlig. Man kann nahezu alles und jeden verwalten und administrieren. Wenn man diese Moeglichkeiten schon zur Verfuegung hat, sollte man sie auch ausnutzen. ProFTP liefert einige Beispiel-Konfigurationsdateien mit, welche man unter proftpd-$VERSION/sample-configurations/ einsehen kann. Diese sind ausreichend kommentiert und enthalten von der Standardkonfiguration, ueber Anonymous-Account (mit und ohne Upload-Verzeichnis) bis zu Beispielen zur Verwendung von VirtualHost’s alles wichtige. Wem diese nicht reichen, der kann sich unter Beispiele von Konfigurationsdateien noch weitere Informationen einholen. Auch diese sind ausreichend kommentiert und uebersichtlich geschrieben.

Man kann die Konfiguration untergliedern. Das heiszt man kann Angaben machen, die fuer den gesamten Server gelten oder man kann Angaben machen, die nur bestimmte Verzeichnisse betreffen. Diese Anweisungen werden in sogenannten Bloecken vorgenommen. Hierbei stehen folgende Bloecke zur Auswahl:

Man kann diese logischerweise auch verschachteln.

Hier musz man beachten, dasz einige Directiven ueber anderen stehen.

Eines haben aber alle Bloecke gemeinsam: Sie beginnen mit <block> und werden mit </block> beendet. Wenn man vergiszt einen Block mit </block> zu beenden, erhaelt man eine Fehlermeldung zurueck und der Server kann nicht starten.

Wenn man User anlegt, die nur Zugriff ueber ftp haben sollen, sollte man nach folgenden Punkten vorgehen:

Grundsaetzlich gibt es zwei Arten von Usern:

Da es sich hier um ProFTP handelt, werde ich nur auf Leztere eingehen.

Es gibt keinen Grund, weshalb ein ftp-User eine Shell besitzen sollte. Um auf ftp zuzugreifen ist keine Shell noetig. Normalerweise weiszt man solchen User /bin/false als "Shell" zu. Diese hat nur den Zweck, einem User der diese Shell hat den Login ueber telnet/ssh zu verbieten. Wenn sich also ein solcher User mit ssh -l <username> -p <port> <host> einloggen will, wird ihm der Zugang verweigert und er erhaelt ein Connection to <hostname> closed. zurueck. Man kann diese Meldung auch etwas persoenlicher gestalten. Ich wurde von Alexander Leidinger darauf hingewiesen das FreeBSD in der Portcollection eine ausfuehrlichere Variante von /sbin/nologin enthaelt (danke dafuer!). Diese kann man bei FreshPorts
[http://www.freshports.org/sysutils/no-login/]
herunterladen.

Diese komiliert man anschlieszend und kopiert sie nach /usr/bin (Name bleibt freigestellt). Wenn das geschehen ist, musz man logischerweise noch die Shell des User aendern und ihm seine neue Shell zuweisen. Das eben kompilierte Programm hat den Namen ftpshell und der User, der diese erhalten soll, heiszt pseudo.

und schon erhaelt er beim naechsten Loginversuch ueber telnet/ssh den in unserem Programm angegebenen String zu sehen und der Login-Vorgang wird beendet.

Man kann jedem User ein eigenes Homedirectory zuweisen, indem man die Option -d bei useradd verwendet. In den nachfolgenden Beispielen werden die User mit

angelegt. Das mache ich, weil ich jedem User ein eigenes Upload-Verzeichnis zuweise, in das nur der betreffende User wechseln kann. Der naechste Vorteil bei verschiedenen Upload-Verzeichnissen ist, dasz man durch die <Directory> in Verbindung mit der <Limit> Directive in der Lage ist, fuer jeden User entsprechende "Rechte" zu setzen. So kann man z. B. den User GuterUser volle Bandbreite zusprechen, waehrend man dem User BoeserUser die Bandbreite begrenzt und/oder mit Ratios belegt. In beiden Faellen sollte man sich mit der Anweisung DefaultRoot vertraut machen. Eine chroot() ist eine Umgebung, aus der man Dazu wird ein beliebiges Verzeichnis zum root - Verzeichnis; das hat dann die Folge, dasz man in kein anderes Verzeichnis wechseln kann, weil man ja schon in der "Wurzel" ist. Der Vorteil von ProFTP ist - das er im Gegensatz zu anderen Daemonen (i. e. wu_ftpd) - keine zusaetzlichen Dateien zum Betrieb der chroot() benoetigt.

Hier wird erlaubt, dasz sich auch Personen einloggen koennen, die keinen regulaeren Account auf dem Server haben. Zur Authentifizierung sind hier lediglich die Usernamen anonymous und ftp (per Default) von Noeten. Die Angabe eines Passwortes wird hier zwar in der Form einer gueltigen E-Mail-Adresse erwartet, allerdings ist diese nicht zwingend notwendig. Im Gegensatz zu wu_ftpd besitzt ProFTP keine Ueberpruefungs-Moeglichkeit des angegebenen Passwortes. D. h. es wird nicht unterschieden ob das Passwort "gueltig" ist oder nicht. Die Angabe von blafasel als Passwort wird genauso akzeptiert wie strcat@gmx.net oder keine Eingabe. Der Vollstaendigkeit halber sei hier gesagt, dasz wu_ftpd in der Lage ist die Passwortangabe von Anonymous-Login`s nach folgenden Kriterien zu ueberpruefen:

Der Anonymous-Server wird normalerweise nur genutzt, um frei zugaengliche Software fuer jedermann zugaenglich zu machen. Wenn man z. B. einen Mirror von ftp.kernel.org erstellt, macht es wenig Sinn diesen nur fuer bestimmte Personen zugaenglich zu machen.

Besonders bei Anonymous-Ftp sollte man sich Gedanken ueber die Sicherheitsvorkehrungen machen. Da man - wie schon gesagt - keinen Account braucht, ist es jedem gestattet sich einzuloggen. Hierbei kann man nicht ausschlieszen, dasz man Opfer von Exploit- und/oder (d)DoS-Attacken wird. Dies ist vorallem bei Anonymous-Ftp gefaehrlich, wo zusaetzlich noch die Moeglichkeit von Uploads gegeben ist. In solchen Faellen haben selbst anonyme User Schreibrechte in einem Verzeichnis und sind somit in der Lage den Server zu attackieren. Wie man sich gegen solche Attacken und Angriffe schuetzten kann, kann man unter Sicherheit nachlesen.

Das erlauben von Anonymous-Login`s ist denkbar einfach. Das folgende Beispiel erlaubt Anonymous-Zugang ohne Upload-Moeglichkeit:

Dieser Abschnitt wird einfach in die /etc/proftpd.conf eingefuegt und schon hat man (nachdem man den Server neu gestartet hat) die Moeglichkeit Anonymous-Logins zu erlauben. Jetzt hat man auch noch die Moeglichkeit einen weiteren anonymen Zugang einzurichten. Ueber denn Sinn dieses Vorhabens laeszt sich zwar streiten, aber ich werde hier trotzdem darauf eingehen. Zuerst musz/sollte man einen weiteren User erstellen (ich nenne ihn fuer dieses Beispiel ‘besucher’). Wenn das geschehen ist, fuegt man folgenden Abschnitt in die /etc/proftpd.conf hinzu:

Wenn man das gemacht hat, kann man sich sowohl als ‘anonymous’, ‘ftp’, als auch als Benutzer ‘besucher’ einloggen. Fuer die Authentifizierung reicht es hier wiederum, sich mit einem der angegebenen Usernamen einzuloggen. Eine Passwortueberpruefung findet nicht statt. Das Problem hierbei ist, dasz sich - als ‘anonymous’ und ‘ftp’ - eingeloggte Benutzer frei bewegen koennen. Das heiszt sie koennen auch in uebergeordnete Verzeichnisse wechseln. Wie man dem entgegenwirken kann, wird im Abschnitt chroot() erklärt.

Ueber denn Sinn eines solchen Verzeichnisses laeszt sich streiten. Auf der einen Seite hat man hiermit die Moeglichkeit auch etwas "zu bekommen" und nicht nur die eierlegende Wollmilchsau spielen zu mueszen, auf der anderen Seite stellt ein solches Verzeichnis ein erhebliches Sicherheitsrisiko dar. Upload-Verzeichnisse stehen nicht nur fuer regulaere User, sondern auch fuer Anonymous zur Verfuegung. Man hat auch die Moeglichkeit diese in einem VirtualHost anzubieten. Wenn man dieses Vorhaben in die Tat umsetzt, sollte man sich vor allem ueber die Sicherheitsrisiken im Klaren sein. Die Problematik liegt hierbei u. a. darin, dasz User hier ein beschreibbares Verzeichnis haben und man somit wieder fuer Exploit-Attacken anfaellig ist. Das naechste Problem ist dann, dasz der auf dem Server vorhandene Speicherplatz ueberflutet werden kann. Wenn man z. B. nur noch 10 MB freien Speicherplatz zur Verfuegung hat, reicht bereits ein Upload einer Datei >= 10MB um den Server lahmzulegen. Dagegen kann man sich aber schuetzten, indem man Quotas setzt; diese kann man entweder im System oder (fuer ftp) mit mod_quota. ahmzulegen. Dagegen kann man sich aber schuetzten, indem man Quotas setzt; diese kann man entweder im System oder (fuer ftp) mit mod_quota. IMHO ist die erste Moeglichkeit sinnvoller, da man nicht Gefahr laeuft, dasz die Quotas durch einen erfolgreichen Angriff auf den Server (z. B. (d)DoS-Attacke) auszer Kraft gesetzt wurden. Da das Thema ‘Upload-Verzeichnisse’ sehr komplex ist, gehe ich in einem spaeterem Abschnitt noch ausfuehrlicher darauf ein.

Der "VirtualHost" Block in der Konfiguration wird benutzt, um eine unabhaengige Konfiguration fuer eine spezielle IP bzw. fuer einen speziellen Hostnamen zu erstellen. Es wird oft benutzt in Verbindung mit System basierten IP Aliasing oder Dummy Netzwerk Schnittstellen, um einen oder mehrere "virtuelle" Server auf einem Server laufen zu lassen. Mittels der "Port" Anweisung innerhalb eines "VirtualHost" Blockes kann man mehrere virtuelle Server unter einer IP auf einem Server laufen lassen, die durch verschiedene Ports angesprochen werden. Dieses ist jedoch nur im Standalone Modus moeglich! Ein "VirtualHost" Block beginnt mit "<VirtualHost>" und wird mittels "</VirtualHost>" beendet. Ein Beispiel fuer einen VirtualHost sieht wie folgt aus:

Hier haette man also drei ftp-Server auf einem Rechner laufen. Diese koennte man wie folgt ansprechen:

Wie man also sieht, sind die Moeglichkeiten hier nahezu unbegrenzt. Bei den hier gezeigten Ausschnitten handelt es sich nur um Beispiele die das Prinzip verdeutlichen sollen. Komplexere Konfigurationsdateien findet man unter im Abschnitt Beispiele von Konfigurationsdateien. Sollte jemand weitere Konfigurationsdateien haben, dann schickt mir die bitte per Mail (strcat@gmx.net), damit ich sie hier noch veröffentlichen kann.

Auf die Sicherheitsrisiken die solche Verzeichnisse bringen bin ich ja schon eingegangen und werde es dabei bewenden lassen. Auf meinem Server verfahre ich mit diesen Verzeichnissen wie folgt:

Mit dieser Untergliederung habe ich die Moeglichkeit jedem User bestimmte "Rechte" zu geben (Upload resumen, Download erlauben, ..), welche unabhaengig von den anderen Usern (bzw. Upload-Verzeichnissen gueltig sind). Hier kann ich z. B. userA das resumen von abgebrochenen Uploads erlauben, waehrend userB keine Moeglichkeit hat, diese Uploads wieder aufzunehmen. Hiermit kann ich - auch ohne die Logs zu ueberpruefen - schnell kontrollieren, wer welche Datei hochgeladen hat. Da jeder User auf unserem Server einen "eigenen Namen" hat, kann man mit chmod 700 <username> <user-uploadverzeichnis> verhindern das z. B. userA in das Verzeichnis /ftp/uploads/userB/ wechselt um dort Dateien hochzuladen.

Das Erstellen von solchen Verzeichnissen ist schnell passiert; es gibt aber trotzdem einiges was man beachten musz:

In unserem Beispiel sieht das also wie folgt aus:

Wenn man jetzt noch Unterverzeichnisse erstellen will, die fuer die einzelnen User gehoeren sollen, dann geht man hier wie folgt vor:

So faehrt man jetzt fuer jeden User dem man ein Upload-Verzeichnis zuweisen will fort. Wenn man damit fertig ist, sieht die Verzeichnsistruktur von /home/ftp/ folgendermaszen aus:

Ein anschlieszendes ls -l /home/ftp/ sollte jetzt folgende Ausgabe liefern:

Jetzt sind schonmal die "Grundrechte" gesetzt; nun mueszen wir aber noch dafuer sorgen, dasz kein User etwas nach /home/ftp/uploads/ laden kann, sondern nur in sein zugewiesenes Verzeichnis. Dazu bedienen wir uns der Directiven <Directory> und <Limit>.

Jetzt kann man mit den Upload-Verzeichnissen der verschiedenen User weitermachen. Welche Kommandos bzw. "Aktivitaeten" man erlaubt, musz man selbst entscheiden ;) Bei Anonymous sieht das ganze anders aus.. Da man in der Regel nicht weisz wer sich da gerade einloggt und was der vorhat, sollte man immer vom Schlimmsten ausgehen. In diesem Fall sollte man ihm alles verbieten was nicht unbedingt notwendig ist. Hierbei sollte man nicht nach dem Motto: Das kann er eh nicht machen.., sondern nach der Regel: Alles was nicht explizit verboten wurde, ist erlaubt! verfahren. Auf das, was man sonst noch machen kann, damit man die Upload-Verzeichnisse "sicher" bekommt, werde ich unter Sonstige Moeglichkeiten ansprechen.

Die Kontrolle der Bandbreite ist ein weiterer wichtiger Gesichtspunkt bei der Administration eines Servers. Wenn man - wie wir hier - Anonymous-Login erlaubt, macht es wenig Sinn, wenn man anonyme User gleichwertig wie regulaere User behandelt. Die Performance von regulaeren User ist wichtiger als die von anonymen. Wenn sich z. B. 20 anonyme User eingeloggt haben und jeder etwas runterlaedt, ist die Bandbreite ziemlich schnell erschoepft. Sollte sich jetzt ein regulaerer User einloggen und auch etwas downloaden wollen, dann hat er ziemlich schlechte Werte und musz warten bis sich einige User ausgeloggt oder ihren aktiven Download beendet haben. Damit man dem entgegenwirken kann, sollte man sich mit den Anweisungen:

auseinandersetzen. Diese erlauben es in den Bloecken <VirtualHost> und <Anonymous> die Bandbreite fuer Downloads zu regeln. So koennten man folgendes in einen <Anonymous> - Block einbauen:

Da man diese jetzt in einem <Anonymous> - Block angegeben hat, gelten diese Einschraenkungen logischerweise auch nur fuer Anonymous. Da man die Bandbreite fuer Downloads geregelt hat, will man ja auch noch das gleiche fuer Uploads machen… auch das ist kein Problem. Dazu bedient man sich der Anweisungen:

Auch diese gelten wieder fuer die Bloecke <VirtualHost>, <Anonymous> und zusaetzlich noch fuer den Block <Directory>. Die Anwendung ist gleichbedeutend mit der oben genannten und auch die Werte werden hier in Bytes pro Sekunde angegeben.

Mit der Anweisung AllowStoreRestart on kann man es erlauben, dasz abgebrochene Uploads wieder aufgenommen werden duerfen. Diese "Feature" ist aber mit Vorsicht zu genieszen. Einerseits stellt man so sicher, dasz User bei einem Verbindungsabbruch waehrend des Uploads nicht wieder von vorne beginnen mueszen (also bei 0%), andererseits ist es somit erlaubt vorhandene Dateien zu ueberschreiben (und diese kann man somit auch zerstoeren). Bei Anonymous-Ftp in Verbindung mit Upload-Moeglichkeit sollte man dieser Moeglichkeit absehen. Es ist zwar fuer den (anonymen) User komfortabler, allerdings kann - wie schon gesagt - ein anderer anonymer User bereits vorhandene Dateien zerstoeren. Wenn ueberhaupt, dann sollte diese Anweisung nur fuer bestimmte User erlaubt werden. Da diese Anweisung fuer die Bloecke:

zur Verfuegung steht, hat man hier relativ grosze Anwendungsmoeglichkeiten. Es sei hier noch erwaehnt, dass AllowStoreRestart per Default auf off steht. Das heiszt das Resumen von abgebrochenen Uploads ist nicht erlaubt.

Von dieser Moeglichkeit sollte man - innerhalb eines Upload-Directorys auf jeden Fall gebrauch machen. Das dient u. a. dazu, dasz man zuerst ueberpruefen kann, ob die (von einem User) hochgeladene Datei sauber ist. Wenn man z. B. den Download aus Upload-Verzeichnissen erlaubt, laeuft man Gefahr das Viren oder aehnliches verbreitet werden koennen. Das naechste ist dann, dasz solche Server als Tauschboersen oder Warez-Server miszbraucht werden.

Da wir im Abschnitt Upload-Verzeichnisse erstellen schon folgenden Block verwendet haben:

koennen wir das auch in dern verschiedenen Upload-Verzeichnissen der User einbringen (sofern dies erwuenscht ist).

Das Problem Upload-Verzeichnis ist immer noch nicht abgeschlossen. Bis jetzt haben wir zwar ein Verzeichnis in das nur die betreffenden User wechseln koennen und nicht mal sie selbst dort etwas downloaden koennen, aber das reicht noch nicht. Es ist ab und zu erforderlich, dasz man den Upload von bestimmten Dateien verbietet. Darunter fallen u. a. .ftpaccess, .htaccess, usw. usw‥ Dem kann man jetzt mit einfachen - aber effektiven - Mitteln entgegenwirken. ProFTP bietet hierzu die Anweisung ' PathDenyFilter' an. Damit kann man verhindern das Dateien bestimmter Art hochgeladen werden. Wenn man (wie ich) einen Linux-Rechner als Server verwendet und man eine ‘M$-Free’-Zone hat, dann wird es schwer Dateien im "Windows-Format" zu ueberpruefen. Aus diesem Grund verbiete ich fuer Anonymous-User folgende Dateien (wobei hier Datei-Suffix relevant ist):

Zusaetzlich ist auch noch der Upload von den Dateien .ftpaccess und .htaccess untersagt. Die Eintraege in die entsprechenden Bloecke sehen wie folgt aus:

Wenn ein User jetzt versucht eine Datei hochzuladen, die unter dieses Muster faellt, bekommt er

zu sehen.

Man hat - wie bei den meisten FTP`s - auch bei ProFTP die Moeglichkeit Messages ausgeben zu lassen. In den nachfolgenden Abschnitten werde ich nur auf die Besonderheiten der einzelnen Directiven eingehen, weil es doch einiges zu beachten gilt. Damit man Messages nutzen kann, ist nichts weiter erforderlich, als eine Ascii-Datei, die den Text enthaelt, der ausgegeben werden soll. Farben und/oder andere Textformatierungen (unterstrichen, fett, kursiv, ..) sind hier auch in Verbindung mit Ansi-Codes nicht möglich. Beim Erstellen von solchen Messages sollte man sich ueberlegen was diese enthalten sollen und was nicht. Wenn man z. B. Anonymous-Login`s erlaubt, sollte man von der Angabe der verwendeten Software absehen. Das hat u. a. den Grund, dasz User, die sich einloggen nicht gleich die Version des eingesetzten Daemons sehen. Einige Kiddies haben es sich scheinbar zur Lebensaufgabe gemacht, nach fehlerhaften Diensten zu scannen um diesen dann zu attackieren. Ich rate auch von der Anwendung sogenannter "Fake-Messages" ab. Eine Unsitte ist zum Beispiel, dasz - bei Verwendung von FTP-A - der Daemon FTP-B angegeben wird. Auf diese Weise wird zwar die eigentlich verwendete Software verschleiert, allerdings kann es dann sein, das der Angreifer nach Exploits fuer die vermutete Version sucht und den Server damit angreift. Man sollte in diesen Messages nur das notwendigste an Informationen angeben. Wie man diese Messages gestaltet, welche zur Verfuegung stehen und wann diese angezeigt werden, wird in den folgenden Abschnitten erklaert

Damit man dies realisieren kann, musz man die Anweisung DisplayConnect /path/to/file in die zu verwendende Konfigurationsdatei einfuegen. Diese Datei musz - wie bei allen anderen auch - eine Ascii-Datei sein. Wenn also eine Verbindung zu unserem ftp-Server aufgebaut wird, erhaelt der User den dort angegebenen Text zu sehen. Hierbei musz man aber folgendes beachten: Diese Nachricht sieht jeder User der eine Verbindung aufbaut (unabhaengig davon ob er im Besitz eines Accounts ist). Es ist hier nicht moeglich verschiedene (also fuer jeden User unterschiedliche) Messages zu erstellen. Hierbei ist zu beachten, dasz man (nach Moeglichkeit) einen absouleten Pfad angibt, da es ansonsten - unter Verwendung von einer chroot() - zu Problemen kommen kann. Wenn diese Datei nicht existiert oder wenn sie nicht gefunden werden kann, wird keine Fehlermeldung ausgegeben. Da - wie schon gesagt - diese Message von allen gelesen werden kann, sollte man hier auf detailierte Angaben zur verwendeten Software verzichten und nur das noetigste an Informationen preisgeben. Eine typische "Connect-Message" sieht z. B. wie folgt aus:

Dies fuehrt zur folgenden Ausgabe:

Die Angaben %U %R und %E werden dynamisch unter Verwendung der Magic-Cookies generiert. Naehere Informationen findet man im Abschnitt Magic-Cookies verwenden. Diese Message enthaelt alles was wichtig ist. Je nach Verwendung des Server’s kann man hier auch noch diverse Infomationen ueber das "Angebot" machen, auf ein externes FAQ verweisen, Mirrors angeben (falls der Server ueberlastet ist), …

Diese Message wird angezeigt, wenn man sich erfolgreich eingeloggt hat. Hier hat man den Vorteil, dasz man verschiedene Messages ausgeben kann. Es wird hier unterschieden zwischen anonymen Login`s und "regulaeren Usern". Dies ist vor allem dann interessant, wenn man Ratios gesetzt hat und/oder den Upload von verschiedenen Dateien verboten hat. Das mit den Ratios sage ich aus folgendem Grund:

Ich habe fuer Anonymous ein Byte/File-Ratio von 1:1 gesetzt und - unter Verwendung von mod_readme- auf die neusten Updates/Aenderungen hingewiesen. Man konnte/sollte sich also zuerst die README ansehen, damit man eventuell auftretenden Problemem aus dem Weg gehen konnte. Fuer regulaere User war dies auch ohne Probleme moeglich, aber wenn man sich als ‘anonymous’ oder ‘ftp’ eingeloggt hatte, muszte man zuerst etwas hochladen um an diese Datei zu kommen. Es ist nicht besonders "angenehm", wenn man zuerst etwas hochladen musz, damit man weisz was auf dem Server vorhanden ist oder was man ueberhaupt hochladen kann/darf/soll. Es ist bei einem File/Byte - Ratio von 1:1 auch nicht moeglich, Dateien mit less <filename> zu betrachten. Man kann hier aber nur zwei verschiedene Messages anzeigen lassen:

Eine Unterscheidung ob sich UserA oder UserB eingeloggt hat, kann hier nicht realisiert werden.
Eine typische Message fuer anonyme User kann z. B. wie folgt aussehen:

Dies wuerde dann folgende Ausgabe liefern:

ine solche Message ist kurz, uebersichtlich, informativ, aussagekraeftig und gibt keine Informationen ueber die verwendete Software weiter. Die Message fuer regulaere User kann man logischerweise "persoenlicher" gestalten ;) Ob und wie man dies anstellt, bleibt jedem selbst ueberlassen. Man musz hier nur beachten, dasz hier zwei verschiedene Dateien notwendig sind. Zum ersten die fuer anonyme User und zum zweiten die fuer regulaere User. Wenn man seinen Server "aufgeraeumt" halten will, sollte man sich ueberlegen, ob man nicht ein spezielles Verzeichnis fuer Messages erstellt. In diesem Verzeichnis kann man dann auch ggfs. zusaetzliche Messages ablegen. Wenn man diese Moeglichkeit nutzen will, musz man die Anweisung DisplayLogin /path/to/file in die Konfigurationsdatei eintragen, damit dies ermoeglicht wird. Wennman "harte" Ratios (File/Byte 1:1) anwendet und einen "INDEX" des Servers anbietet, sollte man (nach Moeglichkeit) diesen auf einen externen Server (ftp oder http) auslagern, damit dieser ohne Umstaende eingesehen werden kann.

Man hat auch die Moeglichkeit, Messages ausgeben zu lassen, wenn User das Verzeichnis wechseln. Die "DisplayFirstChdir" Anweisung gibt eine ASCII Text Datei an, die dem User beim ersten Wechsel in ein Verzeichnis (mit CDW) per FTP Verbindung angezeigt wird. Die Datei wird auszerdem angezeigt, wenn PROFTPD erkennt, dass das Verzeichnis seit dem letzten Besuch geaendert wurde. Wenn der Filenamen relativ angeben wurde, wird zuerst das Verzeichnis durchsucht, in das der User wechselt. Bei anonymen Zugang, musz das Text File innerhalb der chroot(ed) Umgebung sein. Wenn das File nicht gefunden wird, wird keine Fehlermeldung ausgeben bzw. protokolliert.

Mit der DisplayGoAway /path/to/file Anweisung ist es moeglich, eine Ascii-Datei ausgeben zu lassen, welche angezeigt wird, wenn zuviel User von einer Klasse eingeloggt sind. Hier hat man auch wieder die Moeglichkeit, diese zwischen regulaere User und anonyme User zu trennen. Parallel dazu hat man auch die Moeglichkeit, dies ueber MaxClients <anzahl> "hier die message" zu realisieren. Das auch hier wieder die Magic-Cookies verwendet werden koennen.

Diese Message wird angezeigt, wenn man sich ausloggt. Hier ist es auch wieder moeglich, zwischen anonymen und regulaeren Usern zu unterscheiden. Hierbei ist auch wieder die Einbindung von Magic-Cookies moeglich. Im Gegensatz zu wu_ftp ist es mit ProFTP nicht moeglich, die uebertragenen Bytes anzugeben wenn die Verbindung geschlossen wird. Hierzu reicht der Eintrag DisplayQuit /path/to/file in der Konfigurationsdatei. Angesichts der Tatsache, dasz wu_ftp alles andere als "sicher" ist, kann man auf dieses Feature verzichten.

Diese kann man fuer alle Messages verwenden und kombinieren.

Ich gehe in den nachfolgenden Abschnitten nochmal genauer auf das Thema "Sicherheit" ein. Es ist zwar nicht moeglich 100%ige Sicherheit zu erreichen, aber man sollte es eventuellen Angreifern so schwer wie moeglich machen. Dies dient nicht nur der eigenen Sicherheit, sondern man schlieszt auch aus, dasz der Server fuer weitere Schandtaten miszbraucht wird. Wenn ein Angreifer einen Server erfolgreich attackiert hat, ist er meist im Besitz einer Shell. In diesem Fall ist es fuer ihn kein Problem sich die Recht von root anzueignen um Software zu installieren, die fuer Angriffe auf andere Host`s konzipert ist (TfN, Stacheldraht, Trinoo, ..). Hier wird nicht nur der eigene Server beeintraechtig, sondern auch andere. Solche Faelle kann man zwar nie ganz ausschlieszen, aber man kann sich dagegen absichern. Sobald man einen Dienst (egal welcher Art) fuer Dritte zugaenglich macht, ist man immer ein potentielles Opfer. Es reicht nicht aus, einen Daemon zu installieren/konfigurieren und dann laufen zu lassen! Die Verwaltung eines Servers ist nicht eine Sache die nach zwei Tagen abgeschlossen ist. Man musz staendig Ausschau nach eventuellen Sicherheitsluecken halten, Patche/Update`s einspielen, neuere Versionen installieren, … Ein "Admin" dem die Begriffe Bugtraq, Securityfocus und Cert ein Fremdwort sind, ist ein Masochist, der seine Neigungen online auslebt. Solche Personen sollen doch bitte die Finger von sowas lassen! Gleiches gilt auch fuer Leute, die damit ueberfordert sind, ein Programm ohne YaST einzuspielen oder sich nach einer Alternative umsehen, weil sie mit dem Begriff Checksum nichts anfangen koennen.

Bei ProFTP hat man mehrere Moeglichkeiten zu loggen:

Die "ExtendedLog" Anweisung erlaubt die Erstellung von individuellen Logfiles, entweder Global oder per Virtuellen Host. Der Dateiname muss einen absoluten Pfad enthalten, andem proftpd die Logs anhaengt bzw. erstellt. Es koennen mehrere Logfiles (sinnvollerweise mit anderen Anweisungen) erstellt werden.

Auszerdem, kann mittels des "command-classes" Arguments angegeben werden, welche Art von Befehlen mit geloggt werden. Wenn keine Befehls Klasse angegeben ist, werden standardmaeszig alle Befehle geloggt (Passwoerter sind versteckt). Die Befehls Klassen werden durch Komma getrennt. Folgende Befehls Klassen sind zulässig:

Wenn eine Format Beschreibung uebergeben wird, wird dieses vordefiniertes Format uebernommen (erstellt durch LogFormat). Ansonsten wird das Standard Format benutzt.

Die TransferLog Directive benoetigt den absoluten Pfad zu der Datei, in welche der Transfer geloggt werden soll. Das Logformat wird im gleichen Format wie das von wu_ftp gehalten. Man kann auch separate Logfiles fuer Anonymous und VirtualHost’s anlegen lassen.

Hiermit kann man angeben, was alles geloggt werden soll. Die Anweisung LogFormat nickname "format-string" ist wie folgt definiert:

Die Befehlsklassen sind die gleichen wie bei ExtendedLog und werde sie deswegen jetzt nicht nochmal erklaeren. Folgendes kann man alles loggen lassen:

Einige Beispiele:

Das Logformat sollte man nach folgenden Punkten auswaehlen:

e nachdem welches Logformat man verwendet, kann die Groesze der anfallenden Protokolldatei unterschiedlich sein. Wenn man z. B. einen Server hat, auf den im Schnitt zwischen 20 - 30 User zugreifen und Dateien transferieren, kann das oben genannte Logformat nach einigen Tagen durchaus eine Groesze von mehreren MB erreichen. Damit man nicht Gefahr laeuft, dasz der Speicherplatz irgendwann zu gering wird, sollte man in bestimmten Abstaenden einen Cron-Job ausfuehren, der die Logdateien komprimiert und ggfs. loescht. Zur Ueberwachung dieser Logdateien wuerde ich raten auf diverse Scripte auszuweichem

Ein Angreifer hat zwei Moeglichkeiten um an diese Information zu gelangen:

Die erste Moeglichkeit haben wir schon durch das Erstellen einer eigenen Message (Login, Connect, ..) ausgeschaltet. Jetzt steht dem Angreifer aber immer noch die zweite Moeglichkeit zur Verfuegung. Auf diese wird aber jetzt eingegangen ;) Per Default meldet sich ProFTP mit ProFTPD [version] Server (server name) [hostname]. Diese Geschwaetzigkeit kann man ihm gleich auf zwei Arten abgewoehnen:

Die erste Moeglichkeit schneide ich nur am Rande an, da man das gleiche Ergebnis auch schneller erreichen kann. Hierzu musz man die Datei proftpd-$VERSION/src/main.c mit einem Editor oeffnen und die Versionsstringerzeugung in den Zeilen 1040 und 1042 entfernen (Version 1.2.5rc1 (release)!). Dies sollte allerdings nur gemacht werden, wenn man weisz was man tut.

Die zweite (und einfachere Methode ist die Anpassung der ServerIdent. Diese Anweisung kennt drei Parameter:

Der Default bei dieser Anweisung ist - wie schon gesagt - ServerIdent on "ProFTPD [version] Server (server name) [hostname]" Wenn man diese auf off stellt, meldet sich der Server mit FTP Server ready. Diese ist auch noch relativ reich an Informationen, wenn man davon absieht, dasz diese Message afaik nur von ProFTP angezeigt wird. Dem kann man aber mit dem Eintrag

entgegenwirken. Nach einem Neustart des Servers meldet er sich dann mit:

Wenn man z. B. Dateien/Verzeichnisse verstecken will, hat man folgende Anweisungen zur Verfuegung:

HideUser: Die "HideUser" Anweisung gibt innerhalb eines <Directory> oder <Anonymous> Block an, dasz alle Verzeichnis Eintraege des angegebenen Users versteckt werden sollen, auszer dasz der User selbst eingeloggt ist. Auszerdem: Es werden zwar versteckte Dateien per "List" oder "Nlst" nicht angezeigt, koennen jedoch mittels anderer FTP Befehle (CWD, DELE, RETR, usw.) bearbeitet werden. Dieses Verhalten kann mittels der "IgnoreHidden" Anweisung geaendert werden.

Im Gegensatz zu der Directivenliste - in der die Syntax Hide… userid ist, kann man auch User-/Gruppen-Namen angeben. Auf unsere Konfigurationsdatei umgesetzt sieht das wie folgt aus:

Sobald sich jetzt ein User als ‘anonymous’ oder ‘ftp’ einloggt, werden ihm Dateien (bzw. Verzeichnisse) die dem User ‘UserA’ gehoeren, nicht mehr angezeigt. Dies kann man logischerweise auch fuer verschiedene Gruppen umsetzen.

Im Klartext und auf unsere Konfigurationsdatei uebertragen, sieht dies wie folgt aus:

Wenn man sich also jetzt einloggt und ‘ls -l’ ausfuehrt, sieht die Ausgabe wie folgt aus:

Die eigentlichen Rechte werden nicht veraendert! Man hat auch die Moeglichkeit, diese Anweisungen auf verschiedene Arten und in unterschiedlichen Bloecken anzuwenden:

Man sollte aber auch hier im realistischen Bereich bleiben, damit niemand "Verdacht schoepft". Permissions wie chmod 000 oder chmod 755 sehen unglaubwuerdig aus und/oder verleiten foermlich zum Angriff.

"AllowFilter" erlaubt die Erstellung regulaerer Ausdruecke, die allen uebermittelten Kommandos an proftpd entsprechen muessen. Dieses ist sehr sinnvoll, um zu verhindern, dass mittels uebermittelter Zeichenfolgen eventuelle Angriffe gegen PROFTPD gefuehrt werden. Der regulaere Ausdruck wird gegen dan gesamten uebermittelten Befehl ausgefuehrt, daher sollte man bei der Erstellung des Ausdrucker sehr sorgfaeltig sein. Sollte der uebermittelte Befehl den Test nicht bestehen, so wird dem Client ein "Forbidden Command" uebersendet. Die Uebermittlung von Passwoertern (PASS Befehl) wird NICHT geprueft ! Sollte der regulaere Audruck Leerzeichen enthalten, so sind diese in Anfuehrungszeichen zu setzen.

Das Beispiel, welches in der Directiven-Liste gezeigt wird, sieht wie folgt aus:

Von der Verwendung diesen Beispiels rate ich hier ab. Wenn ihr wissen wollt, wieso ich das mache, dann uebernehmt dieses Beispiel, startet den Server neu, loggt euch ein, wechselt in irgendein Verzeichnis und gebt dort dann cd .. ein ;) Ich verwende hier folgende Loesung:

Hier kann man auch ohne Probleme Verzeichnisse mit cd ../Dir/ wechseln.

So wie man die Moeglichkeit hat, bestimmte Kommandoketten zu erlauben, kann man auch welche verbieten. Bei aelteren Versionen von ProFTP bestand ein Bug darin, dasz durch die Eingabe einer bestimmten Zeichenkette der Server "runtergefahren" wurde. Auch wenn dieser Bug bei der aktuellen Version (1.2.5rc1 (release)) nicht mehr vorhanden ist, so sollte man doch von dieser Moeglichkeit Gebrauch machen um diverse Kommandoketten zu verbieten. Die Anwendung ist wie bei AllowFilter aufgebaut. Es werden die Tastatureingaben ueberprueft und wenn das angegebene Muster gefunden worden ist, wird die Ausfuehrung mit einem Forbidden Command quittiert. Man sollte hier beachten, dasz regulaere Ausdruecke verwendet werden mueszen. Es ist nicht moeglich, einzelne Kommandos zu verbieten. DenyFilter "%" wuerde z. B. alle Befehle in denen % enthalten ist verbieten. Eine andere Moeglichkeit waere z. B. Kommandos mit * zu verbieten. Bis dato war es moeglich, mit

einen laufenden ProFTP zu beenden. Dem kann man entgegenwirken, indem man

in die Konfigurationsdatei aufnimmt. Das einzige was es hier zu beachten gilt ist, dasz - wie bei PathAllowFilter auch - diese Anweisung nur fuer die Bloecke <VirtualHost>, <Anonymous> und <Global> zur Verfuegung steht. Eine Anwendung dieser Anweisung innerhalb des Blocks <Directory> ist nicht moeglich.

Eine chroot() Umgebung ist eine Umgebung, aus der man nicht mehr herauskommt. Dazu wird ein beliebiges Verzeichnis zum root - Verzeichnis; das hat dann die Folge, dasz man in kein anderes Verzeichnis wechseln kann, weil man ja schon in der "Wurzel ist.

Die "DefaultRoot" Anweisung bestimmt das standard Root Verzeichnis fuer einen User bei dem Login. Wenn "Default Root" auf ein anderes Verzeichnis als "/" verweist, wird unmittelbar nach dem erfolgten Einloogen ein "chroot" durchgefuehrt. So kann ein Benutzer vom uebrigen Dateisystem isoliert werden. Das genannte Verzeichnis musz mit "/" beginnen oder kann den Platzhalter ~ enthalten, der fuer das Heimatverzeichnis des Users steht. Dieses kann auch ein weiteres Unterverzeichnis enthalten, wie z. B. ~/html Sollte das "DefaultRoot" Verzeichnis auf ein Verzeichnis verweisen, dasz fuer den User nicht zugaenglich ist, wird er auf das aktuelle Arbeitsverzeichnis gesetzt und nicht auf das normale Homeverzeichnis. "DefaultRoot" kann nicht im Anonymen Anweisungsblock verwendet werden, da er hierfuer eine spezielle Anweisung gibt. Die optionale Gruppenangabe kann dazu benutzt werden, "DefaultRoot" auf eine oder mehrere Gruppen zu beschraenken. Der Ausdruck hat folgendes Format:

Der Ausdruck wird als logische "UND"-Verknuepfung abgearbeitet, so jeder Ausdruck muss WAHR ergeben, um die "DefaultRoot" Anweisung zu gestatten. Die Vorzeichen "!" negiert die Gruppenzugehoerigkeit. Achtung: Grundsaetzlich ist dieses keine 100% Sicherheit, da es Wege geben kann, als User aus diesem "root" auszubrechen.

Beispiel:

Im "Einsatz" sieht das dann wie folgt aus:

Ohne die chroot() koennte sich der eingeloggt User in allen Verzeichnissen im System bewegen, in die er auch wechseln koennte, wenn er im Besitz einer Shell ist.

Wie bei allen anderen Diensten auch, werden im Laufe der Zeit Sicherheitsluecken gefunden, die es zu beheben gilt. Hierzu sollte man sich regelmaeszig die Bugreport-Seite von ProFTP ansehen. Hier werden die neusten Bug`s (in Verbindung mit den dazu gehoerenden Patchen) veroeffentlicht, so dasz man sich gegen Angriffe auf dieser Ebene wappnen kann. Eine "Anleitung" wie man diese Patche einspielt, findet man auf der Page und/oder in der README des betreffenden Patches.

Wie bei allen anderen Diensten auch, sollte man auch hier die neuste Version verwenden. Der Sinn des ganzen ist schlicht und einfach der, das Sicherheitsluecken - die bei aelteren Versionen - vorhanden sind ausschlieszen kann. Wenn man eine "alte" Version verwendet, darf man sich nicht wundern, wenn Angriffe erfolgreich ausgefuehrt werden konnten. Eine direkte Moeglichkeit zum Updaten gibt es nicht; man musz die neue Version von ProFTP downloaden und anschlieszend installieren. Das einzige was es hier zu beachten gilt, ist das die neue Version - die installiert werden soll - mit den gleichen Parametern installiert wird wie die alte, da es sonst zu Problemen mit der besteheneden Konfigurationsdatei kommen kann.

Was hilft einem der schoenste ftp-Server, wenn man keine Moeglichkeit hat, die Zugriffe auf diesen zu steuern, damit sich nicht tausende von Usern einloggen koennen ;) ProFTP bietet dazu gleich mehrere Moeglichkeiten an, wie man die Login`s verwalten kann, damit die Zugriffe nicht Ueberhand nehmen. Nachfolgende werde ich auf die verschiedenen Moeglichkeiten genauer eingehen.

Mit der Anweisung MaxClients wird die maximale Anzahl der Logins verwaltet. Diese steht fuer die Bloecke <Global>, <Anonymous> und <VirtualHost> zur Verfuegung und kann wie folgt definiert werden:

Mit Anzahl wird - logischerweise - die Anzahl der maximalen User angegenen, die sich einloggen duerfen. message kann dazu verwendet werden, um bei Ueberschreiten der maximalen Userzahl eine "Nachricht" auszugeben. Als Platzhalter steht hier %M zur Verfuegung (siehe Magic-Cookies).

Mit MaxClients none wird die Userbegrenzung ausgeschaltet. D. h. es koennen sich unendlich viel User einloggen. Von dieser Moeglichkeit sollte man allerdings absehen, da die Bandbreite bei mehreren Transfers ziemlich eingeschraenkt wird.

Die "MaxClientsPerHost" Anweisung konfiguriert die Maximale Anzahl von Clients, die sich von einem Rechner einloggen koennen. Optional kann angegeben werden, welche Nachricht dem Client geschickt werden soll, falls die maximale Anzahl erreicht ist. Wenn keine Nachricht angegeben wird, wird die Systemweite Standardnachricht benutzt. Beispiel:

Ergebnis:

Mit der Anweisung MaxLoginAttempts hat man die Moeglichkeit die maximale Anzahl von Loginversuchen zu begrenzen. Der Defaultwert liegt bei drei Versuchen. Wenn diese "ueberschritten" werden, wird die Verbindung getrennt und eine Message per syslog protokolliert. Diesen Wert sollte man schon allein aus dem Grund beibehalten, damit man gegen Bruteforce-Attacken geschuetzt ist.

Ab und zu kommt es vor das man bestimmte Domains bzw. Hosts blocken will, weil diese in der Vergangenheit "schlecht" aufgefallen sind. Um dies zu ermoeglichen reicht die Anweisung Deny in einem <Limit> - Block aus. Bsp:

Es gibt zwei Arten um ProFTP zu starten:

Das bedeutet soviel wie: "manuelles Starten". D. h. der Daemon wird "allein" gestartet (im Gegensatz zu inetd, aber dazu gleich mehr). Hierzu kann man ProFTp entweder nach jeden reboot mit proftpd starten oder es sich einfacher machen und ein kleines Script in das "Boot-Verzeichnis" legen, welches ProFTP automatisch startet. Mit "Boot-Verzeichnis" ist das Verzeichnis gemeint, in dem die Daemonen liegen, welche beim Start geladen werden (i. e. sshd, syslogd, httpd, ..). Welches Verzeichnis das ist, sollte jeder selbst wissen, da dies von Linux zu Linux (und Unix zu Unix) unterschiedlich ist. Einige Scripte liegen unter proftpd-$VERSION/contrib/dist/rpm/proftpd.init.d (SysV!) bereit‥

Die naechste Moeglichkeit ProFTP zu starten ist ueber einen Eintrag in der /etc/inetd.conf (bzw. xinetd). Da ProFTP hier ueber einen anderen Daemon gestartet wird, musz man hier noch ggfs. die Startparameter angeben. Um ProFTP per inetd zu starten, oeffnet man die /etc/inetd.conf und sucht nach folgender Zeile:

Diese wird durch folgende ersetzt:

Wenn man noch andere Parameter angeben will, musz man diese explizit eintragen:

Sollte man den tcpwrapper nutzen, dann sieht es wieder anders aus:

Wenn man xinetd verwendet, sieht der Eintrag fuer ProFTP wie folgt aus:

ProFTP hat folgende (u. a. kombinierbare) Parameter:

Abgesehen von der Moeglichkeit die Konfigurationsdatei zu testen (--configtest,-t) sollte man auch noch selbst die Konfiguration und Funktionalitaet des Servers testen (oder testen lassen). Dazu loggt man sich einfach per "ftp" auf dem Server ein und versucht das, was man normalerweise nicht machen sollte… Dateien loeschen, umbenennen, kopieren, .. Auf diese Art und Weise ueberprueft man gleich ob die Rechte richtig gesetzt sind, ob der Up- bzw. Download funktioniert, ob die Messages richtig angezeigt werden, … Man sollte auch nicht vor der Anwendung von Exploits zurueckschrecken!

Hier sind einige Scripte, die das Leben erleichtern. Solltet ihr weitere haben/kennen, dann zoegert schickt mir diese bitte per Mail Mail (strcat@gmx.net), damit ich diese hier noch einbauen kann.

Hier sind Beispiele von verschiedenen Konfigurationsdateien zu finden.