Archive pour la catégorie ‘Sécurité’

Eh oui, encore une bizarrerie du linux-like de Synology : pas de scp ni de sftp par défaut. Ces deux softs faisant quand même partie de la base des utilitaires indispensables, voilà comment les installer sans tout casser.

Tout d’abord, installez les paquets zlib et openssl :

Pour installer scp et sftp il faut faire un peu attention : il y a une version spécifique de ssh installée sur les NAS Synology, c’est pourquoi il ne faut pas installer directement le paquet openssh par ipkg.

Commencez par créer un répertoire de travail :

Téléchargez le paquet openssh (sans l’installer!) :

Extrayez les fichiers contenus dans le paquet openssh :

Copiez les exécutables scp et sftp dans /bin :

Renommez openssh-scp :

Créez le lien symbolique suivant (essayez sans, mais chez moi c’était nécessaire) :

Supprimez votre dossier de travail :

Et c’est tout!

Article rédigé d’après cet article, avec quelques mises à jour. Merci à son auteur.

Deuxième article sur mon NAS Synology DS411j, cette fois ci simplement pour passer outre une limitation mise en place par Synology : l’accès en ssh est réservé à l’utilisateur root (ou admin).

Cette limitation a sans doute du être mise en place dans un souci de simplicité pour le grand public, limitant ainsi l’accès au propriétaire du NAS, qui est supposé savoir ce qu’il fait s’il a activé l’accès ssh.

Cependant, cette limitation pose 2 problèmes :
– Tout d’abord, il est déconseillé d’activer l’accès ssh en root à une machine GNU/Linux, pour des raisons de sécurité. Cette limitation va complètement à l’encontre de ce principe élémentaire.
– En plus, dans l’optique de l’utilisation de rsync sur le protocole ssh, ce que je veux mettre en place pour mon futur système de sauvegarde (ça fera l’objet d’un autre article), il faut absolument que chaque utilisateur ait un accès ssh au NAS

La procédure n’est pas très compliquée, mais il faut faire attention à ce que l’on fait car on peut très vite tout casser (et ne plus pouvoir se connecter en ssh du tout par exemple…).

1) Créer un utilisateur ordinaire depuis l’interface web du NAS.

Appelons le julien dans la suite. Je l’ai configuré pour appartenir au groupe « users ».

2) Se connecter en root au NAS.

Il faut bien sûr activer le service ssh au préalable, par l’interface web du NAS. Je conseille d’également activer le telnet pour la durée des manipulations décrites ici, cela permettra un accès de secours au NAS si on casse le SSH…
Pour se connecter en ssh, c’est comme toujours, depuis un terminal Linux :

Le mot de passe est le même que celui de l’administrateur dans l’interface web.

3) Créer le profil de l’utilisateur.

Je conseille la création d’un dossier /volume1/users/ avec dans ce dossier un dossier par utilisateur « standard », qui permettra de mettre tout ce qui est administration des utilisateurs dans ce dossier et non pas dans /volume1/homes/ car ce dossier sera accessible directement par le navigateur de fichier de l’interface web (FileStation). Les fichiers « d’administration » de l’utilisateur (le .profile en l’occurrence) y seront visibles. Cependant, si vous préférez, vous pouvez vous passer de ce nouveau dossier et utiliser /volume1/homes/.
Ensuite, il faut créer (dans le dossier /volume1/users/julien donc) le fichier .profile de julien, sur la base de celui de root.
C’est parti :

Changer la ligne suivante :

Par celle-ci :

4) Adapter le fichier /etc/passwd.

Sauvegarder le fichier /etc/passwd original et adapter sa copie :

Modifier la ligne suivante (elle peut varier légèrement chez vous) :

Pour cette ligne là :

Le dossier « /volume1/users/julien » indique le dossier dans lequel se placer quand l’utilisateur se connecte. C’est aussi dans ce dossier que sera cherché le fichier .profile, pensez donc à adapter ce dossier si vous avez mis votre .profile ailleurs.

5.a) Configurer la lecture du .profile du nouvel utilisateur

Ici, il y a 2 cas de figures.

– Vous avez choisi de n’avoir qu’un seul dossier pour l’utilisateur (/volume1/homes/julien à priori) et le fait de voir le fichier .profile trainer dans l’interface de FileStation ne vous gène pas : passez à l’étape 6).

– Vous avez choisi de suivre ma configuration, avec un dossier « technique » (/volume1/users/julien), dans lequel vous avez mis le .profile, et un dossier « utilisateur » (/volume1/homes/julien) : il faut bidouiller un peu pour s’en sortir. Si vous voulez juste appliquer ce que je dis sans trop comprendre le problème, passez au 5.b).

Sinon je vous explique le problème : il faut que le fichier .profile ne soit pas dans le dossier de connexion de l’utilisateur (configuré dans le /etc/passwd). En effet, FileStation utilise le dossier configuré dans /etc/passwd comme dossier « racine » pour l’utilisateur et on fini par tourner en rond :

– soit on a /volume1/users/julien/ dans /etc/passwd et lors de la connexion en ssh tout se passe bien, le fichier .profile est pris en compte mais dans FileStation on se retrouve aussi dans ce dossier /volume1/users/julien/ alors qu’on voulait être dans /volume1/homes/julien/ (et en plus on voit le fichier .profile du coup ^^ )

– soit on a /volume1/homes/julien/ dans /etc/passwd et on est au bon endroit dans FileStation, mais à la connexion en ssh le .profile sera cherché dans /volume1/homes/julien/, ne sera pas trouvé, et le profile par défaut sera appliqué. On sera bien connecté dans /volume1/homes/julien/ mais la variable $HOME vaudra par exemple « /root », ce qui fait que lorsqu’on passe la commande suivante, on n’a pas vraiment le résultat espéré :

Inattendu hein? :p
L’astuce consiste en fait à modifier le fichier de profile par défaut : /etc/profile. J’explique cela dans le paragraphe suivant.

5.b) Modifier le fichier /etc/profile

Au final, nous voulons donc avoir le dossier /volume1/homes/julien/ comme dossier de connexion par défaut, aussi bien pour le ssh que pour FileStation, tout en prenant en compte le fichier de profile /volume1/users/julien/.profile.
Cela se fait en modifiant le fichier /etc/profile de la manière suivante (ajout des 3 dernières lignes) :

6) Vérifier la bonne configuration de l’utilisateur.

Exécuter les commandes suivantes :

Le résultat de toutes ces commandes est très important. La seule chose qui doit changer chez vous est « julien ». Vous remarquerez que comme le dossier de connexion configuré (/volume1/users/julien) est différent de la valeur attribuée à la variable $HOME à l’étape 3 (/volume1/homes/julien), la commande cd ne nous met pas dans notre répertoire de connexion, mais bien dans notre home. Vous pouvez bien sur mettre un autre dossier dans $HOME à l’étape 3 (comme le dossier /volume1/users/julien, je ne l’ai pas fait parce que je veux garder ce dossier strictement administratif).

7) Configurer sshd.

Commencer par sauvegarder la configuration originale :

Puis adapter la configuration à votre convenance. Les points essentiels sont les suivants :
– Changer la ligne « #Protocol 2,1 » pour « Protocol 2 » (désactivation de ssh v1) si ce n’est pas fait
– Changer la ligne « #PermitRootLogin yes » pour « PermitRootLogin no » pour interdire la connexion en ssh de root (conseillé d’un point de vue sécurité, je ne l’ai pas fait pour des raisons pratiques pour le moment)

Vous pouvez également adapter les 2 lignes suivantes en fonction de ce qui vous parait raisonnable d’un point de vue sécurité :
– « #LoginGraceTime 2m » (par défaut, 2 minutes) : Le serveur se déconnecte après ce délai si l’utilisateur ne s’est pas connecté. Si la valeur est 0, il n’y a aucune limite de temps.
– « #MaxAuthTries 6 » (par défaut, 6 essais) : Nombre maximum d’essais de mot de passe pour la connexion.
– Pour les autre options : « man ssh » dans google =)

8) Redémarrer le démon sshd.

Avant de redémarrer sshd, je vous conseille encore une fois d’activer (provisoirement si vous voulez) le telnet sur votre NAS.
Le démon sshd peut être redémarré de plusieurs manières. La plus simple est de désactiver puis de réactiver le service ssh dans l’interface web. Déconnectez vous avant de faire ça. Sinon, vous pouvez utiliser la commande suivante :

Ou alors, plus brutal, vous pouvez éteindre et rallumer votre NAS.

9) Tester que ça fonctionne!

Se connecter en tant que julien pour voir si ça fonctionne, depuis votre poste Linux :

Si vous avez bien tout suivi, ça devrait fonctionner. Sinon, vous pouvez toujours tenter de me poser une question, je ferai ce que je peux pour vous aider…

Attention

J’ai vu sur le net que le fait de modifier les caractéristique des utilisateurs pour lesquels on a activé le ssh par l’interface web remettait la configuration par défaut et que du coup le ssh ne fonctionnait plus. Si c’est le cas, il vous suffit de ré-appliquer la procédure ci-dessus, ça devrait fonctionner. Au pire, faites les manips en vous connectant via telnet en root. Cela dit, je n’ai pas encore essayé ceci. Synology a peut-être corrigé ce problème maintenant.

Sources utilisées pour cet article

http://bernhard.hensler.net/blog/synology-enable-ssh-user-login-other-than-root/
http://www.delafond.org/traducmanfr/man/man1/ssh.1.html
http://unixhelp.ed.ac.uk/CGI/man-cgi?ssh+1

Cela fait maintenant presque 2 ans que j’ai un serveur qui tourne en (presque) continu, avec SSH sur le port par défault et fail2ban pour refouler les prétendants non désirables.

Comme fail2ban offre la possibilité d’envoyer un mail à chaque attaque, ainsi qu’un WHOIS sur l’ip de l’attaquant, il est possible de faire quelques statistiques. Voici d’abord les résultats, puis la méthode.

Résultats

Pays d’origine de l’attaque

Voici le top 10 des pays:

Un total de 2018 informations de pays ont été extraites des 1044 mails.  Cette différence s’explique par le fait qu’une partie des WHOIS mentionnent plusieurs fois le pays (organisation, FAI, contact technique, ..). Cependant, ces informations en trop ne sont pas spécifiques à des pays en particulier, et n’impactent pas les statistiques.

Comme la Chine écrase les autres pays, ces données sont affichés de manière logarithmique sur les graphiques suivants:

On peut donc voir qu’on se fait allègrement pourrir par la Chine. Les pays les plus attaquants sont en règle générale des pays émergents et/ou très peuplés. Je pense qu’on peut attribuer la cinquième place de la France au fait que le serveur se situe sur un réseau francais (ou alors j’ai des voisins taquins).

Vous pouvez également regarder la liste complète des pays.

Nom d’utilisateur

Voici le top 10 des noms d’utilisateurs essayé par les attaquants:

Un total de 9849 noms d’utilisateurs ont été extraits des mails (2581 différents).

On peut voir que les hackers visent logiquement au plus rentable. L’user root n’est cependant qu’en 4ème position, probablement car la première chose à faire sur un serveur est de désactiver l’accès root par SSH.

Vous pouvez également regarder la liste complète des noms d’utilisateurs.

Méthode

La première étape est de récupérer les mails au format texte. Comme Gmail n’offre pas de fonction d’exports, je me suis connecté à ma boite mail avec thunderbird en IMAP. Ensuite on fait une recherche avec les termes « fail2ban banned » et on exporte la selection au format eml.

La deuxième étape est d’extraire les informations. Pour ça, la ligne de commande est toute indiquée. Voici les commandes magiques:

Ici, grep pour sélectionner les bonnes lignes, awk pour récupérer le bon mot, sort et uniq pour trier et compter, et un coup de sed pour remplacer des espaces par des points-virgule pour contourner un comportement un peu étrange de sort qui considère que « 23 46 » est le nombre 2346.

La récupération des noms d’utilisateurs se fait en deux fois, car le message est différent si l’utilisateur existe réellement sur la machine.

Conclusion

Voilà, je vous laisse vous faire votre propre avis sur la chose. Personnellement, j’ai pu constater grâce à ce serveur et un autre, que changer le port par défaut de SSH, d’avoir des mots de passe complexes et d’utiliser fail2ban pour éviter les brutes forces amène à une relative tranquillité face à ces attaques. A moins bien sur de s’être fait des ennemis ou d’héberger la banque de France =)