Différences

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

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
txs:secup19 [2019/05/16 10:54]
cbarrete
txs:secup19 [2019/05/21 13:45] (Version actuelle)
cbarrete
Ligne 1: Ligne 1:
 ======TX Sécu P19====== ======TX Sécu P19======
 +
 +## Objectifs de la TX
 +
 +Cette TX s'​inscrit dans la continuité de celle de A18 TODO LIEN. Elle avait pour
 +but d'​évaluer les résultats de celle-ci et d'​améliorer la sécurité de
 +l'​infrastructure par la mise en place de nouvelles procédures et solutions
 +techniques.
 +
 +
 +## Actions effectuées au cours de la TX :
 +Au cours de cette TX, nous avons effectuées les actions suivantes :
 +
 +- Identification des points à étudier.
 +- Préconisation de limiter les accès root sur les machines.
 +- Correction de nombreuses permissions erronées au niveau des services.
 +- Étude des possibilités de restriction du démon docker (voir [[txs:​secup19#​restriction_de_docker_avec_systemd|plus bas]]).
 +- Mise en place d'un démon d'​audit permettant une traçabilité des actions réalisées sur les machines.
 +
 +## Périmètre
 +
 +L'​audit a concerné toutes les VM de l'​infrastructure à l'​exception de celle de
 +Stéphane Crozat. Nous avons aussi bien traité les menaces venant de l'​extérieur
 +que de l'​intérieur. Pour ces dernières, le but était surtout d'​éviter les
 +accidents, notamment en production, plutôt que de considérer que les membres de
 +Picasoft aient des intentions malveillantes.
 +
 +L'​audit individuel des services a été fait moins en profondeur, la CI servant à
 +s'​assurer de l'​absence de vulnérabilité dans leur déploiement.
 +
 +Il a cependant été décidé que les machines appartenant aux membres de Picasoft
 +ne faisaient pas partie du périmètre de l'​audit. Ainsi, leur gestion de leurs
 +clefs SSH et du `pass` relèvent exclusivement de leur responsabilité.
 +
 +## Permissions
 +
 +Nous avons observé que tous les membres de l'​association avaient les droits
 +`root` sur l'​infrastructure,​ notamment en production. Cela va à l'​encontre du
 +principe de moindre privilège et facilite les erreurs (`sudo` un peu trop léger,
 +`poweroff` dans le mauvais terminal, etc.). La raison de cette distribution
 +large des droits `root` était que n'​importe quel utilisateur pouvant contrôler
 +Docker a indirectement accès aux droits `root` puisqu'​il peut notamment modifier
 +librement le système de fichiers de l'​hôte en temps que `root` en le montant
 +dans un conteneur. Cependant, un tel comportement est suspicieux et n'​arrive pas
 +par accident.
 +
 +Les droits `root` ont donc été remplacés en production par un ajout au groupe
 +`docker`, qui est suffisant pour administrer les conteneurs. Certains membres
 +comme le président et le responsable technique conservent toutefois les droits
 +`root` pour les tâches d'​administration. Les droits additionnels sont ensuite
 +accordé aux membres en ayant besoin, qui endossent alors les responsabilités
 +associées. Cette politique n'est pas arrêtée et peut évoluer en fonction des
 +besoins de l'​association et de ses membres ainsi que des problèmes
 +éventuellement rencontrés après sa mise en place.
 +
 +## Corrections mineures
 +
 +### Permissions excessives
 +
 +Les permissions de nombreux fichiers et répertoires sur tous les hôtes étaient
 +incorrects pour différentes raisons. Nous avons notamment trouvé des mots de
 +passe en clair lisible par tout le monde, des fichiers de configuration
 +inscriptibles par tout le monde et des fichiers exécutables modifiables par les
 +utilisateurs des services.
 +
 +Nous les avons corrigées en les restreignant au maximum tout en laissant la
 +majorité des fichiers de configuration lisibles aux membres de l'​association
 +pour des raisons pédagogiques.
 +
 +### Suppression de services
 +
 +Nous avons supprimé plusieurs services abandonnés : une instance n'​étant plus
 +fonctionnelle de Giphy pour Mattermost, un serveur fantôme Minetest tournant en
 +production et le site inutilisé Wordpress de Compiègne en transition.
 +
 +### Modifications de configuration
 +
 +Nous avons modifié les configuration SSH de tous les hôtes afin d'​interdire le
 +forwarding X jusque là permis. Aucun des hôtes ne fait a priori tourner de
 +serveur X, mais Xorg pourrait éventuellement être un jour installé,
 +éventuellement en temps que dépendance pour un autre paquet. Xorg étant une
 +vaste surface d'​attaque,​ nous avons décidé de totalement interdire le forwarding
 +X.
  
 ## Restriction de Docker avec systemd ## Restriction de Docker avec systemd
Ligne 41: Ligne 123:
 utilisateurs auxquels on confierait aussi `root`. Il n'y a donc utilisateurs auxquels on confierait aussi `root`. Il n'y a donc
 vraisemblablement pas de solution officielle à notre besoin. vraisemblablement pas de solution officielle à notre besoin.
 +
 +## auditd
 +
 +Nous avons étudié plusieurs solutions permettant de journaliser les commandes
 +exécutées sur le système, le but étant de pouvoir remonter à la cause d'un
 +éventuel problème sur l'​infrastructure.
 +
 +`auditd` est actuellement la solution la plus adaptée aux besoins de Picasoft :
 +il est largement supporté, s'​intègre bien avec SELinux si besoin, permet de
 +centraliser les logs et d'​effectuer leur rotation, permet de journaliser en
 +détail de nombreux événements sur le système et est hautement configurable.
 +
 +TODO centralisation ?
 +
 +TODO expliquer comment l'​utiliser
 +
 +[Une configuration disponible sur
 +Github](https://​gist.github.com/​Neo23x0/​9fe88c0c5979e017a389b90fd19ddfee389b90fd19ddfee389b90fd19ddfee389b90fd19ddfee)
 +présente de bonnes pratiques concernant `auditd` et permet de rapidement se
 +familiariser avec des nombreuses options proposées par son système de règles.
  • txs/secup19.1558004082.txt.gz
  • Dernière modification: 2019/05/16 10:54
  • par cbarrete