La magie du transfert contre-intuitif

Le transfert de fichier vers une zone sensible constitue une problématique vieille comme le monde, mais on bute encore dessus et les solutions généralement apportées sont loin d'être élégantes. Lors de la conception d'une zone sensible, i.e. une zone où les données doivent être fortement protégées en authenticité, disponibilité ou confidentialité, vient tôt ou tard les problèmes d'interconnexion avec les zones moins sensibles, voire carrément hostiles.

Le besoin de mettre à jour des systèmes de la zone sensible constitue une illustration simple :

• Les systèmes sensibles doivent recevoir des mises à jour,
• Certes, celles-ci peuvent être signées numériquement par leurs éditeurs (la plupart des distributions Linux, comme Microsoft, signent leurs mises à jour),
• Mais un flux montant, i.e. depuis la zone hostile vers la zone sensible, est fonctionnellement nécessaire !

Les règles du jeu

Elles sont simples :

• La zone sensible est très sensible : On veut a minima deux mesures de sécurité distinctes et non contournables ;
• Hors de question d'utiliser des solutions type USB-processing : C'est nul, on va faire des erreurs, la clef sera insérée là où il faut pas ; Comment démontrer formellement que ça n'a jamais été le cas, un ingénieur système/réseau a autre chose à faire, etc..

En plus on a techniquement un flux montant et descendant, puisque la clef sera utilisée pour récupérer de nouvelles mises à jour après s'être connectée à la zone sensible, donc faut la reformater avant, mais quel crédit SSI on doit tirer d'un reformatage, et c'est une procédure organisationnelle, est-ce que si l'opérateur oublie, c'est un incident de sécurité, une compro, blah blah blah tristesse chagrin

Le niveau crado : Se contenter de mettre des pare-feux

Attention, je ne dis pas que positionner un pare-feu pour protéger une zone sensible est maladroit, mais que ça ne répond pas au problème qu'on tente de résoudre ici. Cela constitue en fait une fausse solution, ou tenter d'adapter la solution d'un problème A à un problème B. Bien sûr, quand on sait manier un marteau, toute vis est un clou ;

Plus sérieusement, dans notre cas, ça ne marchera pas et donnera un faux sentiment de sécurité.

Pour remettre l'église au centre du village, on a bien évidemment déjà un pare-feu ; En application des bonnes pratiques, celui-ci interdit tout flux montant vers la zone sensible.

Cependant, cette approche naïve permet de mieux positionner notre problème : Nous avons un pare-feu interdisant tout flux montant pour protéger la zone sensible ; Et comme la zone est très sensible, la solution semble couler de source :

• Nous positionnons deux pare-feu de marque différente, il devient peu vraisemblable qu'une vulnérabilité impactant l'un impacte également le deuxième ;
• Nous permettons un flux montant, strictement identifié, associé à sa matrice de flux ; Et ouvrir ce flux sur les deux.

Pourquoi c'est naze ?

Un pare-feu est associé à sa matrice de flux, et là, nos deux pare-feux partagent la même matrice de flux. On sent bien qu'on s'écarte de l'exigence de deux mesures de sécurité indépendantes. Il s'agit de la même mesure dupliquée deux fois. Un peu comme tenter de faire passer comme de l'authentification bi-facteur le fait de demander deux fois le mot de passe à un utilisateur.

Souvent les pare-feux partagent le même noyau. Linux ou \*BSD. StormShield ? Un BSD.

Un pare-feu permet de limiter la surface d'attaque. C'est une bonne pratique, mais on a une zone très sensible à protéger. Et puis, bien que la surface d'attaque au niveau OSI reste limitée, l'attaquant dispose toujours de l'accessibilité pleine et entière au service ! Derrière le pare-feu, il y a bien sûr ce service applicatif qui reçoit les éléments montant et qui les traite :

• Réception et stockage sur disque,
• Vérification de signature numérique (on parle de mises à jour signées dans l'exemple).

Le niveau bof

Bon, reprenons notre copie :

Le dogme parle d'une zone tampon, appelée DMZ, à implémenter, si l'on en croit les bonnes pratiques (expression pédantique régulièrement utilisée pour discréditer l'interlocuteur qui la sort en dernier).

Alors, bien sûr, une DMZ n'est pas nécessairement une mauvaise idée. Voyons ce que ça donne :

On sent bien que c'est moche. C'est lourd, on a dupliqué la solution naze. Bien sûr, le travail devient moins simple pour l'attaquant, qui se retrouve à travailler en deux étapes. Il faudra ensuite spécifier et implémenter les deux briques applicatives pour qu'elles fassent le même travail, mais différemment (encore cette histoire de mesures indépendantes). On a encore l'impression de demander deux fois le même mot de passe à l'utilisateur.

Les pare-feux partagent toujours la même matrice de flux, et on a toujours ce flux entrant.

Rsync et le transfert anti-intuitif

Ce qui est fou, c'est que la solution ne coûte rien en fait : On repart de notre zone tampon, mais on va apporter un petit changement.

• Côté hostile : Le pare-feu externe ne permet que le flux vers le service de réception. Rien de nouveau. Cependant, le service de réception ne fait rien d'autre que déposer la donnée sur un disque.
• Côté sensible : On a un rsync en flux sortant qui vient récupèrer le fichier depuis la zone tampon. Le pare-feu interne reste bloquant pur dans le sens montant.

Au final, nous avons deux mesures de sécurité et trois difficultés à contourner pour l'attaquant :

• Difficulté : Trouver une vulnérabilité sur le service de réception. Pas inatteignable, mais faut quand même du travail, on peut penser à un formulaire d'upload un peu durci et servi par Apache ;
• Mesure de sécurité : Pare-feu entièrement bloquant : L'attaquant ne peut atteindre aucun service applicatif de la zone sensible, s'il envoye une charge malveillante, il ne peu intéragir avec aucun service de traitement fonctionnant en zone sensible ;
• Mesure de sécurité : Vérification de signature numérique : une fois la charge transférée, (par exemple sur une partition sans droit d'exécution), un deuxième service procède à la vérification de signature. L'attaquant doit déterminer une vulnérabilité dans la pile cryptographique vérifiant la signature pour faire passer sa charge pour une mise à jour légitime. Et ce, sans pouvoir interagir sur la pile applicative manipulant les fonctions cryptographiques.