Terminal server con Ubuntu 9.10 e FreeNX

Questo articolo guida passo passo la configurazione di un server terminal (thin‑client) su Ubuntu 9.10 usando FreeNX: installazione del sistema, requisiti minimi, rete statica, firewall con Firehol, installazione e hardening di FreeNX, configurazione client NoMachine e checklist di test e rollback. Segui le sezioni Sicurezza e Troubleshooting prima di esporre il servizio all’esterno.

Introduzione

Il paradigma desktop‑centrico ritorna spesso sotto forma di soluzioni thin‑client o terminal server. FreeNX replica il protocollo NX di NoMachine in versione open source. Rispetto al classico VNC, NX riduce l’uso di banda mantenendo una buona qualità visiva e reattività. Di default il traffico passa su SSH (porta 22), quindi le sessioni sono cifrate.

Definizione rapida: FreeNX — implementazione open source del server NX di NoMachine che fornisce remote desktop tramite SSH.

Perché usarlo: semplicità amministrativa, riuso di hardware obsoleto, controllo centralizzato delle sessioni, minore esposizione a malware rispetto a desktop distribuiti.

Nota importante: le istruzioni qui sotto sono state testate su Ubuntu 9.10. Alcuni comandi e pacchetti possono differire in versioni più recenti.

Sommario rapido dei contenuti

Requisiti e pacchetti necessari
Configurazione della rete con IP statico
Installazione e avvio di Firehol e fail2ban
Installazione e configurazione di FreeNX
Installazione e configurazione client NoMachine
Sicurezza, hardening e considerazioni di produzione
Test, playbook di deploy, rollback e check di accettazione

Requisiti di base

Hardware: un PC con risorse adeguate per il numero di sessioni concorrenti. Per uso domestico un desktop moderno va bene; per produzione calcola CPU, RAM e I/O disco in funzione degli utenti.

Software: Ubuntu 9.10 (Karmic Koala). Pacchetti principali: openssh-server, fail2ban, firehol, freenx (da PPA). Client: NoMachine NX Client su Windows/macOS/Linux.

Accesso: un account con privilegi sudo o accesso root.

Prima di iniziare: disclaimer e buone pratiche

Queste istruzioni funzionano nella mia esperienza. La sicurezza di rete è complessa: valuta firewall, segmentazione e procedure operative secondo le policy della tua organizzazione. Testa tutto in ambiente di staging prima di esporre il servizio in produzione.

Importante: Ubuntu 9.10 è una versione storica. Se stai pianificando rollout in produzione, considera una versione LTS supportata o una soluzione alternativa aggiornata.

Installazione del sistema operativo

Installa Ubuntu 9.10 seguendo una guida dedicata. Non ripetiamo i passaggi di installazione base qui. Consiglio di applicare gli aggiornamenti disponibili dopo l’installazione base.

Riferimento utile: https://www.howtoforge.com/the-perfect-desktop-ubuntu-9.10-karmic-koala

Prerequisiti software e primi comandi

Apri un terminale: Applicazioni -> Accessori -> Terminale.

Eleva i privilegi a root:

 sudo su -l

Aggiorna i repository e installa i pacchetti richiesti:

 aptitude update && aptitude install openssh-server fail2ban firehol

Verifica che il server SSH sia funzionante con un test locale (non proseguire la connessione):

 ssh 127.0.0.1

Dovresti vedere l’impronta RSA e la richiesta di connessione. Premi Ctrl‑C per uscire dopo aver annotato l’impronta. La confronteremo più avanti.

Configurazione rete: IP statico

Poiché si tratta di un server, è preferibile assegnare un IP statico. Puoi anche richiedere una prenotazione DHCP al server di rete.

Verifica le impostazioni correnti:

 ifconfig eth0
 cat /etc/resolv.conf
 route

Annota: IP, broadcast, netmask, nameserver e gateway.

Modifica il file delle interfacce:

 nano /etc/network/interfaces

Se trovi:

 iface eth0 inet dhcp

sostituiscilo o aggiungi la modalità statica:

 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

Usa i tuoi valori di rete. Suggerimento: i DNS pubblici di Google (8.8.8.8 e 8.8.4.4) sono spesso più veloci e affidabili rispetto a DNS ISP locali.

Riavvia la rete:

 /etc/init.d/networking restart

Controlla che la navigazione internet funzioni aprendo Firefox.

Configurazione firewall con Firehol

Abilita Firehol modificando il file di default:

 nano /etc/default/firehol

Cambia:

 START_FIREHOL=NO

in:

 START_FIREHOL=YES

Aggiorna la lista di indirizzi riservati IANA:

 get-iana

Esempio minimo di regola per consentire solo SSH in ingresso (porta 22) e tutto l’uscita:

 nano /etc/firehol/firehol

Aggiungi alla fine del file:

 server ssh accept

Avvia il firewall:

 firehol start

Dovresti vedere messaggi sullo stato, ad esempio “Activating new firewall (47 rules): OK”. Verifica le regole iptables se necessario:

 iptables --list

Note: personalizza le regole in base alle esigenze aziendali. Per servizi aggiuntivi apri le porte in modo esplicito.

Installazione di FreeNX

Aggiungi il PPA di FreeNX, aggiorna e installa:

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

Questa procedura installa i binari e genera le chiavi NX predefinite.

Se il server sarà accessibile dall’esterno, valuta la generazione di chiavi personalizzate e la loro distribuzione ai client. Le chiavi personalizzate migliorano la catena di fiducia ma richiedono gestione delle chiavi lato client.

Generazione e gestione chiavi NX (opzionale)

Generare chiavi personalizzate aumenta la sicurezza, ma devi distribuire la chiave pubblica ai client. Se decidi di rigenerare le chiavi NX, fai una copia di backup delle chiavi in un luogo sicuro.

Esempio (procedura generica):

 /usr/lib/nx/nxsetup --backup
 /usr/lib/nx/nxsetup --generate

Nota: i comandi e i percorsi possono variare. Documenta sempre dove hai salvato le chiavi.

Installazione client NoMachine (NX Client)

Sul client (Windows, macOS, Linux) visita: http://www.nomachine.com/download.php

Scarica e installa il client appropriato. Quando avvii il wizard di connessione NX:

Dai un nome alla sessione
Inserisci l’indirizzo IP del server
Seleziona la qualità di rete (es. LAN)
Nel pannello Desktop environment scegli Gnome se usi GNOME su Ubuntu 9.10 (di default il wizard può proporre KDE)

Se hai chiavi personalizzate, abilita la configurazione avanzata e importa la chiave nel tab Key.

Al primo accesso verrà mostrata l’impronta RSA del server. Confrontala con quella annotata dal test SSH locale e accetta se corrisponde.

Configurare utenti e permessi

Crea utenti locali per ogni persona che dovrà connettersi:

Sistema -> Amministrazione -> Utenti e gruppi

Oppure da terminale:

 adduser nomeutente

Per sessioni multi‑utente centralizzate valuta l’uso di LDAP o Active Directory in ambienti aziendali.

Test di funzionamento

Avvia una sessione NX dal client.
Confronta l’impronta RSA con quella annotata.
Verifica che desktop remoto si apra correttamente e che input e audio/video lavorino come atteso.
Prova trasferimento file (se necessario) e stampa remota.

Sicurezza e hardening consigliati

Cambia porta SSH se vuoi ridurre il rumore di scansione (ricorda di aggiornare Firehol/router). Tuttavia, la sicurezza principale resta l’autenticazione e la gestione delle chiavi.
Usa autenticazione a chiave pubblica per SSH dove possibile. Disabilita l’autenticazione password se i client lo supportano.
Configura fail2ban con regole per SSH/NX per bloccare tentativi di forza bruta.
Limita gli utenti autorizzati a connettersi via SSH tramite il parametro AllowUsers in /etc/ssh/sshd_config.
Imposta umask e profile utente restrittivi per ridurre rischio di escalation.
Monitora i log: /var/log/auth.log e log specifici di NX.
Se il server è esposto all’Internet, considera una DMZ o un jump host intermedio.

Esempi di snippet consigliati per /etc/ssh/sshd_config:

 PermitRootLogin no
 PasswordAuthentication no  # usa solo se hai chiavi pubbliche gestite
 AllowUsers amministratore alice bob
 PermitEmptyPasswords no
 X11Forwarding no

Dopo modifiche a sshd_config:

 /etc/init.d/ssh restart

Fail2ban: regole di esempio

Un’implementazione base di fail2ban aiuta a ridurre tentativi di accesso automatizzati. Configura jail per sshd e monitora i log.

Quando questa soluzione non è adatta (controesempi)

Ambienti che richiedono applicazioni a livello di kernel su client remoti.
Siti con requisiti di conformità che obbligano a VPN con autenticazione forte e audit completo: in alcuni casi una VPN gestita è preferibile.
Se hai banda uplink molto limitata e molte sessioni multimediali contemporanee.

Approcci alternativi

RDP (Remote Desktop Protocol): integrato in Windows, buone prestazioni su LAN, ma meno efficiente di NX su connessioni lente.
X2Go: alternativa open source a NX, buona compressione e supporto per sessioni multiple.
VNC: semplice ma meno efficiente sulla banda e meno sicuro se non incapsulato in SSH.

Maturità e compatibilità

FreeNX su Ubuntu 9.10 fornisce una soluzione matura per l’epoca, ma considera che 9.10 non riceve più aggiornamenti ufficiali. Valuta migration path verso distribuzioni supportate (es. Ubuntu LTS recenti) o soluzioni moderne come NoMachine Enterprise o X2Go per funzionalità e sicurezza aggiornate.

Playbook di deployment (SOP sintetico)

Preparazione server: installa Ubuntu e applica aggiornamenti.
Configura rete statica e DNS.
Installa openssh-server, fail2ban e firehol.
Configura Firehol per consentire solo porte necessarie (SSH in ingresso).
Installa FreeNX dal PPA: add-apt-repository, aptitude update, aptitude install freenx.
Esegui /usr/lib/nx/nxsetup –install e, se necessario, genera chiavi NX personalizzate.
Crea gli account utente e verifica sessioni locali.
Testa connessioni con client NoMachine.
Abilita monitoraggio dei log e backup delle chiavi.
Documenta la procedura di rollback.

Procedura di rollback rapida

Se l’installazione di FreeNX causa problemi: rimuovi il pacchetto e ripristina la configurazione di SSH e firewall.

Esempio:

 aptitude remove --purge freenx
 /etc/init.d/firehol restart
 /etc/init.d/ssh restart

Ripristina i file di configurazione da backup se necessario.

Test, criteri di accettazione e casi di prova

Casi di test essenziali:

Login remoto riuscito con credenziali valide.
Confronto impronte RSA corrispondente (verifica di sicurezza).
Avvio di un ambiente desktop Gnome stabile.
Apertura di applicazioni complesse (es. browser) e verifica latenza/interattività.
Test di riconnessione dopo caduta della rete.
Test di fail2ban: tentativi di login falliti devono portare al ban temporaneo.

Criteri di accettazione (esempi):

Il 100% dei tester autorizzati può connettersi e usare applicazioni di base.
Nessun accesso non autorizzato dopo 20 tentativi di forza bruta (blocked by fail2ban).
Tempo di risposta interattivo accettabile su LAN (soggettivo). Non fissare numeri non verificabili.

Checklist ruolo‑based

Amministratore di sistema:

Configurare firewall e fail2ban
Gestire chiavi NX/SSH
Monitorare log e aggiornamenti

Helpdesk:

Creare account utente
Fornire istruzioni di connessione ai client
Eseguire test di base e raccogliere log per escalation

Utente finale:

Ricevere file di configurazione per sessione NX
Seguire le istruzioni per importare chiave se fornita
Segnalare problemi con screenshot e descrizione dettagliata

Troubleshooting comune

Problema: il client mostra un avviso sull’impronta RSA che è cambiata.

Possibili cause: reinstallazione server, rigenerazione delle chiavi, attacco MITM.
Azioni: verifica fisica dell’impronta sul server, confronta con il backup, indaga prima di accettare il nuovo fingerprint.

Problema: nessuna connessione, timeout.

Controlla: stato servizio SSH (/etc/init.d/ssh status), regole Firehol, forwarding porta sul router se connesso dall’esterno.
Usa: telnet server-ip 22 o nmap per verificare porta.

Compatibilità e migrazione da Ubuntu 9.10

Ubuntu 9.10 è obsoleto. Per migrare:

Valuta una distribuzione LTS supportata (es. Ubuntu 20.04/22.04) o alternative aziendali.
Controlla disponibilità di FreeNX o sue alternative nei repository della nuova versione.
Pianifica migrazione di utenti e backup delle chiavi.

Consiglio operativo: testa la migrazione in laboratorio con un subset di utenti.

Privacy e conformità (note generali)

Tratta i dati degli utenti secondo le leggi locali (es. GDPR in Europa). Minimizza la memorizzazione di dati sensibili su server non adeguatamente protetti.
Documenta quali dati vengono trasferiti/archiviati durante le sessioni remote.

Glossario 1 riga

SSH: protocollo sicuro per shell remota e tunnel crittografati.
NX: protocollo per remote desktop efficiente in banda, tipicamente incapsulato in SSH.

Diagramma decisionale: devo esporre il server a Internet?

flowchart TD
    A[Devo esporre il server a Internet?] -->|Sì| B{Hai firewall e DMZ?}
    A -->|No| Z[Lascia in rete interna]
    B -->|Sì| C{Generi chiavi e distribuisci ai client?}
    B -->|No| Y[Configura DMZ / jump host prima]
    C -->|Sì| X[OK: limita accesso, monitora log]
    C -->|No| W[Non esporre: rischi di sicurezza]

Box dei fatti (senza numeri non verificati)

Porta di default usata: 22 (SSH).
FreeNX è un’implementazione open source del server NX.
Il traffico NX è tipicamente incapsulato in SSH e cifrato.
Client NoMachine è disponibile per Windows, macOS, Linux e Solaris.

Esempi di file e snippet utili

Esempio minimal /etc/network/interfaces (già mostrato sopra). Snippet essenziale sshd_config:

# Esempio minimal
 PermitRootLogin no
 PasswordAuthentication no
 AllowUsers amministratore alice

# Riavvia servizio dopo modifica
 /etc/init.d/ssh restart

Suggerimento per il deploy in azienda

Usa ambienti di staging per testare aggiornamenti.
Automatizza configurazioni con strumenti come Ansible/Puppet per coerenza.
Monitora risorse (CPU, memoria, I/O) e scala orizzontalmente dove necessario.

Annuncio breve (100–200 parole)

Ho configurato un server terminal su Ubuntu 9.10 con FreeNX per accedere ai desktop in modo centralizzato. Il server usa SSH per cifrare le sessioni, Firehol per il firewall e fail2ban per mitigare i tentativi di forza bruta. I client si collegano con NoMachine NX Client. Questa soluzione permette di riutilizzare hardware obsoleto, semplificare la gestione e ridurre la superficie d’attacco rispetto ai desktop distribuiti. Prima di esporre il servizio in produzione, applica le misure di hardening descritte (autenticazione a chiave pubblica, LimitUsers, monitoraggio log) e valuta la migrazione a una distribuzione supportata per un supporto a lungo termine.

Sintesi e passaggi successivi

Segui la playbook per la configurazione iniziale.
Applica le regole di sicurezza e test approfonditi.
Considera la migrazione da Ubuntu 9.10 a una versione supportata.

Grazie per aver letto. Se hai bisogno, posso fornire file di configurazione più dettagliati, template Ansible per automatizzare l’installazione o un runbook di incident response per NX.

Come configurare un terminal server in Linux con Ubuntu 9.10 e FreeNX