PROJET AUTOBLOG


Planet-Libre

source: Planet-Libre

⇐ retour index

TheLinuxFr : Let’s Encrypt et acme.sh sous Debian avec Nginx

mardi 19 avril 2016 à 23:01

Maintenant que Let’s Encrypt est sorti de bêta, nous allons pouvoir commencer à jouer un peu plus sérieusement. Depuis l’annonce de la bêta privé j’utilise Let’s Encrypt, ça fait le job sans problème. J’ai commencé avec le client officiel, mais j’ai vite cherché une solution plus light, sans dépendances et simple à mettre en place. Je suis donc tombé sur acme.sh (anciennement le.sh). Je vais vous présenter ici ma configuration. Je pars d’une Debian Jessie fonctionnelle (c’est mieux) avec Nginx faisant tourner mes divers services (Owncloud, FreshRSS, Kanboard…).

Installation de acme.sh

Rien de plus simple, je vous laisse parcourir le readme du projet, en gros l’installation se résume à :

wget -O -  https://get.acme.sh | sh

Il s’agit ni plus ni moins que de script en sh, ce qui est plutôt cool, pas de dépendances, une installation en quelques secondes et cerise sur le gâteau, une tâche cron est mise en place pour vérifier si un certificat expire.

Configuration de Nginx

Je vais utiliser un webroot pour l’identification et la certification auprès de Let’s Encrypt. Le fichier généré pour le challenge à donc besoin d’être accessible via HTTP. Voici un exemple de configuration de mes hôtes virtuels :

server {
listen 80;
listen [::]:80;
server_name MON_DOMAINE;

location /.well-known/acme-challenge {
root /var/www/letsencrypt;
}

location / {
return 301 https://$server_name$request_uri;
}
}

Les fichiers de challenges vont être générés dans /var/www/letsencrypt, assurez-vous d’avoir créé le dossier et autorisé Nginx (www-data). On peut aussi voir que je redirige toutes les requêtes HTTP vers HTTPS pour le reste. J’applique cette configuration pour les hôtes virtuels que je veux certifier. N’oubliez pas de recharger la configuration de Nginx et on va pouvoir demander nos certificats.

Création des certificats

Nous allons maintenant demander nos certificats. Une simple commande permets cela, vous pouvez spécifier un ou plusieurs domaines :

acme.sh --issue -d mon_domaine.fr -w /var/www/letsencrypt/

Avec plusieurs domaines :

acme.sh --issue -d mon_domaine.fr -d mon_domaine2.fr -d mon_domaine3.fr -w /var/www/letsencrypt/

Patienter quelques secondes, les certificats devraient être générés.

On installe les certificats dans /etc/ssl/private :

acme.sh --installcert -d mon_domaine.fr \\
--keypath /etc/ssl/private/mon_domaine.fr-key.pem \\
--capath /etc/ssl/private/mon_domaine.fr-ca.pem \\
--fullchainpath /etc/ssl/private/mon_domaine.fr.pem \\
--reloadcmd "service nginx reload"

Vous devriez trouver un fichier de configuration dans votre $HOME/.acme.sh/mon_domaine.fr/mon_domaine.fr.conf pour modifier à volontés les variables :

Le_Domain=mon_domaine.fr
Le_Alt=mon_domaine2.fr,mon_domaine3.fr
Le_Webroot=/var/www/letsencrypt/
Le_Keylength=no
Le_RealCertPath=""
Le_RealCACertPath="/etc/ssl/private/mon_domaine.fr-ca.pem"
Le_RealKeyPath="/etc/ssl/private/mon_domaine.fr-key.pem"
Le_ReloadCmd="service nginx reload"
Le_RealFullChainPath="/etc/ssl/private/mon_domaine.fr.pem"
...

Activation du SSL dans Nginx

Il nous reste à configurer les certificats dans les hôtes virtuels Nginx :

ssl on;
ssl_certificate /etc/ssl/private/mon_domaine.fr.pem;
ssl_certificate_key /etc/ssl/private/mon_domaine.fr.pem;

Recharger ensuite Nginx et vous devriez avoir un beau petit certificat.

Tester la configuration

Vous pouvez relancer une certification pour tester :

acme.sh --renew -d mon_domaine.fr -d mon_domaine2.fr -d mon_domaine3.fr -w /var/www/letsencrypt/ --force

Si tous se passe pour le mieux, vous devriez obtenir de nouveau certificats et Nginx devrait redémarrer tous seul comme un grand.

Cet article Let’s Encrypt et acme.sh sous Debian avec Nginx est apparu en premier sur TheLinuxFr.

Gravatar de TheLinuxFr
Original post of TheLinuxFr.Votez pour ce billet sur Planet Libre.

nIQnutn : Galerie d'images: afficher une image contenu dans un zip sur votre site

mardi 19 avril 2016 à 22:18

J'ai précédemment expliqué comment Afficher aléatoirement une citation sur votre site et cela marche également parfaitement avec des images.
Je propose un autre petit script, assez similaire mais qui servira à afficher des images à partir d'une archive .zip.

J'ai effectué plusieurs modifications pour aller un peu plus loin et être capable d'afficher un plus grand nombre d'images ( >1000 fichiers). L'objectif principal restait toujours de se simplifier la tâche:

Il suffit de recopier le code PHP ci-dessous en modifiant le nom de l'archive et l'URL de la galerie.

galerie.php
> URL du fichier zip
$urlPage="galerie.php"; // A MODIFIER >> URL de la page

// navigation
$start= 0 ; // index de départ 
$end= getNbImages($file)-1 ; // index de fin

$urlVar=preg_replace('/(^.*?)\\?/', '', $urlPage."?id") ; //  variable à récupérer
$urlGet=$urlPage."?id"; // URL pour la navigation
$id = isset($_GET[$urlVar])?intval($_GET[$urlVar]):intval(mt_rand($start, $end)); // on récupère l'ID 

// Afficher l'image X
$image=getImageX($file, $id);
echo '
'.$image.'
'; // A MODIFIER >> Mise en page de l'image // Fonction pour retourner l'image correspondant à l'ID function getImageX ($zipFile, $id) { $zip = new ZipArchive; $res = $zip->open($zipFile); if ($res === TRUE) { $src = $zip->getFromIndex($id); $result = 'Image'; return $result; } else { echo 'échec, code:' . $res; } $zip->close(); } // Fonction pour retourner le nombre d'images contenu dans l'archive function getNbImages ($zipFile) { $date_file=filemtime($zipFile); $file_cache=$zipFile.'.cache'; $date_cache=filemtime($file_cache); if ( (file_exists($file_cache)) && ($date_file <= $date_cache) ) { $nb_items_cache = file_get_contents( $file_cache ); } else { $zip = new ZipArchive; $res = $zip->open($zipFile); if ($res === TRUE) { $nb_items_cache=$zip->numFiles; } $zip->close(); file_put_contents($file_cache, $nb_items_cache); } return $nb_items_cache; } ?>

Les variables à modifier:

Puis de l'envoyer sur votre serveur avec l'archive contenant vos images.
En recopiant correctement le code correctement, vous devriez afficher une galerie avec des boutons de navigation.

Le fichier .zip contenant l'ensemble des images ne doit pas comporter d'autres types de fichiers ou de dossiers.

Je n'ai pas de recul concernant les performances de ce script, donc à utiliser avec modération. Avec un fichier comportant plusieurs centaines d'images, cela ne semble pas poser de difficultés.

Ressources


2016 nIQnutn CC-BY

Gravatar de nIQnutn
Original post of nIQnutn.Votez pour ce billet sur Planet Libre.

Framablog : Notre gitlab évolue en Framagit. C’est très efficace !

mardi 19 avril 2016 à 14:23

Warning : cet article parle de forge logicielle qui sert à développer collaborativement du code. Il est donc un peu velu et technique, mais il fera plaisir aux plus « barbu-e-s » d’entre vous !

Préviousselaid, chez Framasoft : nous avions besoin d’une forge logicielle comme outil interne à l’asso… parce que même si nous ne développons pas (ou exceptionnellement) de logiciel libre ; les mettre en avant, les améliorer (parfois), les promouvoir et ouvrir des services au monde, ben ça demande de créer, maintenir, échanger et améliorer du code !

Nous nous étions donc installé Gitlab à la main, sur un coin de serveur, juste pour nous…  Étant les seuls utilisateurs, on s’est dit que ce ne serait pas grave s’il n’était pas toujours à jour, à traquer la dernière version… (oui : nous sommes moins exigeants sur nos outils internes que pour les services que nous ouvrons au grand public ^^).

Franchement, merci Google !

Merci, parce qu’à chaque fois que vous prenez des décisions unilatérales aux dépens de vos utilisateurs-produits, vous nous offrez l’occasion de prouver que le Libre offre des alternatives bien plus respectueuses des personnes qui vous ont confié leur vie numérique (et leur code).

Le jour où nous avons appris que Google Code fermait ses portes, nous avons donc décidé d’ouvrir les nôtres. Cela nous a aussi permis de sensibiliser au fait que, dans le mode des codeurs et développeuses, GitHub est devenu un point central et monopolistique assez inquiétant.

githubdown L’excuse n°1 des programmeurs pour se lâcher sans scrupules : « GitHub est en panne » — Hé, au boulot les gars ! — Github est en panne ! — Ah bon, continuez alors.

L’excuse n°1 des programmeurs pour se lâcher sans scrupules :
« GitHub est en panne »

— Hé, au boulot les gars ! — Github est en panne !
— Ah bon, continuez alors.

 

Forcément, l’ouverture à tous de notre git et les nouvelles fonctionnalités des nouvelles versions de Gitlab (une nouvelle version tous les 22 du mois) nous ont incités à mettre à jour plus régulièrement, ce qui prend plusieurs heures à chaque fois… et plusieurs fois par mois, car des versions correctives sont régulièrement publiées.

Améliorer le Framagit… une priorité

Ceci, ajouté à l’utilisation grandissante de notre forge qui allait bientôt poser des problèmes de taille de disques, nous a amenés à migrer (le 17 mars dernier) notre Gitlab vers une machine avec plus de disque et surtout avec une installation utilisant les paquets dits « omnibus ».

Ces paquets omnibus nous ont permis d’installer Gitlab à l’aide d’un simple apt-get install gitlab-ce plutôt que de suivre la longue procédure d’installation manuelle. Non seulement l’installation est simplifiée, mais — et c’est surtout là la plus-value que nous en attendions — mettre à jour Gitlab devient tout aussi simple avec une seule commande apt-get dist-upgrade.

Résultat : notre Gitlab suit scrupuleusement la publication des nouvelles versions, avec leur lot de nouvelles fonctionnalités !

GitPourTous

Pour fêter cela, nous avons étrenné un nouveau nom de domaine… inspiré par vous ! Avouons-le, «Git point Framasoft point orrrrrrrgueh », ça accroche un peu en bouche. De partout, nous avons entendu parler du « Framagit » : alors tant qu’à faire, autant l’appeler comme vous le faites déjà. Bien entendu, il n’est nul besoin de modifier vos URL, elles restent valides… mais la nouvelle est à votre disposition !

Et si on ajoutait de l’intégration continue ?

Derrière ce terme barbare se cache une fonctionnalité très pratique : on crée une « recette » qui sera exécutée dans une machine virtuelle à chaque push. Cela peut par exemple permettre de lancer une suite de tests pour vérifier que l’on n’a rien cassé. :-)

Pour utiliser cette fonctionnalité, il faut disposer de ce que l’on appelle un runner, c’est à dire un logiciel qui va récupérer la recette et l’exécuter. Il est possible d’installer un runner sur n’importe quel ordinateur, même votre ordinateur de bureau.

Pour ceux qui ne souhaitent pas gérer leur runner eux-mêmes, Framasoft met à disposition deux runners partagés entre tous les utilisateurs de Framagit, que vous pouvez utiliser comme bon vous semble. Notez toutefois que Gitlab indique que quiconque utilise un runner partagé peut accéder aux informations des projets utilisant ce runner : il vaut mieux monter votre propre runner pour vos projets sensibles.

De plus, en utilisant les runners partagés de Framasoft, il est possible que votre projet soit mis en file d’attente, en attendant que les recettes précédentes aient fini de s’exécuter… à vous de voir !

Pouhiou-le-moldu-du-code lisant cet article, allégorie.

Pouhiou-le-moldu-du-code lisant cet article, allégorie.

Vous voulez des pages Gitlab ? Nous aussi !

Github permet à tout un chacun d’héberger un site statique. Gitlab propose une fonctionnalité similaire mais hélas, uniquement dans sa version entreprise… Nous utilisons pour notre part la version communautaire qui est la version libre de Gitlab… donc sans les pages Gitlab.

Nous avons donc ouvert un ticket pour demander que cette fonctionnalité soit incluse dans la version communautaire. Si vous aussi vous aimeriez voir cela arriver, aidez-nous tout simplement en votant sur https://gitlab.com/gitlab-org/gitlab-ce/issues/14605.

En attendant, profitez d’une forge logicielle à jour et libre sur Framagit.org !

Gravatar de Framablog
Original post of Framablog.Votez pour ce billet sur Planet Libre.

Tuxicoman : Comment le FBI pourrait accéder à un appareil Android

mardi 19 avril 2016 à 10:43

Les journaux ont beaucoup médiatisé l’affaire du FBI voulant forcer Apple a créer un outil déverrouillant facilement les iPhone 5. Mais qu’en est-il de la sécurité des appareils Android ?

Je vois 3 cas de figure :

1

L’appareil n’a pas de partition /data chiffrée. Pas de challenge. Le FBI peut tout lire sans souci en branchant l’appareil à un port USB d’un ordinateur. C’est le cas par défaut des appareil sous Android < 6.0 (95% des appareils actifs aujourd’hui)

2

Si l’appareil a les GoogleApps installés (pour faire simple, si l’application GooglePlayStore est installée) et qu’il est connecté à Internet, le FBI a juste à demander à Google de réinitialiser le mot de passe ou d’installer en douce l’application du FBI qui leur permettrait de rentrer de contrôler le téléphone a distance avec les droits root. Le chiffrement de la partition /data est inutile contre cette attaque.

En effet, à travers les GoogleApps, Google a les droits root sur votre appareil. Et par l’application GooglePlay Services, il entretient une communication constante avec votre appareil. Ce privilège permanent de Google sur plus d’un milliard d’appareil personnel est alarmant mais peu s’en préoccupent.

Google a déjà par le passé fait usage de cette position privilégiée pour supprimer et installer des applications sur votre appareil sans votre consentement ni notification.
Avant de vous plaindre, sachez que c’est écrit dans les conditions d’usage du PlayStore (vous savez les conditions que vous passez quand vous démarrez la première fois votre appareil tout neuf et qu’il faut un compte Google pour l’utiliser….)

2.4 From time to time, Google may discover a Product on Google Play that violates the Developer Distribution Agreement or other legal agreements, laws, regulations or policies. You agree that in such an instance Google retains the right to remotely remove those applications from your Device at its sole discretion.

L’utilisateur profite également de ce super pouvoir de Google pour installer des application depuis un autre appareil en utilisant simplement l’interface web du PlayStore (vous croyiez que c’était magique?) ou remplacer les applications (mise à jour) sans notification.

Google peut réinitialiser le mot de passe de verrouillage de l’appareil. Et permet également à l’utilisateur de le faire depuis l’interface web de son compte Google.

Google peut également effacer la mémoire du téléphone à distance. Si un pirate trouve le kill switch et qu’il le lance sur le petit milliard d’appareil, on va rigoler :D

Si l’appareil est éteint, il suffit de lui mettre une carte SIM 3G sans PIN et les GoogleApps vont se connecter automatiquement aux serveurs de Google au démarrage.

Je pense qu’on rentre là dans les 99% des cas.

3

Dans les 0.001% restant de geeks n’ayant pas les GoogleApps installés et une partition chiffrée, il faudrait, sauf exploitation d’une vulnérabilité, casser le chiffrement de la partition /data.

Sur Android pré-4.4, PBKDF2 est utilisé pour dériver la clé de chiffrement à partir du mot de passe utilisateur. Le nombre d’itération étant fixé 2000. On peut retrouver facilement le mot de passe utilsateur avec des GPU :

Even when run on the GPU of a mobile computer (NVIDIA GeForce 730M), hashcat can achieve more than 20,000 PBKDF2 hashes per second, and recovering a 6 digit PIN takes less than 10 seconds. On the same hardware, a 6-letter (lowercase only) password takes about 4 hours.

Sur Android 4.4 et suivant, scrypt est utilisé. Il est plus résistant aux attaques par GPU et FPGA.

Sur Android 6, une clé de chiffrement inscrite en dur dans une puce matérielle de l’appareil peut intervenir dans la génération de la clé, ce qui complique la recherche de mot de passe depuis un autre appareil. Ceci présuppose toutefois qu’il n’y ait pas de faille dans la puce matérielle et que le fabricant n’ait pas de backdoor pour le FBI ou une copie de la clé de chiffrement… (d’où l’intérêt de la NSA d’aller fouiller chez GEMALTO pour récupérer les clés de chiffrement contenues dans les cartes SIM. Qu’en est il de Qualcomm?)

Dans ce cas, ça me parait très similaire à la technique utilisée par Apple dans ses Iphone avec iOS 9.

Note au passage :

PBKDF2 est aussi utilisé pour le chiffrement de disque sous GNU/Linux avec LUKS. Cependant le nombre d’itérations est prévu pour prendre 2 secondes sur votre machine. (1 sec si cryptsetup < 1.7)
Il y a un rapport de bug pour passer à une fonction plus resistante aux GPU ouvert depuis 2012. Le projet répond à sa manière à cette critique :

There is some discussion that a hash-function should have a « large memory » property, i.e. that it should require a lot of memory to be computed. This serves to prevent attacks using special programmable circuits, like FPGAs, and attacks using graphics cards. PBKDF2 does not need a lot of memory and is vulnerable to these attacks. However, the publication usually referred in these discussions is not very convincing in proving that the presented hash really is « large memory » (that may change, email the FAQ maintainer when it does) and it is of limited usefulness anyways. Attackers that use clusters of normal PCs will not be affected at all by a « large memory » property. For example the US Secret Service is known to use the off-hour time of all the office PCs of the Treasury for password breaking. The Treasury has about 110’000 employees. Assuming every one has an office PC, that is significant computing power, all of it with plenty of memory for computing « large memory » hashes. Bot-net operators also have all the memory they want.

Related Posts:

J'aime!(2)Tu dis de la merde!(0)

Gravatar de Tuxicoman
Original post of Tuxicoman.Votez pour ce billet sur Planet Libre.

genma : Yunohost - Trop d'applications ?

mardi 19 avril 2016 à 09:00

C'est sous ce titre un peu racoleur que je voudrais évoquer deux problèmes qui peuvent se présenter si on installe trop d'applications sur son instance Yunohost. Le catalogue d'applications disponibles sur Yunohost est riche et ne cesse de s'enrichir chaque mois et il est tentant d'installer plein d'applications, pour les tester.

Consommation mémoire et processeur

La première chose à laquelle on pense est le fait que toutes ces applications tournant plus ou moins en continue (si ce n'est pas l'application en elle-même, il y a les ressources prises par PHP, MySQL etc.) et que tout cela consomme de la mémoire, du processeur... Surtout si on est plusieurs personnes à utiliser au même moment la même instance à travers différentes appplications. Plus il y a d'applications, plus il y a de ressources consommées.

Si vous trouvez votre machine Yunohost lente, c'est peut être là une piste : il y a trop d'applications de lancer en même temps. Deux solutions s'offrent alors à vous : ajouter de la mémoire ou réduire le nombre d'applications actives.

Failles de sécurité

Multiplier les applications multiplient la surface d'attaque potentielle. Les petits (et mêmes les grands) projets sont peu ou pas audités, ne sont pas forcément codés dans les règles de l'art de la sécurité. Il faut maintenir tous ces projets et applications à jour - ce que Yunohost fait très bien, de façon graphique quand on demande à mettre à jour le système et les applications. Encore faut-il que le mainteneur du paquet de l'application pour Yunohost est prise en compte la recherche de mise à jour de l'application sur le site officiel, que le site officiel fournisse régulièrement des mises à jour et des correctifs de sécurité (c'est le cas avec SPIP par exemple. A ce sujet, voir Yunohost - Comment installer Spip).

Conclusion

Il faut penser à mettre Yunohost et les applications régulièrement à jour via l'interface d'administration. Et surtout vérifier que les dernières versions des différentes applications sont bien les dernières versions disponibles sur les sites officiels de chacune d'elles. Cela demande du temps et de l'energie, mais c'est là le prix à payer pour avoir un peu plus de sécurité et limiter les risques.

Gravatar de genma
Original post of genma.Votez pour ce billet sur Planet Libre.