Évidemment, Synology prend très au sérieux le problème et invite les utilisateurs touchés par le problème à prendre contact avec son support technique.
A priori seules certaines versions de DSM seraient touchées par le problème, mais comme il vaut prévenir que guérir, je vous propose dans la suite de ce tutoriel quelques précautions que l’on peut prendre pour protéger son appareil…
Disons le tout de suite, d’après Synology, le DSM 5.0 ne présenterait pas ce problème (aucun Nas sous DSM 5.0 n’aurait été répertorié à ce jour comme ayant subi ce ransomware) et seules des versions du DSM 4.3-3810 et antérieures présenteraient une faille permettant à SynoLocker d’être installé. En tout état de cause, si vous êtes touchés, ne payez rien, et contactez Synology par leur formulaire de support dédié .
Néanmoins comme une nouvelle faille est toujours possible, voici ce que personnellement j’applique depuis des années pour me protéger « un peu » pour les serveurs et Nas que j’administre au quotidien. Cela diminue les risques mais ne le réduit jamais à zéro ….
1ere suggestion : Tout d’abord , on ne garde pas de compte Administrateur avec un mot de passe trivial du type admin/admin.
C’est bête à dire , mais cela existe encore tellement que de le rappeler n’est peut-être pas inutile. De même si l’appareil s’appelle par exemple : Nas_de_Sam , on ne choisira pas le couple identifiant admin/sam… Choisir un mot de passe avec des lettres en majuscules et minuscules , ainsi que des chiffres et pourquoi pas des caractères spéciaux est plus que recommandé pour un compte administrateur… et souhaitable pour un compte utilisateur.
2eme suggestion : On n’ouvre sur un routeur que les ports vraiment nécessaires !!!
Ne pas mettre son Nas Synology directement en DMZ parce que c’est « plus simple à configurer… » Je vous propose pour cela de relire un de mes tutoriels qui explique comment donner accès à son Nas Synology depuis Internet. Pour renforcer la sécurité, et si c’est pour un accès à un nombre très restreint de personnes que l’on connait bien , on peut utiliser en plus des ports non standards pour la redirection en faisant du PAT (Port Address Translation). Ainsi, au lieu d’autoriser l’administration sur le port 5001, pourquoi ne pas utiliser le port 5551 depuis l’extérieur, afin d’éviter les « bots » qui scannent les ports de services standards.
3eme suggestion : utiliser la version firmware la plus récente.
Tous les constructeurs « sérieux » font évoluer les programmes qui animent leurs matériels. Synology n’échappe évidemment pas à cette règle car c’est un constructeur « sérieux ». Néanmoins , par le passé , certaines mises à jour n’ont pas été un franc succès ( j’ai démarré avec un des premiers Synology baptisé DS-101g en 2005 et j’ai connu quelques déconvenues de mise à jour imputable à une mauvaise finalisation de la part de Synology ) et depuis j’attends toujours quelques semaines sur les NAS en production après la sortie officielle… Je remarque néanmoins que leurs processus de publication s’est nettement amélioré ses derniers temps car TRÈS peu ou pas de désagrément se sont révélés après des mises à jour. Il suffit d’ailleurs de suivre l’actualité des mises à jour sur le site de Synology pour se rendre compte que dorénavant peu de mise à jour viennent corriger des bugs d’une précédente.
Cela permet ainsi, outre d’accéder à de nouvelles fonctionnalités, de combler également des failles de sécurité qui ont été détectées par Synology lui-même ou par les utilisateurs. Ainsi, dans le cas de SynoLocker, Synology annonce que les mises à jour réalisées avec les versions DSM depuis Décembre 2013 évitent la « contamination » par ce ransomware.
4eme suggestion : n’utiliser que des protocoles cryptés pour s’identifier à distance.
Que ce soit pour accéder à l’interface Web d’administration de son Nas ou en FTP ou en ligne de commande ou encore WebDAV , etc … on n’utilisera que les version « S » (sécurisation par cryptage) de ces protocoles . Ainsi , pas d’interrogation de l’interface d’administration en HTTP mais plutôt en HTTPS, pas de FTP mais du FTPS , pas de Telnet mais du SSH, etc … Seuls les protocoles où il est nécessaire d’utiliser un mot de passe sont concernés. En effet, si vous héberger votre site perso sur votre Nas, il est inutile de faire un accès en HttpS pour seulement du contenu public sans authentification.
5eme suggestion : utiliser le dispositif de blocage automatique des connexions.
C’est ce dispositif sur lequel je vais m’attarder dans la suite de ce tutoriel, qui à défaut d’éviter complètement les piratages, permet de les freiner voire de décourager les pirates.
Voyons en détail la mise en oeuvre dans la page suivante.