Vsftpd totalement délirant! (Résolu!)

Support Debian
#1

bonjour…

Là je crois que je vais avoir besoin d’une bonne explication.

Voilà, je me suis monté mon vsftpd et jusqu’à hier, tout allait bien… J’ai un peu bossé sur la sécurité, et notamment j’ai configuré ssh pour qu’il n’accepte qu’un utilisateur à distance.

Rien de spécial, à priori.

Pourtant,

  1. alors que mon chroot fonctionnait à merveille, comme on le voyait au niveau du client, hop! Plus rien! Maintenant, je vois tous les dossiers du serveur. Pourtant, je n’ai pas touché à la config du serveur (sauf après… mais je vais y vernir).

  2. au bout d’un moment, passablement frustré, je décide de tout réinstaller (un peu brutal, comme solution mais impossible de voir d’ou venait le problème, alors…). Et là, c’est le drame : le serveur semble ne pas redémarrer. Quand je suis sur le fichier de conf de base, pas de pb : si je vais un start une fois, puis une seconde fois : il est “allready running” (donc il est bien lancé). Mais dès que je rentre dans une conf plus interessante, à base de ports passifs, comme initialement, ça ne passe pas. Et même un simple ajout de max_clients, ça ne fonctionne pas. Ouech??? (:)). J’ai relancé mon routeur, à la maison, mais rien n’y fait.

Typiquement, j’ai ceci :
Multipass:/etc# /etc/init.d/vsftpd start
Starting FTP server: vsftpd.
Multipass:/etc# /etc/init.d/vsftpd status
Usage: /etc/init.d/vsftpd {start|stop|restart|reload}
Multipass:/etc# /etc/init.d/vsftpd start
Starting FTP server: vsftpd.
Multipass:/etc# ps -ef | grep vsftp
root 4441 4408 0 14:32 pts/0
Multipass:/etc# /etc/init.d/vsftpd restart
Restarting FTP server: vsftpdNo /usr/sbin/vsftpd found running; none killed.
00:00:00 grep vsftp

Comment est-ce possible? Quelqu’un est spécialiste?

Je relaisse mon fichier de conf :

listen=YES
anonymous_enable=NO
write_enable=YES
local_umask=022
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
xferlog_file=/var/log/vsftpd.log
chroot_local_user=NO
chroot_list_enable=YES

(default follows)

chroot_list_file=/etc/vsftpd.chroot_list
secure_chroot_dir=/var/run/vsftpd
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/certs/vsftpd.pem
pasv_max=60000
pasv_min=55000
pasv_address=thisonador.homeftp.org
pasv_addr_resolve=YES

D’autres part, malgré le fait que vsftpd ne soit pas en marche, je peux néanmoins me connecter avec filezilla, sur le port que j’utilise pour le ssh, pour accéder à mes dossiers via la connexion sftp de filezilla. Et naturellement, comme d’hab’, je peux voir tous les dossiers du serveur… ce qui est embarassant!

Y aurait pas un spécialiste? Parce que là, c’est vraiment trop space!

Rgs,
Christian

#2

J’ajoute juste : en logs, j’ai à peu près que dalle, hormis la trace du lancement de la machine ce matin (avec le fichier de conf de base) :

vsftpd.log:Tue May 6 08:56:47 2008 [pid 4169] CONNECT: Client "195.6.147.21"
vsftpd.log:Tue May 6 08:56:47 2008 [pid 4168] [christian] OK LOGIN: Client "195 .6.147.21"
vsftpd.log:Tue May 6 08:57:01 2008 [pid 4172] CONNECT: Client "195.6.147.21"
vsftpd.log:Tue May 6 08:57:01 2008 [pid 4171] [christian] OK LOGIN: Client “195 .6.147.21”

Naturellement, on pourrait conclure que le pb vient de la conf’ mais là… je sèche.

Ah, et au fait, j’ai fait une petite correction: A la fin du fichier de vsftpd.conf, j’ai maintenant :
pasv_max=60000
pasv_min=55000
pasv_address=thisonador.homeftp.org
pasv_address_resolv=YES
(dsl, pas vu)

Mais cela ne change pas grand-chose au problème… :

Multipass:/var/log# vim /etc/vsftpd.conf
Multipass:/var/log# /etc/init.d/vsftpd restart
Restarting FTP server: vsftpdNo /usr/sbin/vsftpd found running; none killed.
.
Multipass:/var/log# /etc/init.d/vsftpd start
Starting FTP server: vsftpd.
Multipass:/var/log# /etc/init.d/vsftpd restart
Restarting FTP server: vsftpdNo /usr/sbin/vsftpd found running; none killed.

#3

Salut,

MMM pas de réponses? Aïe! J’aurais bien besoin d’aide, pour le coup!

Thx d’avance!
:slightly_smiling:

#4

Juste pour info, vsftpd n’a rien à voir avec ssh ni sftp.

#5

Salut

Alors j’ai vu une petite chose dans ta config :

Perso j’ai configuré des utilisateurs virtuels chrootés, mais dans ton cas cela peut expliquer ton “non chroot”. Bon, en même temps je n’ai vraiment pas la même config que toi.

Sinon pour ton problème d’impossibilité de redémarrer le service, je me demande si ca ne vient pas du logrotate car j’ai le même genre de soucis avec mon serveur http.
En gros il existe un fichier /var/run/vsftpd/vsftpd.pid où le service écrit son numéro de PID. Celui-ci sert pour le stopper (notamment lors de la rotation des logs). Donc s’il ne correspond pas au numéro réel du processus, pas moyen de stopper le service.
Donc un jour logrotate a voulu faire tourner les logs, il a voulu stopper le service et il a planté ou autre chose et depuis le PID n’est plus cohérent avec le fichier dans /var/run.
Je ne garantie pas que cela soit la source de ton problème mais tu peux y regarder un peu.

#6

Hello Antalgeek (sympa, comme pseudo),
Hello PascalHambourg,

D’abord merci pour vos réponses…

Pour ce qui est de :
chroot_local_user=NO
chroot_list_enable=YES

(default follows)

chroot_list_file=/etc/vsftpd.chroot_list
secure_chroot_dir=/var/run/vsftpd

Cela signifie que par défaut mes utilisateurs locaux ne sont pas chrootés. Seuls les utilisateurs (locaux ou non, sans doute, mais pour ma part, y a que du local) noté dans vsftpd.chroot_list peuvent se connecter. En l’occurence, je m’y suis noté, j’existe en local et mon répertoire de connexion est /home. Donc… c’est pas logique (à moins de partir sur l’explication que j’envisage plus pas, en relation avec l’histoire du sftp).

Cela dit, ton hypothèse au sujet des PID m’intéresse. Je ne sais pas encore s’il y a un lien (je peux voir ça par quel biais? En comparant les fichier pid et le résultat de ps, par exemple? Mais s’il n’est pas en marche, ça va être compliqué…) Comme j’avais ce fichu problème avec le CHROOT, qui ne fonctionnait plus, j’ai desinstallé et réinstallé vsftpd. Pour régler le problème, s’il vient de là, je dois faire quoi? Supprimer le fichier /var/run/vsftpd/vsftpd.pid, puis de nouveau desinstaller/réinstaller le serveur?

Mais d’un autre côté… comme je disais précedemment, avant de modifier le fichier de conf de vsftpd, ca avait l’air de se mettre en route… comme si n’importe quelle mention supplémentaire dans ledit fichier bloquait le lancement du serveur. et je suppose que si ton idée était la bonne, le serveur ne se lancerait pas du tout quel que soit le cas de figure, n’est ce pas?

Bizarre… Je vais refaire un test, pour voir.

PascalHambourg,
tu me dis que vsftpd n’a rien à voir avec ssh ni sftp. Je crois comprendre ce que tu veux dire : sftp fonctionne sur ssh. “SFTP n’est nullement basé sur FTP, mais sur SSH! Il fait d’ailleurs partie de OpenSSH server et n’utilise par défaut que l’unique port 22 de SSH.” Quand à SSL, c’est ftps.

Mais pour eclaircissement, si j’utilise le port 22, par exemple, pour accéder à mes données, ce que tu veux dire, en fait, c’et que je n’utilise pas vsftpd mais sftp? Et donc que même si vsftpd est down, un utilisateur pourra tout de même récupérer des données par ce biais? Avoir vsftpd, dans ce cadre, ce n’est pas comme si j’avais deux serveurs de transfert des données dans cas?

De même, dans ce cas, cela m’ammène à une autre question : le port par défaut de vsftpd est le port 21, utilisé par le FTP normal. La différence entre le ftp classique et le serveur vsftp… serait donc que le serveur vsftpd s’appuie sur la commande et le protocole ftp pour fonctionner, sans doute? Car d’un autre côté, j’ai entendu parler d’SSL dans le cas de Vsftpd. Pourrais-tu éclairer ma pauvre lanterne? :slightly_smiling:
Je sais que je mélange un peu les choses… les accronymes étant assez trompeurs, pour le coup, ici.

Thx,
Christian

#7

Exactement.

Qu’entends-tu par “ftp classique” ? vsftpd est un serveur FTP parmi d’autres, éventuellement avec une couche de chiffrement SSL/TLS.

#8

PascalHambourg :
Ok. Ca explique au moins une partie du problème… qui finalement n’en est pas un. Toujours pareil, alors : si je te suis bien, en utilisant le port 22 (ou le port que j’ai attribué à ssh, puisque je l’ai changé), l’utilisateur utilisera une liaison sécurisé, via ssh, pour le coup?

Bon… si tel est le cas, la situation n’est pas aussi tragique que prévu, même si elle n’est pas infaillible (je dois tout de même m’arranger pour générer les clés… ce que je n’arrive pas à faire, pour le moment, Cf. le “ticket” Problème de clé ssh/putty - Server refused our key sur le sujet. Je crois que c’est un problème de conversion avec RSA que je ne dois pas faire correctement).

Pour ton autre question, je me suis mal exprimé : j’y confond le serveur FTP (autrement dit qui utilise la commande et le protocole ftp) et le protocole du même nom. C’est une maladresse de ma part. Finalement, dans ce contexte vsftpd est un “ftp classique”, si j’ose dire, dans le sens ou il n’utilise pas ssh - comme tu l’as souligné toi-même mais travaille par contre sur le port 21, à l’inverse de sftp, du coup.
Et j’en comprends d’autant mieux le fonctionnement de cette couche SSL, dont tu me parles aussi. Jusqu’ici, je n’avais pas bien pigé comment le serveur pouvait fonctionner à la fois avec l’un et l’autre… c’est parce que ce n’est pas le cas, en fait, ma “méthode” consistant à me connecter en sftp et non par vsftpd.

Décidemment, tout cela est très intéressant. Merci à vous deux.

Ca ne résouds pas encore mon problème mais au moins… j’ai une vision déjà plus clair du serveur. :smiley:

Cela dit, voilà donc ce que j’ai actuellement :

Multipass:/etc# /etc/init.d/vsftpd start
Starting FTP server: vsftpd.
Multipass:/etc# /etc/init.d/vsftpd status
Usage: /etc/init.d/vsftpd {start|stop|restart|reload}
Multipass:/etc# /etc/init.d/vsftpd stop
Stopping FTP server: vsftpdNo /usr/sbin/vsftpd found running; none killed.
.
Multipass:/etc# vim /etc/vsftpd.conf
Multipass:/etc# /etc/init.d/vsftpd start
Starting FTP server: vsftpd.
Multipass:/etc# /etc/init.d/vsftpd status
Usage: /etc/init.d/vsftpd {start|stop|restart|reload}
Multipass:/etc# /etc/init.d/vsftpd restart
Restarting FTP server: vsftpd.
Multipass:/etc# ps -ef | grep vsftpd
root 5316 1 0 16:18 ? 00:00:00 /usr/sbin/vsftpd
root 5321 5287 0 16:19 pts/0 00:00:00 grep vsftpd

Après avoir ouvert le fichier de conf avec vim, j’ai commenté les lignes relatives aux ports passifs. A l’inverse, j’ai décommenté la ligne relative au port par défaut (listen_port). En principe, ce dernier point n’est pas indispensable, puisque… le port est par défaut.

Ce faisant, le serveur, visiblement, réopnds. Je me retrouve évidemment stoppé par l’absence des ports passifs imposés au client pour la transmission des données. Je note que si je décommente les lignes relatives aux ports passifs (tout en laissant la ligne relative au port 21), Ca ne marche pas plus… ce qui pourrait indiquer un problème à ce niveau là… je vais investiguer dans cette direction.

Peut-être une erreur dans la forme avec ces quatre petites lignes, ou un manque quelque part?

Thx,
Chris

#9

Euh tu pourrais mettre ton fichier de conf actuel car j’avoue que je ne te suis plus là.

#10

antalgeek : oui, bien sûr. Pas de pb :
Ci-suit:

Example config file /etc/vsftpd.conf

listen_port=21
listen=YES
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
xferlog_file=/var/log/vsftpd.log
ftpd_banner=Welcome to Christian FTP service!
chroot_local_user=NO
chroot_list_enable=YES

(default follows)

chroot_list_file=/etc/vsftpd.chroot_list
secure_chroot_dir=/var/run/vsftpd
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/certs/vsftpd.pem

pasv_max=60000
pasv_min=55000
pasv_address=thisonador.homeftp.org
pasv_address_resolv=YES

(donc dès que je décommente les 4 dernière lignes, ça ne marche plus… il doit sans doute y avoir un pb au niveau de la configuration du fichier, mais en l’état actuel des choses, étant au taff, je ne peux pas directement vérifier)
:slightly_smiling:
Thx
Chris

#11

[quote=“sonador”]pasv_max=60000
pasv_min=55000
pasv_address_resolv=YES[/quote]
D’après la page de manuel, ces options s’écrivent pasv_max_port, pasv_min_port et pasv_addr_resolve.

#12

Pascalhambourg,

Arggghhhh What’s the f…? Ok d’accord… v’là la bourde à deux francs! (je sais, les francs, ça n’existe plus… c’est pour ça qu’elle vaut deux francs, justement!) Ok, la honte… Bon, je vais voir ce que ça donne… oulàlà… Ah bravo!

Thx!
Christian

#13

Salut…

Eh bien je passe juste pour dire que ça marche!

D’une part, il restait le pb évoqué par PascalHambourg (corrigé, donc) et d’autre part, je devais ajouter pasv_enable, ce que j’avais oublié.

I’s ok.

Merci à vous deux!

Amicalement,
Chris

#14

Bizarre, d’après la page de manuel de vsftpd.conf l’option pasv_enable est à YES par défaut. Il ne devrait donc pas être nécessaire de l’ajouter pour activer le mode passif.

PS : le [résolu] doit être ajouté dans le sujet du premier message, afin d’apparaître dans la liste des sujets du forum.

#15

J’ajoute ceci :

Pour éviter que tout à chacun puisse accéder au serveur par SFTP :

-Changer le port d’écoute de ssh (ex.11223).
-Changer le numéro de port dans la liste des accès autorisés, sur le firewall du routeur, à l’entrée du réseau (pour tel serveur, autoriser le port d’accès 11223 pour les personnes venant de l’extérieur).
-Ne communiquer ce numéro de port à personne (le 11223 n’est pas le numéro de port que j’ai choisi, évidemment).
-Autoriser un user à accéder à votre serveur à distance. Et interdir une connexion en root (tout ceci se fait par le fichier /etc/ssh/sshd_config).
-Le user devra être êre composé d’une chaine de caractères non correspondante avec un prénom réél. Ex. titadafateg42R. Le mot de passe devra être long, aléatoire et complexe : GZGT44étfzzgfe… etc. Par exemple.
-Ce même user ne devra pas faire partie de ceux autorisés à utiliser vsftpd.
-Aucun des users utilisant vsftpd ne devra faire partie de ceux autorisés à utiliser ssh (Un pirate ne pourra donc pas utiliser l’un de ses user pour tenter de se connecter en ssh).

Le changement de port : éviter ainsi les attaques effectués par les robots. Ceux-ci, souvent, se connecte sur le port ssh 22, le port par défaut.

Le user autorisé à se connecter en ssh : un “nom” de user compliqué pour éviter les attaques par dictionnaire.

Tout cela ne protègera pas de tout… mais au moins, déjà, ça limitera la casse.

Vous pourrez aussi - pourquoi pas - utiliser les propiété de /etc/hosts.allow et /etc/hosts.deny, pour limiter les accès à un seul réseau externe. C’est ce qu’on appelle du Wrapping (moun3im.free.fr/docmaster/articles/linux105.html)

Ex, pour /etc/hosts.allow :

ALL: 192.168.
ALL: 88.178.X.Y
ALL: *.ntt.eu

Seuls les users issus du réseau local et du réseau dont la patte externe est 88.178.X.Y (attention : si l’adresse en question est dynamique, vous aurez des surprises) ou du réseau dont l’adresse DNS est .ntt.eu, pourront se connecter et utiliser tous les protocoles (si l’on avait voulu limiter les accès au ssh : in.sshd 192.168. par exemple).

Et dans /etc/hosts.deny :
ALL: ALL
(personne n’a le droit de se connecter sur la machine, sauf ceux autorisés dans /etc/hosts.allow).

Vous pourrez aussi, ainsi, contrôler qui fait quoi, mais… attention : le tcpWrapper permet de contrôler l’accès pour des machines, des réeseaux… par pour des utilisateurs (pour cela : ssh!).

N’hésitez pas à utiliser les options de sshd. Il y en a plusieurs de très utiles.

Si d’autres ont des suggestions, je suis ouvert!

Christian

PS. Je mets “résolu” demain matin. Au cas ou qq souhaiterait ajouter un commentaire utile (je suis toujours preneur).

PPS. Sans dec’, il a vraiment fallu que je rajoute la ligne, qui d’ailleurs ne figurait pas du tout sur le fichier de conf. Cela dit… peut-être l’ai-je effacé par erreur auparavant? Va savoir… J’ai bien assez déconné comme ça, sur c’t’affaire… Thx, Pascal, en tout cas.

#16

Si tu a vraiment peur pour ton serveur ssh, ou que tu es parano :p! autant le rendre invisible.

http://www.cipherdyne.org/fwsnort/index.html

Bientôt disponible dans les bacs Debian normalement !

#17

lol si tu veux le laisser ouvert à tout le monde, vas-y… pas de pb. File moi l’adresse, les logs et les passwd, si tu es si confiant, tant qu’on y est… :slightly_smiling: Allons… il ne s’agit pas d’être parano, mais, comme d’autres ici (chacun à notre niveau) je travaille sur des serveurs, en entreprise. Je peux t’assurer que les attaques existent : j’en ai vu au boulôt (d’ailleurs l’un de nos clients en a subi une qui a duré qq chose comme huit heures, peu avant mon entrée dans la boite) et, même sur mon serveur, je m’en suis pris une petite par dico (en vain, par bonheur). Je peux même te dire que ça n’a pas trainé : cela s’est produit à peine quelque jours après avoir ouvert mon serveur sur la toile. Ce n’est donc pas de la parano, mais de la simple et élèmentaire prudence. D’autres part je n’ai pas la prétention d’avoir tout vérouillé (j’espère améliorer encore les choses, cela dit), mais j’espère avoir fait le plus évident pour éviter les embrouilles les plus banales, si j’ose dire. Il y a des linuxnautes (arf) qui ne sont pas forcément au fait du genre d’action que l’on peut utiliser pour se protéger, alors pourquoi ne pas les mettre en avant, pendant qu’on y est ? Et pourquoi ne pas être à l’affut de toutes suggestions utiles?? Ca ne peut que servir, que ce soit dans un sens ou dans l’autre. Et enfin… les problèmes de sécurité sont intéressants à étudier, tout simplement. Il y a beauoup à apprendre, à ce niveau. Personnellement, je trouve ça passionnant.

Faut pas se leurrer : si tu ouvres ton réseau sur l’extérieur, il faut évidemment prendre quelques précautions. Ou alors, faut être un peu suicidaire.

Allez, à bon entendeur (je vais mater ton lien dans la minute qui suit. Thanks!!!)

Bonne soirée (PS. ne prends pas mal ma réponse… je ne sais pas si tu plaisantais ou pas, en fait).

Chris

#18

L’intérêt de certaines des contre-mesures que tu suggères me paraît discutable.

  • Changer le port de sshd : un bête scan de ports aura vite fait de le retrouver.
  • Avec des mots de passe corrects ou l’authentification exclusivement par clés, les attaques automatiques des robots n’ont aucune chance de réussir.

Si le but est d’empêcher le SFTP tout en gardant le service SSH (sinon autant couper sshd), il suffit tout simplement de désactiver la fonctionnalité en commentant la directive Subsystem correspondante dans sshd_config.

#19

Pascal,

Ah! Voilà des remarques intéressantes. Pour ce qui est des scans de ports, oui… eh bien j’imagine que l’idée n’est pas tellement de TOUT empêcher en changeant les adresses de ports. Simplement d’éviter une partie des robots sur la toile. D’ailleurs, les quelques articles que j’ai lu sur le sujet semblaient le conseiller. Cela étant, ce que tu dis est tout à fait juste.

Pour l’authentification par clé, en fait j’y travaille… je continue de chercher comment convertir ces f…us clés, avec puttygen. J’ai vu un truc, hier, en cherchant vite fait (à 3h du mat’ y avait intérêt à ce que ce soit vit’fait…) et j’ai entraperçu la commande ssh-add. Ce doit être ce que j’ai oublié de faire.

A vérifier.

Pour ce qui est des mots de passe… on peut toujours les casser, j’imagine. Y compris le miens, évidemment. Cela étant, je ne leur ai pas facilité la tâche : totalement aléatoires et d’une belle longueur, qu’ils sont. Enfin… du moins le seul qui soit autorisé à se loguer en ssh (et qui lui-même est un “nom” assez spécifique, loin de ce qu’on trouve dans les dicos).

Cela dit, le coup de couper le sftp… pas mal… je vais regarder ça. Je ne connaissais pas encore. Merci! C’est bon à savoir.

Enfin, j’ajouterai tout de même que j’ai bien conscience que même avec tous les verouillages possibles… je ne pourrai jamais tout éviter. Ca reste toutefois un sujet passionnant.

Rgs,
Chris

#20

Bonjour

Pour voir la duree d’ un password en force brute:

lockdown.co.uk/?pg=combi&s=articles

Il n’ y a pas de quoi s’affoler.
:smiley: