Re: [OffTopic] Question de gateway
Dans son message du 5/7/2000, Stephane Leclerc écrivait:
> J'éteins la gateway, je me connecte en FTP en utilisant l'adresse IP, ca
> tourne, ca tourne, point de connexion jusqu'au timeout du client.
>
> Je rallume la gateway, connexion impeccable.
Comment se fait l'authentification des comptes FTP ?
Je veux dire, où sont gérés les identifiants de connexion sur le système et les mots de passe ?
Il est possible que cette gestion soit déléguée à une autre machine, ou un serveur de domaine, dont la configuration par défaut cherche à vérifier les adresses qui lui sont communiquées. Exemple de services : une boite NT, les yellow-pages (NIS, NIS+), ...
D'autre part, il est possible également que le ou les serveurs impliqués ont des répertoires NFS montés sur des serveurs situés derrière le routeur que tu as éteint. De ce fait ils ne sont plus accessibles et cela peut bloquer certains processus ou services de ton système, qui alors produisent des erreurs après un délai dépassé (timeout error, NFS stale handle, etc...)
Regarde aussi avec "netstat -an" si des sockets de services ou des connexions clients ne sont pas bloqués quand tu éteins le routeur: il suffit de comparer la liste des sockets affichée avant et après avoir lancé plusieurs tentatives. Tu devrait y trouver la connexion défaillante qui pose problème. Repère le numéro de port de la socket concernée et l'adresse IP accédée s'il s'agit d'une socket cliente.
Autre chose: pour que FTP fonctionne, il faut que le portmapper tourne:
un transfert de fichier, ne serait-ce que celui fournissant la liste des fichiers du serveur avec la commande DIR, nécessite une connexion supplémentaire en plus de la session de contrôle:
Client FTP Serveur FTP
------------ ------------
session [port mappé] -> [port 21]
de "USER xxx" ->
controle: <- "PASS?"
"PASS xxx" ->
<- "OK, connecté"
(commandes) ->
<- (réponses)
"BYE" ->
<- [déconnexion et fin]
[fin]
La session de commande et de contrôle ne fait qu'échanger les commandes du client
FTP et les réponses de statut du serveur. Aucune donnée de fichier n'est échangée
sur ce port. Les transfert utilisent une autre socket de connexion, créé soit dans
le sens client vers serveur (émission de fichier, ou réception de fichier en mode PASV),
soit dans le sens serveur vers client (réception de fichier en mode normal non PASV).
Pendant le transfert, la session de contrôle et de commande reste ouverte mais ne
fait presque rien (transfert de signes "#", statistiques, interruption hors-bande du transfert).
1) Transfert (DIR ou GET) en mode non PASV (mode standard):
------------------------------------------------------------
Ce mode nécessite que le client indique un numéro de port FTP-DATA sur lequel
le serveur FTP viendra se connecter pour transférer les données ou le fichier demandé.
Le numéro de port utilisé par le serveur FTP pour se connecter au client FTP est
déterminé par le client FTP, qui le transmet au serveur avec une commance PORT.
Le serveur mémorise le numéro de port et l'adresse IP transmise, et quand un
transfert de fichier (ou plusieurs) devra être fait vers le client, le serveur ouvrira une
session vers le port indiqué par le client.
Il faut donc que le client écoute le port et autorise le serveur FTP à s'y connecter.
Il faut aussi qu'un firewall entre le client FTP et le serveur FTP laisse passer les
demandes de connexion provenant du serveur (malheureusement la détermination
du numéro de port se fait en ligne dans les données échangées sur la session de
contrôle, ce qui est non conforme au modèle d'application réseau ISO, aussi
bien des firewalls gère mal ce type de transfert, sauf si le firewall est configurable
pour interpréter le protocole FTP échangé sur les sessions de contrôle).
Client FTP (IP=a.b.c.d) Serveur FTP (IP=e.f.g.h)
----------------------------- -----------------------------
(Port controle) (Port x.y) (Port 0.21) (Port u.v)
-------------- ------------ ------------- --------------
(alloue un port x.y)
"PORT a,b,c,d,x,y" -> (mémorise le port FTPData du client FTP)
<- "OK" |
[listen e.f.g.h,*.*] |
"DIR" ou "GET" -> (vérifie la ressource |
demandée, puis:) v
(prépare réception) <- "OK, début transfert"
<- [connect a.b.c.d,x.y]
[accept] ->
(affiche infos) (réception données) <- (infos ###) (émission des données)
[close] <- [close]
(succès) <- "OK, transfert effectué"
2) Transfert (GET ou DIR) en mode PASV
---------------------------------------
Il s'agit d'une extension du protocole FTP, permettant au clients derrière
un firewall filtrant toutes tentatives de connexion vers le client, de faire
un transfert quand même. Cette fois, ce n'est pas le serveur qui se
connecte vers le client, mais le serveur qui indique au client un numéro de
port sur lequel le client pourra se connecter pour récupérer les données
demandées. De cette façon les connexions se font comme si le client
devait envoyer des données vers le serveur, sauf qu'une fois la socket
ouverte, c'est le serveur qui envoit des données au client et non
l'inverse (comme c'est le cas avec la commande PUT permettant au
client d'émettre un fichier vers le serveur)
Maintenant il faut bien voir que le protocole FTP est assez ancien, et est
non conforme au modèle ISO. Il pose des problèmes de sécurité, car
le port de transfert des données est séparé du port utilisé pour la
session de contrôle qui elle est identifiée. Aussi l'implémentation d'un
serveur FTP tente de vérifier l'identité du client qui cherche à se
connecter au serveur pour récupérer des données. Tout d'abord, un
serveur FTP sécurisé devrait travailler en mode PASV car alors le
serveur peut générer un numéro de port aléatoirement, utilisé pour le
transfert d'un fichier spécifique. Le serveur d'autre part doit vérifier
l'identité du client qui cherche à se connecter sur le port d'envoi des
données: normalement il ne doit accepter que le client connu par son
adresse IP et rejeter les autres. D'autre part, le serveur FTP doit
identifier les accès des clients, et la plupart d'entre eux par défaut
génèrent un journal des transactions, en cherchant le nom de domaine
associé à l'adresse IP détectée. Et pour un serveur FTP, la seule
protection possible sur les données échangées sur le port de données est
celle consistant à vérifier les adresses IP et à restreindre les numéros
de port écoutés client par client.
L'autre protection est la génération aléatoire du numéro de port de
connexion au lieu d'utiliser le port 20 par défaut. Ainsi ce numéro de
port devient une sorte de mot de passe à usage très temporaire,
utilisé pour le transfert d'un seul fichier.
Enfin la journalisation en clair des clients est requise: n'enregistrer
que l'adresse IP des clients est insuffisant, car tenter de déjouer
des intrusions détectées risque d'échouer plus tard, l'adresse IP
ayant peut-être été utilisée de façon temporaire. Aussi, un serveur
FTP devrait ne faire confiance qu'aux adresses IP enregistrées dans
un serveur DNS et associées à un nom de domaine vérifiable,
qui peut fournir le nom et l'adresse du fournisseur d'accès, la
localisation du point d'accès sur le réseau du fournisseur Internet,
etc.... Un serveur FTP qui ne parvient pas à trouver le nom de
domaine associé à une adresse IP donnée devrait refuser les
connexions. Cette configuration est possible car le serveur FTP
utilise la fonction de sockets gethostbyaddr(), qui sous Unix
utilise la configuration définie par des fichiers tels que nsswitch.conf
(qui détermine l'ordre de priorité des services de résolution de noms)
et resolv.conf (qui indique la localisation du service DNS).
Hors si on coupe le gateway par défaut, il y a fort à parier que l'accès
au DNS n'est plus possible (car il est situé souvent derrière la passerelle
par défaut), et le serveur FTP ne parviendra pas à associer un nom de
domaine à l'adresse IP qu'il connait. Aussi quand le serveur cherche le
nom du client, il le fait en utilisant la fonction de résolution
gethostbyaddr(). Et là, si on a coupé le gateway sans changer le fichier
resolv.conf, la fonction retournera une erreur dûe au fait que l'adresse IP
n'est pas connue localement et que la méthode de résolution par DNS
ne marche pas non plus.
Si l'adresse IP du client pour lequel on souhaite un accès permanent est
fixe et connue du serveur, on peut l'inscrire dans le fichier /etc/hosts, de
sorte que gethostbyname() n'échouera pas, car la résolution des noms
d'hôte cherche normalement d'abord dans la base locale des adresses IP
connue, avant d'interroger le DNS.
Reply to: