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

• http://www.zerotier.com/manual.shtml#3 (la documentation officielle)
• https://www.reddit.com/r/zerotier/comments/958c3d/flow_rule_for_allowing_only_rdp_traffic/ 
• https://gist.github.com/adamierymenko/7bcc66b5f7627699236cda8ac13f923b
• https://blog.reconinfosec.com/build-a-private-mesh-network-for-free/  
• https://docs.opnsense.org/manual/how-tos/zerotier.html (d'autres idées à creuser)
• https://discuss.zerotier.com/t/new-dns-features-dont-appear-to-work/982/15 (DNS)

Tous les possesseurs de Freebox 4K le savent, ce n’est pas le pied ! Avec sa télécommande indomptable, ses bugs audio à répétitions. Même avec la dernière mise à jour, cette box TV ne cesse d’être capricieuse. Mais il parait que c’est bien mieux que la box Android TV de son conçurent BT. Bref, même les box génériques chinoises font mieux, mais je ne conseillerais pas ces produits pour qui veut un bon player Android TV.

En fait à mon sens il y a deux produits qui tiennent la route sous Android TV. La Nvidia Shield est la reine ou même la v1 est toujours excellente et mise à jour régulièrement, l’outsider étant la Mi Box 3 de Xiaomi en attendant le v4 annoncée il y a un mois avec des améliorations qui semblent cosmétiques. Il y a deux alternatives viables, un ChromeCast ou un Apple TV pour ceux qui ne se sentent bien qu’avec les produits d’Apple, mais ce n’est pas le propos ici.

Pour revenir à Android TV, et si l’on ne dispose pas d’un HD HomeRun ou l’intégration est parfaite, il va se poser le problème de l’intégration des chaines TV de son opérateur en IPTV à partir du fichier .M3U fournit par les FAI. Si l’on exclut certaines applications douteuses, il existe une solution qui permet une intégration parfaite : TVIrl. TVIrl est une application Android TV qui va permettre d’utiliser la playlist fournie par le FAI ainsi qu’un lien vers une source EPG. Le soucis c’est que si les FAI fournissent bien le fichier de leurs chaines en IPTV, il n’en est rien pour l’EPG et les logos.

Internet fourmille de fournisseurs d’EPG dans différents formats, notamment XMLTV ou même des acteurs comme Télérama s’y sont mis, ou encore ça, internet est vote ami). Mais la vraie question sera d’agréger ces informations avec les chaines dans la bonne numérotation avec leur EPG et leurs logos. Si la première solution, notamment pour comprendre est Notepad, on atteindra rapidement ses limites en matière de patience. Il existe des logiciels plus ou moins bugées et des sites. Pour ma part j’ai testé avec X.Tream qui a l’inconvénient d’être payant mais l’avantage de fournir un résultat impeccable et durable. On peut tester avec un trial de 7 jours et ensuite partager les frais à plusieurs.

Le principe est simple, on insère son fichier .m3u, ici freebox.m3u et ensuite on va faire le tri dans les chaines afin d’écarter celles qui ne nous intéressent pas, les versions SD ou certaines chaines étrangères par exemple. On les trie dans l’ordre souhaité pour finir dans le section EPG afin de faire coller une source EPG à chacune des chaines retenues (il y a un doc ici qui décrit le processus. Le menu Picons servira à associer les logos de façon automatique.

Dans la section downloads de X.Tream Editor on obtiendra deux url, la première sera la playlist formatée et la seconde l’EPG. Il va falloir coller ces deux url dans TVIrl sous Android TV. Sachant que TeamViewer ne fonctionne pas très bien sous Android TV, le plus simple sera de se servir de la télécommande Android pour faire un copié / collé. Une fois l’opération terminée on va dans les options de Chaines en direct pour sélectionner les canaux souhaités. L’avantage de cette solution c’est qu’elle est pérenne. A tout moment on peut aller dans X.Tream Editor et y faire des modifications qui seront répercutées dans les Chaines en direct d’Android TV via TVIrl.

Unifi et dual WAN

Il reste un cas particulier qui n’a rien à voir avec ce que j’exposais précédemment. Si on utilise un routeur dual WAN avec deux FAI (ADSL, fibre et 4G) il va falloir indiquer au routeur par ou doit passer le ou les flux TV. En effet le flux Free ne sera accessible que via la ligne Free tout comme le flux Orange devra passer par la ligne Orange. Si sur certains routeurs le réglage est accessible dans l’interface de configuration il n’en est bizarrement rien pour l’USG d’Unifi ou il va falloir y aller en dur via SSH :

configure
set protocols static table 5 route 0.0.0.0/0 next-hop 1.2.3.4
set firewall modify LOAD_BALANCE rule 2500 action modify
set firewall modify LOAD_BALANCE rule 2500 modify table 5
set firewall modify LOAD_BALANCE rule 2500 destination address 212.27.38.0/24
set firewall modify LOAD_BALANCE rule 2500 protocol all
commit;exit

Ou 1.2.3.4 est l’ip de la passerelle de la ligne Freebox que l’on peut retrouver avec un show ip route. Il va falloir rendre cette configuration pérenne au reboot grace à un fichier config.gateway.json, le sujet a été largement abordé dans la communauté Unifi et ailleurs (voir les liens ci dessous).

Si vous avez d'autres idées et astuces, elles sont bienvenues dans les commentaires !

Sources

_{https://help.ubnt.com/hc/en-us/articles/360005460813-UniFi-USG-Advanced-Policy-Based-Routing 
https://help.ubnt.com/hc/en-us/articles/215458888 
https://matthijs.hoekstraonline.net/2017/10/29/configuring-source-address-based-routing-on-my-unifi-usg/ 
https://www.reddit.com/r/AndroidTV/comments/6oo99t/guide_to_setting_up_live_channels_for_android_tv/ 
https://www.reddit.com/r/IPTV/comments/83keyw/tvirl_or_alternatives_android_tv_love_channels_w/}