giovedì 19 novembre 2009

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.

Nessun commento:

Posta un commento