Sicurezza¶
Nel momento stesso in cui mettete una macchina in internet con alcune porte aperte sapete per certo che sarà oggetto di ogni possibile attacco. Spesso i nostri server funzionanao anche da firewall in situazioni “piccole”, ovvero di poche macchine.
In queste occasioni le fonti più comuni di debolezze sono:
- ssh tramite account troppo semplici (password banali)
- apache tramite applicazioni poso sicure
per quanto riguarda il primo punto è facile mettere la macchina in sicurezza con ben poca fatica, tramite l’uso delle chiavi crittografiche.
Accedere al server tramite SSH usando le chiavi¶
Accedere remotamente al proprio server mediante l’utilizzo delle chiavi crittografiche aumenta la sicurezza del proprio server, rendendo inutile, ad esempio, la quasi totalità dei tipi di attacco di tipo dizionario o brute force.
Per le delucidazioni circa il concetto di “chiave di criptazione” si rimanda al seguente indirizzo: http://it.wikipedia.org/wiki/Crittografia_asimmetrica
Configurazione del server OpenSSH¶
Senza dilungarci troppo in trattazioni sulla sicurezza, si suggerisce l’adozione dei seguenti accorgimenti, considerati ragionevole compromesso tra “paranoia” e usabilità.
- disattivazione dell’accesso tramite password.
- attivazione dell’accesso esclusivamente tramite chiavi.
- disattivazione dell’accesso diretto al sistema da parte di root ( sarà comunque accessibile grazie al comando su - ).
Per ottenere tutto ciò, sarà sufficiente assicurarsi che le direttive del proprio /etc/ssh/sshd.conf siano così configurate:
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
PermitRootLogin no
Generazione ed aggiunta delle chiavi utente sul server¶
Autenticarsi con il proprio utente per generare la coppia di chiavi pubblica/privata:
utente1@srv-isi:~$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (~utente1/.ssh/id_dsa): <INVIO> Created directory '~utente1/.ssh'. Enter passphrase (empty for no passphrase): <PASSWORD PER LA CHIAVE> Enter same passphrase again: <PASSWORD PER LA CHIAVE> Your identification has been saved in ~utente1/.ssh/id_dsa. Your public key has been saved in /home/users/admins/utente1/.ssh/id_dsa.pub. The key fingerprint is: 20:d6:94:95:cf:59:a8:81:f0:e4:1e:98:98:47:54:71 utente1@srv-isi cp .ssh/id_dsa.pub /tmp chmod a+r /tmp/id_dsa.pub
Aggiungere la chiave pubblica generata nel file authorized_keys dell’utente da controllare( utente2):
su utente2 <PASSWORD utente2>
Ci si assicuri che la directory .ssh esista:
cd ls .ssh
Se non dovesse essere presente, si provveda a crearla:
mkdir .ssh
Sarà ora possibile aggiungere la propria chiave pubblica, precedentemente copiata in /tmp
cat /tmp/id_dsa.pub >> .ssh/authorized_keys
Nota
Il file authorized_keys contiene le chiavi pubbliche degli utenti abilitati ad accedere remotamente, via ssh e senza password, all’account dell’utente. Modificando tale file con un editor di testo si potranno rimuovere le chiavi pubbliche aggiunte in precedenza, impedendo alle relative utenze di accedere senza password con il nostro utente.
Testare che tutto funzioni, autenticandosi come utente1 e cercando con esso di accedere, via ssh, all’account utente2:
utente1@srv-isi:~$ ssh -l utente2 127.0.0.1 Enter passphrase for key '/home/users/admins/utente1/.ssh/id_dsa': <PASSWORD DELLA CHIAVE PRIVATA> utente2@srv-isi:~$
Aggiunta di un demone ssh secondario¶
Per ragioni di sicurezza, siamo soliti configurare il server openssh affinchè permetta il solo accesso via chiavi, impedendo così l’uso delle password. Purtroppo questa politica mal si sposa con il sistema di autenticazione pensato dal progetto LTSP. LDM infatti utilizza le password credenziali fornite dall’utente in fase di login autenticare l’utente sul server via ssh. Appare dunque chiaro come il metodo di autenticazione via password di ssh sia indispensabile per LDM. La soluzione che abbiamo pensato di adottare è stata quella di creare un servizio ssh ssh secondario, in ascolto sulla porta 23, con una configurazione dedicata che permetta la sola autenticazione via chiavi. L’ultimo tassello rimane la configurazione del firewall, affinchè tutte le richieste provenienti dall’interfaccia esterna vengano ridirette dalla porta 22 alla porta 23.
Per monitorare meglio i processi e non rischiare eventuali problemi con l’annotazione dei pid è necessario avere due eseguibili distinti. Creiamo quindi un collegamento simbolico “/usr/sbin/sshd-external” che punti al binario originale
ln -s /usr/sbin/sshd /usr/sbin/sshd-external
Creiamo i file di configurazione che userà il nostro nuovo demone partendo a partire da quelli originali
cp /etc/ssh/ssh_config /etc/ssh/ssh_config-external
cp /etc/ssh/sshd_config /etc/ssh/sshd_config-external
cp /etc/init.d/ssh /etc/init.d/ssh-external
Sostituendo poi tutte le occorrenze di “sshd” con sshd-external, dovreste ottenere i seguenti file risultanti :
Creiamo poi /etc/default/ssh-external
cp /etc/default/ssh /etc/default/ssh-external
Che modificheremo valorizzando la direttiva SSHD_OPTS come segue
SSHD_OPTS="-f /etc/ssh/sshd_config-external -p 23"
Aggiungiamo una nuova script di runlevel “ssh-external”
cp /etc/init.d/ssh /etc/init.d/ssh-external
Con gli opportuni permessi
chmod 755 /etc/init.d/ssh-external
e provvediamo a sostiture anche qui sshd con sshd-external.
Assicuriamoci che la nuova script venga lanciata all’avvio inserendola nei runlevel opportuni
update-rc.d ssh-external defaults
Tutte le modifiche sopra descritte si possono applicare usando la script seguente:
Terminata la configurazione potremo avviare il servizio
/etc/init.d/ssh-external start
Non ci resta modificare le regole di firewalling. Per ridirigere tutto il traffico in arrivo sulla porta 22 dell’interfaccia esterna alla porta 23, su cui è in ascolto il nostro nuovo demone, aggiungiamo a /etc/argo/fw.add una regola del tipo
iptb -t nat -A PREROUTING -i $EXT --dport 22 -j REDIRECT --to-port 23