Dieser Beitrag stammt von UNBEKANNT
Linux als ftp – Server
1. Grundlagen
2. Site – Planung
3. Installation des wu – ftp
4. Konfiguration von wu – ftp
5. Direktiven der ftp – access – Datei
6. Zugangsbeschränkung mit /etc/ftphosts
7. Zugangsbeschränkung mit /etc/ftpusers
8. Gruppenkonfiguration mit /etc/ftpgroups
9. Konversionsdatei mit /etc/ftpconversions
10. Datenstruktur für anonymus FTP und restricted FTP
1. Grundlagen
Es gibt zwei Arten von FTP – Servern:
Der anonymus FTP – Server wird hauptsächlich genutzt, um freie Software für jeden zugänglich zu machen. Der Zugang ist anonym; das heißt, es ist nicht notwendig, einen Account auf dem Server zu haben.
Der restricted FTP – Server stellt Software nur für einen bestimmten Personenkreis zur Verfügung. Das heißt, man muss sich zuerst einen Account auf diesem Server machen, um an diese Software zu kommen.
Beide Systeme haben eins gemeinsam. Der User hat nur beschränkten Zugriff auf das
Dateisystem. Das Wurzelverzeichnis ist nämlich in ein anderes – vom Administrator
festgelegtes - Verzeichnis verschoben worden.
2. Site - Planung
Es kommt immer darauf an, welche Anforderungen man stellt bzw. welche Anforderungen der Server erfüllen soll. Bei de Planung sollte man folgende Hauptkriterien berücksichtigen.....
Bei geringen Bedarf reicht es – wenn man als Basis 30 Sessions nimmt – einen Pentium Rechner mit min. 32 MB Ram und etwa 4 GB Festplattenkapazität benutzt. Wenn die Möglichkeit der Kompression verzichtet wird, kann der Arbeitsspeicher noch weiter reduziert werden.
Wenn mehr Sessions ermöglicht 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, größere Mengen an
Arbeitsspeicher aufzunehmen. Egal, welche Konfiguration man verwendet, es ist immer darauf
zu achten, dass diese auch ohne Probleme erweiterbar ist.....
Der FTP – Server benötigt in der Regel nur ein Basisbetriebssystem ohne Compiler.
Die Möglichkeit, 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 veränderten Bereiche Read
Only gemountet werden sollte.
Die Auswahl bezieht sich immer auf die Verwendung 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 ermöglicht. Ich gehe hier näher auf den wu
– ftpd ein, da dieser der am meisten eingesetzte Daemon weltweit ist. Er besitzt
sehr große Konfigurationsmöglichkeiten und vor allem sehr gute Verwaltungstools. Des
weiteren besteht die Möglichkeit, eine interne Softwareverteilung anhand der oben
aufgeführten Gastzugänge zu ermöglichen.
3. Installation des wu – ftp
Bei einigen Linux – Distrubationen wird bereits während der Systeminstallation ein offener und anonymer FTP – Zugang eingerichtet. Man kann mit ftp – localhost überprüfen, wie der FTP – Daemon eingerichtet ist. Ein anonymer Zugang zum System ist erst mal unerwünscht, da dieser sehr unsicher ist. Das Setzen eines Passworts für den Benutzer ftp reicht nicht aus, da der Zugang an sich anonym ist. Der ftp – Daemon sucht in der Datei /etc/passwd nach dem User ftp. Wenn er diesen findet, wird eine anonyme Sitzung geöffnet. Um diesem schnell entgegenzutreten, reicht es vorerst aus, den Usernamen ftp in der /etc/passwd in z.B. wftp umzuändern. Es sollten auch immer die neusten Versionen von wu – ftp auf dem System installiert sein. Die Gründe hierzu liegen auf der Hand....
4. Konfiguration von wu - ftp
Zuerst sollte überprüft werden, ob der Daemon korrekt vom inetd aufgerufen wird. Dazu muss man lediglich die Datei /etc/inetd.conf öffnen und die Zeile, die mit ftp beginnt betrachten. Normalerweise sieht sie in etwa wie folgt aus:
ftp stream tcp nowait nobody /usr/sbin/tcpd in.ftpd -l -a
Die Bedeutungen der Felder sind:
<Name des Services><Socket Typ><Protokoll><Flags><User><Serverpfad><Argumente>
Wie man sieht, wird bei der vorhandenen Distrubation der tcp – Wrapper tcpd zwischen den inetd und den ftpd geschaltet. Des weiteren ist der User nobody. Dies ist wichtig, um das System sicher zu machen. Zur ausführlichen Beschreibung des tcp – Wrappers kommen wir später....
Hat man die Datei /etc/inetd.conf geändert, muss der inetd mit /bin/killa
–HUP inetd zu einem erneuten Einlesen seiner Konfiguration gezwungen werden. Des
weiteren müssen die Dateien ftpaccess, ftpgroups, ftphosts, ftpconversions und ftpusers
aus dem Verzeichnis ./doc/examples nach /etc kopiert werden. dadurch
wird das Verhalten des wu – ftp gezielt gesteuert.
5. Direktiven der ftpaccess - Datei
Die ftpaccess – Datei /etc/ftpaccess ist die Hauptdatei für die Konfiguration der Verhaltens von wu – ftp. Die Direktive gliedern sich in fünf Klassen:
Nicht alle Direktiven müssen bei der Konfiguration benutzt werden. bei denjenigen, die Default – Werte angegeben haben, wird die Funktion mit den Default – Werten verwendet. Darf eine Direktive mehrfach verwendet werden, ist der Status mit multi gekennzeichnet.
Hier die Direktiven im Überblick:
alias
class
guestgroup
transfers
tar
umask
autogroup
compress
limit
message
overwrite
upload
banner
delete
loginfails
noretrieve
passwd – check
viritual
cdpath
deny
commands
private
path – filter rename
chmod
shutdown
Jetzt gehen wir mal auf die einzelnen Direktive etwas näher ein….
ALIAS
Syntax: alias <string> <dir>
Klasse: misc
Status: optional
Default: kein Alias
Definiert einen Alias – String für ein Verzeichnis. Hiermit kann ein Konzept mit logischen Verzeichnissen realisiert werden. Aliasse werden nur von dem cd – Kommando ausgewertet. Beispiel:
alias honda /pub/recipies/honda
Das Problem hierbei ist, dass ein User, der vor einem anderen honda – Verzeichnis steht, in dieses mit cd ./honda wechseln muss. Abhilfe schafft man mit folgender Schreibweise: alias honda: /pub/recipies/honda
AUTOGROUP
Syntax: autogroup <groupname> <class> [<class>....]
Klasse: access
Status: optional, single
Default: kein Gruppenwechsel
Wenn ein anonymer User zu einer bestimmten Klasse gehört, kann ihm automatisch mit setgid() eine neue Gruppe zugeordnet werden. diese Gruppenname <groupname> muss ein GÜLTIGER Gruppenname aus /etc/group sein. Das kann dazu verwendet werden, nur lokalen Benutzern den Upload von Dateien zu ermöglichen.
Beispiel:
autogroup warez real, guest
Das ordnet den Benutzerklassen real und guest die Gruppe warez zu.
BANNER
Syntax: banner <path>
Klasse: infomational
Status: optional
Default: kein Banner
Bevor ein User seinen Namen und das Passwort eingibt, wird die Banner – Datei ausgegeben. Es gibt FTP – Software, die das sogenannte Multi Line Response nicht verarbeiten kann. Im schlimmsten Fall ist es dem User nicht möglich, den Server zu nutzen.
Beispiel:
banner /var/ftpd/banner.txt
Dann wird bei Verbindungsaufbau der Inhalt der Datei an den Client gesendet.
CDPATH
Syntax: cdpath <dir>
Klasse: misc
Status: optional, multi
Default: kein Suchpfad
Das definiert einen Suchpfad, der bei dem Kommando cd benutzt wird. Dieser Suchpfad ermöglicht es dem User, direkt in ein Verzeichnis oberhalb des Suchpfades zu wechseln. Die cdpath – Direktive kann mehrfach editiert werden, wobei die Reihenfolge der Auswertung von der Reihenfolge der Definition abhängig ist. Die "normale" Suchreihenfolge beim Verzeichniswechsel ist:
Die cdpath – Direktive kann dazu benutzt werden, um die Anzahl der Aliasse zu verringern. Hierzu wird ein Verzeichnis angelegt, in dem symbolische Links die leicht zu erreichenden Verzeichnisse referenzirren.
Beispiel:
cdpath /pub
cdpath /cddir
so könne alle unter /pub liegenden Verzeichnisse direkt angesprungen werden. So funktioniert auch cd linux an jeder Stelle des Servers, es sei denn, es gibt ein gleichlautendes Verzeichnis im aktuellen Verzeichnis oder einen Alias linux. In /cddir liegen die symbolischen Links auf tiefer geschalteten Verzeichnisstrukturen.
CHMOD
Syntax: chmod <yes | no> <typelist>
Klasse: permission
Status: optional, single
Default: chmod erlaubt
Es erlaubt oder verbietet die Benutzung des FTP – Kommandos chmod durch den User. Beispiel:
chmod no guest, anonymus
Es ist hier den Benutzergruppen guest und anonymus verboten, chmod auszuführen bzw. zu benutzen.
!!! In der Voreinstellung ist allen Usern das FTP – Kommando chmod erlaubt !!!
CLASS
Syntax: class <class> <typelist> <addrglob> [<addrglob>...]
Klasse: access
Status: required, multi
Default: -
Es wird eine Benutzerklasse eines bestimmten Typs und den dazugehörigen Adressen definiert. Der Klassenname kann frei vergeben werden. Es können auch Mehrfachzugehörige zu einer Klasse definiert werden. Wird jedoch vergessen, eine gültige Klasse für einen Host zu definieren, wird diesem der Zugriff verweigert. Die Typliste ist eine durch Komma getrennte Liste aus:
Wenn das Schlüsselwort real verwendet wird, kann die Klasse auf User zutreffen, die ftp auf einem realen Account machen möchten. Das Schlüsselwort anonymus trifft auf die Nutzer des anonymus FTP zu. Mit guest wird die Klasse für den beschränkten Gastzugriff eingerichtet.
Beispiel:
class local real ,guest ,anonymus *.vhonda.com
class local2 real mista.vhonda.com
class remote anonymus *
class grp1 guest *.virtual.edu
class grp2 guest *.bigdomain.mil
Die Klasse local besteht aus allen gültigen Typen, die aber nur von der Domain vhonda.com stammen dürfen. Die Klasse local2 sind reale User von einer bestimmten Maschine. Die Klasse remote ist lediglich vom Typ anonymus, aber weltweit. Die Klassen grp1 und grp2 sind vom Typ guest von virtual.edu und bigdomain.mil
COMPRESS
Syntax: compress <yes | no> <classglob> [<classglob>…]
Klasse: misc
Status: optional, single
Default: keine Kompressionsmöglichkeit
Dieser "Hauptschalter" ermöglicht, "compress on fly" zu steuern. Hierbei wird die Kompressionsmöglichkeit nur für die vorher mit der Direktive class definierten Benutzerklassen freigegeben. Die Konversionen sind in der Datei /etc/ftpconversions definiert. Im folgenden Beispiel ist allen Benutzerklassen bis auf grp2, die Datenkompression mit compress oder gzip erlaubt.
compress yes loc* remote grp1
compress no grp2
DELETE
Syntax: delete <yes | no> <typelist>
Klasse: permission
Status: optional, single
Default: Löschen erlaubt
Erlaubt oder verbietet die Benutzung des Kommandos delete durch den User. Die Typeliste besteht aus den durch Kommas getrennten Zugriffstypen anonymus, guest und real.
!!!Voreinstellung ist, dass ALLEN Usern das Kommando delete erlaubt ist!!!
Diese Zeile sollte in jeder Konfiguration enthalten sein, da diese guest und anonymus den Befehl delete verbietet.
Beispiel:
delete no guest, anonymus
DENY
Syntax: deny <addrglob> <message_file>
Klasse: access
Status: optional, multi
Default: keine Zugriffsverweigerung
Versagt immer den Zugriff für die eingetragenen Hosts und gibt die Hinweisdatei aus. Wenn das Adressfeld den String enthält, so wird allen Hosts der Zugriff verweigert, die keinen Namens – Server – Eintrag besitzen.
Beispiel:
deny nirvana.virtual.edu /var/local/msgs/not_welcome.txt
deny locals* /var/local/msgs/no_loopback.txt
deny !nameserverd /var/local/msgs/no_nameserver.txt
Die User von nirvana.virtual.edu sind nicht willkommen. Es werden auch alle
Verbindungen, mit nicht dem Namenserver bekannten Maschinen unterbunden.
Syntax: E – Mail <name>
Klasse: informational
Status: optional, single
Default: keine Mailadresse
Definiert die E – Mailadresse des FTP – Server – Verwalters. Der String name wir immer dann ausgegeben, wenn in auszugebenden Infos der Magic Cookie %E benutzt wird.
Beispiel:
email mike@vhonda.com
GUESTGROUP
Syntax: guestgroup <groupname> [<groupname>...]
Klasse: access
Status: optional, multi
Default: keine Gastgruppen
Dieser legt die Gastgruppen für die restricted – FTP – Funktion fest. Wenn also ein realer User Mitglied dieser Gruppe ist, verhält sich der FTP – Daemon analog zu der anonymus – Funktion. Das Wurzelverzeichnis wird mit chroot() verschoben und der Benutzer darf die Kommandos user und pass nicht mehr benutzen. Der Gruppenname muss ein gültiger aus der Datei /etc/group sein. Das Verzeichnis muss genauso wie das anonymus – Verzeichnis konfiguriert werden. Das Feld der Datei /etc/passwd wird in zwei Felder aufgeteilt. Das erste wird als Argument chroot() übergeben. Das zweite gibt das neue Heimatverzeichnisfeld der Datei /etc/passwd an.
Beispiel:
mike:<passwd>:50:77:restricted User:/soft/softuser/ /software:/etc/dummy
Hat sich also mike eingeloggt, verschiebt der FTP – Daemon das Verzeichnis sofort nach /soft/softuser und wechselt nach /software. Er kann jetzt nur die Verzeichnisstruktur unter /soft/softuser benutzen.
Beispiel:
guestgroup softuser softdist
Mike gehört zur Gruppe softuser und wird deswegen als guest behandelt.
LIMIT
Syntax: limit <class> <n> <times> <message_file>
Klasse: access
Status: optional, multi
Default: unbegrenzter Zugriff
Regelt den Zugriff in der Klasse auf Benutzer zu bestimmten Zeiten und gibt im Fall einer Verweigerung die mit messgage_file festgelegte Datei aus. Diese Prüfung wird nur beim Einlogen verwendet. Wenn mehrere Limit – Direktiven betroffen sind, wird die erste nutzbare gewählt. Wenn keine gültige vorhanden ist, oder das Limit auf –1 gesetzt ist, gilt uneingeschränkter Zugriff.
Beispiel:
limit remote 50 SaSu | Any 1800-0600 /var/local/ftpd/msgs/msg.toomany
limit remote 30 Any /var/local/ftpd/msgs/msg.toomany
limit local 50 Any /var/local/ftpd/msgs/msg.toomany
Diese Konfiguration lässt maximal 100 Sitzungen gleichzeitig zu. Man sollte immer eine
Obergrenze einrichten, um einen Kollaps der Maschine mangels Hauptspeicher zu vermeiden.
Laut der angegebenen Konfiguration sind Samstags, Sonntags und von 18 bis 6 Uhr 50 User
der Klasse remote zugelassen. In der anderen Zeiten sind es jedoch nur 30.
LOGINFAILS
Syntax: loginfail <number>
Klasse: access
Status: optional, single
Default: 5 vergebliche Versuche
Wenn ein User zuviel vergebliche Login – Versuche hat, wird die Verbindung
geschlossen. Im Normalfall sollten drei Versuche ausreichen.
LOG COMMANDS
Syntax: log commands <typelist>
Klasse: logging
Status: optional, single
Default: kein logging
Schaltet das Aufzeichnen durch den Benutzer verwendeter Kommandos ein. Die Typliste ist eine durch Kommas getrennte Liste von Schlüsselwörtern. Diese stellen die drei möglichen Benutzergruppen dar:
Erscheint anonymus, werden alle Kommandos beim anonymen Zugriff in die log – Datei geschrieben. Bei guest alles Kommandos dieser Gruppe und bei real die Kommandos der realen Benutzer.
!!! Damit der ftp – Daemon die log – Dateien schreiben kann, muss er
mit der Option -/ gestartet werden!!!
LOG TRANSFERS
Syntax: log transfers <typelist> <directions>
Klasse: logging
Status: optional, single
Default: kein logging
Zeichnet die Transfers der Benutzergruppen und die Transferrichtung auf. Die Schlüsselwörter, die die drei möglichen Benutzergruppen darstellen sind
Erscheint anonymus in der Liste, werden alle Transfers beim anonymen Zugriff in die log – Datei geschrieben, bei guest alle Kommandos dieser Gruppen und bei real die Transfers der realen User. Zusätzlich kann die Transferrichtung angegeben werden. die Richtung wird mit folgenden Schlüsselwörtern angegeben:
inbound ist der Transfer von Daten zum Server und outbound folglich dann
entgegengesetzt.
MESSAGE
Syntax: message <path> {<when> {<class>...}}
Klasse: informational
Status: optional, multi
Default: keine Ausgabe
Definiert einen Pfad auf eine auszugebende Datei. Diese kann beim Einloggen oder beim Wechseln des Verzeichnisses ausgegeben werden. Der <when> Parameter darf zwei Werte besitzen:
Ist LOGIN gesetzt, wird die Datei nach erfolgreichem Login ausgegeben. Bei CWD wird in dir das Verzeichnis geschrieben, bei dem das Ausgeben der Datei getriggert werden soll. Optional können auch die Benutzerklassen angegeben werden, bei denen die Datei angezeigt werden soll.
In den anzuzeigenden Dateien gibt es einige Magic Cookies, mit denen bestimmte Ersetzungen erreicht werden können:
%T Lokale Zeit
%F Freier Plattenplatz in KB des aktuellen Arbeitsverzeichnisses
%C Aktuelles Arbeitsverzeichnis
%E Email – Adresse des Server - Verwalters
%R Name des Remote - Hosts
%L Name des Local - Hosts
%u Username mit der RFC931 – Authentisierung bestimmt
%U Username zur Zeit des Logins
%M Maximal erlaubte Anzahl der User in dieser Klasse
%N Momentane Anzahl der User in dieser Klasse
Beispiel:
message /etc/msgs/welcome.msg login
message .message cwd=*
Die Datei /etc/msgs/welcoms.msg wird bei jedem Login ausgegeben. Existiert in
einem Verzeichnis die Datei .message, wird diese beim Verzeichniswechsel angegeben.
NORETRIEVE
Syntax: noretrieve <filename> <filname> .....
Klasse: access
Status: optional, single
Default: keine Downloadbeschränkung
Verhindert den Download der angegebenen Dateien. Hierbei muss zwischen absoluten
Pfadnamen und Dateinamen unterschieden werden. Relative Dateinamen wie .../group sind
nicht erlaubt. Wenn z.B. die Datei /etc/passwd geschützt werden soll, so ist als
Dateiname /etc/passwd anzugeben. Sollen aber alle Dateien geschützt werden, die passwd
heißen, darf nur passwd angegeben werden.
PRIVATE
Syntax: private <yes | no>
Klasse: access
Status: optional, single
Default: kein erweiteter Zugriffsmode
Ein genereller Schalter für die erweiterte Zugriffsmöglichkeit. Nach erfolgreichem
Einloggen kann der User mit dem Kommando SITE GROUP und SITE GPASS einen erweiterten
Zugriffsmode einer anderen Gruppe erhalten. Waren Gruppenname und Passwort gültig, wird
der User Mitglied einer Gruppe, die in /etc/ftpgroups spezifiziert ist.
README
Syntax: readme <path> {<when> {<class>}}
Klasse: Informational
Status: optional, multi
Default: kein Hinweis
Diese Direktive ermöglicht die Ausgabe eines Verweises auf die README – Datei. Die Dateien werden aber nicht ausgegeben. Die Funktion sollte daher benutzt werden, auf aktuelle Hinweisdateien in den Verzeichnissen aufmerksam zu machen. Es können mehrere Klassen angegeben werden. gibt man allerdings eine ungültige oder nicht existierende Benutzerklasse an, ist somit die ganze Zeile ungültig.
Beispiel:
readme README* login
readme README* cwd* remote local
Liegt also in /pub ein README, wird beim ersten Wechsel in dieses Verzeichnis folgende Ausgabe erscheinen:
250 – Please read the file README
250 – it was last modified on <Angabe des Datums der letzten Aktualisierung>
250 – CWD command successful.
SHUTDOWN
Syntax: shutdown <path>
Klasse: misc
Status: optional, single
Default: kein automatischer Shutdown
Wenn die referenzfierende Datei <path> existiert, prüft der Server diese regelmäßig um herauszufinden, ob der Server herunterfährt. Wenn ein Shutdown geplant ist, wird der User vorher gewarnt, neue Sitzungen werden unterbunden (deny), wenn eine vorher eingestellte Zeit abgelaufen ist, und bevorstehenden Verbindungen werden zu einer bestimmten Zeit vor dem Shutdown abgebrochen (disconnect). Die Datei muss folgende Format besitzen:
<Jahr> <Monat> <Tag> <Stunde> <Minute> <deny_offset> <disconnect_offset> <Text>
Jahr jedes Jahr ab 1970
Monat 0 bin 11
Tag nicht notwendig
Stunde 0 bis 23
Minute 0 bis 59
deny_offset In Stunden und Minuten, in der Form SSMM
disconnect_offset In Stunden und Minuten, in der Form SSMM
Text siehe die Direktive MESSAGE
Magic Cookies
%s Zeit, wann das System herunterfährt
%r Zeit, wann neue Verbindungen abgelehnt werden
%d Zeit, wann bestehende Verbindungen abgebrochen werden
Es darf nur eine shutdown – Direktive in der ftpaccess – Datei
existieren.
TAR
Syntax: tar <yes | no> <classglob> [<classglob>...]
Klasse: misc
Status: optional, single
Default: tar nicht möglich
Der Hauptschalter, um die Möglichkeit des "tar on the fly" zu steuern. Hierbei wird die Möglichkeit der Behandlung ganzer Verzeichnisbäume freigegeben. Die dazugehörenden Konversionen sind in der Datei /etc/ftpconversions definiert.
Beispiel:
tar yes loc* remote grp1
tar no grp2
Es ist also allen Benutzerklassen bis auf grp2 tar erlaubt.
OVERWRITE
Syntax: ocerwrite <yes | no> <typelist>
Klasse: permission
Status: optional, single
Default: Überschreiben erlaubt
Erlaubt oder verbietet das Überschreiben von Dateien. Die Typliste besteht wieder durch die Kommas getrennten Zugriffstypen anonymus, guest und real.
Beispiel:
overwrite no guest, anonymus
Es ist den Benutzergruppen guest und anonymus das Überschreiben von Dateien verboten.
!!!Grundeinstellung ist, dass allen Benutzern das Überschreiben ERLAUBT ist!!!
PASSWD – CHECK
Syntax: passwd – check <none | trivial | rcf822> (<enforce | warn>)
Klasse: permission
Status: optional, single
Default: kein Passwortcheck, der Use wird immer eingeloggt
Sie legt den Level <none | trivial | rfc822> und die "Härte" <enforce | warn> der Passwortprüfung bei anonymen Logins fest. Die verschiedenen Möglichkeiten des ersten Arguments sind:
none Keine Überprüfung des Passworts
Trivial Das Passwort muss ein "@" enthalten
Rcf822 Das Passwort muss eine nach rcf822 gültige Adresse sein
Die Härte der Fehlerbehandlung legt das zweite Argument fest:
warn Der User wird gewarnt, ihm aber erlaubt, sich einzuloggen
enforce Der User wird gewarnt und anschließend ausgelohht
Beispiel:
passwd – check rcf822 enforce
Hier ist die härteste Passwortprüfung aktiviert.
PATH – FILTER
Syntax: path-filter<typelist><mesg>allowed_charset>{<disallowed reg-exp>…}
Klasse: permission
Status: optional, mulit
Default: alle Dateinamen erlaubt
Für die Benutzerlisten definiert path – filter mit regulären Ausdrücken <allowed_charset>, wie ein gültiger Dateiname auszusehen hat und wie nicht. Falls der Dateiname basierend auf den regulären Ausdrücken ungültig ist, wird eine Datei <mesg> ausgegeben.
Beispiel:
path – filter anonymus /etc/msgs/funnyname ^[ -A –Za –z0 – 9\ . ] *$ ^\ . ^- ^ =
Die Dateinamen von anonymen Benutzern dürfen mit Buchstaben, Ziffern, dem Punkt und
dem Bindestrich beginnen.
RENAME
Syntax: rename <yes | no> <typelist>
Klasse: permission
Status: optional, single
Default: Umbenennen erlaubt
Es wird die Benutzung des Kommandos rename durch den User erlaubt oder verboten. Es wird wieder zwischen den Zugriffstypen anonymus, guest und real unterschieden.
Beispiel:
Rename no guest, anonymus
Es ist also den Benutzergruppen guest und anonymus verboten, den Befehl rename auszuführen.
!!! Grundeinstellung ist, dass allen Usern das Kommando rename erlaubt ist !!!
UMASK
Syntax: umask <yes | no> <typelist>
Klasse: permission
Status: optional, single
Default: Setzen einer Maske erlaubt
Ermöglicht oder verbietet die Benutzung des Befehls umask.
Beispiel:
Umask no guest, anonymus
Es ist also den Benutzergruppen guest und anonymus verboten, den FTP
– Befehl umask auszuführen.
UPLOAD
Syntax: upload <root-dir><dirglob><yes | no><owner><group><mode[dirs | nodirs]
Klasse: permission
Status: optional, multi
Default: Upload erlaubt
Definiert ein Verzeichnis mit einer Namensexpansion, dass den Upload von Dateien ermöglicht oder verbietet. Wird der Upload ermöglicht, gehören alle Dateien dem Besitzer aus <owner> und der Gruppe aus <group>. Diese haben dann den Zugriffsmodus aus <mode>. Das letzte Argument ermöglicht das Anlegen von Verzeichnissen mit dem Kommando mkdir zu sperren oder zu erlauben. Die Uploaddirektive betrifft nur die User, die ein Heimatverzeichnis haben, dass <root – dir > entspricht.
Beispiel:
upload /home/ftp /pub/incoming yes ftpadm nobody 0400 nodirs
upload /home/ftp /bin no
upload /home/ftp /cddir no
upload /home/ftp /etc no
upload /home/ftp /lib no
upload /home/ftp * no
In allen Verzeichnissen außer /pub/incoming ist der Upload von Dateien erlaubt.
Dateien die in /pub/incoming abgelegt werden, haben den User ftpadm, die
Gruppe nobody, den Mode 0400 (- r-------) und dürfen keine Verzeichnisse
sein.
VIRTUAL
Syntax: virtual <adress> <root | banner | logfile> <path>
Klasse: misc
Status: optional, multi
Default: keine virtual – Host – Unterstützung
Regelt die Benutzung von virtuellen Server – Adressen, wobei die Adresse <adress>
die IP – Adresse des Servers darstellt. Das zweite Argument ermöglicht die
Festlegung der Referenzierung durch <path>. Entweder zeigt der Pfad auf das
Wurzelverzeichnis des Servers <root>, auf die Bannerdatei <banner>
oder auf die Transfer – log – Datei <logfile>. Falls die Transfer
– log – Datei nicht angegeben wurde, wird die Default – Datei verwendet.
Alle anderen Message – Dateien und Zugriffsbeschränkungen der ftpaccess
– Datei werden grundsätzlich von allen virtuellen Servern benutzt.
6. Zugangsbeschränkung mit /etc/ftphosts
In dieser Datei kann der Zugriff eingestellt werden. hier steht allerdings mehr die Möglichkeit im Vordergrund, reale User zu konfigurieren. Für die Namensauflösung gilt mit einer Einschränkung dasselbe wie bei der ftpaccess – Direktive class. Ein Stern als Wildcard beschreibt nicht den ganzen Hostnamen. Der Stern ersetzt nur die Werte zwischen den Punkten.
Beispiel:
# host access file
#
# Everything after a ‘#’ is treated as comment.
#empty lines are ignored
allow mat nirvana.virtual.edu
allow mike *.vhonda.com
deny fred mista.vhonda.com 126.127.128.*
Mike, der Serververwalter, darf von allem Maschinen der Domian vhonda.com
auf den FTP –Server ftp machen. Fred hat mehrfach versucht, sich als root
einzuloggen. Daraufhin wird ihm der Zugriff von seiner Domain verweigert. Da er aber oft
bei seinem Freund Mat ist, ist der Zugriff auch für ihn eingeschränkt. Hingegen
darf Mat von dem Rechner seiner Domain auf den Server unter seinem Account
zugreifen.
7. Zugriffsbeschränkung mit /etc/ftpusers
Alle Benutzer, die in /etc/ftpusers aufgelistet sind, dürfen kein ftp
von außen auf den Server machen. Im allgemeinen werden hier die Systemuser eingetragen.
Hierdurch wird das Einschleusen von Trojanern erschwert.
8. Gruppenkonfiguration mit /etc/ftpgroups
Das Wechseln der Gruppe wird eher selten benötigt. Es ist die Einführung einer neuen Datei mit Passwörtern auch nicht ganz einfach. Bei anonymus FTP muss diese Datei sogar wurzelverschobenen /etc – Verzeichnis liege. Deswegen sollte man bei der Benutzung der Gruppen die ftpaccess – Datei sehr sorgfältig konfigurieren. Ein Passwortwechsel ist mit sehr viel Kopfarbeit verbunden, zu dem auch noch der Test des Passworts kommt.
Beispiel:
# ftpgroup file
#
# Everything after a # is treated as comment.
# empty lines are ignored
softadm:<password>:softdist
Der reguläre User softadm hat die Gruppe softuser. Bei der
Zusammenstellung von Software ist aber auch bei ftp die Gruppe softdist notwendig,
was der obige Eintrag ermöglicht.
9. Konversionsdatei /etc/ftpconversions
In dieser Datei werden die Zusammenhänge für tar und compress "on
the fly" festgelegt. Bei großen Servern ist auch gzip mit maximaler
Kompression wegen des hohen Ressourcenverbrauchs problematisch. Hier sollte man die
Defaultwerte überarbeiten um den entgegenzuwirken. Man kann auch die Endung .tgz
anfügen. Ob die Möglichkeiten der Konversion noch weiter entwickelt werden, ist
allerdings noch fraglich. Das Dateiformat ist aber auf jeden Fall schon für weitere
Möglichkeiten vorbereitet.
10. Datenstruktur für anonymus FTP und restricted FTP
Nachdem die Konfiguration der verschiedenen Files abgeschlossen ist, muss die Datenstruktur für das wurzelverschobene ftp angelegt werden. Zuerst sollten die Gruppeneinträge in /etc/groups erzeugt werden. für anonymus FTP sollte eine eigene Gruppe zur Verfügung stehen. Praktischerweise nennt man diese auch ftp. Diese Gruppen für restricted FTP hat man ja bereits in der ftpaccess – Datei festgelegt. Das waren die Gruppen softuser und softdist. Hierzu sollte der passenden Usereintrag für anonymus FTP in /etx/passwd und für restricted FTP angelegt werden.
Nun fehlen lediglich noch dir Verzeichnisstruktur und die wenigen Binaries im (verschobenen) /bin – Verzeichnis.
Eine Minimalstruktur kann wie folgt aussehen:
| - - d - -x - - x - - x bin
| | - - - - - x - - x - - x compress
| | - - - - - x - - x - - x gzip
| | - - - - - x - - x - - x ls
| ‘ - - - - - x - - x - - x tar
| - - d - - x - - x - - x cddir
| - - d - - x - - x - - x etc
| | - - - - r - - r - - r - - group
| ‘ - - - - r - - r - - r - - passwd
‘ - - drwxr – xr – x pub
Alle Verzeichnisse und Files bis auf pub gehören root. Werden in bin statisch gebundene Programme verwendet, so kann auf ein lib – Verzeichnis mit der libc und dem ld verzichtet werden. das Verzeichnis pub gehört nicht root, sondern einem User ftpadm mit der Gruppe nobody. Dieser User ist der Administrationsuser, der auch ein Heimatverzeichnis auf dem Server hat. Das Verzeichnis pub wird natürlich nur für anonymus FTP benötigt, für restricted FTP wird statt dessen ein Verzeichnis software angelegt. Es sind auch die Permissions der Verzeichnisse und der Files zu beachten. Nur pub hat weitergehende Permissions, um den FTP – Administrator die Arbeit zu erleichtern. Im public – Zweig müssen aber für die Welt schreibbare Directories und Files vermieden werden.
Arbeiten mehrere Administratoren an einem Verzeichnisbaum, muss dies über die Gruppenrechte geregelt werden. weil der pub – bzw. der software – Baum nicht root gehört, ist eine Personalunion von FTP – Administrator und root nicht unbedingt notwendig. Es ist außerdem wichtig, dass die Dateien in etc/passwd und etc/group nur die notwendigsten Einträge enthalten und vor allem keine Passwörter.
So enthält etc/passwd (nicht /etc/passwd) lediglich:
root : * : 0 : 0 :::
ftpadm: * : 504 : 99 :::
und etc/group:
root : : 0 :
nobody : : 99:
Bei restricted FTP möchte man meistens, dass der User ftp machen kann, sich aber nicht regulär einloggen darf. Die erreicht man durch den Shell – Eintrag /etc/dummy in das Shell – Feld der Users und durch den Eintrag von /etc/dumy in /etc/shells. Der FTP – Daemon wertet /etc/shells aus. Alle gültigen Shells, die von realen Benutzern verwendet werde, müssen hier eingetragen sein. Will man Fehlermeldungen bei Einlog – Versuchen von restricted Benutzern vermeiden, kann man folgenden dummy in /etc installieren:
/* dummy shell */
#include <stdio.h>
void main (void)
{
fprintf (stderr,"\n Sorry, no permission to log in! \n \n");
}
Die Datei wird kompiliert und installiert mit:
cc –s -static dummy.c -o dummy
install –m 755 -o root -g sys dummy /etc
Damit ist die Installation vollständig abgeschlossen. Der FTP – Administrator muss sich lediglich mirror und die dazugehörenden Skripte konfigurieren.
Um Transferauswertungen zu erstellen, kann das Programm ~/util/xferstats
verwendet werde. Die Programme ftpcount(1) und ftpwho(1) sind nützlich, um
den aktuellen Status des Servers festzustellen.
Sollten noch Fragen auftauchen, auf die hier nicht eingegangen worden ist, schreibt mir einfach ne Mail, und ich wird sehen, ob ich euch helfen kann.
Schaut aber bitte zuerst bei folgenden Links nach, ob das Problem nicht schon beschrieben ist....