Différences
Ci-dessous, les différences entre deux révisions de la page.
| Les deux révisions précédentesRévision précédente | |||
| logiciel:reseau:ftp:serveur:vsftpd:exemples:start [2024/09/21 13:41] – supprimée - modification externe (Unknown date) 127.0.0.1 | logiciel:reseau:ftp:serveur:vsftpd:exemples:start [2024/09/21 13:41] (Version actuelle) – ↷ Page déplacée de logiciel:reseau:transfert:serveur:vsftpd:exemples:start à logiciel:reseau:ftp:serveur:vsftpd:exemples:start admin | ||
|---|---|---|---|
| Ligne 1: | Ligne 1: | ||
| + | {{tag> | ||
| + | ====== Vsftpd : cinq exemples de configuration ====== | ||
| + | |||
| + | ===== Une configuration classique ===== | ||
| + | |||
| + | Supposons que vous souhaitez mettre en place un serveur de fichiers, accessible à tous (par exemple par Internet). Votre fichier vsftpd.conf pourrait alors ressembler à ceci : | ||
| + | |||
| + | < | ||
| + | listen=YES | ||
| + | max_clients=200 | ||
| + | max_per_ip=4 | ||
| + | anonymous_enable=YES | ||
| + | local_enable=NO | ||
| + | write_enable=NO | ||
| + | anon_upload_enable=NO | ||
| + | anon_mkdir_write_enable=NO | ||
| + | anon_other_write_enable=NO | ||
| + | anon_world_readable_only=YES | ||
| + | connect_from_port_20=YES | ||
| + | hide_ids=YES | ||
| + | pasv_min_port=50000 | ||
| + | pasv_max_port=60000 | ||
| + | xferlog_enable=YES | ||
| + | ls_recurse_enable=NO | ||
| + | ascii_download_enable=NO | ||
| + | async_abor_enable=YES | ||
| + | one_process_model=YES | ||
| + | idle_session_timeout=120 | ||
| + | data_connection_timeout=300 | ||
| + | accept_timeout=60 | ||
| + | connect_timeout=60anon_max_rate=50000 | ||
| + | Examinons-le en détail : | ||
| + | listen=YES | ||
| + | </ | ||
| + | |||
| + | Le serveur est positionné en mode standalone, ce qui est normal puisqu’il sera a priori sollicité fréquemment. | ||
| + | |||
| + | ? max_clients=200 | ||
| + | : 200 clients simultanés sont acceptés. Les autres recevront un message d’erreur jusqu’à ce qu’une place se libère. De la sorte, le serveur ne sera pas saturé par les requêtes. | ||
| + | ? max_per_ip=4 | ||
| + | : Chaque client ne pourra ouvrir que 4 connexions simultanées. Il n’y aura donc pas de client qui saturera la bande passante. | ||
| + | ? anonymous_enable=YES | ||
| + | : Nous autorisons les connexions anonymes, ce qui est normal puisque le serveur est public. | ||
| + | ? local_enable=NO | ||
| + | : Nous refusons les connexions d’utilisateurs dotés de compte sur la machine. Seules les connexions anonymes seront donc acceptées. Soyons clair : l’idée ici n’est pas d’empêcher vos utilisateurs locaux chéris de se connecter, mais de prévenir des hacks faciles utilisant les comptes standards présents sur toute machine digne de ce nom, comme Apache, gdm ou autre lp. | ||
| + | ? write_enable=NO | ||
| + | : Personne ne modifie de fichier ni n’écrit sur notre serveur. | ||
| + | ? anon_upload_enable=NO | ||
| + | : Les utilisateurs anonymes (donc les utilisateurs du serveur) ne peuvent pas uploader de fichier. | ||
| + | ? anon_mkdir_write_enable=NO | ||
| + | : Les utilisateurs (anonymes) ne peuvent pas non plus créer de répertoire. | ||
| + | ? anon_other_write_enable=NO | ||
| + | : Les utilisateurs (anonymes) ne peuvent pas non plus renommer ni supprimer ni fichier ni répertoire. | ||
| + | ? anon_world_readable_only=YES | ||
| + | : Les utilisateurs (anonymes) ne peuvent télécharger que les fichiers accessibles en lecture à tous. | ||
| + | ? connect_from_port_20=YES | ||
| + | : Nous acceptons les connexions depuis le port 20 (notre éventuel firewall laisse ce port passer). | ||
| + | ? hide_ids=YES | ||
| + | : Tous les fichiers et répertoires du serveur sont montrés comme appartenant à FTP. | ||
| + | ? pasv_min_port=50000, | ||
| + | : En mode passif, les ports acceptés sont dans la tranche 50000 à 60000. Tous les autres sont refusés sur le serveur et sans doute aussi sur le firewall. Qu’est-ce que cette chose-là ? Le mode passif est celui dans lequel le client, au lieu d’envoyer au serveur le numéro du port à partir duquel il souhaite que le serveur envoie les données, envoie PASV, laissant passivement le serveur décider quel port utiliser pour l’envoi de données, habituellement le port 20.\\ Cette directive est par défaut sur Yes, le mode passif est possible (ce qui est souvent nécessaire lorsqu’un firewall est présent avant le serveur. Le mode actif permet en revanche au client d’avoir la certitude, puisque c’est lui qui décide du port, que les données qu’il reçoit correspondent bien à sa demande initiale). | ||
| + | ? xferlog_enable=YES | ||
| + | : Nous logons les transferts. | ||
| + | ? ls_recurse_enable=NO | ||
| + | : Nous interdisons l’option -R de “ls -R”, qui consomme trop de ressources machine. | ||
| + | ? ascii_download_enable=NO | ||
| + | : Nous n’envoyons pas les fichiers en mode ASCII. | ||
| + | ? async_abor_enable=YES | ||
| + | : Nous acceptons la commande async ABOR, pour certains de nos clients qui en ont besoin (qui ? Nous ne savons pas, mais le serveur est public donc nous ne savons pas quel client FTP utilisera notre visiteur).\\ A quoi sert cette directive étrange ? Elle permet d’activer la commande FTP async ABOR, qui permet de stopper un téléchargement asynchrone en cours. Elle est considérée comme complexe et inélégante, | ||
| + | ? one_process_model=YES | ||
| + | : Si vous disposez d’un noyau 2.4 sous Linux, vous pouvez en activant cette fonction générer un processus par connexion. Il s’agit là d’une option moins " pure " en termes de sécurité, mais qui permet une performance parfois meilleure.\\ N’activez cette fonction, par défaut sur No, que si vous savez ce que vous faites et ce que ce changement implique et par ailleurs seulement si votre site reçoit un grand nombre de connexions simultanées.\\ C’est peut-être le cas pour ce serveur, nous l’activons et monitorerons naturellement la charge qu’elle provoquera. | ||
| + | ? idle_session_timeout=120 | ||
| + | : Nous acceptons 120 secondes d’inactivité de la part du client, au-delà il est rejeté pour laisser la place à un autre. | ||
| + | ? data_connection_timeout=300 | ||
| + | : Si un transfert est gelé pendant plus de 300 secondes, nous considérons que le client est déconnecté ou en échec et clôturons la session pour laisser la place à un autre. | ||
| + | ? accept_timeout=60 | ||
| + | : Nous donnons 60 secondes à un client en mode passif pour établir sa connexion. Au delà, nous clôturons pour laisser la place à un autre (60 secondes est largement assez, sauf si le client rencontre un problème important, qui handicapera de toutes les façons son transfert). | ||
| + | ? connect_timeout=60 | ||
| + | : Nous donnons le même délai au client qui se connecte en mode PORT. | ||
| + | ? anon_max_rate=50000 | ||
| + | : Nous autorisons un débit maximal de 50000 octets par seconde (49 ko/s) pour les clients. | ||
| + | |||
| + | ===== Deuxième configuration : filtrage par adresses IP ===== | ||
| + | |||
| + | Dans ce scénario, votre serveur héberge des documents que vous voulez mettre à la disposition d’une partie de votre réseau (par exemple le département comptabilité), | ||
| + | |||
| + | Votre patron vous demande en plus " quelques petits ajustements ", qui consistent à lui donner, à lui tout seul, des possibilités de download spéciales et privilégiées et de réduire les possibilités des stagiaires, qui ont tendance, c’est bien connu, à abuser du système... Vsftpd sait s’appuyer sur tcp_wrappers pour autoriser ou refuser une ou plusieurs adresses IP et appliquer une configuration spécifique. | ||
| + | |||
| + | ==== Support de tcp_wrappers ==== | ||
| + | |||
| + | Cette opération suppose que vsftpd ait été construit avec le support de tcp_wrapper, | ||
| + | |||
| + | Tcp_wrapper étant activé, il faut indiquer à vsftpd que nous souhaitons nous appuyer sur lui pour le filtrage. Ceci se fait en ajoutant dans / | ||
| + | |||
| + | ==== Définition d’une politique de filtrage ==== | ||
| + | |||
| + | Reste alors l’étape la plus importante, la création de la politique de filtrage dans tcp_wrapper. | ||
| + | Elle se fait au travers de deux fichiers / | ||
| + | |||
| + | Éditons donc / | ||
| + | vsftpd: 10.0.0.99: setenv VSFTPD_LOAD_CONF / | ||
| + | vsftpd: 10.0.1.: DENY | ||
| + | vsftpd: 10.0.72.0/ | ||
| + | vsftpd: .compta.maboite.com: | ||
| + | |||
| + | Vous voyez d’un coup d’œil le principe. Chaque ligne définit une règle, qui précise une cible (une adresse, un domaine), pour laquelle on utilisera un fichier de configuration spécifique. Brillant de simplicité, | ||
| + | |||
| + | Ainsi, la première ligne décide que, pour l’adresse IP 10.0.0.99 (celle du patron), nous utiliserons pour vsftpd le fichier de configuration / | ||
| + | * max_clients= 0 (le patron ouvre autant de connexions simultanées qu’il veut) ; | ||
| + | * max_per_ip= 0 (dans ce cas, puisqu’il n’y a qu’une IP, c’est la même chose) ; | ||
| + | * local_enable=Yes (le patron se connectera avec son compte local) ; | ||
| + | * chroot_local_user= No (le patron n’est pas chrooté, c’est le comportement par défaut de cette directive, mais pourquoi ne pas le rappeler) ; | ||
| + | * write_enable=Yes (le patron peut écrire) ; | ||
| + | * local_max_rate=0 (débit illimité pour le patron) ; | ||
| + | * ftpd_banner=Prenez tout ce qu’il vous faut et n’oubliez pas mon augmentation. | ||
| + | |||
| + | D’autres aménagements sont bien sûr possibles, relisez la liste des options étendues que nous citons en référence et l’inspiration viendra sûrement. | ||
| + | La première ligne indiquait une adresse IP entière, le filtrage s’appliquait donc à elle et elle seule. La seconde ligne indique 10.0.1. (notez le point), les trois premiers octets. Dans ce cas, le filtrage s’appliquera à l’ensemble du réseau 10.0.1.0 (donc de 10.0.1.1 à 10.0.1.255). | ||
| + | |||
| + | Tcp_wrappers suppose que la partie manquante prenne toutes les valeurs possibles (ainsi, 10.5. comprendrait les adresses commençant par 10.5, soit de 10.5.0.0 à 10.5.255.255). Ce mode de filtrage est très puissant. Dans cet exemple, nous supposons qu’il s’agit des adresses des stagiaires. Ils sont tout simplement refusés sur le serveur (DENY), bien que nous soyons dans hosts.allow... | ||
| + | |||
| + | La troisième ligne offre une logique similaire, mais avec un adressage classique : 10.0.72.0/ | ||
| + | local_enable=No</ | ||
| + | |||
| + | Ni les utilisateurs dotés de compte ni les anonymes ne peuvent se connecter, bref, c’est l’équivalent d’un deny... Ce serait peut-être un peu excessif dans la réalité... | ||
| + | |||
| + | La quatrième ligne fonctionne sur une logique différente. Il est en effet possible, et même fréquent, que les machines de votre réseau soient en DHCP, auquel cas le filtrage par IP n’est pas idéal. Tcp_wrapper offre aussi la possibilité de filtrer par le nom. Ainsi, .compta.maboite.com désigne tous les noms finissant par .compta.maboite.com, | ||
| + | |||
| + | Nous pourrions là aussi indiquer une machine précise (expert.compta.maboite.com), | ||
| + | |||
| + | Pour tous les ordinateurs du département comptabilité, | ||
| + | |||
| + | Et les autres ? Ceux qui ne sont pas cités dans hosts.allow se verront appliquer le fichier de configuration standard, / | ||
| + | |||
| + | Il ne vous reste plus qu’à redémarrer les services réseau et vsftpd et l’ensemble est fonctionnel. | ||
| + | |||
| + | Bien sûr, les mauvaises langues diront qu’il serait possible de contourner cette sécurité en spoofant l’adresse ou le nom d’un hôte autorisé : c’est vrai et cette évidence est valable pour tous les filtres basés sur l’adresse ou le nom (un filtrage sur l’adresse Mac pourrait être contourné de la même façon). Ce filtrage n’empêche pas l’existence d’un mot de passe, qui pourra être très restrictif (comme nous l’avons vu plus haut avec les directives secure_email_list_enable et email_password_file=/ | ||
| + | |||
| + | ===== Troisième configuration : les utilisateurs virtuels ===== | ||
| + | |||
| + | Justement, les utilisateurs sont capables de tout... une protection supplémentaire de vsftpd consiste à faire en sorte que le client qui accède ainsi à votre serveur ait des pouvoirs très limités... l’idée consiste à créer un utilisateur très particulier, | ||
| + | |||
| + | Puisqu’il n’existe pas vraiment sur le système (il n’a pas de mot de passe sur la machine elle-même), | ||
| + | |||
| + | Il s’agit là d’une protection encore plus efficace... | ||
| + | |||
| + | Elle s’opère en quatre étapes : la création d’une micro base de données qui contient les utilisateurs que vous autoriserez, | ||
| + | |||
| + | ==== Création de la base de données ==== | ||
| + | |||
| + | Il s’agit là d’une étape délicate si vous ne maîtrisez pas PAM. Pour faire simple, PAM est le module d’authentification le plus efficace et le plus développé à ce jour sur les systèmes Linux. | ||
| + | |||
| + | Il utilise une base de données qui contient la liste des utilisateurs. Bien sûr, nous pourrions créer un utilisateur et PAM l’intégrerait directement dans sa base de données. Mais justement, nous ne voulons pas que l’utilisateur existe vraiment sur le système ! | ||
| + | |||
| + | Nous ne le créons donc que pour PAM et en dehors de la machine elle-même et de ses commandes useradd et autres... | ||
| + | |||
| + | Pour ce faire, créons un fichier, qui contiendra la liste des utilisateurs virtuels que nous voulons ajouter. La règle est : sur la première ligne un login, sur la seconde le mot de passe correspondant, | ||
| + | Pierre | ||
| + | Password | ||
| + | Toto | ||
| + | 1234 | ||
| + | |||
| + | </ | ||
| + | |||
| + | Le premier utilisateur est pierre, son mot de passe password. Le second toto, son mot de passe 1234 (je sais, c’est une idée exécrable d’utiliser toto et 1234 : c’est justement pour vous décourager d’utiliser ce fichier tel quel !). | ||
| + | |||
| + | Créons à partir de ce fichier un morceau de base de données utilisable par PAM :<cli prompt=' | ||
| + | USER@MACHINE: | ||
| + | |||
| + | Cette commande doit être lancée en tant que root, depuis le répertoire dans lequel se trouve votre fichier virtuels.txt. Elle suppose que vous ayez le programme Berkeley db installé. | ||
| + | |||
| + | Sur certains systèmes, comme Debian, il arrive que cette commande échoue, parce que plusieurs versions de Berkeley db sont installées (ne me demandez pas pourquoi... peut-être avez-vous recompilé plusieurs fois et les différentes éditions de ce programme, sans lequel aucune authentification n’est raisonnablement possible, se sont ajoutées sans s’écraser). Il faut lancer la version du programme qu’utilise le PAM installé, en remplaçant db_load par db3_load ou db4_load... Pour plus d’informations sur ce programme, allez sur : http:// | ||
| + | |||
| + | Dans tous les cas, cette commande crée le fichier / | ||
| + | |||
| + | Une bonne idée est de rendre ce fichier accessible par root et lui seul :<cli prompt=' | ||
| + | |||
| + | Effacez parallèlement virtuels.txt. Si vous voulez le garder pour conserver la mémoire de ce que vous avez fait, donnez-lui les mêmes droits restrictifs que pour / | ||
| + | |||
| + | ==== Création du fichier PAM à partir de cette base de données ==== | ||
| + | |||
| + | L’objectif de cette étape consiste à informer PAM qu’il faut utiliser notre base de données avec vsftpd... Créez un fichier vsftpd.pam, que vous positionnerez dans le répertoire /etc/pam.d. Ce fichier contiendra deux lignes, du type :<code - > | ||
| + | auth required / | ||
| + | account required / | ||
| + | </ | ||
| + | |||
| + | Elles précisent que tant le mot de passe que le nom d’utilisateur doivent être recherchés par PAM dans le fichier, de type base de données, | ||
| + | / | ||
| + | |||
| + | ==== Création d’un utilisateur virtuel ==== | ||
| + | |||
| + | Jusqu’ici, | ||
| + | |||
| + | PAM les reconnaît dans vsftp, mais ils n’ont aucun droit sur aucun fichier ni répertoire et ne peuvent même pas interagir avec le système ! Ils pourront cependant se connecter et rien d’autre. | ||
| + | |||
| + | A quoi servent-ils ? En fait, nous allons faire en sorte qu’ils puissent faire quelque chose, parce que nous allons les mapper avec un utilisateur du système créé spécialement pour l’occasion. Nommons-le virtuelftp. | ||
| + | |||
| + | Ce dernier n’aura, lui, aucun mot de passe sur le système et dépendra donc complètement de vsftpd... Vous voyez la boucle ? pierre et toto ont un mot de passe mais n’existent pas sur le système ; virtuelftp existe sur le système, mais, n’ayant pas de mot de passe, ne peut pas se connecter... | ||
| + | De la sorte, pierre et Toto peuvent se connecter, mais dès qu’ils dépassent le cadre limité de ce que vous autorisez pour eux en les soudant à virtuelftp, ils se retrouvent soit pierre ou Toto, donc n’existant pas sur le système, soit virtuelftp, donc n’ayant pas de droit de connexion non plus... Un peu compliqué mais diablement sécurisé, n’est-ce pas ? | ||
| + | |||
| + | Créons donc cet utilisateur virtuelftp et précisons que les fichiers du serveur FTP seront dans son répertoire personnel, que nous nommerons siteftp :<cli prompt=' | ||
| + | USER@MACHINE: | ||
| + | drwx------ | ||
| + | |||
| + | Vous pouvez à présent positionner des fichiers dans ce répertoire / | ||
| + | |||
| + | === Paramétrage de vsftpd === | ||
| + | |||
| + | Il ne reste plus qu’à demander à vsftpd d’utiliser tous ces paramétrages, | ||
| + | anonymous_enable=NO | ||
| + | local_enable=YES | ||
| + | write_enable=NO | ||
| + | anon_upload_enable=NO | ||
| + | anon_mkdir_write_enable=NO | ||
| + | anon_other_write_enable=NO | ||
| + | chroot_local_user=YES | ||
| + | guest_enable=YES | ||
| + | guest_username=virtuelftp | ||
| + | listen=YES | ||
| + | listen_port=10021 | ||
| + | pasv_min_port=30000 | ||
| + | pasv_max_port=30999 | ||
| + | </ | ||
| + | |||
| + | Dans ce fichier, nous interdisons naturellement les utilisateurs anonymes et tous les droits qu’ils pourraient avoir (nous ne voulons que pierre ou toto) et autorisons les utilisateurs locaux (parmi lesquels virtuelftp). | ||
| + | |||
| + | Nous les enfermons dans une prison chroot (dans notre cas, / | ||
| + | |||
| + | Notre configuration est prête ! Redémarrez le serveur vsftpd et essayez une connexion ! Vous allez voir comment tout ceci fonctionne : | ||
| + | |||
| + | <cli prompt=' | ||
| + | Connected to | ||
| + | | ||
| + | 220 ready, dude (vsFTPd 1.1.0: beat me, break me) | ||
| + | <cli prompt=': | ||
| + | 331 Please specify the password. | ||
| + | Password: </ | ||
| + | 230 Login successful. Have fun. | ||
| + | Remote system type is UNIX. | ||
| + | Using binary mode to transfer files. | ||
| + | <cli prompt='> | ||
| + | 257 „/“ | ||
| + | ftp> ls | ||
| + | 227 Entering Passive Mode (127, | ||
| + | 150 Here comes the directory listing. | ||
| + | 226 Transfer done (but failed to open directory). | ||
| + | ftp> size essai.txt | ||
| + | 9 12 | ||
| + | ftp> </ | ||
| + | |||
| + | Dans cet exemple, nous nous connectons avec l’utilisateur toto et son mot de passe, le serveur nous dit bien que nous sommes à la racine, alors que l’emplacement véritable est / | ||
| + | |||
| + | Observez les commandes et le retour du serveur. Le message d’erreur lors du ls est bien normal (Transfer done but failed to open directory), puisque le répertoire n’est pas lisible par tous, ce qui est mieux pour la sécurité (vous pourriez changer cet état de chose, par exemple en ajoutant anon_world_readable_only=NO, | ||
| + | Si vos utilisateurs savent ce qu’ils cherchent, pas besoin de leur en donner plus...). En revanche, la commande size nous montre que nous avons bien accès à essai.txt. | ||
| + | |||
| + | Par la suite, chaque fois que vous voudrez rajouter un utilisateur comme pierre ou toto, il vous suffira de refaire les étapes 1 et 2. | ||
| + | Si vous voulez assouplir les règles du répertoire d’accueil, | ||
| + | |||
| + | ===== Quatrième configuration : utilisateurs virtuels, suite et encore plus de sécurité ===== | ||
| + | |||
| + | La configuration qui précède est très sécurisée, | ||
| + | |||
| + | Il est possible d’améliorer les choses pour rendre notre configuration ultime, en créant plusieurs niveaux de droits, avec par exemple un utilisateur pierre qui pourra lire le contenu d’un répertoire et en télécharger quelques fichiers, et un autre, toto, qui lui aura plus de pouvoir, avec par exemple le droit d’upload en plus... | ||
| + | |||
| + | Ces configurations différentes sont possibles parce que vsftpd dispose d’une option nommée " configurabilité utilisateur par utilisateur " (hou ! l’affreux barbarisme). | ||
| + | |||
| + | Cette troisième configuration consiste donc simplement dans un premier temps à activer cette option, puis, dans un deuxième et troisième temps, à définir les droits de pierre et de toto. | ||
| + | |||
| + | ==== Activation de la configurabilité utilisateur par utilisateur ==== | ||
| + | |||
| + | Pour ce faire, dans le fichier / | ||
| + | |||
| + | De la sorte, vous indiquez à vsftpd qu’il existe un répertoire (un répertoire, | ||
| + | |||
| + | S’il n’existe pas de fichier spécifique à l’utilisateur, | ||
| + | |||
| + | Créez le répertoire en question :<cli prompt=' | ||
| + | |||
| + | Nous utilisons ici la configuration précédente pour l’enrichir, | ||
| + | |||
| + | ==== Paramétrages pour pierre ==== | ||
| + | |||
| + | Nous voulons que pierre ait des droits en lecture sur tous les répertoires. Dans la configuration précédente, | ||
| + | |||
| + | Corrigeons ce problème pour pierre. Créons donc un fichier / | ||
| + | |||
| + | De la sorte, nous autorisons le ls même si le répertoire n’est pas ‘r’ pour les autres (il ne contient pas r dans la position ------r--). | ||
| + | |||
| + | Redémarrez le serveur et connectez-vous en tant que pierre, vous verrez que ls fonctionne, tandis qu’il produit un échec à ce stade si vous êtes toto ! | ||
| + | |||
| + | ==== Affinage des droits de toto ==== | ||
| + | |||
| + | Nous voulons que toto puisse lui aussi avoir ls, mais aussi créer ou uploader, sans bien sûr toucher aux fichiers déjà existants. Créez pour ce faire un fichier / | ||
| + | anon_upload_enable=YES | ||
| + | write_enable=YES</ | ||
| + | |||
| + | La première directive lui permet le ls, la deuxième et le troisième l’upload vers le serveur. toto ne peut en revanche pas supprimer de fichier ni créer de répertoire. | ||
| + | |||
| + | Testez ces configurations, | ||
| + | |||
| + | Vous voyez qu’au fond, passer à ce stade ultime n’est pas beaucoup plus compliqué, puisqu’il s’agit au fond simplement, une fois la directive de configurabilité utilisateur par utilisateur activée, de créer un fichier de configuration cousu main pour chaque utilisateur particulier du système. | ||
| + | |||
| + | ===== Cinquième configuration : les IP virtuelles ===== | ||
| + | |||
| + | Mais bon, vous n’êtes peut-être pas paranoïaque à ce point et votre souci est peut-être plus de disposer d’un serveur à tout faire à peu près bien rangé, qui sépare bien le LAN de l’Internet par exemple, que de faire du tuning utilisateur par utilisateur. Imaginons donc un dernier cas. | ||
| + | |||
| + | Dans ce scénario, il ne s’agit donc plus de répondre à un besoin de filtrage serré, mais d’une configuration qui pose des problèmes différents. | ||
| + | |||
| + | Votre serveur FTP doit répondre à des demandes multiples : il sert de source pour les drivers que vous mettez à disposition du grand public, mais aussi de serveur pour que les employés puissent récupérer les formulaires communs à l’entreprise (demandes de congés et autres documents préformatés). | ||
| + | |||
| + | Il sert enfin à abriter les fichiers d’un projet de développement pour la cellule de veille... | ||
| + | |||
| + | Vous n’avez bien sûr pas envie que tout ce petit monde se mélange, que le grand public récupère vos formulaires ou que quiconque ait accès aux fichiers stratégiques de votre cellule de veille. | ||
| + | |||
| + | Votre consultant en sécurité vous dit que vous feriez mieux d’installer des serveurs différents et IL A RAISON. | ||
| + | |||
| + | Mais vous n’avez pas le budget, pas l’organisation qu’il faut, etc., bref, vous êtes cantonné à une seule machine. | ||
| + | |||
| + | Ce n’est pas grave (en fait si, mais disons plutôt que, dans cette situation désagréable, | ||
| + | |||
| + | Vsftpd offre une solution pour vous : les IP virtuelles. | ||
| + | |||
| + | L’idée de ce mécanisme consiste à attribuer plusieurs adresses IP à votre carte réseau (des alias) et de consacrer chaque IP à l’un des trois sites FTP que vous voulez maintenir. | ||
| + | |||
| + | ==== Création d’alias réseau ==== | ||
| + | |||
| + | Pour quoi faire ? Vous allez voir. Supposons que votre carte physique ait pour adresse 10.0.0.10 et qu’il s’agisse de la carte eth0. | ||
| + | |||
| + | La façon la plus simple de créer une adresse IP virtuelle consiste à copier le fichier / | ||
| + | |||
| + | Il devrait contenir des lignes du type :<code - ifcfg-eth0: | ||
| + | BOOTPROTO=none | ||
| + | BROADCAST=10.255.255.255 | ||
| + | IPADDR=10.0.0.10 | ||
| + | NETMASK=255.0.0.0 | ||
| + | NETWORK=10.0.0.0 | ||
| + | ONBOOT=yes | ||
| + | TYPE=Ethernet | ||
| + | USERCTL=yes | ||
| + | PEERDNS=yes | ||
| + | GATEWAY=10.199.0.254 | ||
| + | IPV6INIT=no</ | ||
| + | |||
| + | Les adresses ne seront sans doute pas les mêmes, laissez-les telles qu’elles se présentent dans votre fichier. | ||
| + | |||
| + | L’opération ne consiste qu’à modifier les lignes DEVICE et IPADDR, qui deviendront :<code - > | ||
| + | |||
| + | Enregistrez vos modifications et redémarrez le réseau< | ||
| + | |||
| + | Votre carte réseau dispose désormais de deux adresses, 10.0.0.10 et 10.0.0.11, ce que vous pouvez vérifier avec la commande ifconfig (si les deux cartes réseau n’apparaissent pas, vérifiez vos fichiers, une erreur s’est sûrement glissée lors de votre modification). | ||
| + | |||
| + | De la même façon, nous créons un deuxième alias eth0:2, qui aura l’adresse 10.0.0.12. Notre carte réseau a désormais trois adresses. | ||
| + | |||
| + | ==== Écoute d’une adresse particulière ==== | ||
| + | |||
| + | Occupons-nous à présent du serveur vsftpd et voyons ce que ce merveilleux outil permet de faire avec cette manipulation. | ||
| + | |||
| + | Il s’agit pour lui de créer trois fichiers de configuration différents, | ||
| + | |||
| + | Mais non... certes trois démons écoutent, mais la charge totale des utilisateurs reste la même qu’il y ait un processus ou trois et le surplus est faible en termes d’utilisation de la RAM et du processeur... essayez un top et vous verrez les démons alterner et un ps -aux vous montrera combien la différence est faible avec un seul démon gérant tous les utilisateurs. | ||
| + | |||
| + | En ce qui concerne les trois configurations, | ||
| + | |||
| + | Nous nommerons le fichier de configuration tout venant, à destination des utilisateurs qui téléchargent des drivers, / | ||
| + | |||
| + | De la sorte, en l’absence de directive précise, l’utilisateur lambda utilisera ce fichier. Il devra contenir en revanche obligatoirement les lignes suivantes :<code - > | ||
| + | |||
| + | De cette façon, les connexions sur cette IP (l’IP vers laquelle vous renvoyez les utilisateurs du grand public) utiliseront ce fichier. | ||
| + | |||
| + | Les employés, eux, connaissent l’IP 10.0.0.11 et vous pouvez même prendre la précaution de leur dire que le port n’est pas 21, mais par exemple 10021... | ||
| + | |||
| + | Créez alors un second fichier, par exemple / | ||
| + | listen_port = 10021</ | ||
| + | |||
| + | Enfin, le groupe d’étude qui partage des fichiers accédera à la machine par l’adresse 10.0.0.12, sur le port que vous voulez, par exemple 10021 également (mais tout autre port est possible). | ||
| + | |||
| + | Créez alors un fichier / | ||
| + | listen_port = 10021</ | ||
| + | |||
| + | Il ne reste plus qu’à lancer trois instances de vsftpd, qui chacune écoutera une des adresses ! Encore une fois, ce processus alourdit un peu le serveur, mais pas d’une façon énorme, puisque chaque instance occupera surtout les ressources requises par chaque utilisateur connecté... | ||
| + | |||
| + | <cli prompt=' | ||
| + | vsftpd / | ||
| + | vsftpd / | ||
| + | |||
| + | Bien sûr, vous aurez intérêt à positionner ces différents utilisateurs dans des répertoires différents, | ||
| + | |||
| + | Par ailleurs, cette répartition par adresse IP virtuelle peut se combiner avec les autres configurations vues dans ces exemples. | ||
| + | |||
| + | Ce dernier scénario est loin des exemples extrêmes qui précèdent, | ||
| + | |||
| + | Un utilisateur disposant de la bonne adresse (10.0.0.12 par exemple) pourra tenter une connexion vers le répertoire du groupe... encore faut-il qu’il ait le bon login et mot de passe... comme plus haut, s’il a toutes les informations et qu’il n’est pas supposé les avoir, il faudrait sans doute remettre à plat la politique globale de sécurité. | ||
| + | |||
| + | ===== Conclusion ===== | ||
| + | |||
| + | Nous avons essayé dans cet article de vous proposer plusieurs configurations qui vous permettront, | ||
| + | |||
| + | Pendant quelques temps, chaque fois qu’un droit particulier doit être donné, cependant que vous agirez sur le vrai serveur au niveau utilisateur et répertoire, | ||
| + | |||
| + | ===== Voir aussi ===== | ||
| + | |||
| + | * **(fr)** [[http:// | ||
| + | * **(en)** [[http:// | ||
| + | |||
| + | ---- | ||
| + | //Basé sur << [[http:// | ||
