Quand letsencrypt est passé live, on m’a gentiment signalé qu’on avait plus d’excuses pour faire tourner 0bin en clair.
Bon, soit.
J’ai mis en place ça hier à titre de test : https://0bin.net/.
Pour le moment je vais pas faire de redirection car j’attends de voir si le truc tient.
La bonne nouvelle, c’est que comme l’installation est juste nginx + zerobin, il n’y a pas eut grand chose à faire : lancer un script, le laisser nous identifier et installer les dependances pour qu’il génère le certificat et faire pointer le dit certificat par nginx.
La moins bonne nouvelle c’est que notre archi pour sametmax.com et indexerror.net est basé sur client => varnish => nginx => worker => site.
Il faut donc mettre le certif au niveau de varnish.
Mais comme vous vous en doutez bien, il fallait que ça couille : support de https est un truc récent sur varnish et notre version ne le supporte pas. Donc il reste à :
- Up varnish. Compiler à la main, chercher un mec qui l’a fait, up le serveur ou autre.
- Ou passer varnish derrière nginx et réécrire tout le VLC.
- Ou mettre uniquement HTTPS pour les formulaires de connexions. C’est mieux que rien, mais ça laisse le cookie d’identification en clair et ça va demander de faire des règles milimétriaques.
- Mettre un autre truc en face de varnish juste pour le port 443.
Oh, du boulot en plus, je ne m’y attendais tellement pas…
Merci à tous ceux qui ont proposé et fourni de l’aide néanmoins. C’est cool d’avoir du soutien parmi ses lecteurs.
Pendant ce temps, et ça n’a rien à voir, un lecteur s’est amusé à brute forcer des hashs de mots de passe qu’on avait leakés connement et a trouvé celui de max au bout de quelques jours. Il nous a gentiment envoyé le résultat de ses recherches par mail. Ce n’est pas ironique, hein. J’apprécie que quand quelqu’un trouve que tu es à poil il te le fasse savoir avec précision et honnêteté.
Du coup va falloir aussi changer tous les mots de passe du blog et de indexerror.
Comme ce n’est pas une question de sécurité nationale, je ne suis pas en mode bersek à vouloir faire ça dans la minute, mais sachez-le : changez vos mots de passe à l’occasion. Personne ne va violer votre sœur demain si vous ne le faites pas, mais mieux vaut prévenir que guérir.
Oh, du boulot en plus, je ne m’y attendais tellement pas…
Est-ce qu’on peut avoir quelques infos sur les mots de passe leakés ? Simple curiosité, c’est toujours intéressant de voir les erreurs des autres (une fois corrigées) pour éviter de faire les même. Je comprendrais tout à fait un refus bien sûr.
Y’a moyen de faire plus bizarre mais rapide (sans avoir à installer ou compiler quoi que ce soit) : utiliser nginx en double configuration reverse-proxy/backend : reverse-proxy sur 80/443 pour envoyer à varnish, puis backend derrière sur un port custom. Certes ça parait plus étrange à “dessiner”, mais ça fonctionne.
@cym13: dump sql commité en backup sur le mauvais repo.
@Seboss666: c’est une super bonne idée ! J’avais pas du tout pensé à ça, mais ça évite d’installer un truc en plus, juste un peu de config à faire.
@sam: Pour ceux qui ont le même mot de passe pour plusieurs choses, dont la ceinture de chasteté de leur soeur, il peut y avoir un risque, non?
@Brice: oui, absolument.
hmmm, pourquoi ne pas faire tourner tout ça dans un docker, ça évite les em..erdes nn?
(Si j’ai dis nimp, faîtes-le moi savoir, je dormirai moins coin et ça m’apprendra à dire de le me..de)
Depuis que je suis passé à pass, j’ai pas de souci. Un mot de passe unique et généré pour indexerror.net
Oui, c’est en ligne de commande, et c’est pas intuitif, parce qu’il faut GPG derrière. J’ai mis 6 mois à m’y mettre sérieusement.
Mais bon, je vois que je suis content de l’avoir fait :)
Dans le meme genre il existe aussi passpie. GPG aussi mais interface ligne de commande bien faite. Pour générer des mots de passe velus pour chaque service en ligne. Faut pas oublier sa passphrase par contre :)
@Brice: Et qui plus est, on est chez des gens biens qui disent quand ça a fuité, mais nombres d’admins/webmaster/conseiller en com’ ne le font pas. Et là, ça peut faire mal. Donc mot de passe unique sur tous les sites web pour moi.
Sinon le ‘varnish’, c’est que pour faire du caching ? je serais tenté de dire qu’on s’en fout :) à mes risques et périls
Sans varnish, le blog tombe. WP est très, très lent, et on a 6000 visiteurs / jour.
Salut,
Tu pourrais te passer de varnish, surtout avec nginx mais pour celà un système de cache inhérent à wordpress serait nécessaire (W3 total cache, wp rocket, etc…). Une légère optimisation de ton site serait bien aussi, en commençant par la taille des images. Je suis allé me pendre en voyant la taille de l’image sur la page catégorie de ton article On a tenté de nous hacker 0bin —> 654,96 kb , c’est vraiment énorme pour l’affichage d’une miniature, sans parler des gif mais si tu aimes les animations :)
Sinon j’adore ton style, ce blog est une pépite dans l’univers de plus en plus standardisé du blogging :)
@++
Bonjour
Pourquoi le cache de nginx n’est pas suffisant?
J’ai lu que le purge de nginx n’est pas top, mais il existe des modules pour ca.
@jack of all trades : malheureusement ce n’est pas si simple.
D’abord, varnish a des performances largement supérieurs à tout plugin de cache WP (on en a essayé 4).
Ensuite il est en front de S&M mais aussi de IE.
Enfin, le cache est là pour pallier le nombres aberrants de requêtes lentes que font ces outils pour chaque page et soulager le serveur, non pas pour que le blog se charge plus vite côté client. La taille des images n’a aucun impact là dessus, d’ailleurs notre config varnish les bypass il me semble.
Mais admettons que nous souhaitions réduire la taille de la page des articles (qui fait en tout un putain de 2Mo O_o), nous avons très peu de contrôle. Le CSS + JS + HTML pèse le 1,9 Mo. Sur cette page. Pour un simple article. WP et son écosystème (plugin, thêmes, etc) sont des gros balourds bordéliques et infléxibles.
@Sam : la plupart du temps le goulet d’étranglement d’un serveur web se situe lors de l’exécution du code php via php-fpm. Même en activant opcache ce php-fpm comsomme pas mal de ressources. Lorsque l’on utilise un plugin de cache il faut trouver le moyen pour que nginx serve directement ce qui a été mis en cache sans que le plugin utilise le core wordpress pour fournir à Nginx les fichiers du cache. Dans ce cas Nginx est utilisé pour sa veritable fonction c’est à dire servir directement des pages statiques à une vitesse effrante sans surconsommation de ressources.
Par exemple wprocket utilise cette stratégie par défaut avec Apache (ce qui déchire avec la version 2.4), il est également possible d’appliquer cette stratégie avec nginx en utilisant une configuration décrite par Maxime Jobin sur github. Pour l’avoir testé, je peux dire que cette configuration fonctionne bien.
A mon sens, l’avantage d’un plugin de cache réside dans les options permettant de générer les fichiers de pages statiques: minification du css, js, lazyload, etc..
Peut-être essayer https://www.cloudflare.com/ ?
Pardon, cela ne fait pas trop argumenté. Avec les pages rules de cloudflare tu peux faire un cache complet de toutes tes pages (‘Cache everything’). Et tu évites toutes les galères d’install, upgrade, etc.
On avait un wordpress sous l’au qui a été sauvé grâce à ça ;)
Et quand cloudflare tombe, ton site tombe. Quand cloudflare decide de ban un user ou un pays pour des raisons politiques, il n’y a plus accès. Si quelqu’un demande à cloudflare un takedown ton site tombe et c’est bien galère pour recupérer le droits dessus. Bref, tu mets tes couilles dans les mains d’une société largement incluencée par des interêts commerciaux, politiques, et qui est une boîte noire.