Configurer un serveur Terminal Ubuntu 9.10 avec FreeNX

Ce guide explique étape par étape comment transformer un poste Ubuntu 9.10 en serveur Terminal accessible par des clients légers avec FreeNX. Vous trouverez l’installation, la configuration réseau et pare-feu, la sécurisation (SSH, fail2ban), l’installation client, des modèles, une méthodologie d’exploitation et un plan de reprise.

Introduction

Ce qui était ancien redevient pertinent : l’approche poste de travail centralisé (thin client / mainframe) revient pour certaines organisations et usages. Ce tutoriel explique comment configurer un poste Ubuntu 9.10 pour agir comme un « mainframe » accessible par des clients légers ou des postes classiques via FreeNX.

FreeNX est une implémentation open source du serveur NX de NoMachine. Contrairement à VNC, NX fonctionne au-dessus de SSH et optimise la bande passante tout en fournissant une qualité visuelle et une réactivité correctes. Le client NoMachine (gratuit) existe pour Windows, macOS, Linux et Solaris. Par défaut tout le trafic passe par SSH, donc les connexions sont chiffrées.

Important : ces instructions ont fonctionné pour l’auteur et sont proposées à titre pédagogique. Sécurité réseau et architecture méritent une analyse approfondie adaptée à votre contexte. Suivez ce guide à vos risques et périls.

Vue d’ensemble technique (définition en 1 ligne)

FreeNX : serveur d’accès à distance basé sur le protocole NX utilisant SSH pour transporter les données de session graphique.
SSH : protocole sécurisé pour l’accès distant (port 22 par défaut).

Objectifs du guide

Installer et configurer FreeNX sur Ubuntu 9.10.
Créer une configuration réseau statique adaptée à un serveur.
Configurer un pare-feu minimal (firehol) et une protection contre les bruteforces (fail2ban).
Installer et paramétrer le client NoMachine.
Fournir des modèles, contrôles et procédures opérationnelles (SOP), tests et plan de reprise.

Prérequis rapides

Une machine avec Ubuntu 9.10 (Karmic Koala) installée.
Accès administrateur (root) ou sudo.
Une connexion réseau permettant l’accès SSH depuis les clients.
Une seconde machine pour tester le client NX.

Important : Ubuntu 9.10 est une version ancienne et ne reçoit plus de mises à jour de sécurité. Pour un déploiement en production, préférez une version LTS supportée. Ce guide conserve 9.10 pour correspondre au contexte initial.

1. Système d’exploitation

Installez Ubuntu 9.10 si ce n’est déjà fait. Les instructions d’installation détaillées existent ailleurs ; suivez au minimum les étapes d’installation de base, les mises à jour et l’ajout d’un compte administrateur.

Référence utile : https://www.howtoforge.com/the-perfect-desktop-ubuntu-9.10-karmic-koala

2. Élévation de privilèges

Ouvrez un terminal via Applications -> Accessories -> Terminal et devenez root :

 sudo su -l

Ensuite, installez les paquets requis : openssh-server pour SSH, fail2ban pour limiter les tentatives de bruteforce et firehol pour faciliter la gestion iptables :

  aptitude update && aptitude install openssh-server fail2ban firehol

Testez que le serveur SSH fonctionne localement :

 ssh 127.0.0.1

Vous verrez l’empreinte RSA et la demande de continuer la connexion. Notez l’empreinte pour vérification ultérieure, puis quittez (Ctrl-C) ; cela prouve que le service SSH répond.

3. Configuration réseau (IP statique)

Pour un serveur accessible de façon fiable, une adresse IP statique est recommandée. Vous pouvez aussi configurer une réservation DHCP côté serveur DHCP, mais ici nous montrons la configuration statique locale.

Vérifiez vos paramètres réseau actuels :

ifconfig eth0

Notez addr (IP), Bcast (broadcast) et Mask (netmask). Puis :

 cat /etc/resolv.conf

Notez les serveurs DNS (nameserver). Et enfin :

route

Notez la Gateway (passerelle) sur la ligne starting with default.

Choisissez une adresse IP dans le même sous-réseau non utilisée par DHCP afin d’éviter les conflits. Puis éditez :

 nano /etc/network/interfaces

Si la ligne suivante existe, changez dhcp en static :

iface eth0 inet dhcp

Sinon ajoutez :

iface eth0 inet static

Et complétez par vos paramètres réseau (exemple) :

    address 192.168.1.253
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255
    gateway 192.168.1.1
    dns-nameservers 8.8.8.8, 8.8.4.4

Enregistrez (Ctrl-O) et quittez (Ctrl-X). Relancez le réseau :

 /etc/init.d/networking restart

Ouvrez Firefox et vérifiez l’accès Internet avant de continuer.

Note : j’utilise les DNS publics de Google ici (8.8.8.8 / 8.8.4.4) pour leur disponibilité et leur facilité de mémorisation. Adaptez selon votre politique IT.

4. Configuration du pare-feu (firehol)

Editez la configuration par défaut :

 nano /etc/default/firehol

Changez :

START_FIREHOL=NO

START_FIREHOL=YES

Mettez à jour la liste des adresses réservées :

get-iana

Puis éditez la configuration principale :

nano /etc/firehol/firehol

Pour un serveur minimalisant la surface d’attaque, acceptez uniquement les connexions entrantes SSH (port 22) et laissez les sorties illimitées :

server ssh accept

Démarrez firehol :

 firehol start

Vous devriez voir :

Activating new firewall (47 rules): OK

Listez les règles si souhaité :

 iptables --list

Important : adaptez la politique selon vos besoins ; en production vous voudrez probablement restreindre les sorties et autoriser d’autres services internes.

5. Installation de FreeNX

FreeNX est disponible via un dépôt PPA pour Ubuntu. Installez avec :

add-apt-repository ppa:freenx-team
aptitude update
aptitude install freenx
/usr/lib/nx/nxsetup --install

Après /usr/lib/nx/nxsetup –install, FreeNX installe les clés et la configuration par défaut.

Pour une sécurité renforcée, vous pouvez générer des clés personnalisées (paires RSA) et les distribuer aux clients : cela évite les clefs par défaut partagées entre installations. Si vous générez des clés, conservez-en une copie sécurisée.

6. Installation du client (NoMachine NX)

Sur un poste client, téléchargez le client NoMachine :

http://www.nomachine.com/download.php

Installez le package correspondant à votre OS. Au premier lancement, l’assistant de connexion apparait : donnez un nom à la session, l’adresse IP du serveur et le type de réseau (LAN, DSL, etc.).

Sous Ubuntu 9.10 l’environnement par défaut est GNOME : changez KDE en GNOME si nécessaire, ajustez la résolution, puis terminez. Si vous avez des clés personnalisées, activez l’option Advanced Configuration et importez la clé dans la section Server -> Key.

Connectez-vous avec un nom d’utilisateur et mot de passe du serveur. La première connexion demande d’accepter l’empreinte RSA — comparez-la avec celle notée plus tôt depuis ssh 127.0.0.1. Ne validez pas si l’empreinte change sans raison ; c’est un signal d’alerte.

7. Gestion des utilisateurs

Créez des comptes pour chaque utilisateur via System -> Administration -> Users and Groups. Pour un service multi-utilisateur, préférez des comptes non-administrateurs (UID standard) et gérons les privilèges via sudo si nécessaire.

Sécurité et bonnes pratiques

Important : toute exposition d’un serveur à Internet augmente la surface d’attaque. Appliquez des mesures de défense en profondeur.

Recommandations :

Mettre à jour les paquets et corriger les vulnérabilités dès que possible (aptitude update && aptitude upgrade).
Désactiver les accès root direct SSH si possible (config sshd_config PermitRootLogin no).
Utiliser l’authentification par clé publique pour SSH pour les administrateurs.
Restreindre l’accès SSH par adresse IP via firehol si possible.
Générer des clés FreeNX privées si le serveur est accessible depuis l’extérieur.
Surveiller les logs et configurer alertes (fail2ban, syslog centralisé).

Exemple rapide de configuration fail2ban basique (fichier /etc/fail2ban/jail.local) :

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
bantime = 3600

Cela bannit temporairement les IPs après 5 tentatives échouées.

Alternatives et contre-exemples

Quand FreeNX n’est pas adapté :

Réseau local très lent ou latence élevée : NX peut aider mais x2go ou protocoles spécifiques peuvent mieux compresser certains usages.
Besoin d’accès applicatif plutôt que de session graphique complète : envisagez des solutions d’application remoting ou terminal servers applicatifs.
Environnements Windows-first avec intégration Active Directory : RDP (Remote Desktop Protocol) avec broker et gateway peut être plus intégré.

Alternatives courantes :

VNC : simple mais gourmand en bande passante et moins sécurisé par défaut.
RDP : excellent pour Windows, bonnes performances, intégration AD.
x2go : basé sur NX mais activement maintenu et performant pour sessions X.

Modèle mental / heuristique

Pensez au serveur Terminal comme à un « poste central » :

sessions utilisateurs = processus côté serveur, ressources CPU/RAM partagées.
réseau = canal chiffré (SSH) entre client et serveur.
sécurité = verrouillage des accès réseau (firewall) + durcissement SSH + surveillance (fail2ban).

Si l’utilisation attendue est élevée (nombre d’utilisateurs simultanés), dimensionnez la RAM, le CPU et l’I/O disque en conséquence.

Niveaux de maturité d’un déploiement NX

Niveau 0 (banc d’essai) : 1 serveur, quelques utilisateurs, configuration par défaut.
Niveau 1 (département) : comptes utilisateurs distincts, firewall, fail2ban, clés personnalisées.
Niveau 2 (production) : monitoring, sauvegardes, réplication, plan de reprise, segmentation réseau.
Niveau 3 (critique) : HA, load balancing, audits réguliers de sécurité, gestion centralisée des clés et des accès.

Fiche technique (fact box)

Protocole de transport : SSH (port TCP 22 par défaut)
Logiciel serveur : FreeNX (implémentation open source de NX)
Client recommandé : NoMachine NX client (gratuit pour usage de base)
Systèmes clients supportés : Windows, macOS, Linux, Solaris
Configuration pare-feu recommandée : n’autoriser que le port 22 entrant pour NX

Guide pas-à-pas (SOP minimal pour mise en production)

Installer Ubuntu 9.10 et sécuriser le système (mises à jour et comptes).
Installer openssh-server, fail2ban et firehol.
Vérifier le fonctionnement SSH localement.
Configurer une IP statique ou réservation DHCP.
Configurer firehol pour n’autoriser que SSH entrant.
Ajouter le dépôt FreeNX et installer freenx.
Exécuter /usr/lib/nx/nxsetup –install et générer des clés si nécessaire.
Installer le client NoMachine sur postes utilisateurs et importer la clé si utilisée.
Créer comptes utilisateurs et vérifier les sessions simultanées.
Mettre en place monitoring et sauvegardes.

Template : configuration réseau d’exemple

Voici un modèle réutilisable (/etc/network/interfaces) adapté :

auto eth0
iface eth0 inet static
    address 192.168.1.253
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255
    gateway 192.168.1.1
    dns-nameservers 8.8.8.8, 8.8.4.4

Adaptez les adresses aux valeurs de votre réseau.

Template : règles firehol minimales

Fichier /etc/firehol/firehol (extrait minimal) :

version 6
interface any world
    policy drop
    server ssh accept
    client all accept

Cet exemple illustre une politique par défaut restrictive coté entrée et permissive pour les sorties. En pratique, définissez des règles plus fines selon vos besoins.

Runbook d’incident (connexion refusée / empreinte SSH modifiée)

Vérifier l’état du service SSH : systemctl status ssh ou /etc/init.d/ssh status.
Confirmer l’adresse IP et la route depuis le client (ping, traceroute).
Si l’empreinte SSH diffère de celle notée, ne vous connectez pas : considérez un MITM (man-in-the-middle).
En cas d’attaque brute force détectée, vérifiez /var/log/auth.log et les bans fail2ban : fail2ban-client status sshd.
Si nécessaire, désactiver l’accès externe temporairement en modifiant firehol et redémarrant : firehol stop; corriger et remettre firehol start.
Restaurer une sauvegarde de la configuration si corrompue.

Scénarios de test et critères d’acceptation

Tests à réaliser avant mise en production :

Test 1 : connexion locale SSH (ssh 127.0.0.1) retourne empreinte RSA (ok).
Test 2 : connexion NX depuis client LAN, session GNOME s’ouvre correctement et les entrées/sorties clavier/souris fonctionnent (ok).
Test 3 : essai d’accès externe bloqué si port non publié (ok) ; accès rétabli après NAT/port-forward (ok).
Test 4 : tentative d’authentification SSH avec mot de passe erroné > 5 fois => IP bannie par fail2ban (ok).
Critères d’acceptation : authentification réussie, empreinte vérifiée, firewall n’ouvre que le port 22, logs conformes et pas d’échec anormal.

Restauration et rollback

Gardez une copie des fichiers de configuration originaux (/etc/network/interfaces, /etc/firehol/firehol, /etc/ssh/sshd_config, /etc/fail2ban/jail.local).
Avant chaque modification critique, copiez :

cp /etc/ssh/sshd_config /root/sshd_config.bak.$(date +%F_%T)

En cas de panne, restaurez les fichiers et redémarrez les services :

cp /root/sshd_config.bak.YYYY-MM-DD_HH:MM:SS /etc/ssh/sshd_config
/etc/init.d/ssh restart
firehol restart

(adaptez la date du fichier de sauvegarde)

Liste de vérification par rôle

Administrateur système :

Installer et patcher le système.
Configurer SSH (désactiver root login, privilégier clés publiques).
Configurer firewall (n’autoriser que ce qui est nécessaire).
Gérer FreeNX keys et les distribuer de manière sécurisée.
Surveiller logs et alertes.

Administrateur réseau :

Réserver l’adresse IP ou noter la configuration statique.
Configurer NAT/port-forwarding si accès externe nécessaire.
Mettre en place segmentation réseau et DMZ si applicable.

Utilisateur final :

Installer le client NoMachine.
Importer la clé si fournie.
Ne pas divulguer ses identifiants.
Signaler toute empreinte SSH inattendue.

Confidentialité et conformité (notes GDPR)

Les sessions NX exposent l’environnement de bureau complet : évitez d’ouvrir des données sensibles si la politique locale l’interdit.
Assurez-vous que la conservation des logs et la gestion des comptes respectent la réglementation locale et la politique de confidentialité de votre organisation.

Compatibilité et migration

FreeNX pour Ubuntu 9.10 est basé sur des versions logicielles anciennes. Pour migrer, testez d’abord sur une VM et évaluez x2go ou NoMachine Enterprise si vous avez besoin d’une solution plus moderne et maintenue.

Annuaire de liens utiles

Ubuntu FreeNX Documentation
Firehol
Fail2ban
NoMachine

Résumé et recommandations finales

Trois conseils pratiques :

Vérifiez toujours l’empreinte SSH lors de la première connexion et enquêtez sur tout changement ultérieur.
Limitez l’exposition réseau : n’ouvrez que les ports indispensables et segmentez votre réseau.
Surveillez et automatisez les réponses (fail2ban, monitoring, sauvegardes) pour réduire le temps de rétablissement.

Merci d’avoir suivi ce guide. Si vous voulez, je peux générer des fichiers de configuration prêts à l’emploi ou un playbook Ansible pour automatiser ces étapes.

Comment configurer un serveur Terminal sous Linux avec Ubuntu 9.10 et FreeNX