Forums d'entraide informatique - Astuces - Conseils

Configuration avancée
de proftpd
Pour l'heure, nous n'avons pas fait grand-chose par rapport à l'installation de base
du serveur FTP. Les paramètres que nous avons détaillés dans l'article précédent sont tous déjà définis dans le fichier de configuration par défaut. A présent, nous connaissons suffisamment la syntaxe du fichier de configuration pour nous attaquer à des situations plus poussées.
TP
Bon nombre de serveurs FTP publics mettent à dis- position des fichiers, mais permettent également que les utilisateurs anonymes puissent envoyer des fichiers sur le serveur. On voit alors apparaître un répertoire incoming prévu à cet effet.
La mise en place de ce type de fonctionnalité ne présente pas de difficultés particulières. Il suffit en effet de spécifier des permissions particulières pour le répertoire en question à l'aide des <Lirait>. Nous définissons donc, dans un premier temps. une inter- diction d'écriture sur le serveur pour les connexions anonymes :
<Directory *> <Limit WRITE> DenyAll
</Limit>
</Directory>
puis, nous redéfinissons de nouvelles permissions pour un répertoire en particulier (incoming) <Directory incoming>
<Limit READ>
DenyAll
</Limit>
<Limit STOR>
AllowAll
</Limit>
</Directory>
Nous avons ici deux <Lirait>. La première permet d'interdire la lecture dans le répertoire incoming afin que les utilisateurs anonymes ne puissent pas se servir de ce répertoire comme lieu d'échange de fichiers. La seconde autorise le stockage d'un fichier en provenance d'un client vers le serveur.
Note : N'oubliez pas que les permissions sur le sys- tème de fichiers du serveur prennent toujours le pas
sur les directives du fichier de configuration. Lorsque vous allez créer le répertoire incoming, assurez-vous qu'il appartienne ensuite à l'utilisateur f tp nogroup et non, par exemple, au root. En cas contraire, les directives du fichier de configuration ne serviraient à rien. Le répertoire appartenant à un autre utilisateur, le démon proftpd ne pourrait y accéder en écriture et les tentatives d'upload de fichiers aboutiraient à l'échec.
Ainsi, les utilisateurs anonymes peuvent envoyer des fichiers et non les lire
denis@morgane:- # ftp egon
Connected ta egon.
220 ProFTPD 1.2.0prel0 Server (Egon World) [egon] Name (egon:denis): anonymous
331 Anonymous login ok, send your complete e-mail address as password.
Password:
230-Welcome, archive user anonymous@morgane ! 230-
230-The local time is: Mon Jan 21 15:12:44 2002 230-
230-This is an experimental FTP server. If have any unusual problems,
230-please report them via e-mail ta <root@egon>. 230-
230 Anonymous access granted, restrictions apply. Remote system type is UNIX.
Using binary mode ta transfer files.
ftp> cd incoming
250 CWD command successful.
ftp> put ecole.pdf
local: ecole.pdf remote: ecole.pdf
200 PORT command successful.
150 Opening BINARY mode data connection for ecole.pdf.
226 Transfer complete.
263461 bytes sent in 0.321 secs (8e+02 Kbytes/sec)
ftp> get ecole.pdf
local: ecole.pdf remote: ecole.pdf 200 PORT command successful.
550 ecole.pdf: Permission non accordée ftp> 221 Goodbye.
Selon le serveur et le but dans lequel vous le déployez, ce type de fonctionnement peut être suffi- sant. Si, par exemple, votre serveur FTP met à la disposition de tous des images ou des applications que vous développez, les visiteurs peuvent vous envoyer des contributions (code, images, doc, etc.) dans le répertoire incoming. Vous n'avez pas besoin alors de créer des comptes utilisateurs permettant un accès en écriture pour certains visiteurs ou cer- taines classes de visiteurs. La bonne solution est alors de restreindre davantage l'accès en n'autori- sant tout simplement pas les connexions de la part d'utilisateurs réellement existants sur le système.
Pour cela, il nous suffit d'ajouter deux limitations. Tout d'abord, en dehors de la définition du serveur anonymous, nous interdisons l'accès
<Limit LOGIN> DenyAll
<Limit>
Ainsi, en principe, plus personne ne peut se loguer en FTP sur le serveur. A l'intérieur de la portée de la configuration du serveur anonymous, nous pla- çons une directive inverse :
<Limit LOGIN>
AllowAll
<Limit>
Comme ces dernières lignes se trouvent dans la por- tée de <Anonymous -ftp>, elles ne concernent que les connexions anonymes. Si un utilisateur du systè- me tente de se connecter au serveur en FTP, il sera traité comme un utilisateur inexistant ou dont le mot de passe n'est pas valide
denis@morgane:- # ftp egon
Connected to egon.
220 ProFTPD 1.2.0prel0 Server (Egon World) [egon] Name (egon:denis): moi
331 Password required for moi.
Password:
530 Login incorrect.
Manipulation avancée cies répertoires
L'organisation est une chose fort intéressante, elle permet de travailler plus vite et de retrouver plus facilement ses affaires. Ceci est valable pour bien des domaines et pour un serveur FTP également. Organiser un serveur peut se faire très simplement si vos besoins ne sont pas importants. mais peut rapidement devenir une tâche fastidieuse si vous souhaitez structurer votre serveur de manière très propre.
La convention veut que le répertoire habituellement destiné à recevoir des fichiers soit appelé incoming. De la même manière, la plupart des serveurs FTP de la planète ne mettent pas les fichiers à disposi- tion à la racine. On crée alors un répertoire pub qui contiendra des sous-répertoires par types de fichiers diffusés. Jetez un oeil à des serveurs existants depuis fort longtemps, comme ftp.lip6.fr pour vous forger une idée de la chose.
En plus de la rigueur qui est naturellement la vôtre en ce qui concerne l'organisation des données (?), proftpd vous offrira quelques facilités intéressantes. L'une d'entre elle est de permettre un accès direct à certains répertoires en fonction du nom d'utilisateur employé pour la connexion au serveur.
Imaginez les alias suivant pour l'utilisateur ftp : UserAlias    anonymous ftp
UserAlias    ftpl ftp
UserAlias    ftpi ftp
UserAlias    ftpf ftp
UserAlias    ftpv ftp
Nous conservons anonymous par souci de compa- tibilité avec les navigateurs Web, mais nous ajou- tons quatre nouveaux alias. Ceux-ci sont destinés à être utilisés pour les accès aux archives de, respecti- vement, logos, images, fond d'écran et vidéos.
Note : On regrettera ici le fait de ne pas pouvoir définir plusieurs alias sur une seule ligne. En effet, la directive UserAlias ne prend en argument, dans l'ordre, qu'un alias suivi d'un nom d'utilisateur valide. Ensuite, nous allons créer quatre répertoires du même nom dans /home/ftp. Enfin, nous ajouterons dans notre fichier de configuration (à l'intérieur de la
portée du serveur anonymous) la ligne suivante : UserDirRoct    on
Dès le redémarrage du démon, un utilisateur se loguant sous anonymous ou ftp arrivera sur un serveur chrooté dans /home/ ftp. En revanche, si par exemple il utilise f tpl, il arrivera sur un serveur chrooté dans /home/ ftp/ ftpl.
Gestion des utilisateurs
Une autre forme d'organisation est, bien sûr, la gestion des utilisateurs. Même dans le cas d'un serveur offrant un accès public. il peut être bienvenu qu'un certain nombre de personnes soient autorisées à manipuler certains fichiers et répertoires sur le serveur.
Il n'est pas nécessaire pour autant qu'il s'agisse d'utilisateurs ayant la permission de se loguer sur le système à distance ou même localement. De plus, même si l'utilisateur possède effectivement un compte sur la machine, il n'est pas nécessaire que son répertoire personnel soit automatiquement celui auquel il accède en FTP.
Prenons un exemple concret pour clarifier tout cela. Prenons le cas selon lequel nous avons installé un serveur FTP anonymous destiné à partager certains travaux d'un groupe. Les membres du groupe sont denis et moi. Ces deux utilisateurs partagent publiquement des fichiers sur le serveur FTP. Ces fichiers sont récupérables par n'importe quel visiteur anonyme mais seuls nos deux membres peuvent modifier les données en question à distance.
Nous choisissons donc de créer à la racine du serveur FTP un répertoire pour chaque utilisateur légitime. Nous avons donc dans /home/ ftp :
drwxr-xr-x    5 ftp    nogroup    4096 jan 22 10:05    ./
dn.,xrwsr-x    5 root    staff    4096 jan 21 19:05    .»
drwxr-xr-x    2 denis    denis    4096 jan 22 10:05 denis/
drwxr-xr-x    2 ftp    nogroup    4096 jan 21 19:12 incoming/
drwxr-xr-x    2 moi    usera    4096 jan 22 09:59 moi/
r    r    1 root    roc):    166 fév 24    2001 welcome.msg
Vous remarquerez les permissions sur les répertoires en question. Les utilisateurs ont toutes les permissions sur leurs répertoires alors que les autres peuvent uniquement y entrer et lire le contenu.
A présent. passons au fichier de configuration. Notre section <Anonymous -ftp> contiendra ceci :
<Anonymous -ftp> User ftp
Groupnogroup
UserAlias    anonymous ftp
RequireValidShe11 off
MaxClients 10 DisplayLoginwelcome.msg
DisplayFirstChdir .message
<Directory *> <Limit WRITE>
DenyAll </Limit>
</Directory> <Directory incoming>
<Limit READ WRITE>
DenyAll </Limit>
<Limit STOR> AllowAll </Limit>
</Directory> </Anonymous>
En dehors de la portée de <Anonymous -ftp> nous ajoutons :
RequireValidShell    off
DefaultRoot    /home/ftp
DefaultChdir /home/ftp
C'est surtout cette dernière ligne qui est très importante. Elle nous permet de désactiver le fait que, par défaut, un utilisateur légitime du système arrive directement dans son répertoire personnel. Ici, nous l'envoyons directement à la racine du serveur FTP anonyme et la directive DefaultRoot l'empêche de remonter dans l'arborescence.
Les permissions données sur les répertoires des utilisateurs interdisent aux utilisateurs anonymes d'écrire dans les répertoires en question. Nous n'avons donc pas besoin de spécifier le Limit pour configurer ce point. Le résultat est exactement ce que nous souhaitions. Les utilisateurs denis et moi peuvent allègrement modifier, ajouter et supprimer des fichiers dans les répertoires /home/ ftp/denis et /home/ ftp/moi, tout en autorisant les visiteurs anonymes à récupérer les fichiers qui s'y trouvent.
Imaginons à présent que l'utilisateur responsable du serveur FTP ait pour tâche d'éviter que des données légalement douteuses soient diffusées par les utilisateurs denis et moi via leur répertoire. Il faut alors

qu'il possède la permission de supprimer des fichiers dans ces répertoires. Le problème qui se pose est le suivant : il s'agit de permettre à denis et moi d'écrire dans leur répertoire respectif tout en permettant à un utilisateur que nous appellerons master de faire de même dans les mêmes réper- toires. Bien sûr, il ne faut pas que denis puisse écrire dans le répertoire de moi et inversement.
Nous ne pouvons plus nous baser sur les permis- sions Unix car, même en utilisant un groupe com- mun, nous n'arriverions pas au résultat escompté. Voilà un travail pour le système de permissions de proftpd. Dans un premier temps, les répertoires en question n'appartiendront plus aux utilisateurs légi- times mais à ftp.nogroup :
drwxr-xr-x    5 ftp    nogroup    4096 jan 22 10:05    . /
drwxrwsr-x    6 root    staff    4096 jan 22 10:59    /
cirvacrwrrwx    2 fty    nogroup    4096 jan 22 10:05 denis/
drwxr-xr-x    2 ftp    nogroup    4096 jan 21 19:12 incoming/
drvoulamoc    2 ftp    nogroup    4096 jan 22 11:03 moi/
r    r    1 root    root    166 fév 24    2001
            welcome.msg
Nous changeons également les permissions afin de permettre à tous les utilisateurs d'écrire, de lire et de parcourir ces répertoires. Sans modification du fichier de configuration, n'importe qui pourrait maintenant faire ce qu'il désire dans ces répertoires. Nous nous empressons donc d'ajouter les lignes sui- vantes dans le fichier de configuration de proftpd (en dehors de la section du serveur anonymous):
<Directory /home/ftp/moi> <Limit WRITE>
DenyUser !master,!moi </Limit>
</Directory>
<Directory /home/ftp/denis> <Limit WRITE>
DenyUser !master,!denis </Limit>
</Directory>
Nous utilisons un 'Arrdt pour chacun des réper- toires concernés et faisons usage d'une directive nouvelle : DenyUser. Celle-ci permet, à l'instar de DenyAll, d'interdire l'action spécifiée par le mar- queur Limit, à la différence qu'elle prend en argu- ment un ou plusieurs noms d'utilisateurs. Le ! est le
signe de la négation, notre restriction définit donc une interdiction en écriture dans les répertoires pour tous les utilisateurs excepté le responsable du serveur (master) et l'utilisateur du répertoire en question.
Nous aurions également pu utiliser les lignes sui- vantes
<Directory /home/ftp/moi> <Limit WRITE>
DenyAll
<,Limit>
</Directory>
<Directory /home/ftp/moi> <Limit WRITE>
AllowUser master,moi
</Directory>
Vous conviendrez que la première syntaxe est beau- coup plus concise et facilite la maintenance. Le résultat est le suivant
•    Les utilisateurs anonymes peuvent lire et récupérer le contenu des répertoires moi et denis.
•    Les utilisateurs moi et denis peuvent écrire dans leur répertoire respectif uniquement.
•    L'utilisateur master possède un droit d'écriture dans les répertoires moi et denis.
Comme vous le voyez, l'organisation des permissions et des répertoires n'est pas une tâche complexe pour peu que l'on s'attarde posément sur nos besoins.
Surveiller le serveur
proftpd comme bien des démons serveurs permet l'archivage des journaux d'activité. Ces journaux sont une partie importante de la gestion des serveurs. Ils permettent de résoudre les problèmes de configuration, de surveiller l'activité et la popularité de vos serveurs et surtout, ils sont la principale source de renseignement en cas de problème de sécurité ou d'attaque externe.
Par défaut, en l'absence de configuration spécifique, proftpd est peu bavard. Les informations envoyées dans le syslog se limitent à ceci :