Questo post riguarda il rafforzamento della configurazione SSH
Introduzione
SSH è diventato lo strumento standard per la gestione remota dei sistemi basati su UNIX. Il demone SSH (sshd ) è installato per impostazione predefinita su quasi tutti i principali sistemi. Inoltre, sshd fornisce anche molte opzioni di configurazione per noi.
Nota :Questo articolo è una continuazione del mio precedente argomento su Lynis. Anche se ho provato a renderlo leggibile da solo. Potresti prendere in considerazione la lettura del precedente per avere un po' di contesto.
Le impostazioni predefinite di openssh (la versione di SSH sviluppata dal progetto OpenBSD) segue la filosofia "secure by default", quindi la maggior parte delle configurazioni sono sicure da sole. Tuttavia, durante l'esecuzione della scansione di audit di Lynis ho ricevuto alcuni suggerimenti sulle configurazioni. Quindi esaminiamo i suggerimenti per rafforzare ulteriormente il nostro demone SSH. Commenterò anche se la disattivazione/attivazione di alcuni di essi migliora la sicurezza.
Rafforzamento della configurazione SSH
I suggerimenti includono la modifica del nostro sshd configurazione. Come percorso predefinito per sshd config è /etc/ssh/sshd_config , ecco dove dovremmo guardare.
TCP e inoltro dell'agente
Come si può vedere dallo screenshot, lynis consiglia di impostare AllowTCPForwarding e AllowAgentForwarding su no. È un buon consiglio utilizzare solo ciò che è necessario, quindi dovremmo disabilitare questa opzione se non la stiamo utilizzando. Tuttavia, la disabilitazione non migliorerà la sicurezza se un utente ha accesso alla shell, nel qual caso può configurare i propri forwarder (come sottolineato da sshd_config(5) pagina manuale).
ClientAliveCountMax
ClientAliveCountMax e ClientAliveInterval sono due opzioni correlate. Il conteggio massimo, moltiplicato per l'intervallo attivo del client in secondi, determina quando una connessione non risponde. Non vedo come ciò influisca sulla sicurezza. Forse, ho bisogno di fare più ricerche. Tuttavia, abbassare il valore non dovrebbe nuocere.
Compressione
SSH ci consente di comprimere i dati inviati dopo l'autenticazione tramite questa opzione. Su modem lenti, la compressione può migliorare le velocità di connessione. Tuttavia, sulla maggior parte dei sistemi moderni, l'abilitazione di questo non dovrebbe avere effetto. Inoltre, potrebbe anche introdurci agli attacchi BREACH, come sottolineato in questo commento su GitHub. Pertanto, prendiamo lynis' suggerimento.
Livello registro
sshd registra i messaggi su journald di default sulla maggior parte delle distribuzioni GNU/Linux. Questa opzione controlla il livello di dettagli da registrare. lynis consiglia di impostare da INFO a VERBOSE che può aiutare nella risoluzione dei problemi, ecc. La pagina di manuale di sshd_config(5) sottolinea, tuttavia, che l'impostazione a un livello superiore (es. DEBUG) potrebbe violare la privacy dei propri utenti. Quindi, non vedo davvero alcun miglioramento nella sicurezza modificando questa impostazione.
MaxAuthTries
Questo valore determina quanti tentativi di autenticazione consentire per connessione. Inoltre, quando i tentativi di connessione falliti raggiungono la metà di questo valore, allora sshd inizierà a registrare gli errori. Ergo, ha senso abbassare questo valore.
Max Sessions
Il valore di questa opzione specifica quante sessioni di shell devono essere consentite per connessione. Non credo che sia necessario ssh in un singolo server più volte a uno. Inoltre, c'è anche tmux che ci consente di eseguire il multiplexing che desideriamo senza aprire più sessioni. Quindi, ha senso accettare questo suggerimento.
Porto
La mia interpretazione di questo suggerimento è che dovremmo impostare sshd porta di ascolto su un altro valore. Ciò si rivelerà utile per difendersi dalla maggior parte delle botnet che scansionano Internet alla ricerca di macchine vulnerabili su porte predefinite. Tuttavia, chiunque conosca le basi della mappatura di rete (strumenti come nmap ) saprà che questo non aiuterà. Tuttavia, impostiamolo su un valore non predefinito.
TCPKeepAlive
L'impostazione di questa opzione su SÌ aiuterà il server a notare quando una connessione è interrotta. In questo modo le sessioni non si bloccano indefinitamente sul server. Pertanto, penso che sia meglio non disabilitare questa opzione.
Inoltro X11
Sebbene, la maggior parte di ssh le sessioni devono essere basate solo su testo. Tuttavia, openssh fornisce anche la funzione per aprire le applicazioni GUI sul server che verranno visualizzate sul client. Il modo in cui funziona è che il server X apre un canale di ritorno al client. Il problema è che X11 non è mai stato progettato pensando alla sicurezza. Presuppone che tutti i programmi siano affidabili poiché sono stati eseguiti da noi. Ma, come sottolinea questa risposta, con X11Forwarding, il server può controllare il client e quindi essere in grado di eseguire comandi shell sul client. Quindi, è meglio attivare questa funzione se non ne abbiamo bisogno.
Conclusione
Come sempre, la sicurezza è un argomento molto complicato. Non possiamo sempre sapere quando un sistema è sicuro. Inoltre, l'apparenza di sicurezza è anche peggio di nessuna sicurezza.
In questo articolo, ho esaminato le varie configurazioni inclusi anche i dettagli molto minori che potrebbero aiutare a migliorare la sicurezza del nostro server ssh. Ma come sempre, rafforza il tuo sistema secondo il tuo modello di minaccia.
Quindi conosci l'indurimento della configurazione SSH