Bonjour,
Roger Tarani, au 2019-07-16 :
> Ma première Debian c'était Jessie.
Et moi, c'était une Lenny. :)
> J'ai découvert, fait des erreurs et corrigé au
> fur-et-à-mesure. Heureusement, ce n'était pas pour un serveur
> de production ! Encore aujourd'hui je complète régulièrement
> mes connaissances limitées et je corrige des erreurs. Tant
> que les erreurs me ralentissent, ça va : oubli d'utiliser LVM
> qui simplifie beaucoup la gestion des partitions VS Gparted,
> problème de réseau créé par resolv.conf et sa bande de paquets
> douteux, réglages fins d'openvpn aux conséquences majeures pas
> immédiatement visibles...). Mais je ne suis jamais certain à
> 100% que la machine est sécurisée.
Vous pouvez être certain que votre machine n'est pas sécurisée à
100% ; ou alors vous l'avez balancée dans un trou noir. C'est
vrai pour toutes les machines, pas seulement votre ordinateur.
:)
Si vous vous inquiétez de la sécurité de vos machines, n'hésitez
pas à suivre de près les annonces de sécurité de Debian, en vous
abonnant à la liste par mail, ou en utilisant le flux RSS.
Souvent, des informations importantes accompagnent l'annonce de
mise à jour du ou des paquets affectés :
https://www.debian.org/security/
Le suivi des DSA est un bon début. Si vous avez des programmes
sensibles, alors vous pouvez suivre indépendamment leurs propres
canaux d'annonces de sécurité. Ne suivez pas directement
l'ensemble des CVE, à moins que vous n'ayez rien d'autre à faire
que de la sécurité. Bien sûr, mettez à jour vos systèmes
régulièrement. Si vous avez de nombreuses machines, afin de ne
pas en oublier, il vous faut un inventaire, et le conserver à
jour.
Éventuellement vous pouvez scanner votre réseau à coup de "nmap"
pour, peut-être, repérer des anomalies, comme des machines qui
ne devraient pas être présentes, des services qui ne devraient
pas être lancés, ou ne pas être visible depuis une certaine
partie du réseau. Vous pouvez même potentiellement identifier
des serveurs renvoyant des numéros de version ancien, et qui
mériteraient une mise à jour (à moins que ce serveur tourne sous
Debian, et que le patch soit déjà apporté par la version
X.Y.Z+debNuM). Le manuel de nmap(1) est assez épais ; si vous
ajoutez cet outil à votre processus de sécurisation, passez du
temps dans sa documentation.
Attention, si vous n'êtes pas administrateur système, il se peut
que votre charte informatique ne permette pas l'usage des
logiciels scannant le réseau, et passer outre cette interdiction
peut donc être motif de licenciement. C'est une forme de
sécurité, celle par l'obscurité...
Dans tous les cas, il vous faut une connaissance des services
qui sont déployées sur votre parc. Sans cela, quel que soit
l'outil utilisé pour scanner vos machines, vous ne pouvez pas
discriminer les composants indispensables au bon fonctionnement
de votre infrastructure des anomalies.
La sécurité est un processus, pas un produit.
-- Bruce Schneier
Note : j'espère n'avoir pas été l'hôpital qui se moque de la
charité... :)
[...]
> FAI ou GLPI sont prévus pour déployer des machines en masse et
> obligent au préalable à définir une configuration.
> Pensez-vous qu'ils puissent permettre de régler ce problème en
> vérifiant la configuration par rapport à des règles de
> sécurité et à des failles de sécurité connues ?
Fully Automated Installation (FAI) ne vérifie pas la
configuration à proprement parler, il la met en place dans la
foulée de l'installation du système d'exploitation. Lors de la
mise au point de vos scripts FAI, vous allez tester le système
résultant pour vous assurer qu'il rend bien le service pour
lequel il a été installé. Vous pouvez en profiter pour
scanner cette machine de test, mais une fois que les scripts
d'installation sont validés, ces vérifications post-installation
ne sont plus nécessaires ; du moins, tant que les scripts
d'installation de la machine ne sont pas modifiés.
L'installation se fait en suivant les spécifications que vous
donnez à FAI :
- la liste des paquets à installer, ou éventuellement à éviter,
- la topologie du stockage: point de montage, RAID, LVM, LUKS...
- l'exécution des scripts et copie des fichiers suite à
l'installation, notamment pour configurer la machine,
- le tout étant rassemblé en classes auxquelles vos divers noms
de machines peuvent, ou non, être rattachées.
Attention à ce que tout le monde ne puisse pas accéder à votre
machine dédiée aux installations FAI : elle sert à construire
votre parc d'ordinateurs, ce qui en fait une cible intéressante
en soi.
Si des changements en masse doivent être effectués après
installation, alors il est préférable de le coupler à un outil
de maintenance comme Puppet ou Ansible, et éventuellement de
reporter la modification dans FAI pour les installations
futures.
(Note à part: il y a bien un mécanisme fai-update qui permet de
passer des mises à jour, mais il est loin d'être aussi souple
que des spécifications Puppet ou Ansible, et ce mécano oblige à
rédiger les scripts de post-installation du système de manière
idempotente: l'appliquer une fois ou plusieurs doit toujours
donner la même situation finale.)
> Je ne sais pas s'ils fournissent une configuration des
> machines pré-établie ou si on doit définir la sienne à partir
> d'une feuille blanche.
Un répertoire /srv/fai/config est fourni en exemple dans les
fichiers d'installation, un rappel est affiché à la fin de
l'exécution de `fai-setup` ; la lecture de la documentation est
fortement recommandée pour situer le contexte :
http://fai-project.org/fai-guide/
Étant donné la complexité du programme, ce point de départ est
plus que bienvenu. Mais les exemples proposés ne vont pas
forcément très loin non plus : ils permettent grosso modo de
faire des installations de base, et présentent divers concepts
(host classes, disk config, packages list, scripts, files,
hooks, base archive, etc).
Amicalement,
--
Étienne Mollier <etienne.mollier@mailoo.org>
5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D
Attachment:
signature.asc
Description: OpenPGP digital signature