Attention tout de même à différencier “attaques automatiques / automatisables” de “attaque ciblée sur un serveur en particulier”, c’est deux choses différente. Mon point c’est de dire que se cacher spécifique de Shodan ne fournit pas “vraiment” de sécurité supplémentaire ou réelle. Vraiment, faire un script qui scanne tout le range d’IPv4, c’est relativement simple.
Et surtout, dans la continuité de ce que j’évoque avant : attention au piège classique du faux sentiment de sécurité. Ou de “l’effet Ikea de la sécurité”, genre t’as mis en place 2-3 bricoles toi-même à la main, alors tu penses que ton serveur est “vachement mieux sécurisé”. Sauf que la sécurité c’est un tout, et on peut vite avoir l’impression de faire les choses bien tout en oubliant des énormes trous de sécu là où on y pensait pas. Voir on peut empirer les choses en croyant les améliorer (par ex. changer le port SSH sans propager le nouveau port sur la conf fail2ban)
@Aleks Il me semblait avoir sous-entendu assez clairement les propos que tu a ajouté, mais visiblement ce n’était pas assez clair Bref, tu as bien fait de préciser !
Le message de Cyril (merci à lui) m’a fait découvrir https://observatory.mozilla.org/.
J’ai été surpris du résultat : j’ai créé deux sites internet, l’un professionnel, l’autre pour une association. L’ossature de ces sites en PHP/CSS/XHTML est la même. Ce qui change, c’est principalement les textes, les couleurs et les images.
Le site professionnel, chez un hébergeur, écope d’une note F (20/100 ; 6/11), tandis que le site associatif, que j’héberge avec Yunohost obtient une note B (75/100 ; 9/11).
Principales différences ? Le site Yunohost aurait un CSP (mais mal implémenté), HSTS, X-Content-Type-Options, XFO et XSS.
Or, je n’ai jamais configuré ces trucs.
J’ai remarqué que le code source de la page hébergée chez Yunohost avait en fin de section du code que je n’ai pas tapé : <script type="text/javascript" src="/ynh_portal.js"></script><link type="text/css" rel="stylesheet" href="/ynh_overlay.css"></link><script type="text/javascript" src="/ynhtheme/custom_portal.js"></script><link type="text/css" rel="stylesheet" href="/ynhtheme/custom_overlay.css"></link>
La sécurité serait-elle ajoutée par Yunohost ?
Je n’ai pas trouvé quel lien hébergeait les en-têtes de sécurité.
Oui, mais pas par les scripts/css que tu mentionnes, ça c’est pour le fonctionnement du portail (et d’ailleurs c’est très crade, mais il faudrait revoir complètement l’architecture du SSO, ça fait parti des 4125147 todos)
C’est dans /etc/nginx/conf.d/ … mais tout dépends de ce que tu cherches à faire exactement … Si tu cherches à améliorer les règles CSP ou autres pour avoir un meilleur score, alors prends gardes.
Ce n’est pas trivial de savoir quoi bricoler et comment.
Les sites de score de sécurité comme l’observateur de mozilla ou ssllabs etc sont bien, mais ils laissent sous-entendre que le score de sécurité est le seul paramètre important. En pratique, la sécurité est toujours un compromis avec la comptabilité et la praticité. Par exemple, certaines apps ont besoin (à tort ou à raison) de certains réglages CSP (ou autres headers HTTP) pour fonctionner correctement. Tu peux donc tout à fait avoir un score “A+++” avec des arc-en-ciel et des licornes, mais qu’en fait ton app ne soit pas utilisable… (Ceci dit ça veut pas dire qu’il ne faut pas chercher à améliorer les réglages de Yunohost)
This includes 'unsafe-inline' or data: inside script-src , overly broad sources such as https: inside object-src or script-src , or not restricting the sources for object-src or script-src .
Mais je vais me retenir de tripatouiller tout ça, même si je n’utilise pas javascript : le javascript que vous ajoutez pour le fonctionnement du portail risque de ne plus fonctionner.
J’ai pas mal travaillé sur Rspamd / Yunohost pour améliorer l’antispam, et mes conclusions sont les suivantes :
Oui, Yunohost pratique le greylisting
Non, ça n’a pas l’air particulièrement efficace car maintenant la plupart des serveurs de spam ont des fonctionnalités intelligentes, dont une liste d’attente et des mécanismes pour réessayer les envois
Bref, tu as bien fait de préciser ! 
