Microsoft on Zwindler's Reflection

Comment veulent-ils que nous mettions à jour huit cents serveurs toutes les semaines !?

Sat, 30 Jul 2022 12:00:00 +0000

C’est avec cet extrait d’un article de #LeMagIT que j’ai lancé (un peu malgré moi) un gros débat sur Twitter 🐦.

(Et il y a encore plus grave dans l’article, j’ai rajouté une note, plus loin)

Pour vous résumer la chose, j’ai lu un témoignage de Manutan qui a subit une cyberattaque en février 2021.

Le Mag IT - Récit : comment Manutan s’est sorti de la cyberattaque du 21 février

Le directeur des opérations IT du groupe explique que Microsoft n’a pas voulu les aider (enfin si, mais pas gratuitement et pas au pied levé 😏) car ils ne mettaient pas à jour leurs serveurs.

“Comment veulent-ils que nous mettions à jour huit cents serveurs toutes les semaines !?”

Je tombe de ma chaise 🪑

Quelques réponses que j’ai reçu à la suite de ça :

“tout les Kevin je sais tout qui pense que c’est vraiment possible d’update 800 machine toute les semaines”

(oui quelqu’un m’a répondu ça)

Loin de moi l’idée de nier la difficulté de maintenir un parc de serveurs dans un environnement industriel + Windows (je connais, je l’ai déjà fait).

Et bien entendu qu’il faut rester humble : même avec la meilleure des sécurités, une attaque reste toujours possible pour un criminel suffisamment motivé.

Mais quand même ! Que quelqu’un ose écrire, sans rougir, après attaque au cryptolocker, qu’ils ne mettent pas à jour leur parc, car c’est trop compliqué ???

Avec toutes les cyber attaques qui pleuvent depuis des années ? Avec tous les messages martellés par ANSSI, la gendarmerie et le gouvernement ?

“cest chaud… surtout s’il y a des applications spécifiques avec des technos différentes…”

Que certains systèmes industriels soient mal conçus, peu maintenus par l’éditeur, impossible à mettre à jour sans interruption, ce sont des faits.

Pour autant, ça ne veut pas dire que c’est acceptable, hein ?

A nous, professionnels de l’IT de peser sur les décideurs pour éviter d’en arriver là ! La maintenabilité et les logiciels à sources ouvertes devraient être dans la liste des critères pour choisir une solution logicielle / industrielle, quelle qu’elle soit.

“Une plate-forme de QA Iso prod avec des tests automatisé de non régression est vu comme une charge et non pas comme mandatory. 🤷‍♂️”

Les outils/moyens pour automatiser les mises à jours ET les tests de régression existent (même sous Windows 😏). Encore faut-il y mettre les moyens (financiers, humains) et former les opérationnels ! Pas toujours facile à faire entendre à un ComEx, mais c’est là aussi le rôle et la responsabilité du DSI / RSSI. Ca me parait un peu facile de s’en défausser par la suite.

L’humain est aussi capital et souvent sous-estimé par rapport à l’outillage (acheter un EDR ou faire un audit de sécu oneshot, c’est rassurant, mais est ce suffisant ???).

[EDIT] J’avais mal compris ce passage. Mais en fait, ils avaient les outils pour détecter l’intrusion (qui a duré 3 mois avant le lancement du cryptolocker) mais personne n’a regardé les alertes ! Clairement là c’est super grave.

Si encore il n’y avait que les serveurs industriels, passons

Quand vraiment il n’y a pas de solutions (ou un passif trop important), il faut isoler les systèmes problématiques. Réseaux séparés (physiques ou logiques), pas d’accès à Internet, surveillance accrue… Je connais des industriels qui y arrivent très bien, ce n’est pas impossible.

Mais pour finir, sur les 800 serveurs touchés chez Manutan, il n’y avait pas QUE des serveurs industriels.

Tout y est passé : AD, messagerie, bureautiques, espaces de stockages partagés. Des systèmes “standards” qui eux auraient dû être à jour, car il n’y a pas de difficulté technique particulière sur ces genres de briques techniques…

Derniers mots

On peut quand même reconnaitre à Manutan d’avoir eu les bons réflexes post incident : faire les morts auprès des cybercriminels, chercher de l’aide, ne pas payer la rançon, restaurer les systèmes de manière méthodique.

Ils ont visiblement été bien accompagnés par leur partenaire.

Enfin, on peut surtout saluer la transparence de ce REX.

Bravo pour tout ça.

Mais clairement, il nous reste encore beaucoup de chemin à parcourir et on va avoir besoin d’encore beaucoup de pédagogie pour sécuriser nos SI…

Liens

Le Mag IT - Récit : comment Manutan s’est sorti de la cyberattaque du 21 février
Mon thread Twitter (lien mort, j’ai quitté Twitter)
La même chose sur LinkedIn

Sécuriser l’émission de vos certificats avec un CAA (Azure)

Tue, 12 Jun 2018 11:45:10 +0000

CAA ? Azure ?!?

Et oui, je travaille sur Azure ! Je crois bien que c’est le premier article que je vais faire à ce sujet donc je commence par quelque chose de léger, créer un CAA.

Au-delà de toute considération purement dogmatique, le cloud de Microsoft fait quand même partie des plus grands, avec une richesse fonctionnelle et une API aussi riche que ce qu’on trouve chez les autres. J’aurai l’occasion de faire d’autres articles sur Azure car j’utilise énormément les modules Ansible développés par les équipes de Microsoft (qui s’appuient sur l’API d’Azure).

Et donc, le CAA ?

Mais cet article parle de CAA. Pour ceux qui ne connaitraient pas, un CAA est un « nouveau » (2017) type d’enregistrement DNS :

La CAA est une mesure de sécurité qui permet aux propriétaires d’un nom de domaine de préciser dans leur DNS (Domain Name System) les autorités de certification (AC) qui sont autorisées à émettre des certificats pour leur nom de domaine.

Global Sign (lien mort, pas disponible sur Internet Archive)

Concrètement, si je possède un domaine avec un grand nombre de sites web signés, que je n’utilise qu’une ou deux (ou un nombre fini) autorités de certifications, je peux maintenant spécifier lesquelles (parmi la centaine des AC existantes) sont autorisées à émettre un certificat pour mon domaine. Cela permettra d’éviter que des personnes mal intentionnées génèrent un certificat pour une URL dans un de vos sous domaines.

Comment ça fonctionne ?

Il existe donc un nouveau type d’entrée dans votre DNS qui devrait ressembler à ça :

Name	Type	Value
zwindler.fr.	CAA	0 issue « letsencrypt.org »
zwindler.fr.	CAA	0 iodef « mailto:zwindler@zwindler.fr »

Pour l’entrée zwindler.fr., j’ai donc un CAA qui dispose de 2 variables (issue et iodef) :

La première indiquant que seul letsencrypt.org peut générer des certificats pour mon domaine. On peut en avoir plusieurs si on a plusieurs autorités de certification.
La seconde indiquant qu’il faut m’envoyer un email si jamais quelqu’un qui n’a pas les droits essaye de générer un certificat.

A noter : iodef n’est pas respecté par toutes les autorités de certifications, donc vous n’aurez potentiellement pas d’emails en cas de tentative de génération de certificat chez une AC non autorisé.

Ok, comment je créé un CAA ?

Normalement, c’est trivial. Il s’agit d’un enregistrement DNS comme un autre. Par exemple chez OVH, vous pouvez directement le créer depuis l’interface :

Et sur Azure ?

Il faut bien que ce soit rigolo. Dans le portail d’Azure, il n’est pas possible de créer (ni même de voir !!!) les champs de types CAA, pourtant disponibles depuis mi 2017.

La seule solution est d’utiliser l’API REST, la CLI azure, ou Powershell :

Page de documentation azure cli (record-set)
Gérer les enregistrements DNS avec Powershell

Avec Azure cli

Du coup je suis parti de la doc pour faire ça :

En partant du principe que vous avez un compte sur Azure, que vous gérez les DNS de la zone zwindler.fr depuis Azure DNS (dans un resource group appelé dns-rg), voilà ce qu’il faut faire pour créer une protection pour le sous domaine *.test.zwindler.fr.

az network dns record-set caa add-record --resource-group dns-rg --zone-name zwindler.fr --record-set-name test --flags 0 --tag "issue" --value "letsencrypt.org"
az network dns record-set caa add-record --resource-group dns-rg --zone-name zwindler.fr --record-set-name test --flags 0 --tag "iodef" --value "zwindl3r@zwindler.fr"
az network dns record-set caa list --resource-group dns-rg --zone-name zwindler.fr
{
"caaRecords": [
{
"flags": 0,
"tag": "iodef",
"value": "zwindl3r@zwindler.fr"
},
{
"flags": 0,
"tag": "issue",
"value": "letsencrypt.org"
}
],
"etag": "aaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaa",
"fqdn": "test.zwindler.fr.",
"id": "/subscriptions/aaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaa/resourceGroups/dns-rg/providers/Microsoft.Network/dnszones/zwindler.fr/CAA/test",
"metadata": null,
"name": "test",
"resourceGroup": "dns-rg",
"ttl": 3600,
"type": "Microsoft.Network/dnszones/CAA"
}

Et si je veux le domaine entier ?

Et là c’est la blague !

Si vous créez un record-set « test« , il va vous créer un CAA pour test.zwindler.fr (voire le champ fqdn dans la réponse du list). Vous n’avez pas la main sur le fqdn directement (que ce soit en création ou en mise à jour), il est créé à partir du nom.

Or, vous avez très probablement envie de protéger zwindler.fr, pas seulement test.zwindler.fr, car ça n’aurait pas vraiment de sens (on rappelle que le but de la manœuvre et d’empêcher des gens de générer des certificats pour des sous domaine de votre domaine) sinon.

Créer une liste exhaustive de tous les sous domaines possibles me semble complexe ;-).

L’astuce, que vous ne trouverez pas dans la documentation (en tout cas dans les pages que j’ai lues), est de créer un recordset avec comme nom « @ » (j’avais testé, vide, « * », « . », mais pas « @ »…).

Et là, un recordset sera créé pour l’ensemble de votre zone DNS (zwindler.fr dans mon exemple).

Magie-magie…

Liens utiles

Administrer des serveurs Windows avec Ansible

Tue, 15 Nov 2016 13:00:11 +0000

Ansible sur Windows

Depuis que j’ai découvert Ansible, ma vie d’Ops a changée.

Tout doit pouvoir être géré par Ansible. Tous les playbooks doivent être idempotent (je reviendrais la dessus très probablement). Et du coup, ça vaut aussi pour les serveurs Windows qu’il nous reste !

Il n’existe pas encore de version compatible Windows pour l’exécution locale des playbooks. Cependant, il existe tout de même des modules pour administrer via PowerShell remoting des serveur Windows.

La liste des modules pour Windows est disponible sur cette page. La plupart ne sont pas intégrés au cœur d’Ansible mais font partis des extra-modules.

Prérequis côté serveur

Configuration de base (connexion distante avec des comptes locaux)

Il est nécessaire d’installer un module Python permettant la connexion aux Windows via PowerShell sur le serveur Linux qui servira a exécuter les playbooks.

pip install "pywinrm>=0.1.1"

Configuration Kerberos (connexion distante avec des comptes de domaine AD)

La configuration de base ne permet pas d’utiliser des comptes de domaine. Dans un environnement d’entreprise, la plupart des serveurs Windows sont intégrés à un domaine Active Directory.

Il est donc intéressant d’installer les clients kerberos qui permettront au serveur Linux avec Ansible de s’authentifier sur un domaine AD.

yum -y install python-devel krb5-devel krb5-libs krb5-workstation
pip install kerberos

On peut ensuite configurer le fichier /etc/krb5.conf en fonction du contexte. Voici les variables à renseigner :

[...]
[realms]
ZWINDLER.INFO = {
kdc = dc01.zwindler.info
kdc = dc02.zwindler.info
kdc = dc03.zwindler.info
}
[domain_realm]
.zwindler.info = ZWINDLER.INFO

On peut tester que la configuration fonctionne avec la commande kinit

kinit zwindler@ZWINDLER.INFO
Password for zwindler@ZWINDLER.INFO:

ATTENTION : Il faut obligatoirement donner le nom du domaine en majuscules, et indiquer le nom complet du domaine et pas le nom Netbios. Ca vaut pour le fichier de configuration krb5.conf ET lors de l’appel de la commande kinit.

La commande ne doit pas retourner d’erreur et on peut vérifier que tout fonctionne avec la commande klist

klist
Default principal: zwindler@ZWINDLER.INFO
Valid starting Expires Service principal
23/08/2016 15:15:33 24/08/2016 01:15:33 krbtgt/ZWINDLER.INFO@ZWINDLER.INFO
renew until 30/08/2016 15:15:30

Ajout d’un serveur Windows

Méthode 1 : Compte local, variables de connexion dans un fichier chiffré

A la différence d’Ansible sous Linux où l’authentification peut se faire sans mot de passe à l’aide de certificats, sous Windows, il sera nécessaire de stocker à un moment donné le mot de passe d’un compte qui pourra se connecter sur les serveurs Windows.

On ajoute d’abord les serveurs windows dans le fichiers hosts dans un groupe séparé

[zwindler_windows_prod]
antivirus
wsus
[zwindler_prod:children]
zwindler_ansible_prod
zwindler_linux_prod
zwindler_windows_prod
[zwindler_windows:children]
zwindler_windows_prod

On sécurise l’accès au fichier des variables qui contiendra les comptes d’accès aux machines Windows avec l’utilitaire ansible-vault. Le fichier ne pourra alors être lu/édité qu’avec le mot de passe.

ansible-vault create group_vars/zwindler_windows.yml
New Vault password:
cat group_vars/zwindler_windows.yml
$ANSIBLE_VAULT;1.1;AES256
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
1111
ansible-vault edit group_vars/zwindler_windows.yml
Vault password:
---
ansible_user: local_admin
ansible_password: xxxxxxxx
ansible_port: 5986
ansible_connection: winrm
#Decommenter si vous utiliser Python 2.7.9+ et des certificats WinRM autosignes (defaut)
#ansible_winrm_server_cert_validation: ignore

Comme les serveurs qui ont été ajoutés dans le groupe zwindler_windows_prod héritent des variables définies pour zwindler_windows dans group_vars/zwindler_windows.yml, Ansible les utilisera pour s’y connecter.

Méthode 2 : utiliser kinit pour la connexion

Plutôt que d’utiliser un compte local et stocker le mot de passe dans des variables (de préférence chiffré donc) mais quand même devoir taper le mode de passe du vault à chaque fois, il est possible d’utiliser le binaire kinit pour gérer l’authentification AD via un ticket Kerberos.

# kinit domain_admin@ZWINDLER.INFO
Password for domain_admin@ZWINDLER.INFO:
# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_B82OOxI
Default principal: domain_admin@ZWINDLER.INFO
Valid starting Expires Service principal
23/08/2016 16:37:37 24/08/2016 02:37:37 krbtgt/ZWINDLER.INFO@ZWINDLER.INFO
renew until 30/08/2016 16:36:57

Cependant ce n’est pas suffisant. Pour que l’authentification Kerberos soit tentée par Ansible, il est tout même nécessaire que les variables ansible_user, ansible_port et ansible_connection soient renseignées (bizarrement…).

On doit dont créer un fichier de variable similaire à celui de la méthode précédente, mais sans pour autant nécessiter de le chiffrer puisqu’on ne stockera pas le mot de passe.

vi group_vars/zwindler_windows.yml
---
ansible_user: auth@by.kerberos
ansible_port: 5986
ansible_connection: winrm
#Decommenter si vous utiliser Python 2.7.9+ et des certificats WinRM autosignes (defaut)
#ansible_winrm_server_cert_validation: ignore

A noter, la valeur ansible_user n’est pas du tout utilisée. C’est écrit sur le site d’Ansible :

Ansible will first attempt Kerberos authentication. This method uses the principal you are authenticated to Kerberos with on the control machine and not ‘ansible_user’.

Prérequis côté client

Pour pouvoir se connecter il est également nécessaire de réaliser des modifications sur les serveurs que l’on souhaite administrer avec Ansible.

La commande win_ping permet de vérifier la connectivité avec les serveurs Windows. Ici la commande échoue car l’exécution de commande PowerShell à distance nécessite l’autorisation explicite sur l’ensemble des serveurs concernés.

ansible wsus03 -m win_ping --ask-vault-pass
Vault password:
wsus03 | UNREACHABLE! => {
"changed": false,
"msg": "kerberos: 500 WinRMTransport. [Errno 111] Connection refused, ssl: 500 WinRMTransport. [Errno 111] Connection refused",
"unreachable": true
}

De plus, les serveurs dont le pare-feu est activés doivent laisser passer les connexions vers le port 5986 défini dans le fichier group_vars/zwindler_windows.yml

Powershell 3 (pour Windows 2008)

Sur les serveurs antérieurs à Windows 2012, seul Powershell 2 est installé et c’est Powershell 3 qu’il faut !

Ansible fournit un script pour aider à l’installation si la machine a accès à Internet

powershell https://raw.githubusercontent.com/cchurch/ansible/devel/examples/scripts/upgrade_to_ps3.ps1

(Optionnel) ajouter une exception au pare-feu pour le port 5986

Cette exception n’est plus nécessaire car le script Ansible qui suit l’ajoute de lui même. Cependant si vous souhaitez gérer cela vous même, voici quoi faire.

Se connecter sur le serveur, puis lancer un prompt Powershell avec les droits administrateurs

netsh advfirewall firewall add rule name="WinRM pour Ansible" dir=in localport=5986 protocol=TCP action=allow

Autoriser Ansible à réaliser des actions à distance (WinRM)

Récupérer le script disponible sur la branch « devel » et l’exécuter sur le serveur en question via un prompt Powershell administrateur.

github.com/ansible/ansible-documentation/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1

Autoriser l’exécution de script Powershell si nécessaire.

Set-ExecutionPolicy Unrestricted

Tests et troubleshooting

ansible wsus03 -m win_ping --ask-vault-pass
Vault password:
wsus03 | SUCCESS => {
"changed": false,
"ping": "pong"
}

Dans le cas où on souhaite réinitialiser les tickets kerberos pour valider le bon fonctionnement, on peut utiliser les commandes klist et kdestroy

klist
Ticket cache: KEYRING:persistent:0:krb_ccache_B82OOxI
Default principal: domain_admin@ZWINDLER.INFO
Valid starting Expires Service principal
23/08/2016 16:38:45 24/08/2016 02:37:37 HTTP/wsus03.zwindler.info@ZWINDLER.INFO
renew until 30/08/2016 16:36:57
23/08/2016 16:37:37 24/08/2016 02:37:37 krbtgt/ZWINDLER.INFO@ZWINDLER.INFO
renew until 30/08/2016 16:36:57
kdestroy -A
klist

Have fun !

Sources

[En bref] Désactiver IPv6 sur les Windows Server

Sat, 14 Nov 2015 11:30:12 +0000

IPv6, c’est un standard qui devrait être correctement supporté aujourd’hui, et par tout le monde. On devrait même aller jusqu’à dire qu’on devrait arrêter d’utiliser IPv4 aujourd’hui.

Mais franchement, il faut le reconnaitre, attribuer des adresses sur 128 bits (donc 32 caractères héxa), c’est une vraie tannée pour les administrateurs systèmes (même si il y a des astuces pour réduire la taille des adresses) !

Alors c’est vrai, c’est mal (car non pérenne), mais certains sont donc tentés de ne pas utiliser IPv6, voire même désactiver complément la fonctionnalité. [Edit] Ça peut surtout bloquer certains composants et/ou provoquer des effets de bords difficilement décelables… Autant vous le dire tout de suite, Microsoft n’approuve pas.[/Edit]

Le cas Windows Server

Même si vous n’utiliser pas IPv6, les serveurs ont souvent sur leur carte le double adressage. Ce n’est pas gênant tant que vous ne l’utilisez pas … sauf pour les Windows Server en domaine Active Directory.

Pour simplifier l’administration des DNS, les serveurs Windows dans un domaine sont automatiquement enregistrés dans le DNS fournit par les serveurs DC. Même les adresses IPv6. et des fois, ça provoque des effets de bord quand l’IPv6 répond en premier.

Comme le désactiver ?

On peut donc honteusement vouloir désactiver IPv6, pour se simplifier la vie et éviter de polluer son DNS Active Directory. Mais … décocher la case dans l’interface d’administration des connexions réseau … ne sert à rien !

La seule façon de le faire, c’est de modifier le registre avec regedit (en tant qu’administrateur bien entendu).

Naviguer dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters

Avec un [clic droit], ajouter une nouvelle clé DisabledComponents en type DWORD (32-bit) et lui donner la valeur ~~0xFFFFFFFF (voir commentaires)~~ 0xFF.

[MAJ du 25/01]Ou alors vous pouvez créer un fichier « .reg » à exécuter sur la machine :

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters]
"DisabledComponents"=dword:000000ff

[/MAJ]

Au reboot, IPv6 sera totalement désactivé sur le serveur.

Aller plus loin

Si vous ne voulez pas le faire à la mimine, que vous avez un accès simple vers Internet et que vous n’avez pas peur de faire confiance aveuglément à Microsoft, le KB de Microsoft sur le sujet donne des boutons de paramétrages « one click » pour désactiver ou réactiver simplement IPv4 et/ou IPv6.