Blog BlueTrusty

BlueTrusty, acteur Pure Player CyberSecurité d’ITS Group, s’inscrit dans la démarche gouvernementale d’accompagner les entreprises victimes d’attaques informatiques.

À propos de Cybermalveillance.gouv.fr

Lancé en octobre 2017, Cybermalveillance.gouv.fr est le dispositif gouvernemental d’assistance aux victimes d’actes de cybermalveillance, de sensibilisation aux risques numériques et d’observation de la menace sur le territoire français.

Le dispositif a été incubé par l’Agence nationale de sécurité des systèmes d’information (ANSSI) en copilotage avec le ministère de l’Intérieur et le soutien des ministères de l’Économie et des Finances, de la Justice et du secrétariat d’État chargé du Numérique. Il est désormais piloté par une instance de coordination, le Groupement d’intérêt public (GIP) ACYMA.

À qui s’adresse la plateforme Cybermalveillance.gouv.fr ?

La plateforme Cybermalveillance.gouv.fr s’adresse ainsi principalement à toutes les victimes d’attaques informatiques qui ne disposent pas des compétences et/ou des ressources suffisantes en sécurité numérique : les particuliers, les entreprises, les associations et les collectivités territoriales

Quel est son objectif ?

La plateforme Cybermalveillance.gouv.fr répond à deux objectifs :

1. Prévenir et sensibiliser à la sécurité numérique

Pour vous informer, Cybermalveillance.gouv.fr met à disposition divers contenus thématiques dans la prévention et la sensibilisation aux dangers du numérique

2. Assister les victimes d’actes de cybermalveillance

• L’établissement d’un diagnostic de votre situation grâce à un parcours victime interactif. 
• Des conseils pratiques pour comprendre l’incident dont vous avez été victime et commencer à entreprendre les actions pour le résoudre, voire pour d’éventuelles démarches administratives, comme un dépôt de plainte auprès des services de police ou de la gendarmerie.
• La mise en relation avec des spécialistes et organismes compétents proches de chez vous : suivant la nature de votre problème, vous pourrez être mis en relation avec des professionnels spécialisés en sécurité numérique experts susceptibles de pouvoir vous assister techniquement ou bien vous serez redirigé vers une plateforme spécialisée proposant des solutions adaptées à vos besoins. 

Qu’est-ce qu’un professionnel référencé sur Cybermalveillance.gouv.fr ?

La plateforme Cybermalveillance.gouv.fr met à disposition de la victime une liste de professionnels proches de sa localisation géographique, qui se sont déclarés en mesure d’apporter une assistance technique. Ces professionnels sont référencés sur la plateforme après une candidature volontaire de leur part.

Lors de leur candidature, les professionnels s’engagent par la signature d’une charte à respecter de bonnes pratiques commerciales, à respecter la confidentialité des données de leurs clients et à remonter à Cybermalveillance.gouv.fr les éléments techniques qui pourront être utiles à une meilleure analyse de la menace.

Afin de compléter leur candidature les professionnels répondent à quelques questions portant sur la mission qui leur est proposée et les engagements qu’ils prennent. Les dossiers complets sont ensuite examinés pour validation par les équipes de Cybermalveillance.gouv.fr

Dans un précédent article nous avons présenté VLXAN.

STT, NVGRE et GENEVE sont d’autres exemples de protocoles d’encapsulation qui permettent de construire un overlay (à la manière d’IPSEC dans certains déploiements de Kubernetes sur un Cloud public) pour des réseaux de type SDN.

Un point d’attention particulier est la façon dont les points de terminaison (VTEP : VXLAN Tunnel EndPoint) découvrent leurs pairs et renseignent la table de correspondance (ou mapping) @MAC <=> VTEP.

Dans un environnement limité, les premières solutions constitaient à :

• configurer un mapping statique ; assez peu pertinent quand les workloads sont censés être parfaitement mobiles entre VTEP, et éphèmère
• construire une mapping dynamique en s’appuyant sur du Multicast IP. Cette solution n’est en général pas possible sur du cloud public (OVH, AWS..) car le Multicast est interdit (ou plus exactement pas tranmis/routé)
• construire un mapping pseudo dynamique à base de scripts PowerShell.

Une solution d’envergure et interopérable, consiste à utiliser BGP pour faire transiter ces mappings @MACs <=> VTEP. BGP est réputé pour être robuste, extensible et sclable. Les messages Route Type 2 et Route Type 5 sont utilisés pour transmettre les @MAC et les @IP avec leurs mappings VNI,VTEP.

Ansi est né MP-BGP EVPN, RFC7348. « MP » fait référence à « Multi-Protocol ».

On peut notamment  utiliser toutes les techniques de mise à l’échelle de BGP, par l’utilisation de Route Reflector.

La table de correspondance ainsi construite prend cette forme :

[email protected]:~$ net show evpn arp-cache vni 10100

Number of ARPs (local and remote) known for this VNI: 9IP              Type   MAC               Remote VTEP          50.1.1.11       local  00:02:00:00:00:01 50.1.1.12       local  00:02:00:00:00:02 50.1.1.22       remote 00:02:00:00:00:04 110.0.0.2            2001:50:1:1::11 local  00:02:00:00:00:01 50.1.1.31       remote 00:02:00:00:00:05 110.0.0.3            50.1.1.42       remote 00:02:00:00:00:08 110.0.0.4            50.1.1.21       remote 00:02:00:00:00:03 110.0.0.2            50.1.1.32       remote 00:02:00:00:00:06 110.0.0.3            50.1.1.41       remote 00:02:00:00:00:07 110.0.0.4

Cisco fournit un ebook gratuit sur ce large sujet (A Modern, Open, and Scalable Fabric: VXLAN EVPN). Les autres constructeurs (par ex Arista, Juniper) ou bien éditeurs commerciaux (par ex. VMWARE NSX, plus exactement au niveau des Edge) ou OpenSource (ex Quagga et Cumulus Linux) supportent également BGP EVPN.

Contrairement aux schémas précédents issus de la documentation Cisco, dans les déploiements que nous effectuons en Cloud Public, comme dans la plupart des cas réels, la fonction VTEP est directement portée par l’Hyperviseur, soit nativement soit par le biais d’un container (exemple direct de NFV).

Bien que la RFC date de 2014, nous n’en sommes encore qu’au début de l’implémentation dans les équipements; l’interopérabilité devrait être assurée à terme, des travaux sont en cours à l’IETF.

N’hésitez pas à nous faire vos remarques dans les commentaires ou à nous contacter si vous souhaitez plus de détails ou de l’accompagnement.

Introduction

Il est aujourd’hui monnaie courante pour les hébergeurs et les opérateurs Telco de fournir des réseaux virtuels sur lesquels leurs clients peuvent déployer leurs VLANs 802.1Q.
En raison du nombre limité de VLANs possible (4096) en 802.1Q , les constructeurs ont mis au point de nouvelles technologies  de VLANs déployable dynamiquement au dessus d’un réseau IP routé.

VxLAN est l’une d’entre elles.

Nous sommes là au coeur des technologies réseau (SDN : Software Defined Networks) permettant de faire fonctionner des clouds répartis sur plusieurs DataCenters.

Présentation de VxLAN

VxLAN est un format d’encapsulation porté par Cisco et VMware ayant des fonctionnalités semblables aux VLANs mais avec quelques améliorations que nous allons détailler dans cet article.

VxLAN est l’acronyme de Virtual eXtensible LAN qui est une standardisation à été proposée à l’IETF en 2011.

Grâce à ce format, il est possible de faire transiter des trames de niveau 2, dans UDP.

Cette propriété permet, par conséquent, d’utiliser une segmentation de type VLAN au delà d’un domaine Ethernet.

De plus, grâce à son champ d’identification sur 24 bits, il est possible de créer sur un même domaine VxLAN plus de 16 millions de VLANs différents (224 plus précisément). Cependant, puisque VxLAN est un format d’encapsulation, il provoque une surcharge d’entête dans les trames ethernet. Le schéma ci-dessous compare une trame Ethernet avec VLAN “standard” avec une trame Ethernet avec VxLAN.

Comme on peut le constater sur ce schéma, VxLAN provoque un “overhead” (i.e surcharge d’encapsulation) assez important (A peu de chose près équivalente à la taille des entêtes de niveau 2 + niveau 3 + niveau 4) soit environ 50 octets.

Un peu de vocabulaire

ARP : Address Resolution Protocol, mécanisme de base permettant d’obtenir l’adresse physique d’une machine en fonction de son IP. Protocol de base sur lequel repose IP.

MTU : Maximum Transmission Unit, correspond à la taille maximum transmissible sur une interface (Ethernet dans notre cas) sans fragmentation.

Multicast : Méthode de diffusion permettant à une machine de communiquer avec un groupe de machines avec un système d’abonnement

TTL : Time To Live, valeur incluse dans un paquet IP étant décrementé lors du passage dans un routeur permettant d’éliminer les paquets entrés dans des boucles de routage.

VTEP : VXLAN Tunnel End Point, correspond à la porte d’entrée (ou de sortie) d’un domaine VXLAN : Ces éléments permettent l’encapsulation et la désencapsulation des paquets VXLAN afin d’acheminer ceux-ci vers leur destination finale. Cette fonctionnalité peut-être assuré par le noyau Linux depuis le noyau 3.7.

Principe de fonctionnement

VxLAN repose sur l’encapsulation de trames Ethernet dans UDP.

Le schéma simplifié d’une trame réseau utilisant VXLAN est donc le suivant :

Niveau 5	MAC DestMAC SrcIP SrcIP DestTCP/UDPDATA
Niveau 4	UDP
Niveau 3	IP VTEP SourceIP VTEP Destination
Niveau 2	MAC VTEP Dest (ou MAC GW)MAC VTEP Source
Niveau 1	Cuivre / Fibre

On voit ci-dessus que le paquet originellement emis par la machine dans le domaine VxLAN ne se retrouve qu’au niveau 5. Il est donc possible d’effectuer un routage entre les VTEP avant de décapsuler le paquet et ainsi permettre une segmentation de type V(X)LAN en s’affranchissant des domaines Ethernet.

Etudions maintenant comment fonctionnent les fonctions de niveau 2 (ARP, broadcast, …) au sein d’un domaine VxLAN.

Alors que sur un domaine Ethernet standard, ces protocoles fonctionnent grâce à l’adresse de broadcast, un domaine VXLAN utilise quand à lui une adresse IP Multicast.

De cette façon, lors du déploiement d’un nouveau VTEP sur un domaine VxLAN, il faudra simplement l’abonner au groupe multicast correspondant à son VxLAN.

VXLAN dispose ensuite d’un mecanisme faisant transiter les données de broadcast sur ce groupe multicast permettant à tous les VTEP de communiquer ensemble afin de répondre (par exemple) aux requêtes ARP.

Ceci se traduit lors de la création d’une interface vxlan, par une commande du type :

$ ip link add vxlan10 type vxlan id 10 group 239.0.0.10 ttl 10 dev eth0

$ ip link set vxlan10 up

Grâce à ces deux commandes nous créons une interface VxLAN avec le tag 10 dont l’interface physique sera eth0, dont le domaine de broadcast est géré grâce à l’adresse multicast 239.0.0.10 et le TTL des packets encapsulés à 10.

De ce fait, toutes les machines abonnées au groupe multicast 239.0.0.10 recevront le trafic de broadcast de ce VXLAN.

Limites et remarques

Le fonctionnement de VxLAN reposant sur IP, celui-ci donne aux architecture l’utilisant  l’avantage d’être scalable. Seules les limites des VTEP et de la bonne configuration de votre réseau peuvent limiter les performances du protocole.

En effet, comme nous l’avons vu dans l’introduction, ce protocole d’encapsulation provoque une surcharge d’entête. Celle ci pourrait avoir des conséquences importantes sur les performances de votre réseau si celui-ci est mal configuré.

Plus précisement, avec une surcharge d’environ 50 octets en IPv4 et 100 octets en IPv6, votre VTEP est susceptible d’avoir à générer des trames Ethernet de 1550 à 1600 octets. Si votre réseau est configuré avec une MTU à 1500 (comme dans la majorité des cas), vous risquez d’avoir un taux de fragmentation assez important qui aura un impact sur les performances du réseau.

Afin de résoudre ce problème, deux solutions existent :

1) Limiter vos machines dans un domaine VXLAN à envoyer des trames plus petite (MTU à 1450 ou 1400o)

2) Augmenter le MTU global de votre réseau à 1550 ou 1600, si vous pouvez le paramétrer de bout en bout.

Enfin, mentionnons qu’il existe des initiatives alternatives à VxVLAN telle que Virtual Network over TRILL, aussi nommé VNT (cf http://www.lebardegandi.net/post/2013/02/11/16-millions-de-VLAN-%C3%A7a-vous-suffit )

Sources

http://vincent.bernat.im/fr/blog/2012-multicast-vxlan.html

http://datacenterblog.cisco.fr/tag/vxlan/

VXLAN basics and use cases (when / when not to use it)

http://www.borgcube.com/blogs/2011/11/vxlan-primer-part-1/

http://www.borgcube.com/blogs/2012/03/vxlan-primer-part-2-lets-get-physical/

Typical VXLAN Use Case

http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-00

http://www.lebardegandi.net/public/Virtual_Network_over_TRILL.pdf

Nous nous sommes intéressés récemment aux Linux Capabilities , dans le cadre de durcissement de containers Docker ou de cluster Kubernetes.

Il existe de nombreuses références à ce sujet sur Internet et dépasse l’objet de cet article.

Les Capabilities , intégrées aux Kernel Linux, permettent de décrire finement les droits nécessaires à un exécutable et sont référencées ici. Celles qui nous intéressent le plus souvent dans le cas du confinement de containers Docker sont  :

/* Allow interface configuration */
 /* Allow administration of IP firewall, masquerading and accounting */
 /* Allow setting debug option on sockets */
 /* Allow modification of routing tables */
 /* Allow setting arbitrary process / process group ownership on
 sockets */
 /* Allow binding to any address for transparent proxying (also via NET_RAW) */
 /* Allow setting TOS (type of service) */
 /* Allow setting promiscuous mode */
 /* Allow clearing driver statistics */
 /* Allow multicasting */
 /* Allow read/write of device-specific registers */
 /* Allow activation of ATM control sockets */

#define CAP_NET_ADMIN 12

/* Allow use of RAW sockets */
 /* Allow use of PACKET sockets */
 /* Allow binding to any address for transparent proxying (also via NET_ADMIN) */

#define CAP_NET_RAW 13

Un exemple de classique utilise le binaire « ping » :

[email protected]:~# ls -lh /bin/ping
-rwsr-xr-x 1 root root 44K May  7  2014 /bin/ping

On constate que le bit S (setuid) est activé car ping nécessite le droit de créer une socket ICMP. Si « root » retire ce droit, le ping ne fonctionne plus pour l’utilisateur « toto »:

# chmod -s /bin/ping
# su toto
$ ping randco.fr
ping: icmp open socket: Operation not permitted

Si on ajoute la Capability NET_RAW, ping fonctionne à nouveau et ce nouveau droit est à la fois suffisant et bien plus restreint qu’un bit SETUID :

# setcap cap_net_raw+p /bin/ping
# su toto
$ ping randco.fr
PING randco.fr (164.132.216.245) 56(84) bytes of data.
64 bytes from 164.132.216.245: icmp_seq=1 ttl=57 time=5.72 ms
64 bytes from 164.132.216.245: icmp_seq=2 ttl=57 time=5.30 ms

Dans Kubernetes, les Pod Security Policies (PSP) permettent de détailler au niveau du Cluster les Capabilities à ajouter ou à retirer aux Pods. Ci-dessous un exemple de Policy très contrainte :

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  # Required to prevent escalations to root.
  allowPrivilegeEscalation: false
  # This is redundant with non-root + disallow privilege escalation,
  # but we can provide it for defense in depth.
  requiredDropCapabilities:
    - ALL
[..]

Pour apprendre par le test, nous ne pouvons que vous conseiller d’explorer https://contained.af/.

Si vous avez des questions plus globales sur la sécurisation de cluster Kubernetes, contactez-nous.