Exposition réseau des conteneurs

Qu'est-ce que Exposition réseau des conteneurs?

Publier un port de conteneur le lie par défaut à toutes les interfaces de l'hôte : un mappage ajouté par commodité en local peut ainsi exposer une base de données sur l'Internet public alors que le pare-feu de l'hôte indique toujours le port comme refusé. Vous vous mettrez d'abord dans la peau de l'attaquant : scanner l'hôte, vous connecter directement à la base de données avec un ancien mot de passe volé et lire les fiches clients sans qu'aucune application ne s'interpose. Ensuite, vous lierez le mappage à 127.0.0.1, vérifierez depuis l'extérieur et renouvellerez l'identifiant exposé.

Ce que vous apprendrez dans Exposition réseau des conteneurs

• Reconnaître que la publication d'un port de conteneur avec -p le lie à chaque interface de l'hôte, y compris les interfaces publiques
• Tracez une base de données exposée jusqu'à son mappage de port Compose en lisant la colonne PORTS du conteneur en cours d'exécution.
• Expliquez pourquoi un pare-feu hôte tel que ufw ne bloque pas un port publié par Docker, car les propres règles iptables de Docker sont évaluées en premier
• Appliquez une liaison 127.0.0.1 au mappage de port et vérifiez de l'extérieur que la base de données n'est plus accessible
• Faites pivoter tout identifiant accessible lorsque le port était ouvert, car sa fermeture n'invalide pas ce qui a été volé.

Exposition réseau des conteneurs — Étapes de la formation

1. Une base de données exposée sur internet

   Bob n'est à l'intérieur de rien. Il y a des mois, il a acheté un dump contenant un identifiant de base de données en lecture seule pour Halvexis, mais un identifiant est inutile si vous ne pouvez pas accéder à la base de données. Il analyse donc les hôtes du magasin de données de l'entreprise pour voir si l'un d'entre eux répond de l'extérieur.

2. Accès direct, sans application

   Il n'y a ni page de connexion, ni API, ni limitation de débit. Un port de base de données publié parle le protocole Postgres brut à quiconque peut l'atteindre. Bob pointe un client de base de données directement dessus et s'authentifie avec l'identifiant qu'il possédait déjà.

3. Lire la table des résidents

   L'identifiant est en lecture seule, ce qui est tout ce dont Bob a besoin. Il interroge la table qui contient les locataires de la plateforme et leurs informations, directement depuis la production. Bob possède exactement cet identifiant depuis des mois et ne l'avait jamais utilisé.

4. Ce qui a changé

5. La surveillance signale le trafic

   Halvexis exécute une surveillance cloud sur ses hôtes de production. Elle ne sait pas à quoi sert la base de données ; elle rapporte ce qu'elle a observé.

6. Trouver le port ouvert

   Si le pare-feu refuse toujours 5432, quelque chose sur l'hôte laisse passer le trafic autour de lui : la façon dont un conteneur a publié son port. Alice répertorie le conteneur de base de données et lit la colonne indiquant à quelles interfaces le port est lié.

7. Où le port est publié

   Le mappage de port provient du fichier Compose qui définit la stack. Alice l'ouvre pour voir la ligne qui a publié le port 5432.

8. La ligne responsable

   Un seul mappage, écrit comme un développeur l'écrirait sur son ordinateur portable, est ce qui a mis la base de données sur internet lorsque cette stack a été livrée en production.

9. Le lier à localhost

   L'API atteint la base de données via le réseau Compose par son nom de service, et non via un port hôte publié. Le mappage hôte n'a donc pas besoin d'être public du tout. Alice le restreint à l'interface loopback, de sorte que seul l'hôte lui-même, et les conteneurs de son réseau, puissent y accéder.

10. Lire la liaison corrigée

    Le changement tient en un préfixe d'interface, mais c'est toute la correction. Alice examine le mappage lié avant de redéployer, pour voir exactement ce qui est désormais accessible et depuis où.