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.
