Collegarsi da fuori alla rete di casa? openVPN!

Ora che abbiamo parlato dei certificati possiamo cominciare ad utilizzarli; probabilmente questo utilizzo non è quello più semplice che una persona possa immaginare, ma sicuramente è uno di quelli che permette di capire le potenzialità offerte dalla struttura di certificati di tipo X.509.
Tralasciando la parte relativa alla creazione dei certificati che ormai è stata ampiamente trattata, vi annuncio solamente che l'autenticazione avviene attraverso i certificati X.509, quindi per il server e per ogni client sarà necessario avere a disposizione un certificato, garantito dalla propria CA, con la relativa chiave privata. Due comandi che potrebbero farvi comodo per abbreviare i processi di creazione dei certificati, in caso di creazioni massive, sono i seguenti (dovete posizionarvi all'interno della directory della CA):

• openssl req -new -keyout private/host-utente.unsec.key -out newcerts/host-utente.pem.csr -nodes -text -config ../openssl.conf -subj /"C=IT"/"ST=Provincia"/"L=Città"/"O=Organizzazione"/"OU=openVPN organizzazione"/"CN=utente"/"emailAddress=indirizzo di posta"/
• openssl ca -policy policy_anything -in newcerts/host-utente.pem.csr -out certs/host-utente.pem.crt -config ../openssl.conf -batch -days 1465

Ora veniamo alla parte più complessa, le configurazioni del server e dei client, ma prima di procedere vi devo descrivere la struttura di funzionamento su cui si basa openVPN (considerate che alcune assunzioni sono relative solamente alla mia metodologia di configurazione e vi sono altre possibilità):

• l'autenticazione avviene SOLAMENTE attraverso i certificati firmati dalla stessa CA;
• l'assegnazione degli indirizzi viene fatta in base al certificato presentato dal client, quindi se il file di configurazione per il client non è stato creato non è possibile collegarsi alla VPN perchè non viene assegnato l'indirizzo;
• la default route rimane quella presente anche prima dell'attivazione della VPN;
• solamente le macchine per cui viene specificato il routing sono raggiungibili (questo per limitare le possibilità di conflitto degli indirizzi).

A questo punto creiamo il file di configurazione del server che sarà /etc/openvpn/host-server.conf:
daemon
mode server
tls-server
dev-node /dev/net/tun
dev tun1194
proto udp
port 1194
tun-mtu 1250
ifconfig 10.0.0.1 10.0.0.2
client-config-dir /etc/openvpn/CN2ip
route 10.0.0.0 255.255.255.0
push "route 10.0.0.1 255.255.255.255"
client-to-client
dh /etc/openvpn/certs/dh1024.pem
ca /etc/ssl/YOUR_CA/CA.pem
cert certs/host-server.pem.crt
key certs/host-server.unsec.key
user nobody
group nogroup
persist-key
persist-tun
comp-lzo
keepalive 20 90
verb 1
log-append /var/log/openvpn/server.log
mssfix
Ora spiego i paratetri principali... il parametro daemon, mode server, tls-server e quelli realtivi al tun significano di eseguire openVPN come servizio, di abilitare le modalità server, di creare ed utilizzare utilizzare l'interfaccia tun1194 ed associargli l'mtu dichiarato.
I parametri proto, port, persist-key, persist-tun, comp-lzo e keepalive specificano il protocollo, la porta di servizio, la persistenza della chiave privata e dell'interfaccia tunnel (in caso di restart non vengono reiniziallate), la compressione ed il keepalive, ovvero ogni quanti secondi, dopo che non vi è traffico, inviare dei dati e quanto aspettare prima di riavviare il tunnel se non vi è risposta... parlando di standard imposti dallo IANA, openVPN è stato attestato sulla porta 1194 e con protocolli TCP/UDP. La scelta del protocollo può essere influenzata principalemente da due fattori, la facilità di attraversamento dei firewall per il protocollo UDP o la possibilità di utilizzare il protocollo TCP (modalità tcp-server/tcp-client) per tunnellizzare le connessioni (ad esempio tramite ssh).
I parametri ifconfig e route assegnano l'indirizzo ip e le informazioni di routing all'interfaccia rete creata, mentre client-to-client permette a client di vedersi a vicenda.
Le impostazioni scritte in formato push sono invece relative ai comandi da inviare indistintamente ad ogni client che si collega; siccome può capitare, e nel caso di indirizzo ip statico capita sicuramente, di dover inviare informazioni specifiche a client identificati, l'opzione che ci fa comodo è client-config-dir, e rappresenta il percorso in cui devono essere presenti i file con le configurazioni personalizzate. All'interno di questa directory, i file vengono collegati al loro destinatario attraverso il nome, questo deve essere lo stesso presente all'interno del CN ed in caso di spazi il carattere viene sostituito con l'underscore (_).
Ad esempio, se noi vogliamo che chi si presenta con un certificato valido con CN "Mario Bianchi" abbia un determinato indirizzo IP assegnato, dovremo creare il file /etc/openvpn/CN2ip/Mario_Bianchi con al suo interno i seguenti comandi:
ifconfig-push 10.0.0.14 10.0.0.13
# push "route 192.168.0.127 255.255.255.255" # Indirizzo da raggiungere attraverso la VPN
Ricordate che ogni client in connessione occupa una classe di tipo /30, ovvero ip di network, ip del client, ip del peer, ip di broadcast, quindi equivale dire 4 indirizzi ip... affinchè non vi siano errori di rete dovuti a sovrapposizioni, i client potranno solamente avere indirizzi ip 10.0.0.6, 10.0.0.10, 10.0.0.14...
Le opzioni ca, cert e key non dovrebbero aver bisogno di spiegazioni, sono i parametri relativi alla CA ed al certificato presentato dal server; l'unico parametro non noto e relativo alla crittografia è dh, che deve essere un file di tipo Diffie Hellman; per generarlo potete utilizzare il seguente comando:

• openssl dhparam 1024 > /etc/openvpn/certs/dh1024.pem

I parametri user, group, verb e log-append specificano le modalità con cui il tunnel deve funzionare, ovvero i permessi con cui girare e quante informazioni di debug devono essere presenti all'interno del file di log.
Ora, se avete terminato la configurazione e l'avete terminata in maniera corretta potete provare a vedere cosa succede avviando la openVPN con:

• /etc/init.d/openvpn restart

Se tutto ha funzionato ora avete un processo openVPN che è in esecuzione... adesso non rimane che configurare i client.
Il file di configurazione di un client è molto simile a quello per il server, ma mancano le informazioni per l'assegnazione dei parametri di rete che devono essere prelevate dal server, inoltre in genere la maggior parte dei client normalmente sono machcine windows, quindi file di configurazione con estensione ovpn, certificato e chiave saranno in un'unica cartella; un file di esempio è il seguente:
pull
tls-client
dev tun
proto udp
remote server-host port
remote server-ip port
tun-mtu 1250
resolv-retry infinite
nobind
ca ./hostCA.crt
cert ./host-nome.pem.crt
key ./host-nome.unsec.key
persist-key
persist-tun
ping 30
ping-restart 90
comp-lzo
mssfix
verb 1
Adesso vi spiego i nuovi parametri apparsi... pull e tls-client significano di richiedere le informazioni di configurazione al server ed il tipo di autenticazione utilizzata, remote è una lista di host/ip seguiti dalla porta che dovrebbe essere in ascolto a cui il client continuerà a provare a collegarsi all'infinito.
Siccome la maggior parte dei client saranno macchine windows (od almeno questa è la mia esperienza), affinchè il file di configuraizone venga riconosciuto come tale, deve avere estensione ovpn; inoltre, sotto windows, è molto più semplice mettere tutti i file relativi ad una VPN in una singola cartella (file.ovpn, file.unsec.key, file.crt e fileCA.crt) per non dover specificare percorsi assoluti che potrebbero cambiare con lo spostamento della directory.
Il parametro nobind impedisce ad openVPN di posizionarsi in ascolto, ma fa sì che la connessione alla VPN venga solamente tentata e non attesa, mentre ping e ping-restart fanno sì che avvenga un ping ogni tot secondi e se non si riceve risposta il tunnel viene reinizializzato.
Ultima cosa da notare... non c'è l'informazione relativa al file di log, sappiate che se abilitate il log su file non sarete più in grado di vederlo a video se siete su di una macchina windows.
Direi che a questo punto potete provare la connessione da un client, ricordatevi che il certificato della CA deve essere presente assieme ai file relativi al client, questo perchè openVPN controlla che il server sia effettivamente colui che ci si aspetta e quindi il suo certificato deve essere firmato dalla stessa CA.
Con questo penso di aver trattato tutto il minimo necessario per fare una VPN con determinate caratteristiche; la configurazione di esempio che ho utilizzato è quella che utilizzo più spesso dato che consente di vincolare univocamente un indirizzo IP ad un determinato certificato, sappiate che comunque è possibile creare una VPN in maniera che chiunque si presenta con un certificato valido riceva un indirizzo come se fosse presente un DHCP. Di sicuro cercando su internet troverete molte informazioni più dettagliate ed altre modalità di funzionamento, ma il mio voleva essere solamente un vademecum di come mettere su una VPN, in maniera veloce ed indolore, con autenticazione tramite certificati ed indirizzi ip statici.

Creare i certificati X.509

Bene, ora è giunto il momento di creare la nostra gerarchia di certificati, ma prima di fare questo guardiamoci un attimo attorno per capire come funzionano le cose fatte dai grandi gestori... se prendessimo come esempio le CA riconosciute ufficialmente, osserveremmo che loro richiedono solamente la richiesta di certificato, a cui applicano la firma, per poter poi restituire il certificato; questo viene fatto ai fini di sicurezza dato che voi, i proprietari della chiave privata, volete che NESSUNO sia in grado di venire a conoscenza dei dati che transitano; logicamente se generassero loro la vostra richiesta di certificato, avrebbero generato anche la chiave privata, e quindi la conoscerebbero; inoltre ve la dovrebbero trasmettere, esponendo la chiave privata a possibili sguardi inopportuni e riducendo largamente la sicurezza del sistema creato.
Nel nostro caso le cose si semplificano di molto dato che do per assunto una situazione prestabilita (che riduce altamente la sicurezza in caso di compromissione del server, ma non facendo transazioni bancarie lo ritengo un rischio accettabile): la chiave privata verrà utilizzata da servizi presenti sulla stessa macchina che gestisce la CA, quindi entrambe le chiavi possono risiedere a bordo di questa e gli unici occhi che le possono leggere sono i nostri (sempre che abbiate protetto bene il server).
Per generare la coppia di chiavi, ovvero la chiave privata e la richiesta di certificato (che contiene quella pubblica), eseguire la firma con la CA ed ottenere quindi il certificato, si può utilizzare il seguente script in /etc/*/makeCert.sh:

#!/bin/bash

# Script per la creazione della coppia chiavi pubblica/privata, per la generazione della richiesta di certificato, per la firma della richista trmaite la CA e per la generazione del certificato.
function newCert {
echo -n "Vuoi generare una chiave privata senza password? (s/N) ";
read ANS;
case ${ANS} in
"S"|"s"|"Y"|"y") echo "Attenzione, la chiave privata sara' leggibile da chiunque!";
openssl req -config ${opensslConf} -new -text -nodes -keyout ${CApath}/private/${NOME}.key -out ${CApath}/certs/${NOME}.pem.req;
;;
"N"|"n"|"") echo "Attenzione, ad ogni accesso alla chiave privata si dovra' fornire la password!";
openssl req -config ${opensslConf} -new -text -keyout ${CApath}/private/${NOME}.key -out ${CApath}/certs/${NOME}.pem.req;
echo "Per la rimozione della password usare il seguente comando: openssl rsa -in ${CApath}/private/${NOME}.key -out ${CApath}/private/${NOME}.unsecure.key";
;;
esac;
}
opensslConf=$(find /etc -iname openssl.cnf|sort|head -1);
CApath=$(grep "^[[:space:]]*dir[[:space:]]*=" ${opensslConf} | sed "s/.*=\s\+//" | awk '{print $1}');
if [ "$1" == "" ]; then
echo "La sintassi del comando e' $0 <nome_cert>";
exit -1;
fi;
NOME=$1;
if [ -s "${CApath}/newcerts/${NOME}.pem.crt" ]; then
echo "E' gia' presente il certificato ${CApath}/certs/${NOME}.pem.crt, vuoi rinnovarlo revocandolo ed emettendone uno nuovo [s/N]? ";
read ANS;
case ${ANS} in
"S"|"s"|"Y"|"y") echo "Verra' ora revocato il certificato";
openssl ca -config ${opensslConf} -revoke ${CApath}/newcerts/${NOME}.pem.crt
;;
"N"|"n"|"") echo "Si e' deciso di non revocare il certificato precedente, si potra' proseguire solamente sovrascrivendo i vecchi dati, ricordati che non puoi avere certificati con CN uguali.";
;;
esac;
unset ANS;
fi;
if [ -s "${CApath}/certs/${NOME}.pem.req" -o -s "${CApath}/private/${NOME}.key" ]; then
echo "E' gia' presente la richiesta di certificato ${CApath}/certs/${NOME}.pem.crt, vuoi sovrascriverla [s/N]? ";
read ANS;
case ${ANS} in
"S"|"s"|"Y"|"y") echo "La richiesta di certificato e le relative chiavi verranno sovrascritte.";
newCert;
;;
"N"|"n"|"") echo "Si e' deciso di non sovrascrivere la vecchia richiesta, impossibile proseguire.";
exit -1;
;;
esac;
unset ANS;
else
newCert;
fi;
OLD_UMASK=`umask`;
umask 77;
openssl ca -config ${opensslConf} -policy policy_anything -days 730 -out ${CApath}/newcerts/${NOME}.pem.crt -infiles ${CApath}/certs/${NOME}.pem.req;
chmod a+r ${CApath}/newcerts/*;
umask ${OLD_UMASK};

Dopo tutta questa sbrodolata di codice io sono esaurito, anche perchè lo scrivevo assieme al post e mentre facevo le prove; inoltre penso che se è la prima volta che vi avvicinate ad openssl abbiate le idee molto confuse... tranquilli, è normale. Negli script riportati in precedenza ci sono molti concetti sul funzionamento di openssl, su di alcuni schemi condizionali e sulle nomenclature (scelte da me con una certa logica); uno dei concetti più importanti che ci sono, riguarda il campo CN (Common Name) di un certificato: questo deve essere univoco all'interno di una CA, quindi se avete già emesso un certificato con quel CN è obbligatorio lo revochiate per poterne emettere un altro, anche se questo è già scaduto.
Con questo direi che la trattazione sembra abbastanza esaustiva o comunque sufficiente per rendervi operativi... ricordate che il CN è il campo fondamentale del vostro certificato, e deve contenere l'host, l'ip o l'indirizzo email, relativi al tipo di dati che si vuole proteggere.

Certification authority? Certo, sulla Linux Box

Benissimo, se siete qui a leggere vuole dire che vi servivano informazioni su questo argomento, oppure vi sono piaciuti i post precedenti... io spero la seconda, logicamente per soddisfare un po' il mio ego.
Ora veniamo a noi ed alla breve spiegazione teorica... quando si parla di garantire trasmissioni sicure, si vuole ottenere un sistema che sia in grado di realizzare uno o più dei seguenti requisiti:

• riservatezza/confidenzialità;
• integrità;
• autenticità;
• non ripudio.

Lo scopo viene ottenuto grazie all'utilizzo della crittografia con il sistema delle chiavi pubblica/privata. Questo sistema viene realizzato attraverso i certificati X.509, che realizzano una struttura gerarchica, con sviluppo ad albero, i cui elementi sono legati tramite un rapporto di fiducia, ovvero il "padre" garantisce che i suoi "figli" sono coloro che dicono di essere (autenticità), mentre le parti di integrità, riservatezza e non ripudio sono garantite dalla crittografia legata all'utilizzo delle due chiavi. Logicamente, come dicono i nomi, la chiave pubblica può e deve essere distribuita per poter stabilire se un determinato messaggio è firmato dalla relativa chiave privata o, nel caso di utilizzo della crittografia, per poter crittografare il messaggio che verrà poi decifrato attraverso l'uso della chiave privata. Dietro a tutto questo ci sono molti concetti matematici, che se volete potete cercare e studiare, ma questo esula sicuramente da quello che voglio dirvi.
La parte pratica viene gestita nella seguente maniera:

1. Il figlio genera la richiesta di certificato.
2. Il padre firma la richiesta di certificato del figlio, tramite un certificato valido.
3. La richiesta di certificato firmata diventa certificato e viene assegnato al figlio.
4. Chiunque riconosce l'autorità del padre, automaticamente riconosce anche quella del figlio.

Chi ha spirito pratico, in tutto questo si sarà accorto di una cosa, e si chiederà: "e chi ha firmato il certificato del padre? il nonno? e chi quello del nonno?" e così via. Logicamente qui ci troviamo al discorso del "è nato prima l'uovo o la gallina?", ma la risposta è molto più semplice: il primo certificato si chiama self-signed, ovvero è un certificato autofirmato in cui il firmatario garantisce di essere chi dice di essere. Da un certificato di questo tipo possiamo far nascere la nostra CA, ovvero una certification authority, i cui "figli" saranno riconosciuti da chi ha considerato autorevole il certificato del padre, ovvero quello originario della nostra CA.
La gestione dei certificati all'interno di una linux box ricopre una parte vastissima perchè riguarda tutte le comunicazioni che si vogliono rendere sicure, e pensando alla sicurezza, sono aspetti imprescindibili e molto profondi, quindi conviene impararla velocemente, mettendo i puntini sulle "i" fin dall'inizio ed apprendendo tutto quello che serve. Il mio scopo è darvi delle brevi e semplici informazioni e molti dei comandi utili sotto forma di script, questo al fine di aiutarvi ad addentrarvi in openssl da subito... logicamente, come il solito, dove non arrivano le mie spiegazioni ci arriveranno quelle di qualcun altro che ha scritto un help, un howto o della documentazione varia resa disponibile attraverso internet.
Passando alla configurazione pratica, prima di tutto ci serve installare l'ambiente ed i comandi che ci serviranno per la nostra CA, quindi:

• aptitude install openssl;

A questo punto a livello di comandi e configurazione avremo tutto quello che ci serve, ora dobbiamo solamente personalizzarlo modificando il file openssl.cnf (normalmente in /etc/ssl o /etc/pki/tls per le distribuzioni basate su RedHat) affinchè rispecchi i propri bisogni... io utilizzo i seguenti parametri (in Debian):

• dir = /etc/ssl/YOUR_CA
• private_key = $dir/private/cakey.unsec.pem # se la chiave non ha password
  
• private_key = $dir/private/cakey.pem # se la chiave ha password
• countryName_default = IT
• stateOrProvinceName_default = Turin
• localityName_default = Turin
• 0.organizationName_default = YOUR organization
• organizationalUnitName_default = host.domain from YOUR_CA
• commonName = Common Name (eg, YOUR name as host or IP)
• emailAddress_default = YOUR email address
• challengePassword_default = longpasswordyouwant

Questi parametri presuppongono alcune strutture che io do per scontate nelle mie configurazioni e sono:

• i percorsi a cui si fa riferimento in /etc/*/openssl.cnf sono di tipo assoluto;
• la struttura della CA è locata all'interno di una directory del tipo /etc/*/CA;
• il file openssl.cnf è nella stessa directory in cui vi è la CA;
  
• il nome della CA viene utilizzato anche per il nome del certificato;
• gli hash del certificato della CA vengono messi in /etc/*/certs.

A questo punto dobbiamo creare una struttura che ci permetta di svolgere i ruoli di una CA, ovvero coppia di chiavi pubblica/privata, un percorso in cui andare a salvare le richieste di certificato per elaborarle e trasformarle in certificato ed alcuni file necessari per la gestione "logica" della CA, compresa la CRL (Certificate Revocation List).
Il seguente script, da mettere in /etc/*/makeCA.sh, attingendo dai parametri immessi in openssl.cnf, prepara la struttura necessaria ad ospitare la CA.

#!/bin/bash

# Script per creazione della CA
opensslConf=$(find /etc -iname openssl.cnf|sort|head -1);
dir=$(grep "^[[:space:]]*dir[[:space:]]*=" ${opensslConf} | sed "s/[[:space:]]*dir[[:space:]]*=[[:space:]]*\([^[:space:]]*\)[[:space:]]*.*/\1/");
certificate=$(grep "^[[:space:]]*certificate[[:space:]]*=" ${opensslConf} | sed -e "s/[[:space:]]*certificate[[:space:]]*=[[:space:]]*\([^[:space:]]*\)[[:space:]]*.*/\1/" -e "s|\$dir|$dir|");
private_key=$(grep "^[[:space:]]*private_key[[:space:]]*=" ${opensslConf} | sed -e "s/[[:space:]]*private_key[[:space:]]*=[[:space:]]*\([^[:space:]]*\)[[:space:]]*.*/\1/" -e "s|\$dir|$dir|");
mkdir -pm 755 ${dir};
mkdir -pm 755 ${dir}/{certs,crl,newcerts};
mkdir -pm 700 ${dir}/private;
touch ${dir}/index.txt;
touch ${dir}/private/.rand;
echo 01 > ${dir}/serial;
echo -n "Vuoi generare una chiave privata senza password? (s/N) ";
read ANS;
case ${ANS} in
"S"|"s"|"Y"|"y") echo "Attenzione, la chiave privata sara' leggibile da chiunque!";
openssl genrsa -out ${private_key} 2048;
;;
"N"|"n"|"") echo "Attenzione, ad ogni accesso alla chiave privata si dovra' fornire la password!";
openssl genrsa -des3 -out ${private_key} 2048;
echo "Per la rimozione della password usare il seguente comando: openssl rsa -in ${private_key} -out ${private_key}.unsec";
;;
esac
openssl req -config ${opensslConf} -new -x509 -key ${private_key} -out ${certificate} -text -days 2922;
hash=$(openssl x509 -noout -in ${certificate} -hash);
ln -sf ${certificate} $(dirname ${dir})/$(basename ${dir}).crt;
ln -sf ${certificate} $(dirname ${dir})/certs/${hash}.0;

Ora la nostra CA è pronta a fare il suo dovere e mancano solamente più i certificati "figli".
Per scoprire come creare e gestire i certificati continuate a seguirmi, e vi fornirò le informazioni necessarie ad essere operativi... alla prossima!

E' ora del fax server... hylafax per tutti

Eccoci ad una nuova puntata... nell'ultima abbiamo configurato un modem per la nostra Linux Box, in questa ci occuperemo di farlo funzionare come fax, rendendo la nostra stazione un fax server che ci permetterà di inviare/ricevere fax senza il bisogno o l'obbligo di stamparli.
Il programma che andremo ad utilizzare è hylafax, ma questo ha bisogno anche di altri servizi dato che si appoggia alla posta elettronica, quindi per installarlo avremo bisogno di fornire anche un server smtp, ed io come preferenza scelgo postfix, quindi useremo il seguente comando:

• aptitude install hylafax-server postfix

Il server di posta elettronica, per semplificare la configurazione, lo abilitiamo solamente per un funzionamento locale e quindi durante l'installazione vengono fatte altre poche domande e semplici, tipo il nome della macchina su cui girerà. La configurazione di entrambi i pacchetti verrà avviata automaticamente, ma se avessimo bisogno di rieseguirla dovremo digitare:

• dpkg-reconfigure postfix;
• dpkg-reconfigure hylafax-server;

Il file attraverso il quale si decide se avviare hylafax al boot è /etc/default/hylafax.
Per avviare la configurazione del server hylafax, e specificare il modem ed i parametri di comunicazione, si devono eseguire i seguenti comandi:

• faxaddmodem;
  
• faxsetup;

Al termine della configurazione, dopo aver fornito le risposte ad un sacco di domande (per la maggior parte vanno bene i valori di default), in /etc/hylafax saranno presenti tutti i file di configurazione, editabili anche a mano.
Le impostazioni importanti per utilizzare il nostro device come fax, riguardano la composizione, ovvero le dialstring... una serie di parametri corretti da avere all'interno del file /etc/hylafax/config.porta sono:

• CountryCode: 39
• AreaCode: 012
• FAXNumber: "+39 012 3456789"
• LongDistancePrefix: 0
  
• InternationalPrefix: 00
• RecvFileMode: 0644
• LogFileMode: 0644
  

Due parametri che possono essere molto utili per identificare possibili problematiche riguardano le opzioni di tracing, ovvero i parametri SessionTracing e ServerTracing; valori più alti corrispondono ad un incremento del livello di verbosità (se vi serve modificarli cercate informazioni su internet per conoscere i valori esatti a cui impostarli).
Se vengono fatte delle modifiche ai file di configurazione ricordate sempre di riavviare hylafax:

• /etc/init.d/hylafax restart

A questo punto il nostro fax server è pronto a spedire e ricevere fax, ma manca ancora una configurazione, molto importante per la fruibilità del server, ovvero la gestione degli utenti; gli utenti vengono gestiti con il comando "faxadduser -p password nome_utente" che permette di aggiungere un utente ed assegnargli una password. All'interno di /etc/hylafax/hosts.hfaxd, ogni linea di testo contiene delle credenziali di accesso che possono essere fatte in base al nome, all'host di provenienza e/o alla password; per i pattern riconosciuti viene fatto un matching seguendo le regexp.
La sintassi del file è la seguente:

• client:uid:passwd:adminwd

Client è un'espressione regolare che deve matchare una sintassi del tipo "user@host", in cui host è una stringa oppure un indirizzo ip; per compatibilità con i vecchi formati, se client non contiene @, viene trattato come un host dal quale qualunque username si può collegare, come se fosse stato scritto "^.*@client$client$". L'uid è un valore numerico assegnato ai client per l'accesso (normalmente non viene utilizzato nelle configurazioni base). La password criptata è rappresentata dal campo passwd, se il campo è vuoto l'utente accede senza credenziali. Il campo adminwd contiene la password criptata per l'accesso ai privilegi amministrativi.
Adesso che abbiamo configurato il modem, il fax server è up e gli utenti sono definiti... non ci rimane che scaricare ed installare un client per Hylafax (sotto windows io mi trovo molto bene con Winprint Hylafax che installa una stampante virtuale) e cominciare a far le prove di invio.

Altri file di configurazione molto importanti sono:

• /etc/hylafax/config è il file di configurazione per il processo di scheduling faxq;
• /etc/hylafax/hfaxd.conf è il file di configurazione per hfaxd che si occupa di gestire le comunicazioni client-server; c'è da prestare attenzione al fatto che le comunicazioni di questo tipo seguono uno schema simile all'ftp, quindi in caso di problemi legati a nat presenti, è necessario utilizzare il modulo iptables connection tracking in questa maniera: insmod ip_conntrack_ftp ports=21,4559;
  
• /etc/hylafax/hosts.hfaxd contiene gli utenti abilitati all'accesso al sistema.

Interazione con il mail server
Come detto all'inizio, Hylafax ricerca anche un programma di posta per essere in grado di comunicare con i mail server; questo è dovuto al fatto che i fax in ingresso possono essere indirizzati verso delle caselle di posta elettronica, l'esito dei fax in uscita viene inviato a caselle di posta elettronica ed è possibile inviare dei fax mandando una mail con allegato il documento da faxare ed il numero telefonico relativo, logicamente in un formato prestabilito.
Per eseguire la consegna automatica dei fax ricevuti è necessario creare il file /etc/hylafax/FaxDispatch e mettere al suo interno:

• FILETYPE=pdf|ps|tif;
• SENDTO=address@domain.ext;

Nel caso ci siano dei problemi con i file in formato binario (tif e pdf), sarà necessario aggiungere il percorso di uuencode:

• MIMENCODE=/usr/bin/uuencode;

Informazioni per il debug
Quando si inviano dei fax, questi vengono posti in coda; per controllare la lunghezza della coda si deve utilizzare il comando faxstat -s. A questo comando corrisponde un output con la coda dei job presenti e lo stato; nel caso volessimo forzare una schedulazione in maniera immediata possiamo farlo con il comando: faxalter -A -v -a now JobID
La directory di lavoro di hylafax è /var/spool/hylafax, al suo interno sono presenti vari cartelle; all'interno di sendq sono presenti i fax in uscita, in doneq sono presenti i fax inviati, in recvq sono presenti i fax ricevuti, in docq ci sono i fax in formato postscript in attesa di invio e questa cartella normalmente viene pulita dal comando faxqclean.

Configurazione di un modem/fax PCI sulla Linux box

I moduli disponibili su Debian per far funzionare i modem/fax PCI sotto linux sono: slmodem e martian-modem.
Tutta questa parte non è necessaria nel caso in cui disponiate di un modem seriale classico in quanto le porte seriali in linux sono già presenti ed accessibili.
Non curerò i particolari riguardo ai modem supportati perchè sono troppi e diversi, su internet ci sono molte informazioni che potrete trovare in base al chipset del vostro modem (lo scoprirete leggendo l'integrato presente sulla scheda e l'output del comando lspci -vvnn che contiene l'identificativo PCI); i siti principali sono http://www.linmodems.org/ e http://www.linuxant.com/. C'è un programma che aiuta nell'identificazione del modem ed è scanModem.
Le istruzioni coprono l'installazione di entrambi i driver, in questa maniera potrete provarli entrambi ed attivare solamente quello che vi serve, disinstallando eventualmente l'altro. Siccome sono dei driver "software", per entrambi sono disponibili gli script di avviamento a livello di servizio ed avviati al boot.
Partiamo con l'installazione dei pacchetti necessari:

• aptitude install martian-modem-source sl-modem-source sl-modem-daemon martian-modem minicom

Ora proseguiamo con la compilazione e l'installazione dei driver:

• m-a build martian-modem-source sl-modem-source
• m-a install martian-modem sl-modem

Per conoscere i device PCI supportati da ciascun modulo si possono usar ei seguenti comandi:

• modinfo slamr;
• modinfo martian_dev;

Ed infine decidiamo quale avviare attraverso la configurazione con rcconf, ricordandosi anche di aggiungere il modulo in /etc/modules nel caso non venisse caricato dal suo script di avviamento.
Per testare il funzionamento dei driver con il nostro device, dovremo utilizzare minicom, che è il software per stabilire connessioni con il modem. Per il suo utilizzo dobbiamo configurarlo con minicom -s e dirgli quale porta utilizzare, la velocità e le stringhe di inizializzazione, in seguito salvarlo come configurazione dfl. Se volete, per i test, potete abilitare alzare il volume dello speaker del modem ed abilitarlo durante la fase di connessione con questi comandi modem: ATL3M1.
Una lista dei comandi possibili per le stringhe di inizializzazione è disponibile all'indirizzo http://michaelgellis.tripod.com/modem.html.

Se utilizziamo sl-modem, avviandolo con /etc/init.d/sl-modem-daemon restart, verrà creato automaticamente anche /dev/modem che è un link al device /dev/ttySL0 (che punta a /dev/pts/2).

Se utilizziamo martian_dev abbiamo il file di configurazione relativo in /etc/default/martian-modem che decide come verrà chiamato il link al dispositivo.

Sa avete un modem con chipset Ambient MD3200 è equivalente all'Intel 537EP ed è utilizzabile anche come FXO per asterisk. Il sito di riferimento per i driver è http://www.x9000.fr/Intel/. Io sono riuscito a compilare i driver per l'utilizzo di minicom, ma non riuscivo a farlo comporre; per utilizzarlo come FXO, tramite zaptel, sembra non siano necessari driver (http://www.alfersoft.com.ar/blog/2008/11/01/asterisk-pbx-with-x100p-clone-part-1-installation/).

Io avevo questi modem e per quelli in cui ho specificato i driver sono riuscito a controllare che venissero rilevati, ma non ho approfondito il funzionamento di quelli che non erano sl-modem o martian-modem:

• 00:0e.0 Modem [0703]: Motorola SM56 Data Fax Modem [1057:3052] (rev 04) (prog-if 00 [Generic]) <-> sl-modem
• 00:0e.0 Modem [0703]: ALi Corporation SmartLink SmartPCI561 56K Modem [10b9:5459] (prog-if 00 [Generic]) <-> sl-modem
  
• 00:0d.0 Communication controller [0780]: Agere Systems LT WinModem [11c1:044c] (rev 02) <-> martian-modem
• 00:0e.0 Communication controller [0780]: Tiger Jet Network Inc. Tiger3XX Modem/ISDN interface [e159:0001] <-> driver per Intel 537
• 00:0e.0 Communication controller [0780]: Rockwell International HSF 56k Data/Fax/Voice/Spkp (w/Handset) Modem [127a:2015] (rev 01) <-> driver HSF linuxant
• 00:0e.0 Communication controller [0780]: Ambient Technologies Inc HaM controllerless modem [1813:4000] (rev 02) <-> probabilmente non funziona sui kernel 2.6.x
• 00:0e.0 Communication controller [0780]: Conexant Systems, Inc. SoftV92 SpeakerPhone SoftRing Modem with SmartSP [14f1:2f30] (rev 01) <-> driver HSF linuxant

SSH, difendersi da attacchi brute force ed autenticazione con certificati

L'ultima volta ci siamo lasciati dopo aver securizzato, nel migliore dei modi possibile per un'autenticazione basata su utente e password, il nostro server SSH.
Le nostre debolezze erano intrinseche al sistema di autenticazione utente/password in caso di attacchi di tipo brute force che lavorano per tentativi; qualche possibilità di difesa aggiuntiva la possono offrire sistemi alternativi, basati sull'individuazione di questo tipo di attacchi in maniera da poter prendere delle misure difensive.
Ve ne elenco alcuni: pam_tally, sshguard o sistemi di port knocking.
Io non li ho mai configurati, ma mi sono fatto uno script che opera in maniera simile ad alcuni di questi. Il sistema per tutti è simile, indiduare n tentativi di accesso falliti e bloccare momentaneamente, o definitivamente, l'utente tramite il pam o la sorgente tramite iptables. Il mio script ad esempio ogni ora verifica se ci sono attacchi in corso e se li trova blocca quell'indirizzo tramite iptables in maniera permanente.
Se però vogliamo parlare di securizzazione "profonda", possiamo solamente basarci sull'utilizzo dei certificati; grazie a questo sistema non si utilizzano più utente e password per autenticarsi, ma tutto avviene automaticamente grazie ai certificati ed un sistema di autenticazione dato da chiave pubblica e privata.
Ricordate che hardening dei servizi e facilità di utilizzo spesso sono parole inversamente proporzionali, quindi più è sicuro il vostro server e più sarà complesso il sistema da utilizzare per collegarvici (in questo caso dovrete sempre avere con voi la chiave privata per potervi autenticare).
Il principio di funzionamento ed i file interessati sono i seguenti (prendo in considerazione solamente i percorsi di default):

• /etc/ssh/sshd_config (configurazione del server ssh)
  
• ~/.ssh/authorized_keys - la chiave pubblica viene inserita all'interno della home directory dell'utente remoto che si va ad impersonificare e qualunque utente presenti la chiave privata viene autorizzato all'accesso grazie al riconoscimento dato dal legame matematico che esiste tra queste due;
• ~/.ssh/id_rsa - la chiave privata rimane al client, risiede nella home directory dell'utente locale che si collega verso il server ssh;
• file.ppk (chiave privata dell'utente se macchina Windows con Putty).

Nel caso non sia presente il file ~/.ssh/authorized_keys nella directory dell'utente remoto lo si deve creare a mano con i seguenti comandi:

• cd ~
• mkdir -pm 700 .ssh
• touch ~/.ssh/authorized_keys
• chmod 600 ~/.ssh/authorized_keys

La parte fondamentale riguarda la creazione delle chiavi pubblica e privata, che in caso di macchina linux è molto semplice ed è riassumibile con i seguenti comandi:

• ssh-keygen -t rsa -f ~/.ssh/id_rsa
• ssh-copy-id -i /home/utente/.ssh/id_rsa utente@ssh_server
• ssh -p 2222 utente@ssh_server
• se tutto ha funzionato ed il server era già abilitato per l'utilizzo dei certificati vi siete collegati senza digitare utente e password, diversamente controllate il contenuto del file con le chiavi pubbliche (cat .ssh/authorized_keys) e verificate che il file di configurazione contenga le seguenti linee, altrimenti aggiungetele e riavviare ssh (è necessario essere root):
  RSAAuthentication yes
  PubkeyAuthentication yes
  

A questo punto l'autenticazione tramite certificati dovrebbe essere funzionante, testatela e verificate che non vi venga chiesto niente e che riusciate a collegarvi, potete procedere a disabilitare quella eseguita tramite utente e password in maniera che non sia più possibile un attacco di tipo brute force.
La diabilitazione del login classico avviene aggiungendo le seguenti linee nel file di configurazione:

• ChallengeResponseAuthentication no
• PasswordAuthentication no
• UsePAM no

Dopo aver riavviato il servizio ssh, se provate un login senza presentarvi con una chiave privata corretta, non potrete più collegarvi alla vostra Linux Box ricevendo un bel:
Permission denied (publickey).
Nel caso di utilizzo di Windows invece si deve utilizzare PUTTYgen per generare una coppia di chiavi e salvarla. In seguito editare manualmente il file ~/.ssh/authorized_keys presente nella home directory dell'utente remoto con cui ci si vuole autenticare ed inserire all'interno di questo la stringa presente nella text box e che comincia con "ssh-rsa". A questo punto il procedimento rimane poi identico, con la differenza che si deve dire a Putty di utilizzare il file poco prima salvato come chiave privata e gli si deve anche impostare l'utente di default per la connessione.
A questo punto, se avete seguito tutti i suggerimenti, la connessione con la nostra Linux Box dovrebbe essere molto sicura, non dico impenetrabile perchè nel campo della sicurezza non esiste mai niente di sicuro e nessun sistema è invulnerabile.

Configurare un server SSH

Il primo servizio da fornire, in ordine logico, è un servizio che permetta di potersi collegare alla Linux Box senza bisogno di essere localmente presenti o di avere una tastiera ed un monitor collegati direttamente al computer; questo lo si fa perchè una Linux Box normalmente non deve svolgere funzioni da desktop, ma funzioni da server, e quindi deve essere possibile "imboscarla" in luoghi in cui non da fastidio o dove occupa poco spazio.
La modalità di collegamento "primordiale" si chiamava telnet daemon e permetteva a chiunque di collegarsi alla macchina in oggetto, le stringhe digitate, come quelle di risposta generate dal computer, venivano scambiate attraverso un canale dedicato (socket tcp); questo scambio di dati veniva fatto in chiaro e quindi tutto quello che transitava (compresi utenti e password) era visibile attraverso particolari procedure (sniffing). Per ovviare a questo problema è nato ssh, che si occupa di crittografare il traffico rendendo inutile i tentativi di sniffing.
I passi per eseguire l'installazione e la configurazione del sistema, con uno stile molto schematico, sono i seguenti:

1. prima di tutto è necessario installare il servizio:
   aptitude install openssh-server (Debian)
   yum install openssh-server (Fedora)
2. assicurarsi che il servizio venga avviato con la macchina:
   update-rc.d ssh defaults (Debian)
   chkconfig sshd on (Fedora)
3. modificare il file di configurazione per i propri scopi:
   vi /etc/ssh/sshd_config
4. riavviare il servizio dopo ogni modifica al file di configurazione:
   /etc/init.d/ssh restart (Debian)
   /etc/init.d/sshd restart (Fedora)

Ora veniamo ad una serie di consigli e considerazioni sulla configurazione del servizio... siccome vi sono persone che sono molto interessate a poter usufruire di macchine al di fuori delle proprie mura casalinghe per poter sopperire a bisogni più o meno leciti, le prime attenzioni vanno poste alla securizzazione del servizio, giusto per tentare di non essere facile preda di cracker. Qui di seguito alcuni semplici consigli preliminari:

• utilizzare una porta diversa dalla 22;
• abilitare solamente host ed utenti considerati "sicuri";
• disabilitare la possibilità di accesso come root;
• abilitare solamente l'autenticazione tramite certificati.
  

Siccome non è per niente difficile creare dei programmi o script per tentare il brute force di utenti e password, l'unico problema del cracker rimane individuare un server, attività facilmente eseguibile tramite dei port scanning, conviene cambiare alcuni parametri di default del file di configurazione /etc/ssh/sshd_config.
La prima operazione, e più semplice, è cambiare la porta di default, riducendo già di molto il numero di persone in grado di individuare il vostro ssh in ascolto e riducendo di conseguenza il numero degli attacchi ricevuti. Considerate che spostare il servizio sulla porta 443 affinchè sia facilmente raggiungibile da reti aziendali attraversando firewall e proxy senza grossi problemi, non vi salva dalle scansioni; molti cracker conoscono questo trucco e sanno che le probabilità di trovare degli ssh su quella porta non sono così remote. Per modificare la porta di default, all'interno del file di configurazione dovrete avere una linea del tipo:

• Port 2222

La sicurezza dell'autenticazione si basa su due parametri, nome utente e password; se uno dei due è noto la facilità di un attacco brute force aumenta di molto le possibilità di riuscita. Per ovviare a questo problema è possibile disabilitare il login dell'utente root, sicuramente presente su ogni macchina, impostandolo a no o a without-passoword (autenticazione permessa solamente con un certificato valido); inoltre si possono autorizzare o negare (la negazione ha la precedenza in caso di "conflitto") l'accesso a determinati utenti o gruppi e/o specificare le sorgenti da cui è possibile collegarsi o meno. Come esempio vi riporto alcune possibili linee di configurazione con i parametri che stabiliscono queste opzioni all'interno del file di configurazione:

• PermitRootLogin without-password
• DenyGroups group1 group2
• AllowGroups group3
• DenyUsers root user1@192.168.*.*
• AllowUsers user1 user2@192.168.*.* user3@*.domain.org

Per rendere un sistema molto più sicuro, evitando di basare l'autenticazione sulla sola conoscenza di dati riservati, ma spostandola a dati che si "hanno" e non facilmente riproducibili, la via più sicura è quella di lasciare abilitata solamente l'autenticazione tramite certificati. Questo tipo di autenticazione è altamente sicura in quanto si basa sulla crittografia a chiave pubblica, ma siccome questo sistema presuppone delle modifiche alla configurazione abbastanza importanti, lo tratteremo in un altro post.
Sperando di essere riuscito a condensare l'enorme mole di concetti e possibilità in questo post, vi aspetto per leggere i prossimi.

Installazione di una linux box con Debian

Questo è l'inizio di una serie di post dedicati alla configurazione dei servizi che possono essere forniti da una Linux box, servizi che rimangono visibili solamente a voi, gestiti da voi ed il cui accesso può essere demandato solamente da voi; è anche l'unico motivo per cui preparare un computer dedicato all'utilizzo da remoto, altrimenti potrebbe bastare un'installazione desktop di GNU Linux per sfruttare servizi forniti da altri server, magari su internet.
Bene, ora possiamo cominciare a pensare a preparare la Linux Box secondo i nostri gusti... essendo una Linux Box assumo che vogliate un'installazione testuale, da eseguire su di un vecchio hardware da imboscare in qualche angolo della casa dove arriva solamente una presa elettrica ed una di rete.
Il sistema operativo che utilizzeremo al nostro scopo è la Debian, scaricabile liberamente da http://www.debian.org attraverso diversi sistemi (HTTP/FTP, BitTorrent o Jigdo). Qui troviamo le immagini di installazione della distribuzione definita "stable", questa contiene pacchetti molto conservativi, definiti altamente stabili e molto sicuri (quindi software in circolazione già da un po' di tempo); normalmente è più che sufficiente non volendo interfacce grafiche all'ultimo grido, ma se si vogliono servizi nuovi e molto recenti è necessario migrare alla versione "testing" od "unstable".
Io considero che siate in grado di ottenere un'installazione minimale del sistema, e se non lo siete ci sono un sacco di ottimi tutorial, ovvero qualcosa di perfettamente funzionante ed autonomo, che garantisce le funzioni minime per l'accesso al computer e lo svolgimento delle operazioni di base, possiamo cominciare a pensare ai servizi che potrebbero esserci utili e che potremmo utilizzare da remoto; ricordate di operare sempre come utente "normale" ed utilizzare l'utente root solamente in caso di bisogno.
Se volete/dovete passare ad una distribuzione di tipo testing (software recente, stabile e che ha quasi terminato il ciclo di test per la sicurezza) od unstable (software all'ultimo grido di cui si sa poco o niente), dovete andare ad editare il file di configurazione che si occupa di gestire gli aggiornamenti, ovvero /etc/apt/sources.list e mettere, al posto del nome della distribuzione o della parola stable, la parola testing od unstable... io per ottenere un buon compromesso in genere utilizzo la versione testing per i file binari e la unstable per i sorgenti, in questa maniera è più semplice accorgersi se qualcosa non va o mancano le dipendenze fin dall'inizio.
Se volete automatizzare e scegliere i mirror più veloci disponibili potete utilizzare il comando netselect-apt, questo scarica una lista di mirror e li testa per vedere quale offre migliore velocità... io non ho ancora indagato se per migliore intende con il minor tempo di risposta o con la maggior banda.
La lista dei comandi necessaria per estrarre i dati che ci itneressano sono dati dai seguenti comandi (il significato delle opzioni controllatelo nell'help):

• aptitude install netselect-apt;
• netselect-apt -n --outfile best.list testing;
• cat best.list >> /etc/apt/sources.list;
• vi /etc/apt/sources.list;

Una volta modificate le impostazioni sulla versioni è necessario aggiornare l'elenco dei pacchetti disponibili, ed eventualmente il sistema intero, con i seguenti comandi:

• aptitude update;
• aptitude dist-upgrade;

si aggiorneranno un sacco di pacchetti se avete cambiato la versione e magari vi verranno chieste delle conferme, anche complesse, sulle configurazioni, ma avendo un sistema base senza personalizzazioni potete accettare tutto senza problemi.
Come detto prima abbiamo una distribuzione molto "base" a cui manca qualunque cosa supplementare... quindi, anche in caso di richieste complesse sulle configurazioni da attuare, potete sempre installare le versioni più recenti, non preoccupandovi di quello che era presente nel sistema.
Io in genere voglio sempre poter compilare tutto senza problemi, quindi preparo l'ambiente di compilazione, compreso quello per i moduli del kernel, con i seguenti comandi:

• aptitude install module-assistant;
• m-a prepare;

Siccome per alcuni aspetti mi piace lavorare "comodo", installo sempre Midnight Commander, un clone di Norton Commander che risale ai tempi del Dos, il comando less per visionare i file, le psmisc per il controllo dei processi e rcconf, per stabilire i servizi da avviare all'interno del sistema... il comando necessario è: aptitude install less mc psmisc rcconf.
A questo punto è pronto un ambiente base con doti di compilazione, potrete scaricare pacchetti sorgenti, moduli aggiuntivi del kernel e compilarli... se però ci fossero dei problemi di compilazione le cose si complicheranno, ma se siete già a quel punto probabilmente le mie informazioni molto probabilmente sono superflue perchè sapete già dove andare a cercare.
Adesso manca un'ultima precisazione... ricordate che le parole "servizi" e "da remoto" devono farvi accendere una lampadina perchè sono strettamente legate ad un concetto indissolubile: la sicurezza; se non ci occupiamo di quest'ultima chiunque sarà in grado di fare le nostre stesse operazioni, amministrando servizi a sua discrezione, o, nel caso peggiore, il computer completo e lo potrà fare con qualunque scopo a noi sconosciuto.

Una linux box per SmanettoneX

Forse adesso vi sembrerà più chiara la motivazione della X finale, è uno storpiamento fatto pensando a Linux; probabilmente fosse stato libero l'host losmanettone.blogger.com non mi sarei posto il problema, ma vedendo che qualcuno era già passato per creare un blog morto dopo poco, ho dovuto adattarmi ed accontentarmi degli host liberi che rimanevano... comunque direi che non posso ritenermi insoddisfatto.
Come potreste aver intuito dal post sulla favola di Linux, o dal titolo di questo post, io sono un grande simpatizzante, utilizzatore, supporter e, quando mi riesce, sviluppatore di questo sistema operativo.
Le motivazioni che possono portare una persona al suo utilizzo sono molteplici... partendo dalla filosofia ed ideologia collegata al progetto fino agli aspetti pratici e/o economici. Di svantaggi per una scelta di questo tipo non ne ho trovati, software free o proprietario presuppongono che le persone vengano comunque formate al suo utilizzo e quindi l'unica necessità che si ha è di investire del tempo nell'apprendimento e nella comprensione del software per poterlo utilizzare al meglio; la complessità del software free potrebbe essere leggermente superiore in quanto si tende ad avere un'attenzione inferiore ai fronzoli, ma si bada molto al contenuto ed alle funzionalità.
Io Linux ho cominciato ad usarlo in ambito tecnico universitario, durante la tesi, e durante questo primo contatto ho percepito molto chiaramente le difficoltà presenti per chi era cresciuto con il Dos, ma che si era poi lasciato andare a Windows... a quei tempi l'ambiente era prevalentemente testuale, i comandi erano di base ed i sistemi di funzionamento erano completamente diversi, le interfacce grafiche erano poco sviluppate, poco personalizzabili e molto complesse da usare e configurare... Allo stato attuale sembra di vivere in un altro pianeta grazie alle migliorie apportate, le interfacce sono molto user friendly e gli installer sono alla portata della maggior parte delle persone.
La spinta per continuare ad usarlo ed adottarlo come se fosse un figlio molto promettente sono state le avanzate possibilità di funzionamento che mi venivano fornite, il vasto parco software in continuo ampliamento, l'elevata affidabilità e la possibilità di adattarlo perfettamente alle proprie esigenze grazie alle molte informazioni reperibili su internet. L'avere gratis tutto quello che mi serviva senza infrangere la legge era poi una soddisfazione immensa!
Da allora posso dire che non sono più riuscito a stare senza un computer che avesse GNU Linux a bordo e le mie preferenze si sono affinate sfociando in due diversi ambiti a seconda dello scopo da raggiungere:
- Debian per i sistemi server;
- Fedora per i sistemi desktop.
Ora mi considero un utEntE, sempre affiancato dalla sua Linux Box raggiungibile da ovunque e con tutti i servizi ritenuti indispensabili a bordo, e non un utOntO che effettua le sue scelte perchè non ha la voglia ed il tempo di imparare, capire e sperimentare le nuove frontiere della tecnologia, con software sempre tecnologicamente avanzato e sviluppato al fine di produrre un valore aggiunto in ogni ambito.
Adesso che sapete le potenzialità di un sistema come Linux potreste decidere di provarlo se le mie parole hanno risvegliato il vostro interesse... allora cosa aspettate? Ah, dimenticavo, non usate scuse del tipo "ma il mio computer è vecchio" perchè con Linux configurato come ambiente server (quindi testuale) si possono tranquillamente riutilizzare hardware molto vecchi ed ormai obsoleti per gli altri sistemi operativi di nuova generazione.
Per farvi un'idea di cosa si possa fare con una Linux Box continuate a leggermi, ho in mente di scrivere dei post sulle configurazioni dei servizi più complessi e lunghi.