Dans le précédent article on a vu comment créer facilement un SDN avec Zerotier qui de part ses possibilités explose les deux autres possibilités dont j’avais parlé. Un VPN SDN c’est un réseau étendu qui peu s’intégrer dans un LAN existant ou être totalement virtuel. Dès lors se pose la question de la sécurité des accès et il convient de considérer principalement à deux niveaux :
- Sécurité d’accès aux ressources au niveau machine assurée par celle-ci ou une solution globale comme Active Directory. Dans un petit réseau local les utilisateurs ont tendance à laisser pas mal de choses ouvertes, voire très peu protégées. Dès lors que l’on ouvre un réseau à un SDN il conviendra de renforcer la sécurité des équipements.
- Sécurité d’accès au niveau IP. Sur un LAN ou plusieurs LAN interconnectés via des VPN cette sécurité est assurée au niveau des routeurs et des switches afin d’isoler les départements, entremises, etc…
Dès lors que l’on étend un réseau à un SDN comme Zerotier on va se retrouver avec des devices isolés et il faudra définir ce que ces devices auront le droit de faire. Cela est rendu possible de façon centralisée via un système de règles relativement puissant qui se base sur l’ID de chaque client ZT qui va interagir avec des règles basées sur des tags, les adresses IP ZT ou internes aux réseaux, les ports et les protocoles. Je vais me contenter de donner ici quelques exemples que chacun adaptera à ses besoins.
On se base principalement sur 3 expressions
DROP, on supprime le paquet et on termine l’évaluation de la règle.BREAK, on termine l’évaluation de la règle mais on accepte l’évaluation par une autre capacité.ACCEPT, on autorise.
On va se servir de la règle de base et l'améliorer
Pour autoriser uniquement les trames Ethernet IPv4, IPv4 ARP.
drop
not ethertype ipv4
and not ethertype arp
and not ethertype ipv6;
Pour éviter toute forme d’IP spoofing, mais ça bloque également les IP non ZT. Donc à exclure si on utilise des ponts vers des réseaux existants.
drop
not chr ipauth;
Pour autoriser à tout le monde par exemple SSH, HTTP et HTTPS
accept
ipprotocol tcp
and dport 22 or dport 80 or dport 443;
Ici on va créer un TAG “department” que l’on va associer à des clients, et à partir de là on définira des possibilités. Ces TAG peuvent permettre de faire communiquer ensemble des clients d’un même service en comparant leur niveau (tdiff department 0 ou 0 est la différence acceptable entre deux clients pour être valide), mais on peut aussi utiliser ces TAG avec TSEQ pour affecter des droits.
tag department
id 1000 #ID est arbitraire mais unique
enum 100 Archi
enum 200 Dev
enum 300 Services
enum 400 Finances
enum 500 Ventes;
Autoriser Windows CIFS et Netbios aux clients d'un même groupe (différence = 0)
accept
ipprotocol tcp
and tdiff department 0
and dport 139 or dport 445;
Autoriser les clients tagués 300 (to_LAN1_LAN2) à accéder à des réseaux internes spécifiques via un pont :
accept tseq department 300 and ipdest 192.168.1.0/24;
accept tseq department 300 and ipdest 192.168.2.0/24;
Pour supprimer les paquets TCP SYN,!ACK qui ne sont pas explicitement autorisés
break
chr tcp_syn # TCP SYN (TCP flags will never match non-TCP packets)
and not chr tcp_ack # AND not TCP ACK;
Pour interdire les destinations qui ne sont pas explicitement autorisées ci-dessus
break ipdest 192.168.1.0/24;
break ipdest 192.168.2.0/24;
break ipdest 192.168.3.0/24;
Si restreindre les IP est utilisé pour contrôler l’accès à des machines accessibles via un bridge, Il faut également pouvoir rendre inaccessibles certains clients ZT sensibles. Le modèle utilisé pour le contrôle d'accès ressemble à la façon dont les organisations militaires classifient les données. Les informations sont considérées classifiées et seules les personnes disposant du niveau de classification requis sont autorisées à y accéder. Il ne s'applique hélas pas aux clients non ZT
Au départ, les membres se verront attribuer un tag classified par défaut de 0 ("no"). Ceux-ci peuvent communiquer puisque leur étiquette de classification sera zéro. Pour restreindre l'accès à un membre, définissez son tag de classification sur secret (1) ou top (2). (Dans cet exemple, il n'y a pas de différence, mais deux niveaux sont inclus au cas où vous voudriez mettre en œuvre une sorte de segmentation plus détaillée basée sur ceux-ci.). Ainsi, la première correspondance (not tor classified 0) sera vraie et le paquet sera abandonné, à moins que les deux membres en communication aient au moins un flag (équipe) en commun grâce au bit clearance (tand clearance 0). (et si vous n’avez pas compris allez voir la doc en anglais…).
# Is this member classified?
tag classified
id 2
enum 0 no
enum 1 secret
enum 2 top
default no
;
# Clearance flags (a bit like groups)
tag clearance
id 1
default 0
flag 0 staging
flag 1 production
flag 2 financial
flag 3 security
flag 4 executive
;
# If one party is classified, require at least one overlapping clearance bit
break
not tor classified 0
and tand clearance 0
;
Pour ne pas être en reste, on va bien sur se créer une capacité "superuser" que l’on pourra affecter à des clients ZT pour passer outre les interdictions…
cap superuser
id 2000
accept;
Et enfin on accepte ce qui n’est pas interdit….
accept;
Ce ne sont que quelques exemples et en parcourant la documentation disponible on s’apercevra que les possibilités sont énormes. Je vais essayer de compléter cet article au fil de l'eau, et vos commentaires sont comme toujours les bienvenus.
DNS
A partir de la version 1.6 il est possible d'activer le DNS pour les clients ZT, ce qui veut dire que pour un ou plusieurs domaines spécifiques on pourra faire appel à un ou plusieurs serveurs DNS. On commence par renseigner l'IP du serveur DNS dans l'interface d'administration :
Ensuite au niveau du client il va falloir entrer la commande suivante (en mode admin) et ou $networkID sera l'ID de votre réseau.
zerotier-cli set $networkID allowDNS=1
Il faut bien avoir à l'esprit qu'on agit sur NRTP (Name Resolution Policy Table) sous Windows et que l'on ne verra rien avec un IPConfig... Je suppose que sur MacOS ou Linux il existe une équivalence. Ce qui compte c'est que ça fonctionne et qu'il est désormais inutile d'encombrer vos DNS publics avec des adresses privées pour palier à ce manque !
Sources