Répartition de charge et sécurité : quatre services, cinq filtres

Aiguiller un navire n'est pas le fouiller

Sur le quai qu'on loue, deux personnes attendent chaque navire. La première lui indique à quel poste se ranger : elle regarde le tirant d'eau, la longueur, les postes libres, et rien d'autre. La seconde ouvre les conteneurs et décide de ce qui a le droit d'entrer sur le terminal.

Ces deux personnes ne font pas le même métier, ne dépendent pas du même bureau, et ne s'arrêtent pas pour les mêmes raisons. Sur le port, personne ne les confond.

Sur Azure, tout le monde les confond. Le vocabulaire n'aide pas : quatre services répartissent le trafic, quatre dispositifs le filtrent, et les huit sont posés au même endroit du schéma.

Les quatre aiguilleurs sont Load Balancer, Application Gateway, Front Door et Traffic Manager. Les quatre dispositifs de filtrage sont les groupes de sécurité réseau, Azure Firewall, le pare-feu applicatif et la protection DDoS.

Cinq filtres suffisent à départager les premiers, et ce sont cinq questions : à quelle couche le service travaille, sur quelle étendue géographique, avec quels protocoles, avec ou sans terminaison TLS, et ce qu'il sait inspecter. Posées dans cet ordre, elles ne laissent jamais deux réponses possibles.

Le nom du service ne dit rien de ce qu'il fait. Les cinq mêmes questions, posées à chaque fois, désignent le bon composant sans discussion.

Les quatre aiguilleurs

Azure Load Balancer

C'est le pilote qui amène le navire au premier poste libre du bassin. Il connaît les postes, il sait lesquels sont occupés, et il n'ouvre aucun conteneur.

Le répartiteur de charge Azure travaille à la couche 4, sur TCP et UDP. Il choisit une instance par hachage du quintuplet adresse source, port source, adresse de destination, port de destination et protocole. On peut réduire ce hachage à deux ou trois éléments pour obtenir une affinité par client, avec le défaut habituel des affinités : une répartition moins régulière entre les instances.

Il est régional, et existe en version publique ou interne. Son frontal se déclare redondant inter-zones ou attaché à une zone précise, ce qui devient un choix de conception dès qu'on répartit un parc sur plusieurs zones. Le niveau standard est celui sur lequel on conçoit aujourd'hui.

Deux capacités méritent d'être connues. Les règles de sortie donnent la main sur la traduction d'adresse sortante, ce qui évite l'épuisement de ports quand plusieurs centaines de machines partagent une adresse publique. Les ports en haute disponibilité, réservés au répartiteur interne, permettent de placer une appliance réseau derrière lui sans énumérer chaque port.

Ce qu'il ne fait pas se résume vite : pas de terminaison TLS, pas de routage par chemin, pas de réécriture d'en-tête, pas de pare-feu applicatif. La notion de requête n'existe pas pour lui.

L'erreur classique consiste à le mettre devant une application web parce qu'il est simple. On se retrouve à installer et renouveler le certificat sur chaque machine, puis à découvrir qu'on ne peut pas envoyer /api vers un pool et le reste vers un autre.

Un répartiteur de couche 4 déplace des flux. Tout ce qui se décide en lisant l'URL est hors de sa portée, par construction et pas par option manquante.

Application Gateway

C'est le chef de quai. Il lit le manifeste avant d'orienter la cargaison, et il refuse ce qui n'est pas conforme.

La passerelle applicative travaille à la couche 7, sur HTTP, HTTPS, HTTP/2 et WebSocket. Elle est régionale. Elle termine le TLS, et peut rechiffrer vers le pool quand le trafic interne doit rester protégé de bout en bout.

Elle route par nom d'hôte et par chemin, héberge plusieurs sites derrière une même adresse, réécrit les URL et les en-têtes, applique des redirections, gère l'affinité par cookie et draine les connexions avant de retirer une instance. Sa version à mise à l'échelle automatique porte aussi la redondance de zone.

Le pare-feu applicatif s'ajoute dans le même produit, sur le même objet, avec les mêmes règles de gestion. C'est souvent la vraie raison de la choisir.

Contrainte à anticiper dès le plan d'adressage : elle réclame un sous-réseau qui lui est propre. Un plan trop serré se paie ici.

L'erreur classique consiste à la choisir comme point d'entrée mondial. Elle est régionale. Deux régions veulent dire deux passerelles, donc quelque chose devant pour choisir entre elles.

La passerelle applicative est le bon défaut pour une application web dans une région. Elle cesse de l'être dès que le mot « mondial » entre dans la conversation.

Azure Front Door

C'est le bureau d'affrètement mondial. Le navire ne se présente pas au port principal, il se présente au terminal capable de le recevoir le plus vite, et le bureau tranche.

Front Door est mondial et travaille à la couche 7, en HTTP et HTTPS uniquement. Le client entre par le point de présence le plus proche de lui grâce à une adresse annoncée depuis de nombreux emplacements. La connexion TLS se termine là, en bordure, ce qui raccourcit l'établissement de connexion, puis le trajet vers l'origine emprunte le réseau de l'opérateur plutôt que l'Internet public.

Il organise ses cibles en groupes d'origines, avec une priorité pour désigner le secours et un poids pour partager la charge. Il sonde ces origines, met en cache ce qui peut l'être, applique un moteur de règles, et porte un pare-feu applicatif à l'échelle mondiale. Son niveau supérieur ajoute la liaison privée vers des origines qui n'ont aucune exposition publique.

L'erreur classique consiste à le prendre pour un répartiteur universel. Il ne connaît que le web. Du trafic mondial non HTTP ne le concerne pas.

Front Door déplace le point d'entrée à quelques millisecondes du client. Ce qu'il traite en bordure, l'origine ne le voit jamais, ce qui est autant un gain de latence qu'une réduction de surface.

Traffic Manager

C'est la carte remise au capitaine avant l'appareillage. Elle indique le port de destination, puis elle ne sert plus à rien : le navire ne repasse pas par le bureau qui l'a imprimée.

Traffic Manager travaille au niveau du DNS. Il répond à une demande de résolution de nom, et se retire. Aucun paquet applicatif ne le traverse, jamais.

Il propose plusieurs méthodes de routage : priorité pour un couple actif et passif, pondération pour partager le trafic, performance pour envoyer vers le point de terminaison le plus rapide, géographique pour respecter une contrainte de territoire, valeurs multiples et sous-réseau pour des cas plus précis. Les profils s'imbriquent, ce qui permet de combiner deux méthodes.

Son intérêt réel tient en une phrase : il accepte n'importe quel protocole et n'importe quel point de terminaison, y compris hors d'Azure. C'est le seul des quatre à savoir basculer un service qui n'est pas du web.

Sa limite tient dans la même phrase retournée. Il ne voit aucune requête, ne termine aucun TLS, n'inspecte rien, et un client qui a mis sa réponse en cache continue d'aller au même endroit tant que ce cache n'a pas expiré.

L'erreur classique consiste à en attendre une bascule instantanée. On y revient plus bas, avec le calcul.

Les combinaisons réelles

Un port sérieux n'a pas un seul bureau. Le bureau d'affrètement décide du terminal, le chef de quai décide du poste, et les deux travaillent sans se marcher dessus.

La combinaison la plus fréquente empile un répartiteur mondial devant un répartiteur régional : Front Door en bordure, une passerelle applicative par région derrière. Le filtrage grossier tombe au plus près de l'attaquant, les règles proches du métier restent près de l'application.

Cet empilement crée un trou si on l'oublie. La passerelle régionale garde une adresse publique, et rien n'empêche quelqu'un de l'appeler directement, en contournant tout ce qui a été posé en bordure.

La fermeture se fait en deux gestes. On restreint la source au moyen de l'étiquette de service AzureFrontDoor.Backend, ce qui est nécessaire mais insuffisant : cette étiquette couvre l'ensemble du service, y compris les profils d'autres clients. On ajoute donc une règle qui vérifie l'en-tête X-Azure-FDID et refuse tout ce qui ne porte pas l'identifiant de son propre profil.

Deux autres montages reviennent souvent. Traffic Manager devant plusieurs passerelles régionales, quand le service n'est pas du web ou qu'on veut garder la bascule au niveau du nom. Et une passerelle applicative devant un groupe de machines identiques, avec un répartiteur de couche 4 en interne pour le trafic entre composants.

Ce qu'on évite : empiler par réflexe. Chaque étage ajoute une terminaison TLS, un jeu de sondes à régler, une ligne de facture et un endroit de plus où se tromper.

Deux répartiteurs superposés ne valent que si chacun répond à une question que l'autre ne sait pas traiter. Sinon, le second n'ajoute que de la latence et un point de panne.

Les sondes d'intégrité

La vigie qui autorise un poste d'amarrage ne se contente pas de vérifier que le quai existe. Elle regarde le tirant d'eau réel, la grue en panne, la voie ferrée bloquée. Une vigie qui coche « quai présent » envoie un navire de trois cents mètres dans un piège.

Toute la valeur d'un répartiteur tient dans son avis sur l'état des cibles. Cet avis vaut ce que vaut la sonde, et les quatre services ne sondent pas de la même façon.

La sonde de couche 4 se déclare avec trois paramètres qui décident du temps de détection.

probes: [
  {
    name: 'sonde-app'
    properties: {
      protocol: 'Http'
      port: 8080
      requestPath: '/healthz'
      intervalInSeconds: 5
      numberOfProbes: 2
    }
  }
]

Le cas de Traffic Manager mérite un calcul posé, parce que c'est celui qu'on sous-estime. Les valeurs par défaut de la surveillance de points de terminaison sont un intervalle de 30 secondes, un délai d'attente de 10 secondes et trois échecs tolérés. Une sonde sans réponse échoue au bout de ses 10 secondes, puis trois tentatives espacées de 30 secondes suivent avant que le point de terminaison soit marqué en panne, soit de l'ordre de 100 secondes avant que la réponse DNS change. La durée de vie de l'enregistrement s'ajoute derrière : avec 60 secondes, un nouveau client peut mettre près de trois minutes à être dirigé ailleurs.

En passant à l'intervalle rapide de 10 secondes, la détection tombe autour de 40 secondes, et un enregistrement à durée de vie courte réduit encore l'attente. Reste le facteur qu'on ne contrôle pas : certains résolveurs et certains clients gardent une réponse plus longtemps que la durée annoncée.

Vient ensuite la question qui décide de tout : que teste la sonde exactement ?

Une adresse qui renvoie 200 depuis le serveur web sans rien vérifier prouve qu'un processus écoute. Rien de plus. L'application peut avoir perdu sa connexion à la base, saturé son pool de threads ou vidé son cache de configuration, la sonde continue de la déclarer saine et le répartiteur continue de l'alimenter.

L'excès inverse est pire. Une sonde qui interroge la base de données partagée fait échouer toutes les instances au même instant le jour où cette base hoquette. Un incident local devient une panne totale, provoquée par le mécanisme censé la prévenir.

La séparation utile distingue deux questions : le processus est-il vivant, et est-il en état de prendre du trafic maintenant ? La première ne touche aucune dépendance. La seconde peut en tester quelques-unes, à condition d'assumer qu'un échec commun retire tout le monde.

Trois détails achèvent le réglage. La sonde doit emprunter le même port et le même protocole que le trafic réel, sans quoi elle valide un chemin qui n'est pas celui des clients. Elle doit atteindre un chemin qui n'exige pas d'authentification, faute de quoi le 401 renvoyé vide le pool. Et le comportement du service quand toutes les cibles sont déclarées en panne diffère d'un répartiteur à l'autre : cela se vérifie dans sa documentation, avant l'incident.

Une sonde mal réglée ne se contente pas de rater une panne. Elle en fabrique une, en retirant d'un coup des instances parfaitement capables de servir.

Filtrer

La douane ouvre les conteneurs. Les postes de contrôle vérifient les badges à l'entrée du terminal. La barrière anti-intrusion arrête un camion bélier. Aucun des trois ne remplace les deux autres, et aucun ne voit ce que voient les autres.

Les groupes de sécurité réseau

Un groupe de sécurité réseau est une liste de règles évaluées sur le quintuplet, avec état. Chaque règle porte une priorité de 100 à 4096, l'évaluation se fait par priorité croissante, et la première qui correspond tranche.

Des règles par défaut existent et ne se suppriment pas : le trafic interne au réseau virtuel est autorisé dans les deux sens, les sondes du répartiteur entrent, la sortie vers Internet est ouverte, et tout le reste en entrée est refusé. On les couvre en écrivant une règle de priorité plus basse en nombre.

Les étiquettes de service évitent de maintenir des listes d'adresses qui changent sans prévenir. Les groupes de sécurité d'application vont plus loin : on nomme un ensemble de cartes réseau, puis on écrit une règle qui parle de ce nom au lieu de plages d'adresses.

{
  "name": "allow-frontdoor-inbound",
  "properties": {
    "priority": 200,
    "direction": "Inbound",
    "access": "Allow",
    "protocol": "Tcp",
    "sourceAddressPrefix": "AzureFrontDoor.Backend",
    "sourcePortRange": "*",
    "destinationAddressPrefix": "*",
    "destinationPortRange": "443"
  }
}

Un groupe peut s'attacher au sous-réseau, à la carte réseau, ou aux deux, et les deux sont alors évalués. Deux jeux de règles en désaccord produisent exactement le résultat qu'on redoute pendant un incident.

Ce qu'il ne voit pas : le contenu. Un flux HTTPS autorisé vers le port 443 passe intégralement, quel que soit ce qu'il transporte.

Azure Firewall

Azure Firewall est un pare-feu managé, à état, déployé dans un sous-réseau nommé AzureFirewallSubnet d'au moins /26, en général au centre d'une topologie en étoile.

Ses règles se traitent dans un ordre fixe : traduction d'adresse entrante d'abord, règles de réseau ensuite, règles d'application en dernier. Les règles sont terminales, et c'est là que se logent les surprises : dès qu'une règle de réseau correspond, aucune règle d'application n'est évaluée.

Sa différence utile face à un groupe de sécurité réseau tient dans les règles d'application : elles filtrent par nom de domaine, ce qui permet d'autoriser un dépôt de paquets précis sans ouvrir tout Internet. Le filtrage par renseignement sur les menaces bloque ou signale les destinations connues comme malveillantes.

Ses niveaux se distinguent nettement. Le niveau supérieur ajoute l'inspection TLS, la détection et la prévention d'intrusion, et le filtrage sur l'URL complète : le niveau inférieur ne raisonne que sur le nom de domaine, y compris pour les catégories web. Sans inspection TLS, un pare-feu ne voit d'un flux chiffré que sa destination.

Le piège d'exploitation est ailleurs. Le pare-feu ne s'impose pas tout seul : il faut une route définie par l'utilisateur qui envoie le trafic vers son adresse privée. Sans cette route, il est déployé, facturé, et complètement contourné.

Les stratégies s'organisent en hiérarchie, une stratégie parente portant les règles communes et une stratégie enfant les règles propres à une équipe. C'est le prolongement direct de la hiérarchie de gouvernance posée au premier palier.

Le pare-feu applicatif

Le pare-feu applicatif s'attache soit à la passerelle applicative, donc régional, soit à Front Door, donc mondial. Le service est le même dans l'esprit, la portée change tout.

Il s'appuie sur des jeux de règles gérés dérivés du référentiel OWASP, complétés par un jeu contre les robots. Le fonctionnement par notation d'anomalie mérite d'être compris : chaque règle déclenchée ajoute des points, et le blocage n'intervient qu'au-delà d'un seuil. Une seule correspondance ne bloque pas forcément.

On y ajoute des règles personnalisées : restriction par pays, listes d'adresses, limitation de débit sur un chemin sensible.

La méthode de mise en service ne varie pas. Mode détection d'abord, pendant assez longtemps pour voir passer les traitements de fin de mois et les imports en lot. Analyse des correspondances, construction des exclusions ciblées, puis bascule en blocage. Un pare-feu applicatif activé en blocage le premier jour coupe une fonction métier dans la semaine, et se retrouve désactivé pour de bon.

Ce qu'il ne voit pas : une suite de requêtes parfaitement valides qui abusent d'une logique métier. Il ne remplace aucun contrôle d'autorisation dans le code.

La protection DDoS

La plateforme absorbe déjà en permanence les attaques volumétriques dirigées contre l'infrastructure d'Azure, pour tous les clients, sans souscription ni configuration. Ce socle protège la plateforme, pas le profil de trafic d'une application donnée.

Le niveau de protection réseau s'active sur un réseau virtuel. Il apprend le trafic habituel des adresses publiques qui s'y trouvent et ajuste ses seuils dessus, produit des métriques et des rapports d'atténuation exploitables après coup, ouvre l'accès à une équipe de réponse rapide, et couvre les coûts de montée en charge subis pendant une attaque avérée. Un niveau par adresse IP publique existe pour une entrée plus modeste.

Sa limite est nette : il traite le volumétrique aux couches 3 et 4. Une attaque applicative qui envoie peu de requêtes, bien formées, mais très coûteuses à traiter, relève du pare-feu applicatif et de la limitation de débit.

Chaque dispositif a un angle mort documenté. La conception consiste à faire en sorte que l'angle mort de l'un soit le champ de vision de l'autre, pas à empiler quatre boîtes en espérant.

Accéder à l'administration sans ouvrir de port

Sur le port, personne n'entre sur le terminal par la barrière à camions. Il existe un sas, avec un badge, et une habilitation qui expire.

Le réflexe qu'on garde du monde physique consiste à laisser une adresse publique et un port d'administration ouvert sur chaque machine, en se disant qu'on restreindra la source plus tard. Ce plus tard n'arrive jamais, et les journaux d'un port d'administration exposé se remplissent en quelques heures.

Azure Bastion supprime le problème plutôt que de le déplacer. Il se déploie dans un sous-réseau dédié nommé AzureBastionSubnet, et ouvre les sessions distantes à travers une connexion TLS, depuis le portail ou depuis un client natif. Les machines n'ont plus d'adresse publique, et aucune règle n'autorise le trafic d'administration depuis Internet.

L'accès juste à temps, proposé par Defender for Cloud, complète le dispositif quand une ouverture reste nécessaire. La règle est créée à la demande, pour un port, une adresse source et une durée précis, après approbation, et refermée automatiquement. La demande est tracée, ce qui change la conversation lors d'un audit.

Un port d'administration ouvert en permanence est une décision, pas un oubli. Le sas managé et l'ouverture temporaire coûtent moins cher qu'un seul incident dû à ce raccourci.

Scénario B : Dyn, le 21 octobre 2016

Dyn exploitait un service de DNS managé utilisé par un grand nombre de sites grand public. Le 21 octobre 2016, l'entreprise subit une attaque par déni de service distribué et publie quelques jours plus tard une analyse de l'incident, signée par son directeur de la stratégie Kyle York.

Ce que ce document décrit tient en trois vagues. La première commence vers 11h10 UTC et vise l'infrastructure de DNS managé, d'abord côté est des États-Unis ; elle est maîtrisée vers 13h20. La deuxième démarre vers 15h50, plus largement répartie géographiquement, et l'atténuation aboutit vers 17h00. Une troisième tentative est neutralisée sans effet visible pour les clients.

L'origine du trafic est attribuée pour une part importante à des machines infectées par le logiciel malveillant Mirai, qui compromettait des objets connectés grand public, caméras et enregistreurs vidéo en tête, en essayant des identifiants laissés par défaut.

Dyn indique avoir observé des dizaines de millions d'adresses IP distinctes pendant l'attaque, tout en précisant que ce décompte est gonflé par deux effets : les nouvelles tentatives légitimes des résolveurs récursifs, qui réinterrogent en boucle quand la réponse tarde, et l'usurpation d'adresse source. Sur le volume total, l'entreprise écrit ne pas être en mesure de confirmer les chiffres avancés publiquement à ce moment-là.

L'effet observé mérite d'être posé précisément. Les serveurs applicatifs des sociétés touchées n'étaient pas tombés. Ils fonctionnaient, ils avaient de la capacité disponible, et personne ne pouvait les atteindre parce que leur nom ne se résolvait plus.

Trois lectures pour ce billet.

La surface exposée en bordure n'est pas seulement la sienne. Des centaines de milliers d'objets installés chez des particuliers, avec des identifiants par défaut, forment une capacité d'attaque que personne n'a provisionnée. C'est exactement ce contre quoi une protection volumétrique se dimensionne.

Un aiguilleur qui ne voit passer aucun paquet reste une dépendance de premier ordre. Traffic Manager fonctionne sur le même principe que le service attaqué ce jour-là : il ne transporte rien, et pourtant plus rien n'arrive quand il ne répond plus. Le composant le plus discret d'une architecture est celui qu'on oublie dans l'inventaire des dépendances.

La concentration derrière un point d'entrée unique se paie au moment précis où l'on ne peut rien faire. Plusieurs des services touchés ne disposaient que d'un seul fournisseur de DNS faisant autorité pour leurs domaines.

Un service qui ne voit passer aucun paquet peut mettre tout le reste à l'arrêt. La bonne question n'est pas ce qu'un composant transporte, c'est ce qui s'arrête quand il cesse de répondre.

L'image portuaire est directe. On peut avoir la meilleure douane du bassin, des portiques neufs et des postes d'amarrage libres. Si le bureau qui délivre les instructions de mouillage ne répond plus, aucun navire n'entre, et les quais restent vides toute la journée.

Points clés

• Cinq questions départagent les quatre répartiteurs : la couche, la portée géographique, les protocoles acceptés, la terminaison TLS et ce qu'ils savent inspecter. Load Balancer est régional et de couche 4, Application Gateway régional et de couche 7, Front Door mondial et web, Traffic Manager mondial et purement DNS.
• Traffic Manager ne bascule pas vite, par construction. Avec un intervalle de 30 secondes, trois échecs tolérés et une durée de vie de 60 secondes, il faut compter deux à trois minutes avant qu'un nouveau client soit dirigé ailleurs.
• Un répartiteur mondial devant un répartiteur régional laisse une porte ouverte tant que la passerelle accepte le trafic direct. Restriction de source par étiquette de service et vérification de l'identifiant de profil dans l'en-tête, les deux ensemble.
• La sonde décide de tout, dans les deux sens. Trop naïve, elle laisse une instance morte dans le pool ; trop dépendante d'un composant partagé, elle vide le pool entier au premier hoquet de ce composant.
• Les quatre dispositifs de filtrage ont des angles morts documentés. Le groupe de sécurité réseau ignore le contenu, le pare-feu ne voit que ce qu'on lui route, le pare-feu applicatif ne comprend pas la logique métier, et la protection volumétrique ne réagit pas à une attaque lente et bien formée.

Dans la série

Palier 2 : Construire les terminaux. Domaine : Réseau & connectivité.

• Précédent : Réseau virtuel : adressage, appairage et connectivité hybride
• Suivant : Infrastructure applicative : messagerie, passerelle d'API et cache
• Vue d'ensemble : Concevoir sur Azure : par où commencer

Pour aller plus loin

• Réseau virtuel : adressage, appairage et connectivité hybride, pour le plan d'adressage qui conditionne les sous-réseaux dédiés réclamés par la passerelle, le pare-feu et le sas d'administration.
• Haute disponibilité : SLA, zones, régions et basculement, pour transformer ces choix de répartition en objectifs de reprise chiffrés et en frontaux réellement redondés.
• Choisir un service de répartition de charge sur Azure : l'arbre de décision officiel, à confronter aux cinq filtres de ce billet.
• Documentation d'Azure Firewall et du pare-feu applicatif : les types de règles, l'ordre de traitement et les jeux de règles gérés.
• Protection DDoS Azure : ce que la plateforme couvre sans souscription, et ce que le niveau réseau ajoute réellement.
• Analyse publiée par Dyn sur l'attaque du 21 octobre 2016, signée Kyle York : la chronologie des trois vagues, l'attribution au réseau Mirai et les réserves de l'entreprise sur les volumes rapportés.