Services applicatifs utilisateur

Fichiers

J'utilise une alternative self-hosted à Google Drive. Il s'agit de Filerun, qui est basé lui-même sur Nextcloud.

C'est un peu le service phare de la maison. Le fonctionnement est vraiment proche de celui de Google Drive. De plus, l'application Android (qui est celle de Nextcloud) permet de sauvegarder automatiquement les photos du téléphone vers Filerun. En cas de perte de données du téléphone, les photos ne sont donc pas perdues. Aussi, plus de problème de limitation de l'espace de stockage sur le "Drive". Près de 8 To sont mutualisés entre les utilisateurs, avec possibilité d'augmentation.

Bureau à distance

Ce service permet de se connecter à son ordinateur à distance, depuis n'importe où sur l'Internet. La solution se compose d'un agent VNC installé sur la machine contrôlée, d'une gateway Apache Guacamole, et... d'un simple navigateur Web pour la machine contrôlant. Ainsi il est possible de contrôler un ordinateur Windows ou Linux depuis un smartphone ou une tablette.

IPTV (TV via le réseau)

J'aimerais pouvoir regarder la télévision depuis mon ordinateur. Mais j'aimerais parfois pouvoir la regarder depuis un autre ordinateur, ou même depuis mon téléphone. Je souhaiterais occasionnellement enregistrer un programme TV. Et surtout, je voudrais voir la télévision même si je suis en déplacement.

Il a donc fallu trouver une solution plus élaborée qu'avoir un simple tuner TNT USB. Ainsi j'utilise TVheadend. TVheadend est en contact avec le tuner TNT USB et délivre ensuite la télévision via HTTP en unicast donc. Il s'agit d'une solution dite d'OTT, à l'inverse d'une solution qui utilise un diffusion de type multicast, incompatible avec Internet.

TVheadend permet donc d'enregistrer des programmes. Pour les chaînes de télévision, les clients (ordinateurs et téléphones) y accèdent via VLC. VLC prend en charge les sous-titres, ce qui est appréciable.

Au sujet du tuner TNT (DVB-T pour être précis), il n'est en réalité pas branché sur le serveur principal, où TVheadend est déployé. Ceci pour des raisons physiques. Je n'ai effectivement pas de prise antenne TV dans la pièce où est le serveur. Pour trouver une solution avec une telle contrainte, j'aurais aimé pouvoir brancher le tuner TNT sur le Raspberry Pi qui lui est dans une autre pièce avec prise antenne TV. Reste à trouver un moyen de créer une sorte de tunner TV virtuel au niveau de TVheadend, qui pointe en réalité vers un tuner physique situé sur une autre machine, le Raspberry Pi. TVheadend supporte ce genre de setup. La solution consiste à déployer minisatip sur le Raspberry Pi. Côté réseau, le protocole de transport utilisé est UDP.

Wi-Fi

Concernant l'accès au réseau sans fil, celui se fait comme en entreprise. Ainsi, non pas avec une clé pré-partagée mais plutôt avec un couple identifiant / mot de passe. 802.1x donc. La méthode retenue pour la première phase EAP est TTLS, tandis que la seconde est PAP. Ce choix a été fait en prenant en compte les méthodes supportées par les supplicants (les clients), la manière dont est chiffré le mot de passe dans l'annuaire, et des considérations de sécurité et de simplicité. L'ANSSI a notamment formulé des recommandations intéressantes en matière d'authentification 802.1x.

La demande d'authentification du supplicant est reçue par le point d'accès WiFi, transferée via le protocole RADIUS au serveur d'authenfication, un serveur FreeRADIUS dans mon cas, et FreeRADIUS vérifie l'authentification grâce au serveur LDAP. L'autorisation fonctionne de la même manière : avec des groupes LDAP. Ainsi, selon les groupes auxquels appartient l'utilisateur authentifié, il est mis dans tel ou tel VLAN, voire il est rejeté et ne peut ainsi accéder au réseau. Assignation de VLAN dynamique donc.

Services d'impression

L'imprimante est accessible via IPPS (Internet Pritinting Protocol over SSL). On peut donc imprimer depuis n'importe où. L'accès au service est authentifié et autorisé.

Concernant les scans de documents, ils se font à partir de l'imprimante et sans autre action nécessaire, le fichier scanné se retrouve directement dans le "Drive" (Filerun) de l'utilisateur qui a scanné (il choisit son nom sur l'imprimante au moment de scanner). Si l'utilisateur a l'application Nextcloud permettant de synchroniser son Drive avec le disque dur de son ordinateur, le ficher est directement présent sur le disque dur de l'utilisateur. Ainsi il n'y a pas le moindre téléchargement, la moindre copie depuis un éventuel emplacement réseau à faire, pour avoir le fichier scanné sur le ordinateur. Le workflow est simplifié au maximum.

Web SSH

Le but ici est de pouvoir se connecter en SSH sur des machines de mon infrastructure, depuis n'importe où, ce qui n'est pas si évident. Mettre du SSH en direct sur l'Internet n'est déjà pas rassurant, même avec de l'authentification à clé + passphrase. En effet, les serveurs SSH (OpenSSH pour la plupart) sont parfois sur des équipements embarqués qui ne sont jamais mis à jour (imprimantes par exemple) et comportent alors des vulnérabilités, certaines critiques. Mais de plus, le protocole SSH est souvent bloqué par les pare-feux, parfois avec du Deep Packet Inspection.

Autant le dire dès maintenant, je n'ai pas l'intention de protéger du SSH avec du VPN. Dans ma maigre carrière, j'ai déjà vu une entreprise protéger l'accès à une ressource (prenant la forme d'un serveur SSH) par un VPN, puis un serveur SSH servant de bastion, puis ladite ressource. À chacune des trois étapes il fallait s'authentifier avec un nom d'utilisateur et mot de passe différents. De l'authentification triple à facteur unique. Certes trois comptes différents mais facteur unique puisque "une chose que l'on sait". Avec un peu de chance les trois identifiants pourraient être tous notés sur un bloc-note... En somme, un workflow d'authentification répulsif et une sécurité pas si élevée.

Pour résoudre les deux principaux problèmes évoqués dans le premier paragraphe, il convient de protéger les serveurs SSH derrière une sorte de proxy. Un bastion comme on dit. Mais pas nécessairement un bastion que l'on accèderait en SSH. Car justement, on va de nouveau buter sur l'autre problème : les pare-feux. La solution est donc assez limpide. Il faut une sorte de gateway Web/SSH. Pour faire transiter les flux SSH dans HTTP (voire HTTPS si Chine...). Néanmoins, la grande question est :

Accès SSH via interface Web ou ligne de commande ? À cette question, je n'ai pas encore trouvé de réponse. Chacun a des avantages et inconvénients notables. Pourquoi pas les deux ? C'est sans doute le mieux si on ne compte pas le temps à déployer les deux solutions oui.

L'interface Web permet un accès facile, qui ne nécessite pas d'installer un client. Depuis n'importe quel machine cela devrait donc fonctionner sans prérequis particulier. Le problème est surtout l'interopérabilité. Fini scp, les X sessions, rsync ou autre. La ligne de commande est donc l'inverse.

Je dois donc faire encore un choix en réfléchissant à mes cas d'usage. Il va falloir dans un premier temps faire des compromis en tout cas. Néanmoins j'ai pu essayer plusieurs solutions. Mon choix s'orientera sûrement sur l'une d'entre elles : huproxy, Google Secure Shell Chrome extension + nassh-relay, hterm, Bastillion, Guacamole.

URL shortening

Je dispose également de mon propre service permettant de générer des URL courtes. J'opère de cette manière YOURLS sur le domaine direct.yt.

VPN ?

Non. Pas de VPN. C'est ça la modernité. Ce modèle de sécurité est déjà obsolète dans un contexte de mobilité toujours plus grandissant. Comme le dit Google, l'important est que l'accès à tout service soit chiffré, authentifié et autorisé. En effet c'est Google qui a initié ce modèle sous le nom de BeyondCorp.

En y réfléchissant, la boîte email est sans doute le service le plus critique dans le sens où l'accès à cette dernière permet souvent de récupérer l'accès à tous les autres services, grâce à la fonctionnalité "mot de passe oublié" desdits services, avec laquelle un email sera envoyé pour réinitialiser le mot de passe... Et devinez quoi ? Votre boîte email est accessible sur l'Internet, sans VPN, en direct, avec le plus souvent un simple couple identifiant / mot de passe. Et globablement ça fonctionne bien, personne ne se plaint ici d'un problème de sécurité. Mais pour une meilleure sécurité, on peut toutefois mettre en place une authentification à double facteur.

Et bien chez moi tous les services fonctionnent de cette manière, et le plus souvent via une interface Web, car cela a un tas d'avantages. Tout ce qui est DNS et DHCP est géré de cette manière par exemple, plutôt qu'en ligne de commande dans une connexion SSH. De plus, en terme d'utilisation, de workflow de connexion, il n'y a donc aucune différence selon que nous soyons dans le réseau interne ou non.