lo-ol

“Life is like riding a bicycle. To keep your balance you must keep moving.”

synology

Certificats SSL gratuits pour sécuriser un NAS Synology

Rédigé par lolo • 04 juin 2015 • 7 commentaires

Cela faisait un moment que je cherchais un moyen simple et gratuit de sécuriser davantage mes connexions à mon nas Synology. L'activation du mode https (voir ici) est une première étape mais cela ne suffit pas pour sécuriser les échanges. De plus, cette méthode à un inconvénient : à chaque connexion en https, un message d'avertissement apparaît pour signaler que le certificat du site n'est pas reconnu.

Dans mon cas, le fait de ne pas avoir de certificat me pose un autre souci ; je ne peux pas utiliser les clients CalDavZAP et CardDavMATE en mode https :-(.

J'ai donc cherché un moyen de mettre en place un certificat SSL sur un NAS Synology et j'ai trouvé cet  excellent tutoriel :

http://missilehugger.com/819/free-ssl-certificate-to-secure-your-synology-nas/

En suivant celui-ci, vous pourrez obtenir gratuitement un certificat SSL valable un an pour un nom de domaine et un sous-domaine associé (www par exemple).

Suite à cela, vous pourrez vous connecter en https directement (plus de message d'avertissements) et utiliser les clients CalDavZAP et CardDavMATE en https. A ce propos, la société qui met à disposition ces deux clients (inf-it) propose désormais une nouvelle application InfCloud qui fusionne CalDavZAP et CardDavMATE. Affaire à suivre...

Enjoy !

ShellShock et Synology

Rédigé par lolo • 26 septembre 2014 • Aucun commentaire

Pour ceux qui n'auraient pas suivi l'actualité de ces derniers jours, une gigantesque faille nommée ShellShock a été découverte dans le célébrissime interpréteur de commande "Bash" sous Linux (et également sous Mac Os). Je ne vais pas revenir sur celle-ci, de nombreux sites l'ont déjà fait (par exemple https://shellshocker.net/).

Apparement, cette vulnérabilité existe depuis une vingtaine d'années mais maintenant qu'elle est connue, c'est le branle-bas de combat entre les pirates en herbes qui vont s'en donner à coeur-joie et les sys-admin qui vont devoir payer les pôts cassés. En tout cas, après la désormais célèbre faille "HeartBleed", voilà qui ne va pas redorer le blason du monde du libre...

Bref, maintenant que le problème est connu, la question est de savoir s'il nous impacte en tant que possesseur de nas Synology.

Pour cela, il suffit de se connecter à son nas depuis un terminal et de lancer la commande suivante pour connaitre le shell utilisé :

$ echo $SHELL

Si vous n'avez pas installé de paquets alternatifs via ipkg, vous devriez avoir comme résultat :

/bin/ash

Il s'agit du shell utilisé par défaut par le nas. Il n'est pas impacté par la vulnérabilité. Pour s'en assurer, vous pouvez tester les commandes ci-dessous :

Exploit 1 (CVE-2014-6271)

env x='() { :;}; echo vulnerable' /bin/ash -c "echo this is a test"

Exploit 2 (CVE-2014-7169)

env X='() { (a)=>\' /bin/ash -c "echo date"; cat echo ; rm -f echo

Ouf, c'est rassurant smiley.

En revanche, si vous avez installé bash depuis le gestionnaire de paquets ipkg, vous êtes concerné par la faille et je vous conseille de l'enlever au plus vite :

$ /opt/bin/ipkg remove bash

Si vous souhaiter garder un shell un peu plus évolué que celui installé par défaut, vous pouvez vous tourner vers zsh qui est au moins aussi bien que bash, la vulnérabilité en moins.

Notification mail synology depuis OVH dédié et derrière une freebox

Rédigé par lolo • 05 août 2014 • 1 commentaire

Pour ceux que ça intéresse, je viens de perdre 2 heures à essayer tout un tas de bidouilles pour paramétrer la notification par email de mon nas synology connecté derrière une freebox en utilisant une boite mail hébergée chez ovh.

En fait, c'était tout simple, arggggghhh !!!

Il suffit de renseigner les différents champs comme suit :

Récepteurs : l'adresse ou vous voulez recevoir la notification

Préfixe du sujet : comme vous voulez (par exemple "NAS - ", ça peut aider pour trier ses emails ;-))

Fournisseur de service : Serveur SMTP personnalisé

Serveur SMTP : ssl0.ovh.net

Port SMTP : 465 (ovh conseille d'utiliser le port 587 mais j'ai pas réussi à faire fonctionner les notifications avec)

Ensuite, vous cochez "Authentification requise" et renseigner les champs associés :

 - Nom d'utilisateur : Adresse mail que vous souhaitez utiliser pour l'envoi (du type )

 - Mot de passe : le mot de passe associé à l'adresse mail

Ensuite, on coche l'utilisation de la connexion sécurisée (SSL/TLS) en renseignant les champs associés :

- Nom de l'émetteur : Nom de l'expéditeur du mail

- Adresse email de l'émetteur : même adresse que celle renseignée dans le champ "nom d'utilisateur"

 

Au début, je pensais que le problème venait de redirections de ports manquantes. Mais vu que dans mon cas je n'est pas de serveur de mail sur mon nas et que je fais directement appelle au smtp d'ovh, je n'ai besoin d'aucune redirections (j'ai mis du temps à m'en rendre compte !).

Et voilà, en espérant que ça pourra dépanner quelqu'un.  Enjoy !

Bye bye Gmail - Phase 1

Rédigé par lolo • 02 août 2014 • Aucun commentaire

De pourquoi il est difficile de trouver une alternative à Gmail

Une des plus grosses difficultés pour ceux, qui comme moi, cherche à se désintoxiquer de Google, est de trouver une solution alternative viable à l'un des services clés de Google : Gmail. En effet, ce service est le plus critique car son interface permet de gérer simplement et efficacement ses mails mais également d'accéder à ses contacts, ses listes de tâches et de discuter en ligne avec ses amis. Et si comme moi vous utilisez gmail pour vos échanges pro et perso, vous avez intérêt à ce que votre alternative soit fiable et avec une haute disponibilité si vous ne voulez pas perdre vos mails dans la nature.

Cela fait un moment que je cherche à remplacer Gmail puisque j'avais déjà évoqué, il y a 2 ans maintenant (degooglization-un-an-apres), la mise en place d'une solution en auto-hébergement basée sur le serveur de mail fournit par Synology (mailstation) et le webmail libre et open-source roundcube. J'avais, à l'époque, mis en place cette solution mais était resté en attente de plugins roundcube permettant de synchroniser les contacts avec un serveur cardDAV et de gérer les agendas synchronisés avec un serveur calDAV. Et depuis, pas grand chose ...

En fait, je suis resté bloqué pour plusieurs raisons. Tout d'abord, j'ai cherché une solution alternative proposant des fonctionnalités quasi-équivalentes à Gmail :  une gestion des mails couplée aux contacts et agenda au minimum. De plus, une solution en auto-hebergement ne pouvait pas me permettre de garantir une haute disponibilité. En effet, mon nas ne fonctionne pas 24h/24 (oui, lui aussi dort la nuit) et il peut être soumis à des pertes de connexions dûes à mon fournisseur d'accès. Bref, cette solution n''était pas envisageable pour gérer mes mails pro et perso.

Vers une solution de migration de mon compte Gmail

Ce week-end, j'ai décidé d'aller de l'avant en songeant au fameux adage : "le mieux est l'ennemi du bien". J'ai donc pris la résolution de ne pas attendre le mouton à cinq pattes et de me contenter d'une solution qui gère uniquement les mails (mais les gère bien).

Pour cela, j'ai fait une croix sur l'auto-hébergement des mails et j'ai décidé de passer par un serveur dédié. Je me suis alors souvenu qu'OVH propose avec toute location de nom de domaine, un hébergement limité à 5 Go pour une adresse mail. Cela me suffira pour le moment.

Après avoir passé pas mal de temps à fouiller dans l'interface d'administration d'OVH (qui semble daté des années 80 et est terriblement contre-intuitive), j'ai trouvé l'option pour activer le pack start1m gratuit qui me permet d'ajouter une adresse mail (pourquoi n'est-il pas activé par défaut ?).

Ensuite, rien de bien compliqué. On crée une adresse mail et un mot de passe. OVH fournit plusieurs webmail dont roundcube (ça tombe bien !). Pour y accéder, il faut vous rendre ici : https://ssl0.ovh.net/fr/.

OVH met à disposition un outil pour récupérer tous les mails d'un compte tiers : IMAPCopy. Plus d'info sur la manière de l'utiliser ici.

Ensuite, vous pourrez récupérer vos contacts en les ayant au préalable exporter au format "vCard" depuis Gmail. Que du bonheur !

Conclusion

J'ai enfin trouvé une solution à mon problème d'hébergement d'emails ! Ouf, il était temps ! Certes celle-ci n'est pas parfaite car mes données sont toujours hébergées par un tiers. Mais ce tiers me semble plus digne de confiance et a l'avantage d'être localisé en France (ça c'est mon côté chauvin). En terme de disponibilité, rien à dire puisque le service est dispo 24h/24. Il faut désormais que je réadresse tous mes comptes internet et informe mes contacts (c'est la partie pénible qui risque de prendre pas mal de temps). Autre point positif : mon nas va pouvoir être débarassé de la gestion des mails. Reste à voir si l'absence de synchronisation cardDAV/calDAV dans le webmail roundcube va être facile à accepter.

Gérer ses dépôts Git sur son serveur Synology

Rédigé par lolo • 01 février 2014 • 522 commentaires

Après avoir utilisé le site collaboratif Github pour héberger mes dépôts git, j'ai décidé de mettre en place une solution équivalente sur mon propre serveur Synology.

Je ne vais pas revenir sur les raisons qui m'ont poussé à auto-héberger mes dépôts, d'autres l'ont déjà bien expliqué avant moi (voir par exemple l'article de Sheevaboite).

Côté interface web, j'ai choisi d'installer Gitlist, un simple visualisateur de dépôt git écrit en PHP.

Etant donné que j'ai quand même un peu galérer pour mettre la chose en place, je vais décrire la procédure que j'ai suivi sur mon nas Synology pour l'installer.

Configuration du serveur Git depuis le DSM :

La première étape consiste à récupérer et installer le paquet "Git server" fourni par Synology. Ensuite, on crée un nouvel utilisateur "git" spécifique en faisant attention à lui donner les droits d'accès qui conviennent. Dans mon cas, j'ai affecté l'utilisateur "git" au groupe web du syno car c'est là que je vais placer mes dossier git.

Création des répertoires git et initialisation d'un premier dépôt depuis le serveur :

On se connecte en ssh au serveur pour crée un dossier qui va contenir les projets git (ici dans le répertoire web) :

mkdir /volume1/web/git

Pour l'exemple, nous créons un projet "test" et on l'initialise puis on donne les droits à l'utilisateur git et au groupe web apache pour le tout ("http" pour la version DSM 5.0) :

cd /volume1/web/git
mkdir test
cd test
git --bare init
chown -R git:http /volume1/web/git

Premier commit depuis l'ordinateur local vers le serveur :

Nous avons désormais un premier dépôt prêt à être utilisé sur le serveur. Il ne reste plus qu'à le remplir. Pour cela, on se connecte sur son ordi local et on va envoyer le contenu de notre dossier "test" vers le serveur :

# sur l'ordi de l'utilisateur
cd test
git init
git add .
git commit -m 'initial commit'
git remote add origin git@server:/volume1/web/git/test
git push origin master

Si tout s'est bien passé, les sources sont désormais sur le serveur et un utilisateur peut les récupérer via :

git clone git@server:/volume1/web/git/test

Et pour mettre à jour son répertoire local :

git pull origin master

Installation et configuration de Gitlist :

Pour installer Gitlist, pas de difficulté particulières. Cela se fait de manière classique et on trouve de nombreux tutos sur le net comme ici.

Pour ce qui est de la configuration, il faut définir le chemin d'accès vers le dépôt git. Dans mon cas, mes dossiers git et gitlist étant tous les deux à la racine du dossier web (/volume1/web). J'ai dû modifié le fichier conf.ini dans gitlist  de la manière suivante :

[git]
client = '/usr/bin/git' ; Your git executable path
default_branch = 'master' ; Default branch when HEAD is detached
repositories[] = '../git/' ; Path to your repositories
...

Et voilà, un serveur git perso avec une jolie interface web KISS ! Un pas de plus vers l'indépendance.

Github -> Git server + Gitlist