Différences

Ci-dessous, les différences entre deux révisions de la page.

--- fr:securite_sysadmin [2017/07/14 10:03] – [Module header] zatalyz
+++ fr:securite_sysadmin [2021/12/03 19:19] – modification externe 127.0.0.1
@@ Ligne 2: / Ligne 2: @@
 Cet article s'adresse aux personnes qui gèrent l'infrastructure et le système des serveurs : les sysadmin. Il concerne un système sous Linux (dans nos exemple, Debian stable). C'est un pense-bête plus qu'un vrai cours.
-<WRAP center round help 60%>
+<WRAP center round info 60%>
-Ce serait pas mal de faire un vrai bon tour d'horizon des bonnes pratiques sur la partie sécu pure... mais en même temps ça couvre tellement de chose, renvoyer vers les bons ouvrages seraient aussi bien ? Faut que je retrouve les liens et que je n'oublie pas de les mettre ici !
+Voir aussi
+  * [[fr:consignes_securite_people]]
- --- //[[wiki:user:zatalyz|zatalyz]] 2016/09/14 17:34//
+  * [[fr:consignes_securite_admins]]
+  * [[fr:consignes_securite_sysadmins]]
 </WRAP>
@@ Ligne 107: / Ligne 109: @@
 ==== HTTPS ====
-Sauf cas très particulier, toutes les pages web devraient être accessibles uniquement via https. C'est absolument incontournable lorsque le serveur et le client échangent des informations, afin que les mots de passe ne soient pas en clair.
+Sauf cas très particulier, toutes les pages web devraient être accessibles uniquement via https. C'est absolument incontournable lorsque le serveur et le client échangent des informations, afin que les mots de passe ne soient pas transmis en clair sur le réseau.
 Donc on configure bien son https. Voir [[fr:https_ssl|l'article détaillé]].
@@ Ligne 135: / Ligne 137: @@
 En principe nos serveurs sont à jours, hein. Mais en cas d'oubli, ne facilitons pas la tâche des observateurs :
-  nano /etc/apache2/apache2.conf
+  nano /etc/apache2/conf-available/security.conf
 <code># Cacher la version d'Apache2
@@ Ligne 144: / Ligne 146: @@
 À refaire sur chacun de ses serveurs !
+<WRAP center round tip 60%>
+On peut aussi paramétrer (et modifier) ces options dans ''/etc/apache2/apache2.conf'' mais c'est moins élégant.
+</WRAP>
 === Module header ===
@@ Ligne 167: / Ligne 173: @@
 # Interdire l'embarquement de tout ou partie de votre site dans un site ou logiciel tiers
 Header set X-Permitted-Cross-Domain-Policies none
+# X-Clacks, ça sert à rien, c'est donc vital.
+header set X-Clacks-Overhead "GNU Terry Pratchett"
 # Enfin, les CSP permettent de vérifier l'origine des éléments du site
-# CSP, pour eviter de charger des scripts d'ailleurs.
+# CSP, pour eviter de charger des scripts d'ailleurs. /!\ partie complexe à gérer suivant vos CMS
-Header set Content-Security-Policy "default-src 'self' "
+Header set Content-Security-Policy "default-src 'self' *.monsite.org 'unsafe-eval' 'unsafe-inline' "
 </code>
 Les explications :
   * Header set X-Robots-Tag : http://robots-txt.com/x-robots-tag/
-  * CSP : https://ole.michelsen.dk/blog/secure-your-website-with-content-security-policy.html .
+  * CSP : https://ole.michelsen.dk/blog/secure-your-website-with-content-security-policy.html
-<WRAP center round info 90%>
+== Content Security Policy (CSP) ==
-Note à propos de CSP :
+Les CSP améliorent grandement la sécurité d'une installation, en interdisant à certaines ressources de s'exécuter, par exemple des scripts malicieux injectés dans vos sites webs.
-Il est difficile de faire marcher les CMS tout en ayant une politique sécurisée sur les CSP.
+Mais il est difficile de faire marcher les CMS tout en ayant une politique sécurisée sur les CSP.
-L'option suivante permet à Dokuwiki et Simple Machine Forum de marcher, mais pas à Etherpad, et ne vaut rien aux yeux de [[https://observatory.mozilla.org/|l'Observatoire Mozilla]].
+Le site de référence est [[https://content-security-policy.com/]]. En anglais, mais il contient toute la documentation officielle sur le sujet.
+  * Premier cas : pas de politique CSP. Certains CMS permettent aux utilisateurs d'appeler "des bouts de web" venant d'ailleurs, généralement les images, mais dans certains cas aussi du code... Un attaquant peut se servir de ça pour appeler sur le serveur un code malicieux. Un CMS sécurisé réduit beaucoup les possibilités, mais le risque zéro n'existe pas, et la plupart des CMS ont des failles, c'est un fait.
+  * Second cas : une politique CSP stricte (paramétrée uniquement sur ''self''). Ici, plus moyen d'appeler un truc d'ailleurs. Par contre cela va bloquer le fonctionnement légitime de certains CMS, entre autre ce qui concerne les scripts (pourquoi, je n'ai pas pas encore bien compris, mais c'est un fait).
+  * Troisième cas : ajouter des règles comme ''unsafe-eval'' et ''unsafe-inline''. Cela va permettre aux scripts en question de fonctionner MAIS cela permet aussi à certains attaquant d'utiliser des failles : comme leur nom l'indique, cela est considéré comme "non sécurisé". Ils autorisent explicitement certains trucs à marcher, sans plus de vérification. Cela ouvre la porte à des injections. Cependant, d'après mes tests, les scripts ayant une adresse externe ne sont PAS exécutés sur le domaine. Ne vous sentez pas en confiance pour autant.
+  * Quatrième cas : exécuter localement uniquement les scripts validés explicitement. Cela demande de rajouter la variable ''nonce'' ou ''hash'', puis d'ajouter dans chacun des scripts de notre serveur la clé associée (un hash sur les scripts, ou bien une clé dans ces derniers). Cela veut donc dire : avoir la main sur tout... c'est assez irréaliste dans la majorité des cas, et entre autre pour les CMS qui embarquent trop de scripts et qui écraseront nos modifications à chaque mise à jour. Cela demande aussi un certain niveau de développement, or la plupart des sysadmin/webmestres sont surtout des bidouilleuses, pas des développeuses.
+== Quelques exemples ==
+L'option suivante permet à Dokuwiki et Simple Machine Forum de marcher, mais pas à Etherpad, et ne vaut rien aux yeux de [[https://observatory.mozilla.org/|l'Observatoire Mozilla]]. Cependant, même l'etherpad de Mozilla ne fait pas mieux.
   Header set Content-Security-Policy "default-src 'self' *khaganat.net; script-src 'self' 'unsafe-inline' *khaganat.net; style-src 'self' 'unsafe-inline'; img-src * "
-En effet, le paramètre ''unsafe-inline'' est, comme son nom l'indique, pas vraiment sécurisé, sans parler de ''img-src *'' qui accepte tout (mais sans ça, bonjour pour accepter les images en lien...).
+''img-src *'' ici accepte tout, mais sans ça, on n'affiche plus les images en lien, par exemple dans le forum, ce qui demande une solution interne pour les héberger.
-</WRAP>
-<WRAP center round todo 60%>
+Pour onlyoffice, après de nombreuses galères : la solution a été la CSP frame-ancestors pour permettre l'accès à une autre instance Onlyoffice par plusieurs instances nextcloud. Dans ce cas sur nginx avec le module more_headers, ça a donné ça :
-Travail en cours, on va trouver l'option ultime pour CSP, qui permette sécurité, A+ et fonctionnalités :-)
+  more_set_headers "Content-Security-Policy : frame-ancestors https://site1.example.com/nextcloud https://site2.example.com/ https://site3.example.com/nextcloud ";
+La règle suivante, assez générique, va "fonctionner" pour la plupart des CMS. La mettre dans une règle sur le proxy, appelée par les diverses configurations :
+  add_header Content-Security-Policy "default-src 'self' *.monsite.org 'unsafe-eval' 'unsafe-inline'; ";
-Pour le moment, cependant, etherpad bloque un csp de qualité. Même l'etherpad de Mozilla ne fait pas mieux.</WRAP>
@@ Ligne 203: / Ligne 222: @@
   * Le dernier morceau concerne OCSP qui accélère un peu les échanges en https, voir aussi [[https://www.octopuce.fr/accelerer-votre-ssl-tls-avec-ocsp-stapling/|Accélérer votre réponse SSL/TLS avec l’OCSP Stapling]]
 <code>
-SSLProtocol all -SSLv2 -SSLv3
+SSLProtocol +TLSv1.2
 SSLCompression off
-SSLCipherSuite ALL:!aNULL:!eNULL:!LOW:!MEDIUM:!EXP:!RC4:!3DES:!MD5:!PSK:+HIGH
+SSLCipherSuite HIGH:!aNULL:!eNULL:!LOW:!MEDIUM:!EXP:!RC4:!3DES:!MD5:!PSK:!kRSA:!SRP:-DH:+ECDH
 SSLHonorCipherOrder On
@@ Ligne 216: / Ligne 235: @@
-Pour la liste ''SSLCipherSuite'', consulter les préconisations de [[https://mozilla.github.io/server-side-tls/ssl-config-generator/|Mozilla SSL Configuration Generator]] et lire tranquillement l'explication si dessous avant de modifier la proposition ''ALL:!aNULL:!eNULL:!LOW:!MEDIUM:!EXP:!RC4:!3DES:!MD5:!PSK:+HIGH''
+Pour la liste ''SSLCipherSuite'', consulter les préconisations de [[https://mozilla.github.io/server-side-tls/ssl-config-generator/|Mozilla SSL Configuration Generator]] et lire tranquillement l'explication si dessous avant de modifier la proposition <wrap hi>mise à jour le 29 novembre 2017.</wrap>
@@ Ligne 230: / Ligne 249: @@
 Ce qui suit est extrait d'une conversation avec TychoBrahe ; j'ai conservé son style fleuri si savoureux.
- --- //[[wiki:user:zatalyz|zatalyz]] 2016/12/30 13:27//
+ --- //[[user:zatalyz|zatalyz]] 2016/12/30 13:27//
 </WRAP>
@@ Ligne 246: / Ligne 265: @@
 On pourrait croire qu'il y a 5 algorithmes, par exemple avec ECDHE-RSA-AES128-GCM-SHA256. En fait, GCM est un des modes de fonctionnement d'AES, donc AES128-GCM désigne de l'AES en mode GCM avec une clé de 128 bits. Pour info, les EC devant ECDHE et parfois ECDSA c'est pour //elliptic curve//, donc l'utilisation de courbes elliptiques au lieu de nombres premiers.
-SSL et TLS permettent d'utiliser non pas une seule combinaison, mais plusieurs, ce qui fait que ces protocoles intègrent une phase de négociation de la cipher suite. Chaque version de SSL ou TLS autorise ou non certaines cipher suites etc, bref c'est le bordel, sachant qu'il faut, avant ça, négocier la version de SSL ou TLS utilisée. Soit dit en passant, il existe une cipher suite NULL qui dit qu'il n'y a aucun chiffrement, du coup cette phase de négociation a été attaqué, un MITM((wpfr>Attaque_de_l'homme_du_milieu|Man In The Middle)) permettant de forcer une cipher suite (genre NULL ou une faible).
+SSL et TLS permettent d'utiliser non pas une seule combinaison, mais plusieurs, ce qui fait que ces protocoles intègrent une phase de négociation de la cipher suite. Chaque version de SSL ou TLS autorise ou non certaines cipher suites etc, bref c'est le bordel, sachant qu'il faut, avant ça, négocier la version de SSL ou TLS utilisée. Soit dit en passant, il existe une cipher suite NULL qui dit qu'il n'y a aucun chiffrement, du coup cette phase de négociation a été attaquée, un MITM(([[wpfr>Attaque_de_l'homme_du_milieu|Man In The Middle]])) permettant de forcer une cipher suite (genre NULL ou une faible).
 Afin d'éviter les ennuis, on va dire au serveur de n'utiliser que certaines cipher suites et pas d'autres : c'est l'option SSLCipherSuite. Chaque cipher suite est séparée par '':'' et s'il y a un ''!'' devant son nom, c'est pour explicitement l'interdire.
@@ Ligne 260: / Ligne 279: @@
   * !PSK <- pareil, une merde de plus de virée
   * +HIGH <- et enfin on autorise la famille des cipher suites reconnues comme fortes
-Du coup on fait confiance dans les familles définies dans les lib crypto, mais en imposant des restrictions sur certains trucs trop limites pour y être inclus mais qui ont des chances de tout de même s'y retrouver.
+Du coup on fait confiance dans les familles définies dans les lib crypto, mais en imposant des restrictions sur certains trucs trop limite pour y être inclus mais qui ont des chances de tout de même s'y retrouver.
 Les librairies ont un outil pour lister les familles, qui liste soit toutes les cipher suites supportées, soit, si on précise, la liste de ce qui est autorisé :
@@ Ligne 270: / Ligne 290: @@
   man 1 ciphers
-=== Les fichiers de site-enabled (vhost) ===
+== L'échange de clefs ==
+C'est un mécanisme permettant l'échange de clefs en toute confidentialité, sans qu'un tiers puisse avoir connaissance de celles-ci.
+== Le chiffrement a/symétrique ==
+La différence entre le chiffrement symétrique et le chiffrement asymétrique est que dans le premier cas, il n'y a besoin que d'une seule clef, qui permet aussi bien de chiffrer un message que de le déchiffrer. Pour le chiffrement asymétrique, on utilise une clef pour le chiffrement, et une autre clef différente de la première pour le déchiffrement. C'est pour cela qu'on parle de clef dite publique (celle que tout le monde peut voir et avec laquelle on va chiffrer les messages qui nous sont destinés) et de clef dite privée (celle avec laquelle on va déchiffrer notre message ; si on n'a pas accès à cette clef privée, on ne peut pas déchiffrer le message).
+== Le contrôle ==
+Afin de vérifier l'intégrité des messages que l'on transmet, on calcule une somme de contrôle que l'on envoie avec le message. Une fois le message et sa somme de contrôle réceptionnés, on peut recalculer la somme de contrôle du message et vérifier qu'elle correspond bien à celle qui a été transmise. Si elles diffèrent, c'est que le message a été altéré (ou qu'il y a une collision, c'est à dire que pour deux messages différents on obtient la même somme de contrôle, mais ce cas ne devrait quasiment presque jamais arriver).
+=== Les fichiers de sites-enabled (vhost) ===
 Une fois https configuré (let's encrypt lancé, les fichiers ''/etc/apache2/site-enabled/MONSITE-le-ssl.conf'' automatiquement configurés, vérifiez ces derniers. Là, deux possibilités : soit l'architecture "de base", où on a un seul serveur, sur la même machine que le pare-feu, soit deux machines, l'un étant le pare-feu et l'autre hébergeant les services web.
@@ Ligne 313: / Ligne 344: @@
 Je n'ai sans doute pas tout compris, ou alors ce n'est pas compatible avec ma version d'apache, mais si je l'ajoute ça me fait une erreur.
- --- //[[wiki:user:zatalyz|zatalyz]] 2017/01/01 18:33//
+ --- //[[user:zatalyz|zatalyz]] 2017/01/01 18:33//
 </WRAP>
+=== Faire suivre les IP derrière les reverse proxy ===
+Si vous avez une VM (A) qui sert de pare-feu avant de redistribuer le trafic aux autres VM (B) de votre serveur, il y a un petit souci : les VM B croient que tout le trafic vient de l'ip de la VM A. Ce qui pose un gros souci dans le cas où vous avez du spam et que votre CMS favori permet de bannir par IP... si vous bannissez la VM A, plus rien ne passera, même les utilisateurs légitimes.
+Il faut donc activer le transfert des IP sur les VMs destinataires (pas toucher au pare-feu, ce n'est pas là que ça se joue).
+Créer ''/etc/apache2/conf-available/remoteip.conf'' et lui donner ceci :
+<code>
+RemoteIPHeader X-Forwarded-For
+RemoteIPInternalProxy 192.168.20.35
+</code>
+Remplacer ''192.168.20.35'' par l'IP interne de la VM pare-feu.
+Activer le [[https://httpd.apache.org/docs/trunk/mod/mod_remoteip.html|module remoteip]] qui fait ça :
+  a2enmod remoteip
+  a2enconf remoteip
+  apache2ctl configtest && service apache2 restart
+Cela devrait marcher. À répeter sur chaque VM du réseau.
+=== Virer les traqueurs de Facebook ===
+Si vos liens se baladent sur Facebook, vos visiteurs vont visiter vos pages avec un tracker collé à l'url, du type ''https://monsite.fr/?fbclid=IwAR1RNFCx5Gu9SHRAbuj67ebqbu3Hc7YGgkOKh''. C'est pas propre, et puis ça peut mettre le bazar dans certains sites.
+On se fait un petit fichier appelé "bidouilles.conf"((On peut y rajouter d'autres trucs, pour le moment y'a surtout du Facebook.)) avec ce contenu :
+<code>
+# Des bidouilles à inclure partout.
+# Pour virer le tracker de Facebook
+<IfModule mod_rewrite.c>
+  RewriteEngine On
+  RewriteCond %{QUERY_STRING} ^(.*)(?:^|&)fbclid=(?:[^&]*)((?:&|$).*)$ [NC]
+  RewriteCond %1%2 (^|&)([^&].*|$)
+  RewriteRule ^(.*) $1?%2 [R=301,L]
+</IfModule>
+</code>
+Ensuite on appelle ce fichier dans nos vhost actifs :
+<code>
+<VirtualHost *:443>
+        ServerName monsite.fr
+# toute configuration utile en rab...
+# bidouilles perso
+        Include /etc/apache2/bidouilles.conf
+</code>
+Relancer apache et voilà, ça marche.
-{{tag> Serveur Administration Sécurité }}
+Astuce tirée de [[https://blog.paranoidpenguin.net/2018/12/how-to-remove-facebooks-fbclid-parameter-using-mod_rewrite-on-apache-2-4/|ce site]] avec quelques aménagements.
+{{tag> Serveur Sysadmin Sécurité }}