david999
Posts: 7
Joined: Mon Mar 23, 2015 9:01 pm

NAS + FTP + SSH... le tout sécurisé!

Mon Mar 23, 2015 9:22 pm

Bonjour à tous!

J'ai l'intention d'acquérir une Raspberry Pi 2 pour l'utiliser sur 3 points différents. Je m'explique.
Le but serait de l'utiliser comme:
- NAS: sur un disque dur externe relié à la Raspberry, je stockerai tout mes docs, photos et vidéos. Le but étant d'y avoir accès depuis n'importe quel ordinateur (ou smartphone) relié au réseau.
- Serveur FTP: créer un dossier dans lequel je stockerai des fichiers que mes amis pourraient télécharger (et ils pourraient également uploader des fichiers à leur tour)
- Connexion SSH: le but étant de pouvoir me connecter depuis l'extérieur lorsque je veux avoir accès aux contenus de mon disque dur.

La Raspberry serait équipée de Raspbian.
Pour le NAS, je pense installer Samba (jamais configuré encore mais ça devrait être jouable je pense).
Pour le FTP, probablement sFTP ou FTPs.

Maintenant, mes interrogations concernant ce projet:
- est-il possible de mettre en place ces 3 services ensemble?
- d'un point de vue sécurité, comment protéger mes données? Désirant laisser la Raspberry branchée en permanence sur le réseau, comment être sûr que quelqu'un se connectant au FTP ne pourra pas explorer une faille et récupérer mes fichiers personnels (donc pas ceux du répertoire FTP)? Autrement dit, comment sécuriser au maximum mes données? L'installation d'iptable peut elle aider en ce sens?

Je pense que ça doit être réalisable, mais je ne voudrais pas mettre en place une passoire qui donnerait accès à mes fichiers à tous les gugus essayant de se connecter à mon serveur FTP!!!! :o

Merci d'avance pour vos lumières et vos conseils. ;)

David

fedji78
Posts: 16
Joined: Sun Jan 25, 2015 2:06 am

Re: NAS + FTP + SSH... le tout sécurisé!

Tue Mar 24, 2015 3:08 am

david999 wrote:Bonjour à tous!

Maintenant, mes interrogations concernant ce projet:
- est-il possible de mettre en place ces 3 services ensemble?
- d'un point de vue sécurité, comment protéger mes données? Désirant laisser la Raspberry branchée en permanence sur le réseau, comment être sûr que quelqu'un se connectant au FTP ne pourra pas explorer une faille et récupérer mes fichiers personnels (donc pas ceux du répertoire FTP)? Autrement dit, comment sécuriser au maximum mes données? L'installation d'iptable peut elle aider en ce sens?

David
Bonjour David,
Alors pour installé ces 3 services ensemble: Oui c'est possible. il faut s'armer de patience, enfin, quoi que avec le Pi 2 sa va plus vite que ces cousins lol :P .
En tout cas oui c'est entièrement envisageable.
Je l'ai fais avec Pi B+ mais pas encore avec PI 2. Donc j'essayerai d'installer tout ça ce weekend et je te tiens au JUS :D
Keep kalm and code
fedji78

david999
Posts: 7
Joined: Mon Mar 23, 2015 9:01 pm

Re: NAS + FTP + SSH... le tout sécurisé!

Tue Mar 24, 2015 8:50 am

Salut fedji!

Merci pour ta réponse! J'attends impatiemment d'avoir ton retour après l'installation!!! :P
C'est sympa en tous cas. ;)

Concernant la partie "sécurisation" de la Rpi avec le disque dur connecté dessus, je pense partir sur iptables... et quelques petits softs qui ont l'air relativement légers. Après faut pas tomber dans la paranoia non plus mais bon... :lol:
J'ai trouvé ce tuto vachement bien fait sur le site du zéro:
http://openclassrooms.com/courses/secur ... veur-linux

Ah oui! Une dernière question (pour l'instant :D ), pour installer tout ça sur la Rpi, il faut une micro SD de quelle capacité (sachant qu'elle ne servira qu'à installer le système. Tout ce qui est données sera sur le disque dur externe)?

Merci d'avance pour les précisions!

JumpZero
Posts: 1033
Joined: Thu Mar 28, 2013 7:35 pm
Location: 127.0.0.1

Re: NAS + FTP + SSH... le tout sécurisé!

Tue Mar 24, 2015 11:49 am

Bonjour,

Ce que tu veux faire est un classique sous GNU/Linux.
Pour mémoire Raspbian est basé sur Debian et tu trouveras toutes les réponses a tes questions sur le site officiel Debian et aussi sur les excellents "cahiers de l’administrateur Debian" en français (livre libre) ici:
http://debian-handbook.info/browse/fr-FR/stable/
Le raspberry pi n'est que la plateforme et n'importe pas vraiment pour ces services (la je ne parle pas de performances... ;-) )
Prépares toi a beaucoup lire et beaucoup apprendre.
--
Jmp0

david999
Posts: 7
Joined: Mon Mar 23, 2015 9:01 pm

Re: NAS + FTP + SSH... le tout sécurisé!

Tue Mar 24, 2015 12:16 pm

Bonjour JumpZero,

merci pour ta réponse.
J'ai beaucoup entendu parlé de Samba, j'ai manipulé un peu PorFTPD, j'ai lu aussi plusieurs choses sur le SSH... mais je n'ai jamais vraiment mis en place quoi que ce soit!
Du coup il va y avoir du boulot oui, même si je me doute que c'est réalisable avec Debian.

J'ai appris pas mal de choses grâce au livre du site du zéro "Reprenez le contrôle avec Linux" (bien écrit pour les gens qui débutent comme moi). Ca m'a permit de mettre un pied à l'étrier. Linux est un monde vraiment passionnant, mais pas toujours évident!
Et un grand merci pour ton lien! Le moins que l'on puisse dire, c'est qu'il est... COMPLET!!!!! :shock: J'ai seulement survolé mais ça à l'air super intéressant (je n'étais jamais tombé dessus auparavant).

Merci!

jeanluc
Posts: 294
Joined: Thu Apr 11, 2013 9:44 am

Re: NAS + FTP + SSH... le tout sécurisé!

Tue Mar 24, 2015 1:32 pm

Bonjour;
ça te regarde, mais a mon avis ça ne sert a rien le ftp ou le ftps, car si tu as le ssh, donc automatiquement le sftp disponible qui suffira amplement, et pour la sécurité, moins tu auras de softs en écoute, mieux c'est....car moins de ports ouverts sur le net..surtout quand il s'agit de softs qui peuvent faire la même chose..
-Pour le ssh, tu fais une connexion par paire de clés (2048 ou 4096) et tu bannis la connexion par mot de passe une fois opérationel.
-Pour le sftp, tu chroot tous les autres utilisateurs :
#UsePAM yes
Subsystem sftp internal-sftp ### #Subsystem sftp /usr/lib/openssh/sftp-server
Match Group sftpusers
ChrootDirectory /home/%u
ForceCommand internal-sftp
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
Et les utilisateurs que tu veux chrooter tu les rentres dans le groupe sftpusers après avoir créé le groupe. Le home utilisateur => groupe de l'utilisateur et propriétaire root en 755.
Sinon si ta rpi est derrière une box, t'as pas grand chose à faire d'autre; installes fail2ban si tu veux réduire les logs de tentative d'intrusion, c'est tout..
Pour ce qui est du pare-feu (iptables ou netfilter), je te ramène à ces discussions très intéressantes, d'un certain TIRAxxx qui vient d'ailleurs de publier dans le dernier LINUX-PRATIQUE N° 87 de janvier février, et qui démonte toutes les idées reçues sur l'intérêt du firewall; il ne dit pas que c'est toujours inutile, mais quasiment tout le temps inutile que l'on soit derrière une box ou directement connecté au net :

http://forum.ubuntu-fr.org/viewtopic.php?id=1285441&p=1
http://forum.ubuntu-fr.org/viewtopic.php?id=1758661

Pas plus utile pour un serveur directement connecté au net :

http://forum.ubuntu-fr.org/viewtopic.ph ... #p17942651 :
"L'utilité de Netfiler, c'est :
- soit de bloquer des ports que tu ne peux pas fermer (cas très rare) ;
- soit de faire un filtrage sélectif (blocage de certaines ip, ce que fait fail2ban, ou tu peux aussi bloquer les ip de TMG HADOPI par exemple)
- soit de faire des redirections de port.

http://forum.ubuntu-fr.org/viewtopic.ph ... #p18225451

Bonne lecture, et si tu lis tout, tu verras aussi que certaines idées reçues tel que le changement de port SSH ou le blocage de connexion pour root sont toutes aussi inutiles; à condition bien sur de bien sécuriser ton accès : mot de passe très fort ou mieux clés ssh et d'avoir un système a jour.
Last edited by jeanluc on Tue Mar 24, 2015 4:27 pm, edited 2 times in total.

david999
Posts: 7
Joined: Mon Mar 23, 2015 9:01 pm

Re: NAS + FTP + SSH... le tout sécurisé!

Tue Mar 24, 2015 2:23 pm

Bonjour Jean-Luc,

merci pour ta réponse et tous les éléments apportés. C'est vachement intéressant.
Déjà, concernant le sFTP, tu as entièrement raison, c'est plutôt logique même... :roll:
Après c'est vrai que derrière une box, il faut peut être arrêter de se faire des films, les black-hat auront sûrement mieux à attaquer!
Ah paranoia... quand tu nous tiens... :lol:
Mais je pense que quelque part c'était aussi un moyen de tout paramétrer et se faire la main sur iptables et compagnie (et de se casser la tête aussi, soyons réalistes).

Concernant les liens, je vais me faire un plaisir de les lire (même si ça risque de prendre du temps avec la lecture du livre debian en plus :D ) car ça m'intéresse ces idées reçues! En effet, j'avais déjà prévu de changer le port pour SSH, de supprimer l'accès root... bref, vouloir sécuriser au maximum et tout ça éventuellement... pour rien!

Donc merci pour les lectures ainsi que pour les astuces sFTP!

jeanluc
Posts: 294
Joined: Thu Apr 11, 2013 9:44 am

Re: NAS + FTP + SSH... le tout sécurisé!

Tue Mar 24, 2015 3:30 pm

david999 wrote:Bonjour Jean-Luc,

merci pour ta réponse et tous les éléments apportés. C'est vachement intéressant.
Déjà, concernant le sFTP, tu as entièrement raison, c'est plutôt logique même... :roll:
Après c'est vrai que derrière une box, il faut peut être arrêter de se faire des films, les black-hat auront sûrement mieux à attaquer!
Ah paranoia... quand tu nous tiens... :lol:
Mais je pense que quelque part c'était aussi un moyen de tout paramétrer et se faire la main sur iptables et compagnie (et de se casser la tête aussi, soyons réalistes).

Concernant les liens, je vais me faire un plaisir de les lire (même si ça risque de prendre du temps avec la lecture du livre debian en plus :D ) car ça m'intéresse ces idées reçues! En effet, j'avais déjà prévu de changer le port pour SSH, de supprimer l'accès root... bref, vouloir sécuriser au maximum et tout ça éventuellement... pour rien!

Donc merci pour les lectures ainsi que pour les astuces sFTP!
Si tu lis tout, tu verras aussi que même si tu n'est pas derrière une box (serveur kimsufi, online..), le raisonnement est le même :

-Par défaut tous les ports sont fermés sous des distributions linux tel DEBIAN UBUNTU (inutile de mettre une porte cadenassée devant un mur) !!!
-Si le port est ouvert, c'est que tu as un service qui l'utilise, et si tu utilises ce service faut bien le laisser ouvert...

-Si tu as un service d'actif; exemple SSH , il va t'ouvrir le port 22..mais comme tu veux te connecter à ce port, il faut bien le laisser ouvert , donc le firewall ne sert a rien; seule précaution à prendre éventuellement c'est de limiter l'accès à ce port a certaines ip seulement ou d'en contrôler son accès avec fail2ban qui bannira l'ip si x tentatives de connexions infructueuses en créant lui même une règle iptables de blocage d'ip (une des seules règles iptables avec la redirection de ports si on en a besoin qui sont réellement utiles).
Ou dans ton fichier de config ssh des règles du type :
AllowUsers [email protected] [email protected] etc...

Le danger ne peut provenir que des ports ouverts, c'est pour ça que je te dis qu'il est inutile de cumuler le ftp et le sftp surtout que pour l'échange de fichiers ça ne t'apportera rien de plus, mais augmentera les risques avec 2 ports ouverts supplémentaires : (20 & 21) au lieu d'un seul (22).

De plus le ftp est à bannir, seul le ftps devrait être utilisé, car sinon les mots de passe et les flux transitent en clair; et en plus c'est souvent assez contraignant derrière une box avec les "passive ports" au changement d'ip, car si tu as une ip dynamique qui change quasiment tous les jours, bien sur il a noip, mais nécessaire de redémarrer le serveur à chaque changement d'ip pour la prise en compte, et finalement par rapport à une connexion SSH, c'est quand même beaucoup plus contraignant pour un bénéfice nul.

JumpZero
Posts: 1033
Joined: Thu Mar 28, 2013 7:35 pm
Location: 127.0.0.1

Re: NAS + FTP + SSH... le tout sécurisé!

Wed Mar 25, 2015 10:18 am

Bjr,

il existe aussi une technique inintéressante: le port knocking
http://en.wikipedia.org/wiki/Port_knocking
Je ne l'ai jamais essayée, mais je le ferais un jour. ;-)
En gros le port est fermé et ne s'ouvre qu'a la réception d'une certaine séquence prévue a l'avance.
Exemple: Je tape 5 coups rapides suivi de 2 coups lents sur ta porte, comme ça tu reconnais que c'est moi et tu ouvres...
--
Jmp0

david999
Posts: 7
Joined: Mon Mar 23, 2015 9:01 pm

Re: NAS + FTP + SSH... le tout sécurisé!

Wed Mar 25, 2015 1:02 pm

Bonjour,

@Jean Luc:
merci pour tes explications.
Pour le FTP, je suis entièrement d'accord avec toi, on oublie!

Ensuite, j'ai lu tous les posts que tu m'as mis en lien (j'avais du temps de libre :D ).
La personne qui écrit des articles pour le magazine Linux donne de très bonnes explications et de bons arguments. Cependant, même si je ne suis qu'un débutant et qu'il s'agit d'un expert, je ne suis pas d'accord sur 2 ou 3 points (je n'ai pas pour autant envie de relancer le débat qui a fait rage sur le forum ubuntu sur 7 pages):
- changer le port 22 pour le SSH: évidemment le scan des ports permettra de trouver le port utilisant SSH sans soucis, mais vu qu'il existe (apparament) des attaques automatisées visant un grand nombre d'IP sur les ports connus, cela permet d'échapper à ce type d'attaque. Et même si cela ne représentait qu'une attaque sur 500, ça ne me dérange pas de l'éviter en ayant simplement à changer le port par défaut.
- concernant le pare-feu: c'est beaucoup plus conflictuel comme débat. Je suis à 90% d'accord avec les arguments avancés par cette personne, quant au fait qu'avoir un pare-feu (qui ne fait qu'ouvrir ou fermer les ports) ne sert à rien dans la plupart des cas. Encore plus vrai derrière une box. Par contre, le fait qu'un assaillant ne puisse savoir si un port est ouvert ou fermé dû au fait qu'ils apparaissent tous comme étant filtrés ne donne aucun info à l'assaillant. Alors bien sûr, je ne me fais pas d'illusion: qqn qui connait bien son sujet sera capable de pénétrer sur le réseau malgré tout! Mais si ça donne quelques difficultés en plus... pourquoi pas! Après la vraie question, je pense, est de savoir si ça vaut la peine de mettre un pare-feu avec toute la config qui va bien, au risque de bloquer certains services et qu'un amateur (comme moi pour le moment) en pare-feu ne sache y remédier. Et donc au final une perte de temps et des problèmes pour pas grand chose...
- interdire le log in en root: J'ai bien compris qu'il vaut mieux se connecter avec des clés et non le mot de passe. Maintenant si la personne se connecte en SSH avec un mdp, en se connectant en mode user il n'aura pas forcément accès au compte admin. Certains parlent de l'utilisation de sudo, mais cela n'est pas forcément installé ou peut être désinstallé (si je ne dis pas de bêtises). Donc dans ce cas, impossible de toucher au compte root. Et quant aux attaques brute force, je pense malgré tout (comme dit sur le forum) que le fait de ne pas connaitre le username donnera toujours plus de boulot pour réussir à pénétrer le système. Ok ce n'est pas un gage de sécurité, mais je pense que ça ne facilite pas les choses à l'assaillant.

En gros, des petites modifs toutes simples peuvent faire en sorte que le niveau de sécurité soit (légèrement) augmenté. Et pour des modifs qui sont au final très simples (mise à part le pare-feu qui risque au final de compliquer la vie!).

Qu'en pensez-vous?


@Jump0:
Merci pour le lien! C'est super intéressant!
Je n'en avais jamais entendu parlé (mais en même temps je ne suis qu'un petit débutant là dedans!). Je regarderai de façon plus approfondie ce sujet.

jeanluc
Posts: 294
Joined: Thu Apr 11, 2013 9:44 am

Re: NAS + FTP + SSH... le tout sécurisé!

Wed Mar 25, 2015 5:24 pm

Salut;
Va voir ici :

http://www.git-attitude.fr/2010/09/13/c ... -cles-ssh/

Une clé ssh de 2048 est inviolable (avant que la NSA veuille bien accorder ne serait ce qu'une heure de leur puissance pour te craquer ta clé...faut pas exagérer...), alors si t'es parano t'en crée une de 4096 si tu veux, la connexion via putty ou autres sera un peu plus lente s'est tout...

Si quelqu'un s'attaque à ton port 22, il restera à la porte c'est tout !!! il finira bien par se fatiguer !!! que veux tu de plus, ça te dérange qu'il tape à la porte vu qu'il ne peux de toute façon rentrer ???

A la limite tu mets fail2ban pour le bannir 1h ou 24h, mais to OS ne risque absolument rien, et pas besoin de s'emmerder avec du port knocking, et en plus c'est bien plus facile à mettre en place.

Si tu génères une paire de clés pour root dont la publique sera dans le dossier .ssh de root, seul la personne possédant la clé privée correspondant pourra se connecter à root : toi par exemple.

Ensuite pour chacun des autres users non admin, tu leur génères aussi chacun une paire de clés, même principe que pour root, et chacun ne peut se connecter que chez lui.

Soit tu les génères sous pytty avec puttygen si t'es sous win :
http://marc.terrier.free.fr/docputty/Chapter8.html
ou sous linux:
http://jeyg.info/ssh-authentification-p ... sa-ou-dsa/

Un pare-feu sauf blocage d'ip, un nat (passerelle); ça ne sert à rien...qu'à surcharger ton serveur avec un truc inutile, au risque de bloquer un truc que tu ne veux pas bloquer..
Par contre, le fait qu'un assaillant ne puisse savoir si un port est ouvert ou fermé dû au fait qu'ils apparaissent tous comme étant filtrés ne donne aucun info à l'assaillant
Là je pense qu'il te faut relire, car t'as pas tout capté....

-Sans firewall : l'assaillant il voit un mur, ça ne vaut pas le coup qu'il insiste...
-Avec firewall (filtré): l'assaillant il voit une porte cadenassée...ça vaut peut être le coup d'essayer car il y a peu être quelque chose derrière !!!
-Un port ouvert, de toute façon tu ne peux pas le fermer si tu veux utiliser le service et là non plus les règles iptables ne servent à rien, ou alors vaut mieux désinstaller le service et l'assaillant verra alors cette porte fermée; c'est pour un port ouvert qu'intervient par exemple fail2ban qui lui va générer comme un grand une règle iptable pour bannir son ip.

D'autres liens de cette personne sur le sujet :
Logiciel malicieux à l'intérieur ou venant de l'extérieur:

http://forum.ubuntu-fr.org/viewtopic.ph ... #p18826291 :

"Je reprend maintenant mon argumentation que j'ai donnée hier soir dans un autre fil sur ce même forum.

- le blocage en entrée servirait à "protéger" le cas où un logiciel malicieux se mettrait en écoute sur un port quelconque
- le blocage en sortie servirait à "protéger" le cas où un logiciel malicieux se connecterait vers l'extérieur.

Dans les deux cas, ça n'arrive pas sur un système "propre" : on est déjà dans le cas d'une machine corrompue, il est trop tard pour penser à la sécurité......


Pas plus utile pour un serveur :

http://forum.ubuntu-fr.org/viewtopic.ph ... #p17942651 :

"L'utilité de Netfiler, c'est :
- soit de bloquer des ports que tu ne peux pas fermer (cas très rare) ;
- soit de faire un filtrage sélectif (mais je parie que ce n'est pas ce que tu envisageais de faire) ;
- soit de faire des redirections de port."


Quelles sont les bases pour sécuriser son serveur ?:

http://forum.ubuntu-fr.org/viewtopic.ph ... #p18225451

Et je précise à nouveau que je parle là d'une machine de type serveur :

http://forum.ubuntu-fr.org/viewtopic.ph ... #p17952831

J'ai commandé un Kimsufi:

http://forum.ubuntu-fr.org/viewtopic.php?id=1206651

installation et configuration d'un p'tit serveur Dedibox

http://forum.ubuntu-fr.org/viewtopic.ph ... #p13999291

david999
Posts: 7
Joined: Mon Mar 23, 2015 9:01 pm

Re: NAS + FTP + SSH... le tout sécurisé!

Wed Mar 25, 2015 9:08 pm

Salut Jean Luc,

J'hésitais à commenter les liens du forum ubuntu parce que je sentais que le sujet initial du post allait dévier, et ce n'était pas le but.

Ok pour le SSH. C'est intégré. C'est sécurisé, c'est inviolable une clé de 2048 etc...
J'ai bien compris. J'ai bien compris tes arguments, tout comme j'ai très bien compris les arguments de la personne intervenant sur le forum ubuntu: tout est question d'avoir un système sain, et de paramétrer correctement le tout, mettre de vrais mots de passe, faire les bons choix (connexion en ssh avec clé et non mot de passe)...
MAIS je ne vois (toujours) pas où est le problème d'utiliser un autre port que le port 22 par exemple? La porte est fermée et il va se fatiguer à taper? Ok, mais si il commence par se fatiguer à taper à la mauvaise porte, ça ne me dérange pas non plus!
Alors OUI, la VRAIE solution de sécurité (dans ce cas du SSH) c'est une clé SSH de 2048 et non le changement de port. Mais si le changement de port prend 2 secondes et peut éviter une attaque (sur une porte déjà ultra sécurisée certes), où est le problème?

Même chose concernant la connexion avec le compte root! Admettons que le compte est super sécurisé, il est quasi impossible de pirater la connexion avec le compte root. Mais par miracle, par une chance aussi infime soit elle, une personne réussit à pirater le compte. Ne serait il pas mieux qu'elle pirate le compte utilisateur plutôt que le compte root?

Je crois que dans tous les cas, vous partez du principe que si c'est correctement sécurisé, pas besoin d'en rajouter. Je le conçois. J'ai vu pas mal d'analogies sur le forum ubuntu par rapport à tout ça, du coup j'me lance avec la mienne! :D
Je veux fixer un superbe écran plat que je viens d'acheter, méga beau, méga lourd, et méga cher! En me renseignant, je me rends compte que des vis de 6x50mm sont largement suffisantes pour supporter la charge. Ca me laisse même de la marge.
Oui mais voilà, mon écran est tout neuf et tout cher! J'y tiens moi! Où est le problème si je décide de mettre des vis de 8 (alors que théoriquement ce n'était pas nécessaire), sachant que ça me donnera comme boulot supplémentaire juste le fait d'emprunter une mèche de 8 en plus!
Là je pense qu'il te faut relire, car t'as pas tout capté....
Pour le coup je pense avoir capté si, mais je me suis sûrement mal exprimé. Je voulais simplement dire que, d'après ce que j'ai lu sur le forum, avec la présence d'un pare-feu, l'assaillant ne sait pas si un port est ouvert ou fermé. Il n'a donc aucune info sur aucun des ports (il faudrait que je retrouve le passage en question sur le forum, l'intervenant du forum le confirmait d'ailleurs). Donc d'après ce que j'ai compris du forum, l'assaillant voit plus de 60000 ports cadenassés... C'est là que je voulais en venir.

jeanluc
Posts: 294
Joined: Thu Apr 11, 2013 9:44 am

Re: NAS + FTP + SSH... le tout sécurisé!

Wed Mar 25, 2015 11:07 pm

MAIS je ne vois (toujours) pas où est le problème d'utiliser un autre port que le port 22 par exemple? La porte est fermée et il va se fatiguer à taper? Ok, mais si il commence par se fatiguer à taper à la mauvaise porte, ça ne me dérange pas non plus!
Alors OUI, la VRAIE solution de sécurité (dans ce cas du SSH) c'est une clé SSH de 2048 et non le changement de port. Mais si le changement de port prend 2 secondes et peut éviter une attaque (sur une porte déjà ultra sécurisée certes), où est le problème?
Il n'y a absolument aucun problème, c'est tout simplement inutile....et les softs tel fail2ban prennent le 22 par défaut, bien sur tu pourras modifier le port de surveillance.
Mais quand quelque chose est inutile et n'apporte rien pourquoi le faire ???
Si t'as un serveur web, si tu veux que les gens visitent ton site, tu va bien les mettre sur le port 80 ou 443, tu ne va pas changer ces ports pour des ports exotiques, au risque de ne voir personne sur ton site...le vrai problème c'est plutôt de sécuriser ces ports que de les délocaliser.!!!
Par ce que t'a vu des tutos génériques sur le net, qui sont tous copiés les un sur les autres à peu de choses près!!!
Le gars qui parle dans ce topic, t'a vu son pédigrée ? et le nombre d'articles de publiés ? dans le topic en question et les autres liens, qui a t'on avis a les réponses les plus cohérentes ?
Même chose concernant la connexion avec le compte root! Admettons que le compte est super sécurisé, il est quasi impossible de pirater la connexion avec le compte root. Mais par miracle, par une chance aussi infime soit elle, une personne réussit à pirater le compte. Ne serait il pas mieux qu'elle pirate le compte utilisateur plutôt que le compte root?
En tant qu'admin de ton serveur, si tu ne connectes pas en root, tu crées au minimum un compte avec les droits root, si tu te fais pirater celui là (tout aussi improbable que le compte root si clés SSH), le résultat sera le même....encore un truc de bidouilleurs tout aussi inutile.

Explique nous plutôt comment un assaillant pourrait se connecter en root sur le port 22 avec :
-Une clé SSH (considérée comme inviolable)
-Et en plus s'accaparer l'ip ou le hostname de là ou tu te connectes pour pouvoir se connecter avec AllowUsers [email protected] [email protected] dans /etc/ssh/sshd_config
-Et éventuellement en plus obtenir une passphrase qui peut encore protéger l'accès à ta clé

Les robots de scans cherchent à pénétrer un max de serveurs en un minimum de temps donc souvent des serveurs avec:
-Un couple login et password faible et basique ex: toto toto260187, prénom, date de naissance, etc..(Je suis persuadé que plus des 3/4 des mots de passes utilisés puisqu'il faut qu'ils soient facilement mémorisables font moins de 12 de longueur,et mélangent rarement majuscules+minuscles+chiffres+caractères spéciaux.

Pour finir avec le pare-feu :

-Un port non utilisé est fermé -> sans y toucher personne ne pourra rentrer -> si tu mets un verrou devant (un drop) ->l'attaquant le verra comme un port filtré (mais qui ne filtre rien en réalité puisque dans un port fermé rien ne passe).

-Un vrai filtre tel que je l'entends, c'est sur un port ouvert (t'as un service derrière ex SSH sur le 22) -> donc je décide de le filtrer-> donc par exemple je fais :
1° je drop le port 22 (eh oui je drop un port ouvert!! droper un port fermé ça ne sert à rien!! )
2° j'ouvre le port 22 à l'ip 111.222.77.52
3° j'ouvre le port 22 à l'ip 84.56.89.41
4° j'ouvre le port 22 à l'ip etc...
Et là c'est un vrai filtre (vois tu la différence entre un vrai filtre ou vu comme filtré ?)
C'est d'ailleurs un des seuls cas ou les règles iptables peuvent être utiles (avec le NAT) ou dans le même principe le blocage d'ip, autre exemple, j'ai un client torrent qui se connecte par exemple au port 56235 mais j'ai une liste des ip du vilain TMG qui me surveille (moi le gentil pirate..) pour HADOPI :
1° je drop l'ip1 de TMG
2° je drop l'ip2 de TMG
3° je drop etc...ou autre solution je mets ces ip dans la blocklist de mon client torrent

Pour les autres, si tu veux partager, il te faut bien laisser le port 56325 ouvert, sinon désinstalle ton client torrent..

***Pour le SSH il est tout aussi simple et aussi efficace d'utiliser dans le fichier /etc/ssh/sshd_config la directive AllowUsers citée + haut.

Mais tous les tutos standards ne se basent que sur le drop ou le accept des ports : totalement inutile...après chacun fait ce qu'il veut et comme il pense, moi aussi avant d'avoir lu puis testé j'étais aussi fervent du firewall et je voyais ça comme un élément incontournable de la sécurité, alors que c'est plus un leurre qui aurait même tendance à donner un trop grand sentiment de sécurité qui ferait oublier la base qui est la sécurité de la connexion elle même et le bon paramétrage des applications.

J'ai un dédié kimsufi (certainement plus exposé qu'un rpi) et pas de soucis sans règles iptables de type drop ou accept de ports, les seules que j'utilise sont celles du filtrage d'ip.

La base c'est d'avoir un système propre, toujours à jour, éviter au maximum les paquets ne provenant pas des dépôts de la distribution; après chaque installation, un petit "netstat -lntup" pour bien noter les ports en écoute, voir si éventuellement il n'y a rien d'illégitime ou ne non voulu (normalement ça n'arrive jamais, mais ça ne coûte rien de vérifier); on doit toujours savoir quels ports sont en écoute et à quoi ils correspondent, et pourquoi pas mettre fail2ban comme chien de garde sur ces ports.

david999
Posts: 7
Joined: Mon Mar 23, 2015 9:01 pm

Re: NAS + FTP + SSH... le tout sécurisé!

Fri Mar 27, 2015 11:50 am

Bonjour Jean-Luc,
Le gars qui parle dans ce topic, t'a vu son pédigrée ? et le nombre d'articles de publiés ? dans le topic en question et les autres liens, qui a t'on avis a les réponses les plus cohérentes ?
J'ai vu son pédigré oui, mais je trouve surtout ses réponses et explications très cohérentes. Cependant, j'ai aussi trouvé certaines remarques d'autres personnes pertinentes, et c'est pourquoi je les exposes ici (avec ma compréhension, n'étant pas un expert en la matière).
En tant qu'admin de ton serveur, si tu ne connectes pas en root, tu crées au minimum un compte avec les droits root, si tu te fais pirater celui là (tout aussi improbable que le compte root si clés SSH), le résultat sera le même....encore un truc de bidouilleurs tout aussi inutile.
Concernant ce point, je suis entièrement d'accord avec toi. En fait, mon but de connexion en SSH à la base, était simplement d'accéder aux dossiers sur mon disque dur depuis l'extérieur.
Autrement dit, dans mon idée initiale, j'aurais eu:
- un répertoire pour le FTP
- un répertoire avec tous mes fichiers
Le SSH m'aurait permis d'accéder à tous les fichiers, alors que les utilisateurs FTP n'auraient eu accès qu'au répertoire FTP. D'où l'inutilité dans ce cas de se connecter en root.
Maintenant que le FTP est abandonné dans mon projet au profit du sFTP, je pense qu'il s'agit juste de créer plusieurs profils en SSH avec des droits différents (je n'ai pas étudié la question, il faut encore que je vois bien comment ça marche. Donc pas taper svp!!! :roll: ).

Le AllowUsers est une bonne chose, mais du coup je ne pourrais pas me connecter de n'importe quel endroit (si je ne l'ai pas autorisé préalablement). Et mon but premier pour l'utilisation du SSH était celui-là.
-Un vrai filtre tel que je l'entends, c'est sur un port ouvert (t'as un service derrière ex SSH sur le 22) -> donc je décide de le filtrer-> donc par exemple je fais :
1° je drop le port 22 (eh oui je drop un port ouvert!! droper un port fermé ça ne sert à rien!! )
2° j'ouvre le port 22 à l'ip 111.222.77.52
3° j'ouvre le port 22 à l'ip 84.56.89.41
4° j'ouvre le port 22 à l'ip etc...
Et là c'est un vrai filtre (vois tu la différence entre un vrai filtre ou vu comme filtré ?)
Oui, je comprends bien la différence. Je crois surtout que je n'ai pas non plus utilisé le bon vocabulaire dans les posts précédents à ce sujet... :?
La base c'est d'avoir un système propre, toujours à jour, éviter au maximum les paquets ne provenant pas des dépôts de la distribution; après chaque installation, un petit "netstat -lntup" pour bien noter les ports en écoute, voir si éventuellement il n'y a rien d'illégitime ou ne non voulu (normalement ça n'arrive jamais, mais ça ne coûte rien de vérifier); on doit toujours savoir quels ports sont en écoute et à quoi ils correspondent, et pourquoi pas mettre fail2ban comme chien de garde sur ces ports.
Je suis entièrement d'accord avec toi (comme quoi! :D ).
Il faut quelque chose de propre et bien paramétré avant tout.
Quant à fail2ban, même si tout le monde ne l'utilise pas, il semble plutôt faire l'unanimité. Du coup je pense le mettre en place.
A ce propos, que penses tu de Portsentry afin de bloquer le scan des ports? Cela est-il vraiment efficace ou est ce plutôt un gadget?
Même question concernant Rkhunter?

Merci d'avance pour tes réponses et pour ton aide. 8-)

jeanluc
Posts: 294
Joined: Thu Apr 11, 2013 9:44 am

Re: NAS + FTP + SSH... le tout sécurisé!

Fri Mar 27, 2015 5:04 pm

Salut;
Le AllowUsers est une bonne chose, mais du coup je ne pourrais pas me connecter de n'importe quel endroit (si je ne l'ai pas autorisé préalablement). Et mon but premier pour l'utilisation du SSH était celui-là.
Tout est possible, faut seulement y réfléchir !!!

La connexion en root, c'est uniquement pour l'administration : (mises à jour, installations, désinstallations, ...etc).

AllowUsers [email protected] (soit l'ip locale du pc) duquel tu fais ta maintenance suffit pour un rpi car je présume que la maintenance tu va la faire de chez toi; sinon il te faut installer noip qui va toutes les 5 minutes vérifier si changement d'ip publique et faire pointer cette nouvelle ip externe vers un hostname ex xx.noip.com, mais une fois en place ce n'est pas plus contraignant : AllowUsers [email protected] toute façon pour te connecter de l'extérieur il te faudra noip dans tous les cas, et pour tes amis aussi...

Ensuite tu crées des users qui eux sont chrootés dans leur home ex : user1, user2,user3,user4,user5 qui eux pourront se connecter de n'importe ou avec le hostname noip....et user1 pour toi de l'extérieur (toujours avec noip) et bien sur il te faudra ouvrir le port dans ta box.

Ton AllowUsers [email protected] devient donc AllowUsers [email protected] user1 user2 user3 user4 user5 si root ne se connecte que du domicile.
ou
AllowUsers [email protected] [email protected] user1 user2 user3 user4 user5 si tu veux vraiment te connecter en root de l'extérieur.
Maintenant que le FTP est abandonné dans mon projet au profit du sFTP, je pense qu'il s'agit juste de créer plusieurs profils en SSH avec des droits différents (je n'ai pas étudié la question, il faut encore que je vois bien comment ça marche.
Après dans chaque home tu crées un dossier partage (propriété user et groupe sftpusers 750); et tu crées un autre dossier commun dans /home/commun root:root 555; puis dedans un dossier partage root:sftpusers /home/commun/partage 750
Dans le dossier partage créer dossiers user1 user1:user1 750 ..puis idem pour les autres ou chacun déposera ses fichiers communs en lecture pour les autres, et chaque propriétaire pourra effacer ses propres fichiers communs, mais pas ceux des autres.

Ensuite tu vas dans /etc/fstab, et tu crées un montage bind de chaque dossier partage vers le dossier partage commun.

/home/commun/partage /home/user1/partage none bind
/home/commun/partage /home/user2/partage none bind
/home/commun/partage /home/user3/partage none bind
/home/commun/partage /home/user4/partage none bind
/home/commun/partage /home/user5/partage none bind
*redémarrer pour que ce soit pris en compte..

Portsentry..pas obligatoire et surtout derrière une box (pour empêcher le scan des ports de la box ???); à partir du moment que les gens ne peuvent pas rentrer, ils peuvent toujours vérifier les portes, et de toute façon si t'es une cible privilégiée (ce qui n'arrivera jamais); ils arrivent toujours à découvrir tes ports,ils vont scanner entre 20 et 30 et se faire ban, puis avec une autre ip ils vont scanner de 31 à 40 etc...à la fin ils vont bien finir par les découvrir tous, mais ou est le problème ? si t'as un serveur web, tu mets faif2ban avec les filtres adéquats sur le 80 et le 443.

Rkhunter, idem, si tu te contentes d'installer des logiciels ne provenant que des dépôts, ils sont sains (on n'est pas sous windows, ou les gens vont pêcher leurs softs un peu partout, et des gens mal intentionnés y rajoutent des tas d'addons, spyware..etc par exemple les softs pris chez softronic,..); mais ce ne doit pas être le cas sous linux, et encore moins sur un serveur ou le nombre de trucs installés est minimal : (ssh, web, mysql, nfs, samba, torrent,...on a vite fait le tour)...tout ça ce sont des déformations de windowsiens...

Un petit relevé des ports ouverts après chaque installation suffit pour voir si il n'y a rien d'anormalement ouvert.

fahdyezz
Posts: 4
Joined: Sun May 10, 2015 2:09 pm

Re: NAS + FTP + SSH... le tout sécurisé!

Sun May 10, 2015 3:41 pm

Bonjour,

J'ai lu avec beaucoup d'intérêt tous vos échanges de points de vue (si, si.., même les liens!) car j'ai un projet similaire à celui de david999. Je vous expose cela:

Dans mon cas, j'ai une Raspberry Pi 2 installée en Raspbian, système rootfs déporté sur DD Usb (80 Go), un serveur Ubuntu 14.04 dédié pour l'instant, qui me sert pour les tests.
Pour les tests, j'ai chrooté directement le home d'Ubuntu avec des utilisateurs fictifs ayant chacun leur répertoire de dépôt, et ne pouvant faire que du sftp.
J'ai une adresse no-ip.org qui pointe sur l'ip de la Rasp, ssh port 6xxx (qui sera communiquée à mes futurs "clients"), redirigée vers Ubuntu via "rinetd". Utilisation de la Rasp comme "passerelle" en quelque sorte, ou serveur de rebond ssh ou portforward.

D'aucuns m'ont déjà questionné sur l'intérêt d'une telle architecture, en arguant du fait que si la Rasp tombe, je perds l'accès à mon serveur final. "Cépafô" rétorqué-je, mais uniquement de l'extérieur, et si c'est le serveur final qui tombe, "salsepareille", non?
Je n'ai qu'une porte pour entrer chez moi, accéder à différentes pièces qui possèdent elles-mêmes leur propre porte. Il m'a donc semblé plus facile d'administrer une seule interface pour un ensemble de services, sous réserve que les différents serveurs finaux soient bien configurés. Peut-être me trompé-je?

Compte-tenu de mon architecture intérieure, la Rasp sera placée près de ma chaine HiFi (raccordée via Jack), un Dual-DD Usb (2x640Go - Raid1, Jbod ou indépendants, je ne sais encore) sera ajouté comme partage samba Ziq, et le DD Usb initial (80Go) servirait pour enregistrer les utilisateurs "chrootés". Le serveur Ubuntu, quant à lui, sera remplacé par un ou plusieurs Nas, déjà opérationnels en samba mais sur lesquels l'espace disque ne manque pas et qui ne seront pas accessibles directement depuis internet. L'idée étant de placer sur ceux-ci les répertoires des "clients" chrootés sur la Rasp.

Pour l'instant, les connexions des utilisateurs (actuellement chrootés sur le serveur final de tests Ubuntu), via Filezilla en sftp sur l'adresse no-ip.org, fonctionnent très bien.
L'inconvénient, avec rinetd, c'est la perte de l'accès ssh via PuTTY à la Rasp: j'ai essayé en redirigeant le port 22 sur la box, ou en ne mettant que le sftp dans rinetd.conf sans succès et je ne sais pas si on peut mettre deux ports différents dans le fichier sshd_config de la Rasp.
J'ai oublié de préciser que j'ai tout de même accès à la Rasp via "TightVncServer" et RealVnc. Ouf!

Après avoir cherché (je suis assez newbee, faut-il le dire?): ProxyCommand, connect-proxy, serveur de rebond, gateway ou autres PortForwarding avec NetFilter/Iptables, Proxy ou Nat, rinetd semble être une solution mais pas LA solution idéale.

En outre, en l'état actuel, les utilisateurs chrootés et leur dossier respectif sont enregistrés sur le même serveur final, alors que, dans mon idée, ces users seraient placés dans une sorte d'"antichambre" de contrôle à partir de laquelle ils seraient redirigés vers leur répertoire anonyme situé sur Nas n°1, Nas n°2, ...

Navré, c'est un peu long, mais si l'un d'entre vous peut m'apporter ses lumières afin d'améliorer mon projet, de le simplifier, ou me dire: "keucépaqomsakiphoferr!", merci d'avance.

Apprendre c'est bien, comprendre c'est mieux!

fahdyezz.

jeanluc
Posts: 294
Joined: Thu Apr 11, 2013 9:44 am

Re: NAS + FTP + SSH... le tout sécurisé!

Thu May 28, 2015 3:43 pm

Salut;
Pour les tests, j'ai chrooté directement le home d'Ubuntu avec des utilisateurs fictifs ayant chacun leur répertoire de dépôt, et ne pouvant faire que du sftp.
Tu ne confonds pas SFTP qui fonctionne avec un tunnel SSH et FTPS : (FTP /TLS /SSL), via vsftpd, proftpd..etc...sous lesquels on peut créer des users virtuels gérables dans une Bdd.

En SFTP, mis à part des users avec un shell restreint (mysecureshell, rbash, rssh, /bin/false..), ça reste des users linux, mais si ils sont chrootés et n'ont pas d'accès à la ligne de commande SSH, le virtuel n'apporterait rien de plus en terme de sécurité...surtout que tu peux leurs donner une connexion par clefs (considérée comme quasi-inviolable), et bannir la connexion par mot de passe dans le fichier sshd_config.

fahdyezz
Posts: 4
Joined: Sun May 10, 2015 2:09 pm

Re: NAS + FTP + SSH... le tout sécurisé!

Sat May 30, 2015 8:44 am

Bjr Jean-Luc

Non, je ne confonds pas sftp et fstp, mais mes users "fictifs" ne sont pas des users "virtuels" mais plutôt des users "test".

En attendant, j'ai résolu mon problème grâce à rinetd.

Le problème de perte de connexion ssh via PuTTY sur la Rasp, une fois rinetd installé pour forwarder l'adresse no-ip vers les répertoires "clients" sur le serveur final se résout en ajoutant un second port d'écoute dans le sshd_config de celle-ci, ce qui redonne la main dessus, port que je n'ai pas forwardé au niveau de la box.
Encore fallait-il savoir que c'était possible. Et donc, les utilisateurs sont chrootés uniquement sur le serveur final, et ont accès directement à leur dossier respectif en sftp, ce qui me convient.

Précision: j'ai opté pour cette solution de "passerelle" avec la Rasp car j'ai remarqué que la Livebox vire systématiquement 90% environ de mes "préférences" enregistrées (noms DNS, particulièrement) après chaque reboot ou modification hebdomadaire de mon IP externe, ce qui est particulièrement gavant quand il faut se re-coltiner à chaque fois le paramétrage des machines présentes, voire intolérable.

Donc, voilà, on peut passer ce sujet en résolu, ce que je ne sais pas faire.

Cordialement.

jeanluc
Posts: 294
Joined: Thu Apr 11, 2013 9:44 am

Re: NAS + FTP + SSH... le tout sécurisé!

Sat May 30, 2015 4:29 pm

fahdyezz wrote:Bjr Jean-Luc

Non, je ne confonds pas sftp et fstp, mais mes users "fictifs" ne sont pas des users "virtuels" mais plutôt des users "test".

En attendant, j'ai résolu mon problème grâce à rinetd.

Le problème de perte de connexion ssh via PuTTY sur la Rasp, une fois rinetd installé pour forwarder l'adresse no-ip vers les répertoires "clients" sur le serveur final se résout en ajoutant un second port d'écoute dans le sshd_config de celle-ci, ce qui redonne la main dessus, port que je n'ai pas forwardé au niveau de la box.
Encore fallait-il savoir que c'était possible. Et donc, les utilisateurs sont chrootés uniquement sur le serveur final, et ont accès directement à leur dossier respectif en sftp, ce qui me convient.

Précision: j'ai opté pour cette solution de "passerelle" avec la Rasp car j'ai remarqué que la Livebox vire systématiquement 90% environ de mes "préférences" enregistrées (noms DNS, particulièrement) après chaque reboot ou modification hebdomadaire de mon IP externe, ce qui est particulièrement gavant quand il faut se re-coltiner à chaque fois le paramétrage des machines présentes, voire intolérable.

Donc, voilà, on peut passer ce sujet en résolu, ce que je ne sais pas faire.

Cordialement.
Salut;
Satisfait que t'ai résolu ton problème...
Mais tu ne peux pas passer ce sujet en résolu, vu que tu n'es pas l'initiateur du post mais @david999 ???

Sinon, c'est quoi des users "test" ?? , j'avoue ne pas comprendre ?? je connaissais les users "linux" avec plus ou moins de droits ou d'accès au shell, voir pas du tout, et les users "virtuels"; si tu pouvais éclairer ma lanterne....ça permet d'apprendre.. car même sous google en saisissant "utilisateur user test"...ça ne m'éclaire pas !!!
:?:

fahdyezz
Posts: 4
Joined: Sun May 10, 2015 2:09 pm

Re: NAS + FTP + SSH... le tout sécurisé!

Sun May 31, 2015 8:40 am

Navré pour les users "test", je voulais dire des utilisateurs de test, comme toto, titi, ... ou user1, user2, ... ou encore user_test1, user_test2, and so on...

Par contre, comme je n'avais pas de réponse sur ce post, j'en avais ouvert un autre, et j'ai cru que ton message était sur ce dernier.
Alors il faut que je le recherche, ce qui ne me pose pas de problème, mais pour le marquer en résolu, c'est ce que je ne sais pas faire.

Au fait, pendant que j'y suis, j'ai préparé un serveur final en Debian Jessie x64 dans le cadre de ce projet.
Première galère, impossible d'utiliser ma carte graphique Nvidia GeForce 7500 LE pourtant fonctionnelle. Le pilote "nouveau" ou les pilotes nvidia ne gèrent pas cette carte en Debian 8 (du moins en x64).
J'ai donc changé pour une GeForce 8400 Gs ayant l'air de faire l'affaire (une semaine pour comprendre).
Mais, parce qu'il y a toujours un MAIS, impossible d'avoir un écran distant sur mon PC portable en Win 7.
J'ai essayé avec tightvncserver, vnc4server, ssvnc et d'autres, je n'arrive pas à avoir de bureau (gnome-session) ni de terminal alors que la connexion s'établit correctement avec RealVnc: j'ai un écran gris, vide, sans aucun moyen de faire quoi que ce soit. J'ai tenté diverses configurations des fichiers (.xstartup entre autres) mais apparemment, personne n'a de soluce concrète sur le net. J'ai bien un icône "Partage de bureau" sur ma Debian, mais il ne lance rien, donc je ne sais pas s'il est actif ou désactivé, ce qui semble être obligatoire pour échanger avec VNC.
Aurais-tu une idée la-dessus? Je veux dire sur Deb 8?

Return to “Français”