Effacement sécurisé de disque

Bonjour à tous,

Aujourd’hui j’aimerai aborder un sujet important que je trouve trop souvent négligé. La question de l’effacement sécurisé d’un disque, d’une clé USB et par extension tout autre moyen de stockage.

Depuis plusieurs années, j’utilise une méthode qui a fait ses preuves, j’ouvre complètement le disque, casse les plateaux ou si ils ne cassent pas, je les maltraite au maximum puis termine le démontage.

L’ensemble part ensuite à la déchetterie. Ici, on parle de vieux disques, capacité très faible (quelques Giga), connectique obsolète (IDE, et oui !).

Dernièrement, une clé USB a donné des signes flagrants de faiblesses, impossible de la monter sur n’importe quel système. Conclusion, il faut s’en séparer. Oui, mais pas n’importe comment !

Par un heureux miracle, après plusieurs semaines sans toucher la clé en question, elle monte sur un système linux. J’en profite pour récupérer quelques bricoles (rien de vitale) puis je démarre quelques manipulations.

1. Suppression de la partition via gparted
2. Création d’une nouvelle partition FAT 32 via gparted aussi
3. Utilisation de shred

shred, comme son nom l’indique (en anglais) sert à déchiqueter des fichiers, c’est à dire remplacer le contenu du fichier par de l’aléa. Très bien mais ce qu’il me faut c’est effacer tout le disque.

ATTENTION – Cette action est IRREVERSIBLE et effacera DEFINITIVEMENT les données, il est impératif de s’assurer que l’on spécifie le bon disque !

Pour lister l’ensemble des disques :

fdisk -l

Pas de problème, il suffit d’indiquer à shred le disque à effacer, pour moi /dev/sdb :

shred -n1 -z -v /dev/sdb

-z pour écrire des 0 après le déchiquetage

-v pour le mode verbose

-n1 1 passe d’écriture

A titre d’exemple, pour une clé USB de 8 Go, il aura fallu 32 minutes d’exécution.

Un dernier point important, cette méthode ne fonctionne pas totalement sur les systèmes de fichiers journalisés ou certains environnements tels que les systèmes RAID. Pour le vérifier, tout est expliqué dans le man de l’application.

man shred

Si vous désirez en savoir plus sur les normes d’effacement de données, vous pouvez consulter les pages wikipedia :

• https://fr.wikipedia.org/wiki/Effacement_de_donn%C3%A9es
• https://en.wikipedia.org/wiki/Data_erasure

Stay tuned !

Publicité

Réception d’images SSTV de l’ISS

Bonjour à tous,

Durant le week-end du 16-17 février 2019, la station spatiale internationale, l’ISS, émettait des images SSTV (Slow Scan Television) sur une fréquence radioamateur.

Un total de 12 images a été transmis durant l’activation planifiée du 15/02/2019 à 08h45 UTC jusqu’au 17/02/2019 à 17h25 UTC.

La fréquence de réception est 145.800 MHz en FM et le mode PD-120.

Les conditions de réception : Kenwood TH-F7 + antenne magnétique 1/2 onde.

L’objectif pour moi était de montrer aux enfants qui passaient à la maison (et oui il y a de l’activité), ce que l’on pouvait recevoir avec peu de moyens et provenant de l’espace. Ce n’est pas tous les jours que l’ISS envoie des images.

Pour les heures de passage, j’utilise Gpredict sur Xubuntu.

Côté décodage, j’ai commencé avec l’application Robot36 sur mon smartphone Android, après 2 passages de la station, je décide d’arrêter car le résultat n’est vraiment pas terrible. Cependant, j’ai constaté sur Twitter que certains avaient une qualité de décodage bien supérieure à la mienne.

Finalement, je décide d’utiliser une technique qui avait fait ses preuves quelques années en arrière pour le passage des « cubes sat » et plus particulièrement ARISSAT-1.

J’ouvre le squelch du pocket puis j’utilise la fonction magnétophone du smartphone. Pour moi le fichier de sortie est en m4a.

Après transfert sur le PC, j’utilise Audacity pour la conversion en format wav.

Enfin, je configure QSSTV pour lire le fichier audio en question à la place de ma carte son pour une capture en temps réel.

Le résultat est plutôt bon.

Sites web intéressants :

• Site officiel ARISS US
• Site de l’ARISS France
• Galerie des images reçues
• Blog de l’ARISS US pour les transmissions SSTV
• Demande de diplôme

A noter que pour les demandes de diplôme il faut être rapide (cette information m’avait échappée) car la limite était fixée au 19/02/2019.

Stay tuned !

Patcher son VMware ESXi en ligne de commande

Bonjour à tous,

J’avais écrit un article il y a quelques temps sur le fait que j’avais monté un labo sous environnement VMware ESXi. Même si je l’utilise peu en ce moment, je ne néglige pas pourtant de passer régulièrement les patchs de l’éditeur.

Si vous avez un ESXi avec une licence gratuite, vous avez un compte myvmware. Parfait nous avons seulement besoin de ceci.

Vous retrouverez les patchs de votre version à l’adresse suivante : https://my.vmware.com/group/vmware/patch

Ceci est une procédure personnelle et non une recommandation pour vos machines de production. A vous de juger les risques encourus.

Je préfère télécharger le fichier zip en local puis le transférer via ssh sur la machine plutôt que d’utiliser la webui ou le client Windows.

scp ESXi550-201703001.zip root@IP-ESXI:/vmfs/volumes/datastore

 

Pour effectuer une mise à jour ou l’application de patch, je me connecte en ssh et passe en mode maintenance, ce qui implique de basculer les VM sur un autre hyperviseur, ou de les arrêter.

esxcli system maintenanceMode set –enable true

 

Pour vérifier l’état du mode maintenance :

esxcli system maintenanceMode get

Si la réponse est « Enable », le mode maintenance est activé, si c’est « Disable », il est désactivé.

 

Application du patch, il faut impérativement indiquer le chemin complet, le chemin relatif ou seulement le nom de fichier ne fonctionne pas.

esxcli software vib install -d /vmfs/volumes/datastore/ESXi550-201703001.zip

L’installation est terminée, pour « Reboot Required » il est indiqué « true », donc il faut redémarrer l’ESX.

 

Redémarrage de l’hyperviseur

reboot

 

Le redémarrage étant terminé, il faut se reconnecter en ssh et désactiver le mode maintenance

esxcli system maintenanceMode set –enable false

 

Comme d’habitude, les commentaires vous sont ouverts.

Stay tuned !

 

Passage de StartSSL à Let’s Encrypt avec validation DNS

Bonjour à tous,

Pour ceux qui suivent les articles peu fréquents du blog, je m’intéresse particulièrement aux certificats x.509 et aux configurations des services associés depuis 2014. Après plusieurs années de bons services avec StartSSL, il se trouve que je dois changer d’autorité de certification (CA, Certificate Authority) car cette dernière ne sera plus reconnue de confiance à partir du 8 mai 2017. Pour les détails, vous les retrouverez  sur le blog de Qualys.com (en anglais).

Après recherche d’un remplaçant pour ma nouvelle autorité, j’ai finalement opté pour Let’s Encrypt, autorité gratuite et reconnu de la plupart des clients (logiciels).

Seulement avant de se lancer, il y a des choses à connaitre sur les modalités de signature d’un certificat :

• Validité de 60 jours
• Pas de certificat EV (Extended Validation), le nom de l’entité ayant fait la demande
• Utilisation du protocole ACME (Automatic Certificate Management Environment) pour la demande et le renouvellement
• Validation de l’appartenance du domaine à signer par une vérification HTTP ou DNS

Autre choix à faire, quel client ACME utiliser. La liste est longue et il est difficile de les distinguer, tous n’implémentent pas toutes les possibilités de Let’s Encrypt, certains détails ne sont pas paramétrables, pas mis à jour depuis plusieurs mois. J’ai finalement choisi d’utiliser acme.sh, un client shell, tout simplement.

Un autre point à prendre en compte, mon port 80 n’est pas disponible publiquement sur internet, je n’étais donc pas super chaud pour l’ouvrir dans le seul but de valider mon domaine tous les 60 jours (environ). C’est la où le challenge DNS m’intéresse. Le principe est simple, si vous avez la main sur le DNS gérant le domaine, vous êtes légitime pour obtenir un certificat, comment ? En ajoutant un ou plusieurs enregistrements TXT contenant une clé de validation. Alors oui à la main ça sera fastidieux d’ajouter/modifier l’enregistrement tous les 60 jours, mais acme.sh s’interface avec les API de nombreux opérateurs DNS dont OVH, problème résolu !

 

Installation

Comme d’habitude, je ne saurais trop vous inciter à mettre à jour votre système par le classique :

aptitude update
aptitude upgrade

Pour les 4 façons d’installer le client acme.sh, je vous invite à lire la page wiki dédiée, ici j’indique la méthode simple.

Information importante : bien que les installations en « root » ne soit pas toujours un bon choix, pour notre usage il semble que ça soit la bonne méthode, à cause des droits déjà et également pour les commandes après signature (issue) et renouvellement (renew). A vous d’évaluer ceci selon votre environnement !

curl https://get.acme.sh | sh

L’installation faisant un ajout dans le fichier .bashrc de l’utilisateur, il faut se déconnecter et reconnecter au shell pour que la modification soit active.

 

Mode manuel avec challenge DNS

Si vous n’avez pas d’API pour votre DNS ou que vous voulez gérer cette partie manuellement, c’est possible, la première demande s’effectue de la manière suivante :

acme.sh –issue –dns -d sub.domaine.tld -d domaine.tld –keylength 4096

Ici, on fait une demande (–issue) par DNS challenge (–dns) pour un domaine et sous-domaine (-d sub.domaine.tld -d domaine.tld) avec une clé privée de longueur 4096 (–keylength 4096) générée de suite (par défaut 2048).

Le script nous indique les enregistrements TXT pour _acme-challenge.sub.domaine.tld et _acme-challenge.domaine.tld.

 

Mode auto API OVH

Comme indiqué plus haut, acme.sh s’interface avec l’API d’OVH, une page wiki d’explication est disponible également.

On suit donc ce qui est indiqué en se connectant sur https://eu.api.ovh.com/createApp/ on remplit les informations et on valide. On dispose maintenant de deux éléments importants, « Application Key » et « Application secret » à renseigner dans le fichier :

/root/.acme.sh/dnsapi/dns_ovh.sh

J’en profite pour préciser que l’ensemble des fichiers liées à acme.sh et Let’s Encrypt se trouve dans le dossier caché « .acme.sh » de l’utilisateur qui a fait l’installation.

Première demande en utilisant l’API OVH :

acme.sh –issue –dns dns_ovh -d sub.domaine.tld -d domaine.tld –keylength 4096

Et la ça ne fonctionne pas, un message nous indique d’ouvrir une grande URL « https://eu.api.ovh.com/auth/?credentialToken=XXXxxXXXx » afin de déterminer la durée de validité du compte sur l’API, « Unlimited » semble la bonne réponse dans notre usage et on valide. C’est normal, cette opération est à faire seulement la première fois.

Répéter la commande précédente, si tout va bien, vous devriez obtenir votre certificat, le certificat de l’autorité et la chaine complète de certification.

Les fichiers se trouveront dans /root/.acme.sh/sub.domaine.tld/

-rw-r–r– 1 root root 1,7K avril 30 15:35 ca.cer
-rw-r–r– 1 root root 3,8K avril 30 15:35 fullchain.cer
-rw-r–r– 1 root root 2,2K avril 30 15:35 sub.domaine.tld.cer
-rw-r–r– 1 root root  900 avril 30 15:51 sub.domaine.tld.conf
-rw-r–r– 1 root root 1,7K avril 30 15:35 sub.domaine.tld.csr
-rw-r–r– 1 root root  203 avril 30 15:35 sub.domaine.tld.csr.conf
-rw-r–r– 1 root root 3,2K avril 30 15:35 sub.domaine.tld.key

 

Mise en place des certificats

Aller chercher les certificats dans /root ce n’est pas vraiment l’état de l’art, il faut donc les installer dans un endroit accessible par notre ou nos application(s).

Il reste à repasser sur les configurations des services afin de spécifier où se trouve les fichiers de certificats dont ils auront besoin pour démarrer. Sur ce point je vous laisse faire et vous référer à la commande qui suit pour les chemins.

acme.sh –installcert -d sub.domaine.tld –keypath /etc/ssl/private/sub.domaine.tld.key –capath /etc/ssl/certs/sub.domaine.tld-ca.pem –fullchainpath /etc/ssl/certs/sub.domaine.tld-full.pem –reloadcmd « service nginx reload && service postfix reload && service dovecot restart »

Grâce à cette commande, la clé privée est installée dans /etc/ssl/private. Le certificat de l’autorité et la chaine complète dans /etc/ssl/certs. Enfin, le paramètre –reloadcmd permet d’exécuter une commande à l’issue, ici le reload des configurations de nginx et postfix  ainsi que le restart de dovecot. On peut très bien exécuter un script shell si besoin.

Logiquement tout est en place. Toutes les nuits une tâche cron s’exécutera afin de vérifier si il faut faire une demande de renouvellement. Pour vous en assurer :

crontab -e

 

Conclusion

Tout ceci n’est pas très difficile en soit mais il faut faire les choses dans l’ordre et analyser un peu ce que l’on veut faire et comment.

Pour ceux qui font du DANE TLSA, il faudra mettre à jour votre enregistrement DNS TLSA associé.

Concernant la clé privée, les droits de lecture en 644 (lecture/écriture pour le propriétaire, lecture pour le groupe et les autres) ne me plait pas des masses, je préfère 640, donc un petit chmod s’imposera, éventuellement à ajouter à un script à exécuter avant le reload des services.

 

Comme d’habitude, si vous avez des remarques ou des commentaires, n’hésitez pas !

 

Stay tuned !

Un labo sous ESXi

Salut à tous,

Depuis quelques temps je m’amuse avec une machine qui me sert de « labo » pour des tests. La machine n’est pas ultra puissante et ne dispose pas de ressources démesurées mais j’ai tout de même décidé d’installer VMware ESXi dessus. C’est l’occasion de faire quelques billets autour de ce bricolage.

Certains vont peut être se poser la question du choix de l’hyperviseur, pourquoi ne pas utiliser un Hyper-V de chez Microsoft ou encore un Proxmox. La réponse est simple, c’est la solution de virtualisation que je connais, tout simplement.

Pour ceux qui ne le savent pas, la société VMware, éditrice de l’hyperviseur ESXi, permet une utilisation gratuite, fonctionnelle mais cependant un peu limitée. Pour vSphere 5.5 la configuration maximum en lien.

La seule chose à faire ? S’enregistrer en créant un compte et faire une demande de clé qui est valide sans limitation de durée.

Vous avez également la possibilité d’installer les patchs de sécurités qui sont mis à disposition, toujours via le compte myVMware.

Dernière chose intéressante, la webui peut être ajoutée pour la gestion de l’ESXi et les VM sans passer par le vSphere Client est uniquement disponible sous Windows.

Le vCenter qui permet de gérer plusieurs ESX, le clonage de VM, déploiement de template, les alertes, le vmotion… est quand à lui payant.

Stay tuned !

Prioriser le réseau wifi plutôt que l’ethernet sous Ubuntu

Bonjour,

Aujourd’hui un article rapide sur une problématique rencontrée ce week-end.

Un PC fixe sous linux, xubuntu 16.04 LTS pour ne pas le citer, accède à internet en wifi et dispose également d’une connexion ethernet gigabit vers un NAS. Le problème, c’est que par défaut, la connexion filaire est prioritaire pour l’accès internet. Pour les plus spécialistes, chaque carte dispose d’une passerelle pour les accès hors lan, la configuration se faisant par DHCP sur les 2 interfaces.

La table de routage ressemble à ceci, le hic provient de la première ligne.

user@PC:~$ route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
0.0.0.0     192.168.2.254         255.255.255.0   UG     100    0        0 enp0s7
0.0.0.0         192.168.1.254   0.0.0.0         UG    600    0        0 wlx0026f2a5685b
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 enp0s7
192.168.1.0     0.0.0.0         255.255.255.0   U     600    0        0 wlx0026f2a5685b
192.168.2.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s7

3 solutions possibles.

– Supprimer manuellement la route qui ne convient pas avec un :

sudo route -v del -net 0.0.0.0 enp0s7

Cela fonctionne de suite, mais ce n’est pas persistant (il faudra le refaire à chaque redémarrage ou déconnexion/connexion du câble).
– Modifier le fichier /etc/network/interfaces et supprimer la route sitôt que l’interface est UP. A la fin de la déclaration de l’interface, on ajoute :

up route -v del -net 0.0.0.0 enp0s7

La encore ça ne convient pas car cette configuration n’est pas utilisée par NetworkManager, le gestionnaire de Ubuntu. Par contre, la commande ifup utilise bien la configuration.
– Dernière solution, dans l’interface graphique de management de la configuration réseau, il y a une subtilité à cocher :

Et voila, la passerelle de cette interface ne sera plus ajouté aux routes du système !

Stay tuned !

Tuto – Installation du script cryptcheck

Aujourd’hui je vous propose un article dans la continuité de celui qui s’intitulait Configurer son serveur web en HTTPS. Pour cela, petit tuto pour installer cryptcheck qui est une application Ruby 2.2.2 développée par  Aeris22 qui permet de tester différents paramètres SSL/TLS ainsi que les ciphers. A la fin on obtient une note globale d’une lettre. Il supporte les protocoles HTTPS, SMTP et XMPP.

Tout d’abord on met à jour les dépôts puis on installe quelques bricoles comme le git pour récupérer les sources, le make pour compiler et quelques lib nécessaires au rbenv (Ruby Environment).

apt-get update
apt-get install make gcc git libssl-dev libreadline-dev zlib1g-dev

Ensuite on vient cloner les fichiers de rbenv dans un dossier caché .rbenv sur l’utilisateur (celui de la session en cours).

git clone https://github.com/sstephenson/rbenv.git ~/.rbenv

Il y a 2 manipulations à faire (dans cette ordre) pour que le shell retrouve les binaires Ruby à la demande d’exécution plus tard. Pour les debian et ubuntu c’est vers le fichier .bashrc que l’on va écrire, il se peut que ça soit vers .bash_profile suivant la distribution.

echo ‘export PATH= »$HOME/.rbenv/bin:$PATH »‘ >> ~/.bashrc
echo ‘eval « $(rbenv init -) »‘ >> ~/.bashrc

Il faut redémarrer le shell pour que les modifications soient prise en compte, fermer la fenêtre et la relancer ou se déconnecter et reconnecter. Taper la commande :

type rbenv

On doit obtenir la réponse :

#=> « rbenv is a function »

ou

rbenv est une fonction

L’environnement est installé mais c’est une coquille vide et nous voulons disposer de la version 2.2.2 de Ruby. Pour ce faire nous devons installer ruby-build.

git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build

Puis pour installer cette fameuse 2.2.2 :

rbenv install 2.2.2

Il va se passer de nombreuses minutes pour cette installation, c’est normal et dépend de votre machine. Quand c’est terminé il faut déclarer que cette version est disponible :

rbenv global 2.2.2

Pour Ruby c’est terminé, on passe à cryptcheck.

git clone https://github.com/aeris/cryptcheck.git
cd cryptcheck/
make

Il est très important de faire un make et non un sudo make car au moment d’exécuter Ruby, il ne le trouvera pas ne disposant du bon chemin car plus dans le contexte de l’utilisateur. Si le make s’interrompt, on peut le relancer en tapant make de nouveau. J’ai eu le cas sur un problème de récupération d’openSSL.

Dernière installation à faire avant de lancer le test.

gem install bundler && bundle install

Pour lancer le test d’un serveur web :

./bin/check_https monsiteweb.fr

Un outil bien pratique pour des tests en local avant de mettre un serveur en vue sur internet par exemple.

Mise à jour : 24/08/2015 sslcheck s’appelle maintenant cryptcheck

Stay tuned !

Configurer son serveur web en HTTPS

Bonjour à tous,

Aujourd’hui je vous propose de déblayer un peu le sujet de la configuration HTTPS (HyperText Transfer Protocol Secure) au niveau d’un serveur web. Comme me le faisait remarquer xhark, l’auteur du blog http://blogmotion.fr, il y a beaucoup de publications sur le sujet, souvent tout n’est pas très clair, je vais donc faire le maximum pour l’être.
Autre problème, on rencontre des configurations obsolètes, ce qui sera peut être le cas de cet article dans 10 jours, 1 mois, 1 an. Vous l’aurez compris, dans le domaine les changements vont vites.

Je donne des conseils par rapport à mes observations et ne serait être tenu responsable en cas de problème sur vos serveurs pour quel problème que cela soit.

Avant toute chose, les applications telles que le serveur web et openSSL doivent être mis à jour, des failles sont décelées et corrigées régulièrement. Il vous faudra un certificat x509 (souvent appelé inexactement certificat SSL). Cet élément et la clé privée associée sont indispensables à la configuration de votre serveur. Pour plus d’informations je vous renvoie vers mes précédents articles :

• Tuto – Générer un certificat SSL valide et gratuit
• Renouveler son certificat x509

L’objectif affiché est d’obtenir une configuration optimum qui fonctionnera avec un maximum de navigateurs, systèmes d’exploitations et un niveau de sécurité élevé. Mon but, obtenir une note « A » voir « A+ » sur le test de SSLLabs.

Personnellement j’utilise nginX comme serveur web car je le trouve léger et performant mais l’ensemble de ce que je vais vous indiquer se fait sur d’autres serveurs type Apache, lighttpd ou même IIS (dire « 2IS »). Le tout n’est pas de copier/coller une configuration mais de comprendre ce qu’elle apporte et de savoir si c’est  pertinent dans le cadre de mon utilisation.

 

Temps de configuration : entre 10 et 20 minutes

 

• Désactiver les protocoles SSLv2 et SSLv3

Ces protocoles (SSL : Secure Sockets Layer) sont maintenant obsolètes et vulnérables à de nombreuses failles, donc on désactive tout ça et laisse activer la relève, TLSv1, TLSv1.1 et TLSv1.2 (TLS : Transport Layer Security). Je vous donne les lignes de configuration au fur et à mesure.
Conséquence : Les Windows XP avec IE6 ne pourront pas se connecter car IE6 ne sait pas faire de TLSv1.

Sous nginX :

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Sous Apache :

SSLProtocol All -SSLv2 -SSLv3

 

• Mise en place du Perfect Forward Secrecy (confidentialité persistante)

Lors de la connexion du client au serveur, ce dernier va renvoyer les suites ciphers (les algorithmes de chiffrement) avec lesquelles il sait travailler. On indique avec la première ligne de configuration qu’il y a un ordre, du plus fort au moins fort, à la fin ce que l’on ne veut pas utiliser est précédé d’un « ! ». Ensuite le client et le serveur se mettent d’accord sur l’algorithme et font divers échanges avant que la communication soit sécurisée.
Le Forward Secrecy est la capacité de rendre secret dans le temps la communication par un mécanisme d’échange de secret partagé Diffie-Hellman, même si la clé privée du serveur est compromise plus tard. Le Perfect Forward Secrecy est l’utilisation de l’échange Diffie-Hellman éphémère (EDH ou DHE dans les ciphers).

Conséquence : Ne fonctionne pas sous XP et IE6/IE8, Java 6/7

Sous nginX :

ssl_prefer_server_ciphers on;
ssl_ciphers « EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH »;

Sous Apache :

SSLHonorCipherOrder On
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH

L’excellent site Cipherli.st référence pour de nombreuses applications le paramétrage à effectuer pour obtenir une configuration convenable. Par défaut il propose cette petite suite de ciphers mais une configuration plus large pour un fonctionnement avec un maximum d’environnements est disponible.

 

• Générer de nouveaux paramètres Diffie-Hellman

Pas de chance, sur le papier l’échange de clé semblait optimum mais dans la réalité une attaque appelée « logjam » permettait de connaitre les paramètres que le serveur échangerait et donc la communication n’était plus sûr. La solution à ce problème est simple, générer de nouveaux paramètres avec la commande openSSL puis indiquer au serveur de prendre en compte ces derniers.
La longueur de clé recommandée aujourd’hui est de 2048 bit ou plus. Sachant qu’un certificat est valide plusieurs années en générale, il semble bon de partir directement sur « plus ». Les paramètres DH doivent être de la longueur de votre clé privée.
On se place dans le dossier qui contient les certificats du serveur et on exécute la commande suivante :

openssl dhparam -out dhparams.pem 4096

L’outil répond :

Generating DH parameters, 4096 bit long safe prime, generator 2
This is going to take a long time

A titre d’exemple, sur un Core 2 Duo 2,26 GHz, comptez plus de 35 minutes montre en main.

Sous nginX :

ssl_dhparam /path/to/dhparam.pem;

Sous Apache :

SSLDHParametersFile /path/to/dhparam.pem

 

• Gestion des sessions SSL

Autre point intéressant, la façon dont est géré le pool de sessions SSL avec le serveur ou ses processus. La première instruction indique un cache des sessions partagées avec ses processus et 10 Mb ce qui selon la documentation nginX permet de gérer 10 x 4 000 sessions.
Le timeout est la période pendant laquelle le client peut réutiliser sa session sans faire une nouvelle négociation. Par défaut, selon la documentation toujours, le délai est de 5 minutes.

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

Concernant Apache il semble conseillé de désactiver :

SSLSessionTickets Off

 

• Activer le HSTS

Le HSTS (HTTP Strict Transport Security) est une information ajoutée par le serveur dans les en-têtes renvoyées au client afin de lui indiquer qu’il sait faire du HTTPS. Une notion de durée (en secondes) est ajoutée (ici 2 ans) ce qui permet au client (le navigateur) de revenir directement en HTTPS la fois suivante, de même pour les sous-domaines.
Au passage on ajoute l’en-tête « X-Frame-Options » qui permet d’éviter les vols de cookie de session.

Sous nginX :

add_header Strict-Transport-Security « max-age=63072000; includeSubdomains; preload »;
add_header X-Frame-Options « DENY »;

Sous Apache :

Header always set Strict-Transport-Security « max-age=63072000; includeSubdomains; preload »
Header always set X-Frame-Options DENY

 

• Conclusion

Nous sommes arrivés au bout (pour ceux qui ont résisté) de cette configuration. J’espère avoir été synthétique et clair.

Il ne me reste plus qu’à vous inviter à tester votre site sur SSLLabs afin de savoir si la note obtenue vous convient. N’hésitez pas à me laisser vos commentaires pour faire évoluer ce billet.

Un dernier site pour tester d’autres services comme l’IMAP (niveau SSL) ou autre : SSLDecoder

Stay tuned !

EDIT : MAJ des suites ciphers (16/08/2015)

Renouveler son certificat x509

Après 6 mois sans article, je vous fais ce (petit) billet à propos du renouvellement d’un certificat x509 (SSL/TLS). Dans un article précédent Générer un certificat SSL valide et gratuit j’expliquais comment faire une demande et obtenir un certificat valide aux yeux des navigateurs en utilisant les services de startssl.com

A 15 jours de l’expiration de mon certificat, je reçois un mail d’avertissement sur l’adresse postmaster de mon domaine afin de me prévenir. De même sur l’adresse email enregistrée pour l’administration puisque pour ceux qui ne savent pas, l’authentification se fait via certificat client associé à l’adresse email.

Une fois connecté au portail d’administration, il y a 2 choses à faire, renouveler le certificat client et le certificat serveur pour le domaine (qui est en fait une nouvelle génération à chaque fois).

Renouveler le certificat client :

Renseigner l’adresse email utilisée pour l’administration sur le site.

Un code de confirmation est envoyé par email, le saisir pour confirmer que vous avez accès à cet email.

Choisir l’adresse email dont on veut faire le certificat, concernant le hash, préférer du SHA2 sauf si votre OS est (très) ancien.

Le nouveau certificat s’installe dans votre navigateur, le magasin ou dans le trousseau d’accès pour les propriétaires d’appareil avec une pomme. Personnellement j’ai retiré mon ancien certificat, mais on peut conserver les 2 à priori.

Renouveler le certificat serveur :

J’ai généré un csr en local sur ma machine donc je passe à « Skip » directement. Pourquoi ? La clé privée reste chez moi, tout simplement. Pour la Keysize, je vous conseille d’opter tout de suite pour 4096 et non 2048 (Medium) comme sélectionné par défaut. Voici la commande OpenSSL que j’utilise, le CSR à copier/coller sera dans csr.txt, la clé privée dans mon.domaine.fr.key

openssl req -newkey rsa:4096 -sha512 -keyout mon.domaine.fr.key -nodes -subj /C=FR/O=domaine.fr/CN=mon.domaine.fr/ -out csr.txt

Ensuite il vous sera demandé d’indiquer à nouveau le domaine et un sous domaine (SAN). Si tout est OK, vous recevrez l’information par email (sur l’adresse postmaster) quand le certificat sera prêt.

Récupérer le certificat serveur :

Le retrait du certificat serveur est un peu moins commode que pour celui de la partie client.

Il faut faire un copier/coller de tout le bloc de texte dans un fichier, c’est ça le certificat associé à la clé privée.

Dernier point important, la chaine de certification, c’est grâce à cela que le certificat parait valide pour les navigateurs. Nous aurons besoin de ceci :

Il y a la possibilité de les télécharger et faire un copier/coller des 2 certificats de StartCom plus le notre (ssl.crt) en un seul fichier à la main ou de réutiliser quelques commandes de la dernière fois.

wget http://www.startssl.com/certs/ca.pem
wget http://www.startssl.com/certs/sub.class1.server.ca.pem
cat ssl.crt sub.class1.server.ca.pem ca.pem > ssl-unified.crt

Il vous restera à placer les fichiers au bon endroit, vérifier la configuration du serveur ainsi que les permissions sur le fichier de la clé privée, il est conseillé de faire un chmod 600 et clown root:root dessus.

Conclusion

Pour conclure ce renouvellement, je vous invite à vérifier votre site et l’implémentation SSL directement sur le site https://www.ssllabs.com une référence en la matière. Avec ce nouveau certificat et l’optimisation de ma configuration, je passe de la note « A » à « A+ ».

 

Stay tuned !

grauphel sur ownCloud et TomDroid pour remplacer Evernote

Salut à tous !

Je profite de ce premier post de l’année pour vous souhaiter une très bonne année 2015 et de longues heures de bricole. Pensez à lever le nez de temps en temps pour profiter un peu de ceux qui vous entourent 😉

Revenons en au sujet du jour, remplacer Evernote, le système de prise de note bien connu pour une solution, je l’entends au fond de l’assistance, auto-hébergée. Si vous êtes déjà dans une dynamique d’héberger vos services, c’est un passage obligé. Je vous propose de (re)lire Se passer des services de Google Partie 1 et Partie 2 ainsi que la présentation de ownCloud.

Possédant déjà un ownCloud qui tourne pour tout ce qui est calDav, cardDav et zone de cloud d’appoint, l’application grauphel semblait toute indiquée pour remplir le job.

Pour fonctionner, grauphel a besoin du module PHP oauth car il n’utilise pas votre login/mot de passe ownCloud mais un token. On installe donc ce qu’il faut et supposons que votre ownCloud est opérationnel.

sudo apt-get upgrade
sudo apt-get update sudo apt-get install php-pear php5-dev libpcre3-dev
sudo pecl install oauth

Ensuite il faut indiquer à PHP de charger le module oauth dans son php.ini Pour un serveur NginX c’est dans le php-fpm que l’on indique ça. Il faut éditer le fichier « /etc/php5/fpm/php.ini » et ajouter la ligne :

extension=oauth.so

Très bien, on recharge donc la configuration de PHP-FPM et de NginX.

sudo /etc/init.d/php5-fpm reload
sudo /etc/init.d/nginx reload

Passons au téléchargement de la dernière version de grauphel, le décompresser, le copier dans le dossier « apps » de votre ownCloud et attribuer le bon propriétaire.

wget http://cweiske.de/download/grauphel/grauphel-0.4.0.tar.bz2
tar xjf grauphel-0.4.0.tar.bz2
sudo cp -R grauphel/ /var/www/owncloud/apps/
sudo chown -R www-data:www-data /var/www/owncloud/apps/grauphel/

La dernière étape côté serveur consiste depuis le compte administrateur de ownCloud d’activer l’application.

 

Pour terminer, il faut configurer l’application Tomdroid pour fonctionner avec grauphel, plutôt qu’un long discours, je vous invite à regarder la vidéo suivante :

Source : http://cweiske.de/tagebuch/grauphel.htm

Stay tuned !