TOC

Comment auditer la sécurité de l’hôte Docker avec Docker Bench for Security sur Ubuntu 16.04

introduction

L’utilisation de Docker pour la mise en conteneur de vos applications et services peut vous apporter certains avantages en matière de sécurité, mais une installation par défaut de Docker a encore de la place pour certaines améliorations de la configuration liées à la sécurité. Le https://www.cisecurity.org [Centre pour la sécurité Internet], une organisation à but non lucratif dont la mission est de promouvoir les meilleures pratiques en matière de sécurité Internet, a créé a step étape par étape pour la sécurisation de Docker. Par la suite, l’équipe Docker a publié un outil d’audit de la sécurité, Docker Bench for Security, pour parcourir cette liste de contrôle sur un hôte Docker et signaler les problèmes détectés.

Dans ce didacticiel, nous allons installer Docker Bench for Security, puis l’utiliser pour évaluer la position de sécurité d’une installation Docker par défaut (à partir du référentiel Docker officiel) sur un hôte Ubuntu 16.04. Nous réglerons ensuite certains des problèmes pour lesquels il nous met en garde.

Nos correctifs sont principalement constitués des deux mises à jour de configuration suivantes:

  • Installer + auditd + et configurer des règles d’audit pour le démon Docker et ses fichiers associés

  • Mise à jour du fichier de configuration de Docker + daemon.json

Nous n’entrerons pas dans les détails sur la création de conteneurs sécurisés, nous nous concentrerons uniquement sur les mises à jour de la sécurité de l’hôte Docker dans ce tutoriel.

Conditions préalables

Pour compléter ce tutoriel, vous aurez besoin des éléments suivants:

Étape 1 - Installation de Docker Bench Security

Pour commencer, SSH dans l’hôte Docker en tant qu’utilisateur non root.

Nous allons d’abord cloner le script Docker Bench for Security sur le serveur en utilisant + git +, puis exécuter le script directement à partir du référentiel cloné.

Accédez à un répertoire dans lequel votre utilisateur peut écrire. Dans cet exemple, nous allons télécharger le script dans le répertoire de base de l’utilisateur:

cd ~

Puis clonez le référentiel Git + docker-bench-security +:

git clone https://github.com/docker/docker-bench-security.git

Tous les fichiers du référentiel seront extraits et placés dans un répertoire local + docker-bench-security +. Ensuite, déplacez-vous dans le répertoire résultant:

cd docker-bench-security

Enfin, pour effectuer l’audit de sécurité, exécutez le script + docker-bench-security.sh +:

./docker-bench-security.sh
Output# ------------------------------------------------------------------------------
# Docker Bench for Security v1.3.4
#
# Docker, Inc. (c) 2015-
#
# Checks for dozens of common best-practices around deploying Docker containers in production.
# Inspired by the CIS Docker Community Edition Benchmark v1.1.0.
# ------------------------------------------------------------------------------

Initializing Tue Jun  5 18:59:11 UTC 2018


[INFO] 1 - Host Configuration
[WARN] 1.1  - Ensure a separate partition for containers has been created
[NOTE] 1.2  - Ensure the container host has been Hardened
[INFO] 1.3  - Ensure Docker is up to date
[INFO]      * Using 18.03.1, verify is it up to date as deemed necessary
. . .

Le script exécute une variété de tests et donne un résultat + INFO +, + NOTE +, + PASS +, ou + WARN + pour chacun. Une installation par défaut de Docker sur Ubuntu 16.04 passera bon nombre de ces tests, mais affichera des avertissements dans les sections 1, 2 et 4.

Dans la suite de ce didacticiel, nous aborderons ces avertissements en sécurisant notre installation de Docker.

Étape 2 - Correction des avertissements de configuration de l’hôte

La première partie de l’audit teste la configuration du système d’exploitation de votre hôte, y compris son renforcement, ses versions de package et sa configuration d’audit. Regardons les tests de cette section:

  • 1.1 S’assurer qu’une partition distincte pour les conteneurs a été créée *

Pour assurer une isolation correcte, il est judicieux de conserver les conteneurs Docker et tous les + / var / lib / docker + sur leur propre partition de système de fichiers. Cela peut s’avérer difficile dans certaines situations d’hébergement dans le cloud où il est possible que vous ne puissiez pas partitionner les lecteurs. Dans ces cas, vous pouvez satisfaire à ce test en déplaçant le répertoire de données de Docker vers un périphérique bloc externe connecté au réseau.

Ce test est juste une note pour vous rappeler de penser à renforcer votre hôte. Le durcissement implique généralement la configuration d’un pare-feu, le verrouillage de divers services, la configuration de l’audit et de la journalisation, ainsi que la mise en œuvre d’autres mesures de sécurité. Vous pouvez commencer avec ceci en lisant 7 Mesures de sécurité pour protéger vos serveurs.

  • 1.3 S’assurer que Docker est à jour *

Ce test imprime votre version de Docker. Vous pouvez vérifier quelle version correspond à la version stable actuelle en visitant the release notes de Docker CE. Si vous n’êtes pas à jour et que vous avez installé Docker en utilisant + apt-get install y, vous pouvez utiliser` + apt-get in` pour mettre à jour le paquet Docker:

sudo apt-get update
sudo apt-get upgrade

  • 1.4 S’assurer que seuls les utilisateurs de confiance sont autorisés à contrôler le démon Docker *

Dans le prerequisite tutorial d’installation de Docker, nous avons ajouté notre utilisateur non root au groupe * docker * pour lui donner accès au démon Docker. Ce test génère la ligne de groupe * docker * à partir du fichier + / etc / group:

Outputdocker:x:999:

Cette ligne affiche tous les utilisateurs inclus dans le groupe * docker *. Passez en revue la ligne et assurez-vous que seuls les utilisateurs appropriés sont autorisés à contrôler le démon Docker. Dans l’exemple ci-dessus, notre utilisateur autorisé * sammy * est mis en surbrillance. Pour supprimer des utilisateurs de ce groupe, vous pouvez utiliser + gpasswd +:

gpasswd -d  docker

  • 1.5–1.13 Assurez-vous que l’audit est configuré pour différents fichiers Docker *

Nous devons installer et configurer + auditd + pour permettre l’audit de certains fichiers, répertoires et sockets de Docker. Auditd est un sous-système de surveillance et de comptabilisation des accès Linux qui enregistre les opérations système notables au niveau du noyau.

Installez + auditd avec` + apt-get`:

sudo apt-get install auditd

Cela installera et démarrera le démon + auditd +. Nous allons maintenant configurer + auditd + pour surveiller les fichiers et les répertoires Docker. Dans un éditeur de texte, ouvrez le fichier de règles d’audit:

sudo nano /etc/audit/audit.rules

Vous devriez voir le texte suivant:

/etc/audit/audit.rules

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 320

# Feel free to add below this line. See auditctl man page

Collez l’extrait suivant au bas du fichier, puis enregistrez et quittez l’éditeur:

/etc/audit/audit.rules

-w /usr/bin/docker -p wa
-w /var/lib/docker -p wa
-w /etc/docker -p wa
-w /lib/systemd/system/docker.service -p wa
-w /lib/systemd/system/docker.socket -p wa
-w /etc/default/docker -p wa
-w /etc/docker/daemon.json -p wa
-w /usr/bin/docker-containerd -p wa
-w /usr/bin/docker-runc -p wa

Ces règles indiquent à auditd de surveiller (+ -w +) le fichier ou le répertoire spécifié et de consigner toute écriture ou modification d’attribut (+ -p wa +) dans ces fichiers.

Redémarrez + auditd + pour que les modifications prennent effet:

sudo systemctl restart auditd

À ce stade, vous avez correctement configuré + auditd + pour surveiller les fichiers et les répertoires Docker à la recherche de modifications suspectes. Vous pouvez réexécuter le script Docker Bench for Security pour confirmer que les tests de la section 1 sont maintenant réussis.

Pour plus d’informations sur + auditd +, vous pouvez lire notre tutoriel How To Utilisez le système d’audit Linux sur CentOS 7. Bien qu’elles aient été écrites pour CentOS, les sections sur la configuration et l’utilisation du système d’audit s’appliquent également à Ubuntu.

Maintenant que nous avons vérifié la configuration de notre hôte, nous passons à la section 2 de l’audit de sécurité Docker, la configuration du démon Docker.

Étape 3 - Correction des avertissements de configuration de Docker Daemon

Cette section de l’audit traite de la configuration du démon Docker. Ces avertissements peuvent tous être traités en créant un fichier de configuration pour le démon appelé + daemon.json +, auquel nous ajouterons des paramètres de configuration liés à la sécurité. Nous allons d’abord créer et sauvegarder ce fichier de configuration, puis passer en revue les tests et les lignes correspondantes dans la configuration un par un.

Pour commencer, ouvrez le fichier de configuration dans votre éditeur favori:

sudo nano /etc/docker/daemon.json

Cela vous présentera un fichier texte vierge. Coller dans ce qui suit:

/etc/docker/daemon.json

{
   "icc": false,
   "userns-remap": "default",
   "log-driver": "syslog",
   "disable-legacy-registry": true,
   "live-restore": true,
   "userland-proxy": false,
   "no-new-privileges": true
}

Enregistrez et fermez le fichier, puis redémarrez le démon Docker pour qu’il prenne cette nouvelle configuration:

sudo systemctl restart docker

Vous pouvez maintenant réexécuter l’audit pour confirmer que tous les avertissements de la section 2 ont été traités.

Les variables de configuration que nous avons insérées dans ce fichier sont organisées dans le même ordre que les avertissements d’audit. Parcourons chacun d’eux:

  • 2.1 S’assurer que le trafic réseau est restreint entre les conteneurs sur le pont par défaut *

Cet avertissement est adressé par +" icc ": false + dans le fichier de configuration. Cette configuration crée des conteneurs qui ne peuvent communiquer entre eux que lorsqu’ils sont explicitement liés à l’aide de + - link = + sur la ligne de commande Docker ou du paramètre + links: + dans les fichiers de configuration de Docker Compose. L’un des avantages de cela est que si un attaquant met en péril un conteneur, il aura plus de mal à trouver et à attaquer d’autres conteneurs sur le même hôte.

  • 2.8 Activer la prise en charge des espaces de noms d’utilisateurs *

Les espaces de noms Linux fournissent une isolation supplémentaire pour les processus exécutés dans vos conteneurs. Le remappage de l’espace de noms d’utilisateur permet aux processus de s’exécuter en tant que * racine * dans un conteneur tout en étant remappés vers un utilisateur moins privilégié sur l’hôte. Nous activons le remappage de l’espace de noms d’utilisateurs avec la ligne " userns-remap ":" default " dans le fichier de configuration.

Nous définissons le paramètre sur + default +, ce qui signifie que Docker créera un utilisateur * dockremap * vers lequel les utilisateurs du conteneur seront remappés. Vous pouvez vérifier que l’utilisateur * dockremap * a été créé à l’aide de la commande + id +:

sudo id dockremap

Vous devriez voir une sortie similaire à celle-ci:

Outputuid=112(dockremap) gid=116(dockremap) groups=116(dockremap)

Si le remappage des utilisateurs de conteneur vers un autre utilisateur hôte est plus logique pour votre cas d’utilisation, spécifiez la combinaison utilisateur ou utilisateur + groupe: à la place de + défaut + `dans le fichier de configuration.

  • 2.11 Vérifier que l’autorisation pour les commandes du client Docker est activée *

Si vous devez autoriser un accès réseau au socket Docker, vous devez consultez la documentation officielle de Docker pour savoir comment configurer les certificats et les clés nécessaires. si bien.

Nous ne couvrirons pas ce processus ici, car les détails dépendent trop des situations individuelles. L’audit continuera à signaler ce test comme un «+ WARN +», bien que l’accès au socket Docker local uniquement par défaut soit protégé en exigeant l’appartenance au groupe * docker * afin que celui-ci puisse être ignoré en toute sécurité.

  • 2.12 S’assurer que la journalisation à distance et centralisée est configurée *

Dans le fichier de configuration du démon Docker, nous avons activé la journalisation syslog standard avec la ligne " log-driver ":" syslog ". Vous devez ensuite configurer syslog pour transférer les journaux vers un serveur syslog centralisé. Cela permet d’enregistrer les journaux de l’hôte Docker et de tout attaquant susceptible de les modifier ou de les supprimer.

Si vous souhaitez uniquement transférer les journaux Docker et ne souhaitez pas envoyer le journal syslog, vous pouvez spécifier le serveur syslog distant dans le fichier de configuration de Docker en ajoutant le paramètre suivant au fichier:

/etc/docker/daemon.json

   `"log-opts": { "syslog-address": "udp://:" }`

Veillez à remplacer l’adresse IP par votre propre adresse de serveur Syslog.

Vous pouvez également spécifier un pilote de journal tel que + splunk + ou + fluentd + pour expédier les journaux du démon Docker à l’aide d’autres services d’agrégation de journaux. Pour plus d’informations sur les pilotes de journal Docker et leur configuration, voir consultez la documentation officielle des pilotes de journalisation Docker.

  • 2.13 S’assurer que les opérations sur le registre existant (v1) sont désactivées *

Cet avertissement est corrigé par la ligne +" disable-legacy-registry ": true + dans le fichier de configuration du démon. Ceci désactive un protocole de registre d’images hérité non sécurisé. La prise en charge de ce protocole ayant déjà été supprimée du démon Docker, cet indicateur est en cours de dépréciation.

  • 2.14 S’assurer que la restauration en direct est activée *

En spécifiant +" live-restore ": true + dans la configuration du démon, nous permettons aux conteneurs de continuer à s’exécuter lorsque le démon Docker ne l’est pas. Cela améliore la disponibilité du conteneur lors des mises à jour du système hôte et d’autres problèmes de stabilité.

  • 2.15 S’assurer que le proxy Userland est désactivé *

La ligne +" userland-proxy ": false + corrige cet avertissement. Cela désactive le processus userland + docker-proxy + qui gère par défaut le transfert des ports de l’hôte vers les conteneurs et le remplace par les règles + iptables +. Si le NAT en épingle à cheveux est disponible, le proxy userland n’est pas nécessaire et doit être désactivé pour réduire la surface d’attaque de votre hôte.

  • 2.18 S’assurer que les conteneurs ne peuvent pas acquérir de nouveaux privilèges *

La ligne +" no-new-privileges ": true + dans la configuration du démon empêche l’escalade des privilèges depuis les conteneurs. Cela garantit que les conteneurs ne peuvent pas obtenir de nouveaux privilèges en utilisant les fichiers binaires + setuid + ou + setgid +.

Maintenant que nous avons mis à jour la configuration du démon Docker, corrigeons le dernier avertissement de la section quatre de l’audit.

Étape 4 - Activer la confiance du contenu

Le test final signalé par notre audit est +4.5 Assurez-vous que la confiance du contenu pour Docker est activée +. La confiance du contenu est un système permettant de signer les images Docker et de vérifier leurs signatures avant de les exécuter. Nous pouvons activer la confiance du contenu avec la variable d’environnement + DOCKER_CONTENT_TRUST +.

Pour définir cette variable pour votre session shell actuelle, tapez ce qui suit dans le shell:

export DOCKER_CONTENT_TRUST=1

L’exécution de l’audit après cette commande + export + devrait montrer que la confiance du contenu a été activée et effacer cet avertissement. Pour l’activer automatiquement pour tous les utilisateurs et toutes les sessions, ajoutez la variable + DOCKER_CONTENT_TRUST + au fichier + / etc / environment +, qui est un fichier permettant d’affecter des variables d’environnement à l’ensemble du système:

echo "DOCKER_CONTENT_TRUST=1" | sudo tee -a /etc/environment

Pour plus d’informations sur la confiance de Docker Content, consultez la documentation officielle de confiance de Docker Content.

À ce stade, nous avons traité tous les avertissements signalés par le script Docker Bench for Security. Nous avons maintenant un hôte Docker plus sécurisé pour exécuter les conteneurs.

Conclusion

Dans ce didacticiel, nous avons installé le script Docker Bench for Security, utilisé pour auditer la sécurité de notre installation Docker et résolu les avertissements en installant et en configurant + auditd + et le fichier de configuration du démon Docker.

Après avoir terminé ce didacticiel, l’exécution du script d’audit ne devrait générer que très peu d’erreurs ou d’avertissements. Vous devez également comprendre et avoir de bonnes raisons d’ignorer celles qui persistent.

Pour plus d’informations sur les options de configuration de la sécurité Docker, veuillez consulter la section Docker documentation et consultez les liens vers des sous-sections spécifiques de la documentation, qui ont été incluses tout au long de ce didacticiel.

Related