[RELug] ssh bruteforce e prevenzione

[Vladimir Nicola Chersi]

[...]

> Ringraziandoti per l'esauriente risposta, direi  che hai reso
> perfettamente l'idea di quanto succede durante la connessione, sia a me
> che a tutta il popolo della lista .
>
> Mi chiedevo inoltre come avesse fatto il liga a contare questi attacchi

Come ho gia` scritto in risposta ad un altro thread proprio in questi
giorni, nel file /var/log/auth.log viene tenuta una traccia di tutti gli
accessi riusciti e di tutti i tentativi di accesso non andati a buon fine,
tranne gli accessi che malauguratamente dovessero avvenire per mezzo di un
bug, ma questo e` un discorso a parte.
Un accesso, o un tentativo di accesso via ssh comporta sempre una
registrazione nel log di cui sopra.

> Ovvero , dal momento che io debba predisporre un accesso da remoto su un
> server ltsp , quali sono i servizi che bisogna studiarsi per avere
> eventualmente in una "macchina di prova" la dimostrazione che il tutto
> funziona in modo invulnerabile.

Come ho gia` scritto, occorre limitare al minimo indispensabile le porte
aperte verso internet, e quindi rimuovere tutti i servizi non
indispensabili;
se inoltre esistono servizi che sono necessari ma servono solo all'interno
della rete locale configurarli in modo tale che accettino connessioni solo
dalla rete locale e non dal mondo intero;
in aggiunta sul router impostare le regole per lasciare passare i
tentativi di accesso solo per i servizi che si vogliono rendere
disponibili su internet, e niente altro.
Infine (e` e` quello da cui e` nato questo discorso) implementare sul
server dei sistemi che limitino o o impediscano i tentativi di attacco ai
servizi di cui sopra (nel caso di ssh abilitare l'accesso solo con
passphrase e/o impostare la regola di iptables per bloccare tentativi di
accesso ad un massimo di 3 al minuto, per esempio).

> Questo per "aprire la porta" solo quando si è sicuri di aver predisposto
> tutte le protezioni.

La sicurezza assoluta non l'avrai mai, pero` ci sono molte cose che uno
puo` fare per cercare di evitare intrusioni indesiderate.
In aggiunta alle varie cose di cui sopra una cosa molto importante rimane
il mantenere il sistema aggiornato per quanto riguarda la sicurezza.

Se io avessi una macchina UBUNTU vedei di eliminare anche la possibilita`
di fare "sudo" perche` se uno riesce con qualche artificio (keylogger,
brute-force, etc.) a scoprire la password dell'utente in questione, di
fatto puo` diventare root molto semplicemente (basta che provi a fare sudo
e che, tanto per provare, usi la stessa password dell'utente che ha appena
scoperto in altro modo, senza nemmeno perdere tempo con un altro tentativo
brute-force).
Ovviamente poi bisogna impostare una password per l'utente root che sia
non banale. Restano valide tutte le considerazioni precedenti, e cioe` che
se uno puo` disabilitare il login con password da remoto, e` una buona
idea, e il login per l'utente root da remoto deve essere disabilitato in
ogni caso. (negli ultimi 4 giorni sul mio server ho avuto circa 70
tentativi di intrusione via ssh, e di questi circa la meta` erano per
entrare come "root", che non e` abilitato ad accedere via ssh).
Se poi uno ha bisogno di diventare root, esiste sempre il comando "su" che
richiede la password di root, e quindi per entrare uno ha bisogno di due
chiavi (la password o la passphrase dell'utente + la password di root) e
non solo di una (quella dell'utente "sudoer").
Poi ci sono opinioni divergenti in materia (c'e` gente che ritiene che
qualunque utente che possa in qualche maniera diventare root deve essere
considerato alla stessa stregua di root), ma poter fare manutenzione da
remoto e` una comodita` troppo grande per poter pensare di farne a meno
(disabilitando, oltre all'accesso via ssh di root, anche la possibilita`
di fare "su" o "sudo"), e quindi secondo me l'unica opzione accettabile e`
rendere quanto piu` sicuro e complicato il diventare root, ma lasciare
comunque aperta la possibilita`.


> Ciao.
> -Mirco

Ciao, Vladimir Nicola