Comment savoir quelle adresse le serveur FTP journalise réellement

Une ligne de journal affiche une adresse. L’ordinateur portable porte une adresse de tunnel, la connexion peut sortir par une autre sortie, et la vérification du navigateur que vous avez effectuée ne prouve rien au sujet de FTP. Ces trois valeurs peuvent toutes différer, et la ligne de journal n’en enregistre toujours qu’une. Décidez de quelle connexion vous parlez avant de comparer quoi que ce soit..

Ces étapes supposent une enquête autorisée avec une fenêtre de temps définie, et non une exploration des transferts de quelqu’un d’autre..

1. Fixez de quelle connexion vous parlez

FTP utilise deux connexions. La connexion de contrôle transporte les commandes et les réponses, et la connexion de données transporte le fichier lui-même. Un événement de connexion appartient à la première, un événement de transfert à la seconde, donc une session dans un journal peut contenir des observations provenant de deux chemins réseau différents. Notez à quel événement appartient le champ d’adresse avant d’en tirer des conclusions..

Cette séparation a une conséquence pratique. Une ligne de connexion et une ligne de transfert de la même session peuvent porter deux adresses source différentes, donc citer l’une ou l’autre comme « l’adresse du client » revient à deviner quelle connexion vous lisez. Vérifiez le type d’événement avant de faire correspondre une adresse à quoi que ce soit..

2. Suivez la connexion de contrôle

Lancez le client avec la sortie de débogage activée, ou capturez sur le client pendant qu’il se connecte, et notez le pair qu’il atteint réellement. Si un VPN est actif et que le client passe par lui, le serveur voit l’adresse de sortie du VPN et non l’adresse du réseau d’accès de l’ordinateur portable.

Si le client contourne le tunnel, le serveur voit l’adresse d’accès et l’adresse propre de l’interface VPN n’apparaît jamais sur le fil. C’est pourquoi l’adresse de tunnel de l’ordinateur portable est généralement la valeur la moins utile du tableau : elle n’existe qu’à l’intérieur du tunnel. Utilisez ss ou une capture de paquets pour confirmer la source que le client présente, plutôt que de la lire sur un écran de configuration..

Deux commandes couvrent l’essentiel :

ss -tnp state established "( sport = :21 or dport = :21 )"
tcpdump -ni any tcp port 21

La première liste les extrémités locale et distante que votre propre pile a utilisées. La seconde montre les adresses écrites sur le fil, ce qui est plus proche de la vue du serveur mais s’arrête encore à votre interface, donc seul le journal du serveur ou sa propre capture montre ce que le serveur a enregistré..

3. Vérifiez si la connexion de données correspond

En mode passif, le serveur indique au client où se connecter, et en mode actif, le serveur se reconnecte à une adresse fournie par le client. Les deux modes peuvent envoyer la connexion de données ailleurs que la connexion de contrôle lorsqu’une traduction ou un proxy se trouve sur le chemin. Confirmez le mode à partir du journal du client, puis vérifiez si la connexion de données a utilisé le même chemin..

Un transfert journalisé depuis une adresse différente de la connexion est une observation réelle et non un enregistrement corrompu, et il dit généralement quelque chose sur le chemin..

4. Demandez à l’opérateur un enregistrement étroit

Donnez à l’opérateur du serveur l’heure de la session avec son fuseau horaire, le compte, l’opération et la destination. Demandez quelle connexion a produit le champ d’adresse, et si un intermédiaire de confiance en change le sens..

Lisez le schéma réel de ce serveur au lieu de supposer que chaque produit enregistre séparément le client d’origine, le pair de contrôle et le pair de données, car certains résument toute une session sur une seule ligne. Gardez aussi le protocole clair : SFTP est un protocole basé sur SSH et non FTP sur un autre port, et FTPS ajoute TLS à FTP, donc l’identité du service dans le journal dépend de celui que vous avez déployé..

5. Vérifiez avant d’attribuer

Une adresse de sortie peut servir de nombreux clients, et un compte peut être utilisé depuis plusieurs sources autorisées, donc une adresse et un nom d’utilisateur n’identifient pas la même unité. La journalisation est une politique du serveur : un VPN change la source qu’une connexion présente, mais il n’efface pas le nom du compte, le nom du fichier ni l’opération traitée par le service destinataire. N’attribuez que ce que l’enregistrement montre et marquez le reste comme inconnu. La description FTP de WinSCP est une référence compacte du modèle à deux connexions si vous devez l’expliquer à quelqu’un..

Deux cas ordinaires montrent pourquoi cela compte. Un bureau peut faire sortir tous les utilisateurs par une seule adresse de sortie, donc cent personnes produisent une seule valeur dans le journal. L’inverse arrive tout aussi souvent : un compte se connecte depuis une ligne domestique et depuis une ligne de bureau la même semaine, et les deux entrées décrivent la même personne..