s’adresse principalement aux Debian · Philippe PIERRE a exercé de nombreuses années comme Administrateur de Bases de données puis Admi - nistrateur Système et Réseau. Aujourd’hui

Deb

ian

GN

U/L

inux

Maî

tris

ez la

séc

urité

des

app

licat

ions

Debian GNU/Linux Maîtrisez la sécurité des applications

Philippe PIERRE a exercé de nombreuses années comme Administrateur de Bases de données puis Admi-nistrateur Système et Réseau. Aujourd’hui responsable d’une infrastructure complète, il connaît parfaitement les systèmes Linux et Unix dans le cadre d’un environ-nement d’entreprise à haute disponibilité. Cette exper-tise lui permet de fournir au lecteur un livre réellement opérationnel, 100 % Debian, sur l’axe de la sécurité !

Ce livre sur la sécurité des applications d’un système Debian GNU/Linux s’adresse principalement aux administrateurs d’infrastructures mais aussi à toute personne en charge d’applications critiques nécessitant de la haute disponibilité. Un minimum de connaissances sur le fonctionnement des ser-vices web, de la messagerie, sur la gestion du stockage ainsi que sur le cloud est nécessaire afin de tirer le meilleur profit de ce livre. La lecture des livres Debian GNU/Linux - Maîtrisez la sécurité du système et Debian GNU/Linux - Maîtrisez la sécurité des infrastructures du même auteur est également un plus.L’auteur donne au lecteur les informations nécessaires pour gérer efficacement la sécurité des appli-cations web, des serveurs d’administration (DNS, DHCP, NIS, LDAP), des bases de données ainsi que des applications de stockage et de la messagerie. Ainsi, vous découvrirez comment sécuriser des services web tels que des serveurs de documentation wiki ou des blogs WordPress ou comment sécuriser des annuaires. Vous étudierez ensuite la sécuri-sation des données et la gestion du stockage en prenant l’exemple d’un serveur NAS. Vous passerez à la sécurisation d’un serveur de messagerie en étudiant les questions de filtrage de distribution, d’authentification via le protocole SASL ou encore de chiffrement avec des certificats TLS/SSL. Avec un chapitre sur la sécurité de l’Internet des Objets, l’auteur apporte des éléments clés pour minimi-ser les intrusions potentielles via les équipements. Pour finir, le dernier chapitre, tour d’horizon des applications d’hébergement dans le Cloud, décrit les nouvelles perspectives de la cybersécurité 2.0 (OpenStack, Duplicity).À l’issue de cette lecture, vous serez en mesure d’accroître considérablement la sécurité des applica-tions dans un système Debian/GNU Linux.

Avant-propos • Sécurisation d’applications web • Sécurisation d’annuaires • Sécurisa-tion des données et du stockage • Sécurisation de la messagerie • Sécurisation de l’Internet des objets • Sécurité et Cloud • Conclusion • Glossaire

Les chapitres du livre

Téléchargementwww.editions-eni.fr.fr

sur www.editions-eni.fr : b Les scripts des exemples du livre.b Une description de la chaîne bitcoin.

ISSN : 1960-3444ISBN : 978-2-409-01332-4

54 €

Pour plus d’informations :

Debian GNU/Linux

Maîtrisez la sécurité des applications

Philippe PIERRE

1Table des matières

Avant-propos1. Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2. Public visé. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Prérequis et connaissances nécessaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4. Structure de l'ouvrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5. Normes et règles de nommage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Chapitre 1

Sécurisation d’applications web1. Cryptographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.1 Présentation et définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2 Algorithmes et protocoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.3 Fonctions de hachage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4 Législation et cadre juridique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.5 Les limites de la cryptographie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2. Infrastructure PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2 Infrastructure à clé publique ou PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.3 Certificat X.509. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.4 La suite OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.5 Autorité de certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3. Les certificats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.1 La certification SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2 Les certificats multiples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.3 Mise en œuvre d’un certificat SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.4 L’alternative "Let’s Encrypt". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Les éléments à télécharger sont disponibles à l'adresse suivante : http://www.editions-eni.fr

Saisissez la référence ENI de l'ouvrage EPSADEB dans la zone de recherche et validez. Cliquez sur le titre du livre puis sur le bouton de téléchargement.

lcroise

Tampon

2Maîtrisez la sécurité des applications

Debian GNU/Linux

3.5 Tests de la configuration avec SSL Labs . . . . . . . . . . . . . . . . . . . . . . . . 53

4. Serveur web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.1 Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.2 Sécurisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.3 Chiffrement et certificat du serveur web . . . . . . . . . . . . . . . . . . . . . . . 654.4 Tunnels sécurisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5. Les serveurs Wiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.2 Permissions d’accès au Wiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.3 Apparence du Wiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.4 Personnalisation de la page d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.5 Sécurisation du serveur web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6. Publications WordPress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966.2 Gestion de contenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976.3 Installation de WordPress. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.4 Personnalisation du thème . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016.5 Sécurisation du blog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Chapitre 2

Sécurisation d’annuaires1. Sécurisation de l’annuaire de noms DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

1.1 Généralités sur le serveur de noms. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1101.2 Attaques visant le serveur de noms . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111.3 Recommandations générales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1121.4 Mise en œuvre d'un serveur DNS simple . . . . . . . . . . . . . . . . . . . . . . 1131.5 Emprisonnement du serveur de noms . . . . . . . . . . . . . . . . . . . . . . . . . 1181.6 Mise en place du protocole TSIG et DNSSEC . . . . . . . . . . . . . . . . . . 124

2. Mise en œuvre d'un annuaire OpenLDAP . . . . . . . . . . . . . . . . . . . . . . . . . . 1282.1 Architecture d'un annuaire LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1292.2 Sécurité d'utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1332.3 Sécurisation du backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1362.4 Installation d’un serveur LDAP minimal. . . . . . . . . . . . . . . . . . . . . . . 1382.5 Réplication des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1462.6 Chiffrement des échanges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150


3. Alternative de l'annuaire LDAP : NIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1533.1 Service NIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1533.2 Restriction d'utilisateurs ou de groupes . . . . . . . . . . . . . . . . . . . . . . . 1563.3 Sécurisation du service NIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573.4 Initialisation d'un serveur NIS esclave . . . . . . . . . . . . . . . . . . . . . . . . 158

4. Service d'adressage dynamique DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1594.1 Fonctionnalités du service DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1594.2 Sécurisation du service DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1614.3 Utilisation du failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1624.4 Association avec le protocole DNSSEC. . . . . . . . . . . . . . . . . . . . . . . . 163

5. Solution évoluée : SAMBA 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1675.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1675.2 Installation de la solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1685.3 Configuration du domaine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1705.4 Administration du domaine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Chapitre 3

Sécurisation des données et du stockage1. Introduction à la donnée. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

1.1 Qu’est-ce qu’une donnée ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1751.2 Référentiel et métadonnées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1761.3 Gestion de la donnée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1781.4 Cycle de vie de la donnée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

2. Notion de stockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1832.1 Les bases de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1832.2 Constitution d’une base de données . . . . . . . . . . . . . . . . . . . . . . . . . . 1842.3 Les composants d’une base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

3. Protection des bases de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1873.1 Sécurisation de PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1873.2 Sécurisation de MariaDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1983.3 Sécurisation de Cassandra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2103.4 Sécurisation de MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217


Debian GNU/Linux

4. Comment protéger le stockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2234.1 Différents types de stockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2234.2 Axes de sécurisation du SAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2264.3 Axes de sécurisation du stockage NAS . . . . . . . . . . . . . . . . . . . . . . . . 228

5. Mise en œuvre d’un serveur NAS OpenMediaVault . . . . . . . . . . . . . . . . . . 2305.1 Présentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2305.2 Prérequis à l’installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2315.3 Installation d’OpenMediaVault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2335.4 Configuration d’OpenMediaVault. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2405.5 Sécurisation d’OpenMediaVault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Chapitre 4

Sécurisation de la messagerie1. Les différentes fonctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

1.1 La messagerie électronique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2531.2 L’agent de transfert des messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2561.3 L’agent de distribution des messages . . . . . . . . . . . . . . . . . . . . . . . . . . 2581.4 L’agent des messages utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

2. Configuration avancée. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2642.1 Le mécanisme anti-relayage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2642.2 Daemon chrooté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2642.3 Gestion des filtres anti-spam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2672.4 Filtrage des en-têtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

3. Intégration en base de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2703.1 Initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2703.2 Configuration SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2723.3 Filtrage de messages non conformes . . . . . . . . . . . . . . . . . . . . . . . . . . 2753.4 Authentification SASL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2763.5 Génération de certificats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

4. Sécurisation des clients de messagerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2814.1 Installation d’Enigmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2814.2 Configuration d’Enigmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2834.3 Génération de la paire de clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286


4.4 Échanges de clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2894.4.1 Export de clé publique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2904.4.2 Import de clé publique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

4.5 Échanges de messages chiffrés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

5. Passerelle complète anti-spam sécurisée . . . . . . . . . . . . . . . . . . . . . . . . . . . 2965.1 Description du modèle et installation . . . . . . . . . . . . . . . . . . . . . . . . . 2965.2 Configuration du "grey listing" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3005.3 Configuration de la validation de signature . . . . . . . . . . . . . . . . . . . . 3005.4 Configuration du MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3015.5 Configuration de MailScanner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

5.5.1 Nettoyage des courriels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3125.5.2 Fichiers de configuration supplémentaires. . . . . . . . . . . . . . . . 3135.5.3 Outil MailWatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314

5.6 Fonctionnement de la plateforme complète . . . . . . . . . . . . . . . . . . . . 317

Chapitre 5

Sécurisation de l’Internet des objets1. Définitions et présentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

1.1 Qu’est-ce que l’IoT ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3221.2 Le "big data". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3231.3 Données et protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3231.4 Architecture IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3251.5 Sécurité du réseau LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

2. Protocole de distribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3362.1 Le protocole MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3362.2 Implémentations de MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3412.3 Failles connues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3422.4 Récapitulatif des risques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

3. Évolution de la cryptographie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3453.1 Infections de l’IoT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

3.1.1 Fonctionnement d’un botnet . . . . . . . . . . . . . . . . . . . . . . . . . . 3453.1.2 Exemple de botnet : mirai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

3.2 Constat technologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357


Debian GNU/Linux

3.3 Cryptographie légère. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3603.3.1 Algorithmes de chiffrement par bloc . . . . . . . . . . . . . . . . . . . . 3603.3.2 Algorithmes de chiffrement par flot . . . . . . . . . . . . . . . . . . . . . 3623.3.3 Fonction de hachage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

3.4 Nouvelle piste à explorer : blockchain . . . . . . . . . . . . . . . . . . . . . . . . . 3643.5 Éprouver la sécurité d’objets connectés . . . . . . . . . . . . . . . . . . . . . . . . 368

3.5.1 Conception d’un micronoyau . . . . . . . . . . . . . . . . . . . . . . . . . . 3713.5.2 Base de confiance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3733.5.3 L’isolation des programmes sensibles . . . . . . . . . . . . . . . . . . . . 3733.5.4 Génération de preuves formelles . . . . . . . . . . . . . . . . . . . . . . . . 374

4. Mise en œuvre d’objets connectés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3764.1 Installation de la pile Tick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3784.2 Installation de la base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3794.3 Installation de l’outil de collecte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3814.4 Installation de l’interface utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . 3834.5 Mise en œuvre de la communication. . . . . . . . . . . . . . . . . . . . . . . . . . 387

Chapitre 6

Sécurité et Cloud1. Présentation et définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

1.1 Qu’est-ce que le Cloud ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3911.2 Types de Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3931.3 Problématiques liées au Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3941.4 Les niveaux de services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3951.5 Debian et le Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

1.5.1 Classification des données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4001.5.2 Externalisation du contenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4011.5.3 Administration à 360° des données. . . . . . . . . . . . . . . . . . . . . . 4011.5.4 Administration de l’écosystème . . . . . . . . . . . . . . . . . . . . . . . . 4031.5.5 Sauvegarde de l’écosystème. . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

2. Installation de Dropbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4052.1 Installation en ligne de commande . . . . . . . . . . . . . . . . . . . . . . . . . . . 4052.2 Installation via GDebi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4072.3 Configuration Dropbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4082.4 Sécurisation de Dropbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409


3. Mise en place d’un SIEM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4093.1 Initialisation du SIEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4103.2 Structure interne du SIEM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4113.3 Règles de corrélation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4143.4 Module de gestion de logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4153.5 Module de présentation web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416

4. Déploiement OpenStack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4204.1 Présentation et technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4204.2 Réseau et virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4244.3 Mise en œuvre de Keystone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4274.4 Mise en œuvre de Glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4304.5 Mise en œuvre de Nova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4324.6 Mise en œuvre de Cinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4354.7 Intégration de l’interface Horizon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437

5. Sauvegardes Duplicity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4395.1 Introduction et description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4395.2 Utilisation basique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4405.3 Sauvegarde de bases de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4415.4 Synchronisation distante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4435.5 Sauvegarde chiffrée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4435.6 Communication avec le Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445

Conclusion1. Niveaux évolutifs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449

2. Évolution de la sécurisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450

3. Bilan des opérations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452

4. Cybersécurité 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453

5. Pour conclure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454

Glossaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469

Chapitre 2

Sécurisation d’annuaires

Sécurisation d’annuaires1. Sécurisation de l’annuaire de noms DNS

Dans la mesure où nombre d’applications, comme nous l'avons vu précédemment,ont recours à la résolution de noms pour reconnaître les serveurs sous-jacents, on peutalors s’interroger sur le degré de sécurité souhaité en ce qui concerne ce service bienparticulier, faisant transiter des informations critiques au travers d’Internet (adressesIP et noms FQDN). La fonctionnalité BIND (Berkeley Internet Name Daemon aussiappelée Berkeley Internet Name Domain) est le serveur de résolution de noms DNS leplus utilisé sur Internet, spécialement sur des serveurs Unix/Linux. C’est donc devenule standard de facto de la résolution DNS et il appartient donc aux applications cou-ramment utilisées.RAPPEL : la première version de BIND a été conçue par quatre étudiants diplômés del’université de Berkeley en Californie, sur la base du système d’exploitation BSD 4.3.En 1988, c’est Paul VIXIE qui reprend la maintenance du projet. Actuellement, BINDest développé par l’Internet System Consortium (ISC).

lcroise

Tampon

© E

dit

ions

EN

I -

All r

ights

rese

rved


Debian GNU/Linux

1.1 Généralités sur le serveur de noms

Un serveur de noms (abrégé en DNS pour Domain Name Server) est un annuaire àstructure arborescente inversée. La racine est généralement représentée en haut etdéploie ses branches vers le bas. Son rôle est de faciliter l'accès aux systèmes disposantd'adresses IP et leur permettre, grâce à un mécanisme d'association, de récupérer lenom des serveurs. La racine est alors représentée par un ".", on trouve, en dessous, lesdomaines de haut niveau (aussi appelés top-level domains) : .fr, .com, .org, .eu... Leparcours s'effectue donc à l'envers depuis la racine, vers le bas (la machine ou le ser-veur référencé) :

De façon intégrée, le serveur de noms possède une configuration particulière pour lesrouteurs de courrier électronique (notée généralement MX), autorisant une résolutioninverse de celle effectuée par les hôtes classiques, ainsi qu'un mécanisme autorisantun facteur de priorité et une tolérance aux pannes. En résumé, le serveur de noms estconçu pour pallier les défaillances du fichier système /etc/hosts et doit permettrede répondre ainsi aux impératifs de conception et d'architecture que sont :– L'aspect dynamique : les enregistrements doivent être manipulés de façon unique

au sein du réseau et sont accessibles de tous.– L'aspect réplication : il est nécessaire de dupliquer les informations pour ne pas avoir

de point de contention.

111Sécurisation d’annuairesChapitre 2

– L'aspect hiérarchie : le fait d'architecturer un DNS en arbre permet une meilleureorganisation. Chaque niveau est appelé « zone » et le sommet de l'arbre est noté ".".

– L'aspect répartition : l'arbre DNS est distribué. Les informations sont réparties surune multitude de zones et l'ensemble de ces bases d'informations compose l'intégra-lité des enregistrements DNS. Cela permet d'envisager la répartition de charge avecplus de facilité.

– L'aspect sécurité : suite à des attaques multiples sur l'annuaire lui-même, les infor-mations (socle de cette architecture) ayant été corrompues, il a fallu trouver unmoyen de protéger ces enregistrements. On peut ainsi mettre en place un systèmed'authentification, de contrôle d'accès et d'intégrité.

Les résolutions de noms (ou d'adresses) s'effectuent au travers d'un équipement(serveur, ou autre), appelé résolveur. Sans pour autant résoudre tous les problèmes desécurité, liés au protocole BIND, il convient, malgré tout, de déporter le service DNS,au sein d'une arborescence dédiée, afin de réduire le risque d'utilisation d'une faille desécurité, par un tiers malveillant. Bien évidemment, il faut aussi utiliser un comptedifférent de celui du super-utilisateur afin d'empêcher la possibilité, à un pirate, dedisposer des droits d'administration renforcés du compte root.

1.2 Attaques visant le serveur de noms

Les attaques sur les différents équipements impliquant le serveur DNS sont plutôtd'ordre technique et font, le plus souvent, référence à des stratégies d'attaquesmassives ou à des corruptions d'enregistrements échangés entre les résolveurs et lesserveurs DNS. On dénombre principalement quatre catégories d'attaques directes :– Attaque par empoisonnement : l'attaquant « intoxique » le résolveur pour forcer

la machine de l'attaquant à être reconnue comme valide, au lieu de la machine d'ori-gine. Ce genre de détournement vise essentiellement à capter les requêtes DNS versun autre site, sans que les utilisateurs locaux puissent s'en rendre compte.

– Déni de service (on parle aussi de Denial of Service que l'on note DoS) : le piraterend un service distant inactif (voire inaccessible), en saturant la machine héber-geant le service, de requêtes.

Remarque

Une forme plus élaborée du Denial of Service appelée distributed Denial of Service (etnoté dDoS), utilise le même principe, mais en s'appuyant, non plus sur la seule machinedu pirate, mais sur l'ensemble des machines du réseau Internet. Cela s'apparente à unroBOT NETwork (aussi abrégé en BOTNET).

© E

dit

ions

EN

I -

All r

ights

rese

rved


Debian GNU/Linux

– Réflexion : l'attaquant émet de nombreuses requêtes au nom de sa victime. Lorsqueles destinataires répondent, ils contribuent ainsi à saturer les infrastructures de l'en-treprise visée, à cause de la convergence des messages.

Remarque

Combinée à la réflexion, l'amplification permet de ralentir les résolutions de noms et parlà même, les performances des serveurs de noms DNS.

– Fast flux : le pirate falsifie son adresse IP (pour ne pas être démasqué), tout ens'appuyant sur la rapidité de diffusion des informations de localisation (pour éviterd'être localisé trop rapidement). Il existe de nombreuses variantes : simple flux (oùl'adresse du serveur web change périodiquement et régulièrement), double flux (oùles adresses des serveurs web et DNS changent).

1.3 Recommandations générales

Au sein d'une architecture d'entreprise, il convient donc de sécuriser les différentsmaillons de l'application DNS, d'abord dans sa globalité : au niveau architectural, maiségalement au niveau fonctionnel : les flux d'informations circulant entre les échelonsde l'arborescence DNS. Voici donc quelques conseils et préconisations fondamentauxde sécurité concernant la résolution de noms.

Opter pour la redondance

Pour qu'en cas d'attaque, le service de noms continue de fonctionner et que le serveurvisé puisse être changé ou remplacé de façon transparente, il vaut mieux installer lenom de domaine, au minimum sur deux serveurs identiques. La plupart du temps, oninstalle un premier serveur appelé maître, qu'il suffit ensuite de cloner pour permettrede répartir la charge et les services sur ce second équipement, appelé esclave.

Veiller à tenir à jour la version

Ce qui est valable pour le système d'exploitation l'est a fortiori pour une de sesapplications : le DNS. Il faut donc toujours s'assurer d'appliquer les dernières versionsdu protocole BIND et/ou les derniers patchs, en vue de ne pas être inquiété par les vul-nérabilités et les failles potentielles des anciennes versions.

Effectuer une surveillance accrue

Cette recommandation va de pair avec la précédente. Il s'agit de ne pas faire entière-ment confiance à la robustesse de l'architecture redondée, mais de surveiller régulière-ment les serveurs de noms et leur configuration (ainsi que leurs performances). Cettevérification peut être faite par script, via un programme tiers (comme ZoneCheck) oudepuis l'extérieur, en faisant appel à un organisme payant et accrédité.

113Sécurisation d’annuairesChapitre 2

Sécuriser les flux d'échanges

La meilleure façon de protéger un serveur de noms est de chiffrer les échanges entreclients, résolveurs et serveurs de noms. Il existe, à cet égard, un protocole de sécurisa-tion autorisant l'authentification des serveurs et empêchant les attaques de type em-poisonnement. Il s'agit du protocole DNSSEC.

Prévoir un plan de reprise

Nous avons déjà traité ce sujet dans le livre Debian GNU/Linux - Maîtrisez la sécuritédes infrastructures, chapitre Outils de sauvegarde. Mais il paraît évident qu'il ne fautsurtout pas négliger le plan de reprise d'activité en cas de grosses catastrophes : incen-die, inondation, destruction... De plus, ce genre de politique présente aussi un aspectfinancier, car les serveurs à provisionner sont à prévoir dans les budgets d'entrepriseet à installer dans un plan d'adresses différent de celui de la production.

1.4 Mise en œuvre d'un serveur DNS simple

Après avoir évoqué quelques éléments d'architecture et de sécurité, il est possibled'installer le package bind9 sur Debian, de la façon suivante :# apt-get update # apt-get install bind9

Il faut veiller à modifier et/ou créer les trois fichiers de configuration suivants pourpouvoir paramétrer son serveur DNS comme on le souhaite :– Le fichier de configuration principal : /etc/bind/named.conf.local– Le fichier de zone : /etc/bind/db.mydmn.org (référencé dansnamed.conf.local)

– Le fichier de la zone reverse : /etc/bind/db.mydmn.org.rev (référencé dansnamed.conf.local)

Remarque

Le fichier named.conf n’est en fait qu’un regroupement d’inclusions de fichiers. Il estfortement déconseillé de le modifier. Il vaut mieux ajouter les zones dans le fichiernamed.conf.local.

En ce qui concerne le fichier named.conf.local, il faut déclarer la liste des zones(ou domaines), que le serveur DNS va devoir prendre en charge :

zone "mydmn.org" { type master;

file "/etc/bind/db.mydmn.org"; forwarders{};

};

© E

dit

ions

EN

I -

All r

ights

rese

rved


Debian GNU/Linux

Dans cet exemple, le nom de zone est mydmn.org, son fichier associé de paramétragese trouve dans /etc/bind et se nomme db.mydmn.org. En toute logique, il fautconfigurer la zone "reverse" de la même manière :

zone "1.168.192.in-addr.arpa" { type master;

file "/etc/bind/db.mydmn.org.rev"; forwarders{};

};

En lieu et place du nom de la zone, il suffit de positionner l'adresse réseau inverse de192.168.1, soit 1.168.192 en ajoutant .in-addr.arpa. Nous pouvons alors générerle fichier principal de la zone mydmn.org, en déclarant l’autorité de résolutioncomme suit :

$TTL 604800

@ IN SOA debian.mydmn.org. root (

2017100725 ; n° Serial

604800 ; Refresh

86400 ; Retry

2419200 ; Expire

604800) ; Minimum

IN NS debian.mydmn.org. ; Nom du serveur DNS

debian IN A 192.168.1.251 ; Adresse du DNS

debian HINFO "MyDNS" "Debian Jessie Beta1" ; Infos du DNS

Avant d’aller plus loin, remarquez que les commentaires sont préfixés par des ";".Vient ensuite la déclaration SOA de l’autorité de résolution des noms. Le numéroSerial (ici, 2017100725), est utilisé par les serveurs DNS esclaves que l’on doit confi-gurer par la suite, afin d’indiquer s’ils doivent ou non mettre à jour leur base. Généra-lement, ce numéro se compose d’une date inversée suffixée par un chiffre que l’onincrémente lors de chaque modification du fichier de zone. Les trois champs suivantspermettent de configurer le processus de communication du serveur esclave, vis-à-visde son maître : à l’expiration du délai Refresh, le serveur esclave contacte son maîtreet si le message n’aboutit pas, il faudra relancer une tentative au bout du délai exprimépar le champ Retry. À l’expiration du délai Expire, le serveur esclave considéreraalors que son maître n’est plus joignable. Le dernier champ permet de définir la duréede vie minimum du cache. Les délais sont exprimés en secondes. Les trois dernièreslignes de la déclaration de l’autorité de résolution permettent au serveur de noms dese repérer lui-même. Le champ HINFO donne la possibilité de repérer, à l’aide d’infor-mations complémentaires, le serveur de noms lui-même. Mais pour des raisons de sé-curité, il est déconseillé d’indiquer trop d’informations.

Documents

s’adresse principalement aux Debian · Philippe PIERRE a exercé de nombreuses années comme Administrateur de Bases de données puis Admi - nistrateur Système et Réseau. Aujourd’hui