Premessa
Nel corso del tempo abbiamo parlato tanto di hardening su sistemi Windows Server, un po’ meno di quello su sistemi Linux. Come ben sappiamo il concetto di hardening indica l’insieme di operazioni mirate sulla configurazione di un dato sistema informatico (e dei suoi componenti) che mirano a minimizzare l’impatto di possibili attacchi informatici. Pertanto, lo scopo finale di queste operazioni mira a migliorare la sicurezza complessiva.
Disclaimer
Questa serie di articoli non si prefiggono come obbiettivo quello di elencare passo passo tutti i passaggi tecnici su come migliorare in toto la sicurezza in ambito Linux, sono piuttosto da vedere come traccie logiche sulle quali vorrei far porre l’attenzione del lettore.
Come è di consuetudine in questo blog, non imposterò gli articoli di modo che risultino dei tutotial: come ho già detto alla nausea, internet ne è pieno! Dove lo riterrò opportuno posterò eventuali link di approfondimento.
Oggi parliamo di: SSH
Il metodo di autenticazione predefinito per SSH è affidato alla combinazione nome utente/password. Come sappiamo questa tipologia di autenticazione è soggetta ad attacchi di tipo brute force in cui l’attaccante tenta mediante dizionario o per tentativi sequenziali di indovinare la password di accesso.
Consiglio base ma che quasi mai vedo implementare consiste nell’implementazione dell’autenticazione basata su chiave, in cui questa è resa possibile da coppie di chiavi SSH pubbliche e private. La chiave privata rimane sul PC client mentre la chiave pubblica viene copiata sul server.
Durante l’autenticazione della chiave SSH, il server controlla se il PC client possiede la chiave privata: se il controllo ha esito positivo viene creata una sessione (di shell o di comando remoto) sul server remoto, in alternativa l’autenticazione ha esito negativo bloccando l’accesso alla risorsa remota.
Anche dopo aver configurato l'autenticazione basata su chiave, il server è ancora suscettibile agli attacchi brute force in quanto l'autenticazione mediante password è ancora attiva. Questa deve essere disabilitata andando ad agire sul file /etc/ssh/sshd_config modificando la direttiva PasswordAuthentication al valore "no" (e riavviando il servizio ssh).
Fail2ban
Se non dovesse essere possibile implementare l’autenticazione via chiave privata/pubblica, un metodo interessante per mitigare questi attacchi consiste nell’installazione e configurazione di fail2ban.
Fail2ban è un IPF (Intrusion Prevention Framework) open source che esegue la lettura dei file di log dei servizi alla ricerca di errori di autenticazione e blocca gli IP che falliscono ripetutamente le login per un determinato periodo di tempo.
Fail2ban ovviamente non è l’unico IPF disponibile, ne esistono diversi come ad esempio sshguard. Scegliete e configurate quello che più vi aggrada!
TCP Wrapper
Altra possibilità potrebbe essere quella di implementare delle ACL per restringere l’accesso al server basandosi sull’IP sorgente.
Il wrapper utilizzano i file di configurazione /etc/hosts.allow e /etc/hosts.deny (in questo preciso ordine) per determinare se il client remoto può accedere o meno a un servizio specifico.
Autenticazione a due fattori
Si, è possibile!
Tecnicamente mediante un apposito modulo da installare sul server e l’app mobile Google Authenticator è possibile aggiungere un secondo livello di autenticazione. Personalmente non mai eseguito questa configurazione ma, se è di interesse, vi lascio qui il link di Tecmint sul come fare.
EOF