Attacchi di forza bruta, come "Crack" o "John the Ripper" (si veda la Sezione 6.9) possono spesso indovinare la password se non è abbastanza casuale. I moduli PAM (vedi sotto) permettono di usare una diversa routine crittografica per le proprie password (MD5 o simili). Si potrebbe anche usare Crack a proprio vantaggio. Si esegua periodicamente Crack sul database delle password, per trovare quelle insicure. Poi si contatti l'utente in questione e gli si faccia cambiare password.
Si può visitare http://consult.cern.ch/writeup/security/security_3.html per avere informazioni su come scegliere una buona password.
Ci sono vantaggi in entrambi i metodi di crittografia, e si possono scoprire queste differenze nelle FAQ della RSA sulla crittografia, citata alla fine di questa sezione.
PGP (Pretty Good Privacy) è ben supportata da Linux. Le versioni 2.6.2 e 5.0 funzionano bene. Per una buona introduzione a PGP e a come usarlo, si dia un'occhiata alla FAQ di PGP: http://www.pgp.com/service/export/faq/55faq.cgi
Ci si assicuri di usare la versione valida per il proprio stato. A causa dei limiti di esportazione del governo USA, è proibito portare fuori dagli USA ogni forma di crittografia elettronica.
I controlli sull'esportazione dagli USA sono ora gestiti dall'EAR (Regole di Amministrazione dell'Esportazione). Non sono più gestite dall'ITAR.
C'è anche una guida passo-passo per configurare PGP su Linux presso http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/article7.html. È scritta per la versione internazionale di PGP, ma è facilmente adattabile alla versione USA. Si potrebbe aver bisogno di una patch anche per alcune recenti versioni di Linux; la patch è disponibile presso ftp://metalab.unc.edu/pub/Linux/apps/crypto.
C'è un progetto che lavora ad una versione libera e open source di PGP. GnuPG è un sostituto completo e libero per PGP. Visto che non usa IDEA o RSA può essere usato senza restrizioni. GnuPG aderisce a OpenPGP. Si veda il sito di GNU Privacy Guard per avere più informazioni: http://www.gnupg.org/.
Ulteriori informazioni sulla crittografia si trovano nella FAQ della RSA sulla crittografia, disponibile presso http://www.rsa.com/rsalabs/newfaq/. Qui si troveranno informazioni su termini come "Diffie-Hellman", "crittografia a chiave pubblica", "certificati digitali", ecc.
SSL: - SSL, o Secure Sockets Layer (Layer di Socket Sicuri), è un metodo crittografico sviluppato da Netscape per dare sicurezza su Internet. Supporta diversi protocolli crittografici, e fornisce autenticazione del client e del server. SSL opera sullo strato di trasporto, crea un canale di dati sicuro e crittografato e può quindi crittografare dati di molti tipi. Ciò si nota soprattutto quando si visita un sito sicuro con Communicator ed è la base di tutte le comunicazioni sicure con esso, oltre che con altro software Netscape. Ulteriori informazioni si trovano presso http://www.consensus.com/security/ssl-talk-faq.html. Informazioni su altre forme di sicurezza di Netscape e un buon punto di partenza su questi protocolli sono disponibili presso http://home.netscape.com/info/security-doc.html. È importante notare che il protocollo SSL può essere usato per passare molti altri protocolli comuni, "incapsulandoli" per sicurezza. Si veda: http://www.quiltaholic.com/rickk/sslwrap/
S-HTTP: - S-HTTP è un altro protocollo che fornisce servizi di sicurezza su Internet. È stato progettato per dare privacy, autenticazione, integrità e per impedire scambi di persona, supportando contemporaneamente meccanismi di controllo con chiavi multiple e algoritmi crittografici attraverso la negoziazione di opzioni fra le parti coinvolte in ogni transazione. S-HTTP è limitato al software specifico che lo implementa, e crittografa ogni messaggio individualmente. (Dalla FAQ della RSA sulla crittografia, pagina 138)
S/MIME: - S/MIME, o Secure Multipurpose Internet Mail Extension (Estensione Multiuso Sicura per la Posta via Internet), è uno standard crittografico usato per la posta elettronica e altri tipi di messaggi su Internet. È uno standard aperto sviluppato da RSA, quindi probabilmente lo vedremo presto su Linux. Altre informazioni su S/MIME si trovano presso http://home.netscape.com/assist/security/smime/overview.html.
Oltre a CIPE, e altre forme di crittografia, ci sono anche molte altre implementazioni di IPSEC per Linux. IPSEC è un tentativo della IETF di creare comunicazioni crittograficamente sicure al livello della rete IP e di fornire autenticazione, integrità, controllo di accesso e privacy. Informazioni su IPSEC si trovano presso http://www.ietf.org/html.charters/ipsec-charter.html. Si troveranno anche link ad altri protocolli, una mailing list di IPSEC e degli archivi.
L'implementazione Linux di x-kernel, che viene sviluppata all'Università dell'Arizona, usa una struttura basata su oggetti per implementare protocolli di rete detti x-kernel, e si trova presso http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html. Più semplicente, l'x-kernel è un metodo per passare messaggi al livello del kernel, il che rende l'implementazione più facile.
Un'altra implementazione liberamente disponibile di IPSEC è FreeS/WAN. Sul loro sito si legge: "Questi servizi vi permettono di creare tunnel sicuri attraverso reti inaffidabili. Ogni cosa che passa per la rete inaffidabile è crittografata dalla macchina gateway IPSEC e decrittografata dal gateway all'altro capo. Il risultato è una Virtual Private Network (Rete Privata Virtuale) o VPN. È una rete che rimane privata nonostante includa macchine connesse attraverso l'insicura Internet."
È scaricabile presso http://www.xs4all.nl/~freeswan/, ed ha appena raggiunto la versione 1.0 al momento della scrittura.
Come per altre forme di crittografia, non è distribuita col kernel di default a causa di restrizioni di esportazione.
Ci sono diverse implementazioni ssh al momento. Quella commerciale originale di Data Fellows si trova nella homepage di ssh presso http://www.datafellows.com.
L'eccellente implementazione Openssh è basata su una delle prime versioni ssh di Data Fellows ed è stata completamente ricostruita per non includere alcuna parte proprietaria o brevettata. È libera e sotto licenza BSD. Si trova presso: http://www.openssh.com.
Esiste anche un progetto open source per reimplementare ssh da zero chiamato "psst...". Per ulteriori informazioni si veda: http://www.net.lut.ac.uk/psst/
Si può anche usare ssh dalla vostra workstation Windows verso un server ssh Linux. Ci sono diversi client liberi per Windows, incluso quello presso http://guardian.htu.tuwien.ac.at/therapy/ssh/ oltre ad una versione commerciale di DataFellows, presso http://www.datafellows.com.
SSLeay è una versione libera del protocollo di Netscape Secure Sockets Layer, sviluppato da Eric Young. Include diverse applicazioni, come Secure telnet, un modulo per Apache, diversi database, oltre a molti algoritmi inclusi DES, IDEA e Blowfish.
Usando questa libreria è stato creato un sostituto sicuro per telnet che usa la crittografia per la connessione. A differenza di SSH, stelnet usa SSL, il protocollo di Netscape. Si può trovare Secure telnet e Secure FTP iniziando con la FAQ di SSLeay, disponibile presso http://www.psy.uq.oz.au/~ftp/Crypto/.
SRP è un'altra implementazione sicura di telnet/ftp. Dalla loro pagina web:
"Il progetto SRP sta sviluppando software sicuro per Internet per l'uso libero in tutto il mondo. Iniziando con una distribuzione del tutto sicura di telnet e FTP, speriamo di soppiantare i deboli sistemi di autenticazione con forti sostituti che non sacrifichino la facilità d'uso per la sicurezza. La sicurezza dovrebbe essere lo standard, non un'opzione!"
Per ulteriori informazioni si visiti http://www-cs-students.stanford.edu/~tjw/srp/
Le ultime versioni delle distribuzioni Red Hat Linux e Debian Linux sono distribuite con uno schema di autenticazione unificato detto "PAM". PAM permette di cambiare i vostri metodi e requisiti di autenticazione al volo, e di aggiornare di conseguenza tutti i metodi di autenticazione senza ricompilare alcun binario. La configurazione di PAM trascende gli scopi di questo documento, ma ci si assicuri di dare un'occhiata al sito web di PAM per altre informazioni. http://www.kernel.org/pub/linux/libs/pam/index.html.
Solo alcune delle cose che si possono fare con PAM:
Usare crittografia non-DES per le password. (Rendendole più difficili da decodificare con la forza bruta.)
Impostare limiti alle risorse degli utenti perché non possano attuare attacchi di denial-of-service (numero di processi, quantità di memoria, ecc.)
Abilitare le shadow passwords (vedi sotto) al volo
Permettere a singoli utenti di accedere solo ad ore precise da posti precisi
Nel giro di poche ore dall'installazione e configurazione del vostro sistema, si possono prevenire molti attacchi. Per esempio, si può usare PAM per impedire l'uso nel sistema di file .rhosts nella home directory degli utenti aggiungendo queste linee a /etc/pam.d/rlogin:
# # disabilita rsh/rlogin/rexec per gli utenti # login auth required pam_rhosts_auth.so no_rhosts |
Riassumendo la documentazione CIPE:
Ulteriori informazioni possono essere trovate presso http://www.inka.de/~bigred/devel/cipe.html
Come per altre forme di crittografia, non è distribuita di default con il kernel a causa di restrizioni di esportazione.
Si possono trovare ulteriori informazioni su Kerberos leggendo le FAQ di Kerberos, inoltre si può reperire il codice presso http://nii.isi.edu/info/kerberos/.
[Da: Stein, Jennifer G., Clifford Neuman, e Jeffrey L. Schiller. "Kerberos: An Authentication Service for Open Network Systems." USENIX Conference Proceedings, Dallas, Texas, Winter 1998.]
Kerberos non dovrebbe essere il primo passo nel miglioramento della sicurezza del proprio host. Porta a molte conseguenze e non è usato quanto, per esempio, SSH.
Le shadow password sono un mezzo per tenere segrete agli utenti normali le password crittografate. Le ultime versioni di RedHat e Debian Linux usano di default le shadow password, ma in altri sistemi le password crittografate sono tenute in /etc/passwd dove tutti possono leggerle. Quindi chiunque potrebbe eseguire su di loro programmi che tentino di indovinare quali sono. Al contrario, le shadow password sono salvate in /etc/shadow, che solo gli utenti privilegiati possono leggere. Per usare le shadow password ci si deve assicurare che tutte le applicazioni che devono leggere le password siano ricompilate per supportarle. PAM (vedi sopra) invece permette di installare semplicemente un modulo shadow; non richiede la ricompilazione degli eseguibili. Si può fare riferimento allo Shadow-Password HOWTO per ulteriori informazioni se necessario. È disponibile presso http://metalab.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html È abbastanza datato al momento, e non è necessario per le distribuzioni che supportano PAM.
Esistono moltissimi programmi di questo tipo... i due più degni di nota sono "Crack" e "John the Ripper" (http://www.openwall.com/john/). Usano moltissimo la cpu, ma, eseguendoli, si può capire se possono trovare le password e si potranno quindi avvertire gli utenti con password deboli. Si noti che un intruso dovrebbe prima riuscire a trovare qualche altro buco per leggere il vostro /etc/passwd ma questi buchi sono più comuni di quanto pensiate.
Poichè la sicurezza è forte soltanto quanto il più insicuro degli host, è bene ricordare che se si hanno macchine Windows sulla rete dovreste controllare L0phtCrack, una versione Windows di Crack. È disponibile presso http://www.l0pht.com
CFS è un modo per crittografare interi alberi di directory e dare modo agli utenti di salvare al loro interno file crittografati. Usa un server NFS eseguito sulla macchina locale. Gli RPM sono disponibili presso http://www.zedz.net/redhat/, e troverete altre informazioni su come funziona presso ftp://ftp.research.att.com/dist/mab/.
TCFS migliora CFS aggiungendo più integrazione con il file system. Ulteriori informazioni sono presso: http://www.tcfs.it/.
Inoltre non serve che sia usato su interi file system. Funziona anche su alberi di directory.
Quando si usa xdm per entrare, si ha un metodo di accesso molto migliore: MIT-MAGIC-COOKIE-1. Un "cookie" a 128 bit viene creato nel file .Xauthority. Se si deve permettere che una macchina remota acceda al display, si può usare il comando xauth e le informazioni nel file .Xauthority per dare accesso solo a quella connessione. Si legga il Remote-X-Apps mini-howto, disponibile presso http://metalab.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html.
Si può anche usare ssh (si veda la Sezione 6.4, sopra) per permettere connessioni a X sicure. Ciò ha il vantaggio anche di essere trasparente per l'utente finale, e comporta che nessun dato non crittografato passi per la rete.
Si possono anche impedire connessioni remote al server X usando l'opzione '-nolisten tcp' del server X. Questo previene connessioni di rete al server tramite socket tcp.
Si dia uno sguardo alla pagina man di Xsecurity per avere più informazioni sulla sicurezza di X. La via sicura è usare xdm per entrare nella console e quindi usare ssh per eseguire programmi X su macchine remote.
Il progetto Linux GGI sta tentando di risolvere i diversi problemi delle interfacce grafiche di Linux. GGI sposterà una piccola parte del codice video nel kernel di Linux e quindi controllerà direttamente l'accesso al sistema video. Questo significa che GGI potrà ripristinare la console in ogni momento. Inoltre permetterà di usare una chiave sicura, per poter essere certi che non c'è alcun cavallo di Troia che manometta il programma login della console. http://synergy.caltech.edu/~ggi/