Archives de catégorie : cloud

Sécurité – Les demandes de certificats trahissent votre infrastructure

Comment les demandes de certificats peuvent trahir la structure publique et privée de votre infrastructure.

La sécurisation des communications est une réelle avancée dans l’amélioration de la vie privée.

Aujourd’hui les certificats ACME fournis par Let’s Encrypt ou ZeroSSL représentent la majorité des certificats utilisés dans le monde. Les statistiques le montre.

Cependant peu de gens savent ou prennent en compte que ces demandes sont publiques.

Et Alors ?

Un exemple

https://crt.sh/?q=voila.fr

Vous y verrez par exemple pour le site voila.fr possède des sous admin vip, etc, certains en wildcard ou ne répondant plus.

Même constat avec orange.fr par exemple.

Vous me direz, ou est le problème ?

Il est simple, vous informez la terre entière que vous avez un service nommé par exemple billing.stagingrealdata.macompagnie.fr , ce service est une cible privilégié.

Pourquoi ?

  • Ce service est peut-être en développement, vous ne voulez pas forcément communiquer dessus
  • La sécurité de ce service, n’est pas forcément parfaite, par exemple il peut avoir des comptes de test plutôt génériques avec des mots de passe très sommaire.
  • être non maintenu
  • être seulement accessible en interne, mais donne tout de même l’architecture de votre infrastructure alors que vous pensiez l’avoir protégée et cachée derrière un wildcard dns fictif.
  • et je vous laisse chercher les autres raisons.

Conclusion

A l’aire du Zero Trust, ce n’est pas grave en soit, mais ajoute une menace supplémentaire.

Bien-sûr tout ça va également dans le bon sens.

Référence et notes

https://github.com/SSLMate/certspotter/

Rancher 2.6 et docker-compose

En complément de Certificat Let’s Encrypt sur réseau local qui montre comment centraliser une génération privée de certificat, pour Kubernetes, voici un article sur comment monter un homelab simplement avec Rancher et docker-compose.

+

Docker-compose vs Kubernetes

Pourquoi Docker-compose plutôt que Kubernetes? Pour une question de ressource.

Rancher est très gourmand si en plus vous rajoutez Kubernetes votre micro serveur ou raspberry pi va tomber. il faudra déjà compter minimum 2 cpu et 4go de ram.

Enfin, c’est du test, donc du jetable.

Comment

Ci-dessous un docker-compose.yml reprenant l’exercice.

Vous y trouverez:

  • Traefik en tant que gateway et générateur de certificat ssl DNS-01 avec ici le provider Namecheap
  • Rancher en version stable
  • whoami pour tester la génération de certificat

Détails

Il y a plusieurs subtilités,

Rancher 2 impose le ssl à son niveau, donc vous devez pouvoir faire:

Browser ↔️ ssl let’s encrypt ↔️ Traefik ↔️ ssl (let’s encrypt ou pas) ↔️ rancher

Dans notre cas, avec docker-compose avec Traefik et sans accès public au serveur seul un certificat auto-signé au niveau rancher est possible. Il faut donc passer à –serverstransport.insecureskipverify=true.

Et enfin toute la partie label permettant de faire du proxy passthrough.

Tips

     profiles:
      - donotstart

Permet de gérer des profiles d’execution dans docker-compose, dans notre cas il nous permet surtout de ne pas executer directement whoami, de l’ignorer.

 restart: always

Attention, L’option restart ne marche que avec l’executable docker-compose (ici en 2.12), pas avec le plugin docker.

Certificat Let’s Encrypt sur réseau local

On peut lire un peu partout qu’il n’est pas possible d’utiliser Let’s Encrypt sur son réseau privé. Cette assertion est trop rapide. C’est compliqué, pas supporté par défaut, mais amplement faisable.

Une solution consiste à utiliser les fonctions de challenge DNS de Let’s Encrypt et de récupérer et installer en local ces certificats.

Si l’on souhaite cacher l’architecture interne de notre infrastructure (sans la déclarer dans dans un dns public), il suffit simplement d’utiliser un wildcard de sous-domaine.

Le flux d’action, réseau privé / internet, est le suivant:

Pour fonctionner, cette procédure nécessite un serveur DNS public avec une api permettant de mettre à jour vos enregistrement DNS. Vous trouverez de tels services auprès par exemple de DigitalOcean, Namecheap.

Exemple avec un serveur DNS namecheap

dans un répertoire de votre serveur possédant docker (ou directement avec certbot et python), par exemple /data/certs

git clone https://github.com/heralight/certbot_dns_namecheap.git

créer le fichier namecheap.ini dans /data/certs

dans /data/certs/certbot_dns_namecheap

docker-compose run certbot-dns-namecheap  certonly \
  --non-interactive  -a certbot-dns-namecheap:dns-namecheap \
  --certbot-dns-namecheap:dns-namecheap-credentials=/namecheap.ini \
  --agree-tos \
  --email "[email protected]" \
  -d *.mondomain.com

les certificats se trouvent dans /data/certs/certbot_dns_namecheap/out/certs/live/mondomain.com/

listes des certificats Let’s Encrypt certbot

docker-compose run  certbot-dns-namecheap  certificates  

renouvellement des certificats Let’s Encrypt certbot

Les certificats Let’s Encrypt ont une durée de validité courte, il vous faut les renouveler périodiquement.

docker-compose run  certbot-dns-namecheap  renew --force-renewal

dans un crontab ajouter -T en option pour éviter les problèmes. ex: docker-compose run -T …etc

Ensuite, à vous de configurer ou transférer (avec rsync, etcd ou consul par exemple) ces certificats ou bon vous semble.

Exemple – Lier Ingress avec ces certificats

Ci-après, un exemple d’utilisation pour un cluster Kubernetes avec une sur couche Rancher 2. Ingress va automatiquement utiliser vos certificats générés pour vos services exposés sur votre infrastructure.

Première étape, créer le secret contenant les certificats pour ingress.

kubectl -n devops-tools create secret tls tls-rancher-ingress \   --cert=/data/certs/certbot_dns_namecheap/out/certs/live/mondomain.com/cert.pem \   --key=/data/certs/certbot_dns_namecheap/out/certs/live/mondomain.com/privkey.pem

Ensuite automatiser la mise à jour avec crontab.

43 6 * * * cd /data/certs/certbot_dns_namecheap && /usr/local/bin/docker-compose run -T  certbot-dns-namecheap  renew --post-hook "kubectl -n devops-tools create secret tls tls-rancher-ingress    --cert=/data/certs/certbot_dns_namecheap/out/certs/live/mondomain.com/cert.pem   --key=/data/certs/certbot_dns_namecheap/out/certs/live/mondomain.com/privkey.pem --dry-run -o yaml |    kubectl apply -f - "

En conclusion, pas simple, mais faisable.

Pour information, l’api de Namecheap est disponible uniquement sur demande et sous condition d’avoir beaucoup de leur produit, mais à l’énorme avantage d’être compatible avec des domaines plus exotique, … comme les domaines islandais.