Come (ulteriormente) garantire la sicurezza SSH?

Esegui quante più mitigazioni possibili.

Il tuo obiettivo è costringere un'ampia varietà di potenziali aggressori a dedicare più impegno, risorse, tempo al computer (e quindi bolletta elettrica) e soprattutto ore-persona "qualificate" (rare o scarse e quindi preziose). Nessuna protezione funziona contro ogni minaccia. Non tutte le minacce possono essere protette rimanendo su Internet.

Tuttavia, un gran numero di minacce (script kiddies e aggressori poco qualificati o con poche risorse) possono essere sconfitte quasi sempre disponendo di una difesa in profondità - molti livelli di buona e solida sicurezza, ognuno dei quali dovrebbe - in teoria - essere sufficiente per sconfiggere molte minacce da solo. Pertanto, quando le regole di iptables del tuo sistema consentono a qualcuno di entrare accidentalmente, l'autenticazione del certificato SSHD lo tiene fuori. Quando il tuo servizio SSHD ha un difetto, la tua VPN impedisce a chiunque di vederlo. Quando sia la tua VPN che il tuo SSHD hanno un difetto allo stesso tempo, le tue regole del firewall impediscono alla maggior parte degli indirizzi IP del mondo di tentarlo, lasciando solo i locali e le grandi botnet in grado di provare a sfruttare le vulnerabilità, che correggi come il prima possibile.

Quindi, lo ripeto, inserire quante più mitigazioni possibili a quanti più livelli possibile. Non puoi sapere in anticipo quali hanno vulnerabilità non scoperte e in quale ordine verranno sfruttate.

• Assicurati di consentire solo SSH v2

  • sshd_config

    • Protocollo 2

• Rimani aggiornato

• Usa il tuo iptables per consentire SOLO gli indirizzi IP o gli intervalli che utilizzi effettivamente

• Configura il tuo SSH per consentire l'accesso SOLO tramite certificato, non tramite nome utente/password, secondo la pagina SSH/OpenSSH/Configurazione del sito di assistenza di Ubuntu

  • sshd_config

    • PubkeyAuthentication sì

    • Autenticazione password no

  • Se utilizzi una home directory crittografata

    • AuthorizedKeysFile /etc/ssh/%u/authorized_keys

  • In caso contrario, l'impostazione normale per le home directory può funzionare

    • AuthorizedKeysFile %h/.ssh/authorized_keys

    • Assicurati che non ci siano autorizzazioni eccessive.

      • chmod 700 ~/.ssh

      • chmod 600 ~/.ssh/authorized_keys

      • chmod go-w ~

  • E imposta un certificato il più forte possibile. La generazione delle chiavi è trattata nella pagina SSH/OpenSSH/Keys del sito di assistenza di Ubuntu

    • Inizierei con una chiave RSA a 4096 bit o una chiave ed25519 con una passphrase lunga e forte. Assicurati di generarlo localmente, digita una passphrase lunga e complessa quando richiesto, usa -o per garantire il nuovo formato della chiave OpenSSH 6.5 e assicurati che il server non abbia mai nient'altro che la chiave pubblica.

      • ssh-keygen -o -t ed25519 -f ~/.ssh/id_ed25519

      • ssh-keygen -o -b 4096 -t rsa -f ~/.ssh/id_rsa

      • Per controllare la lunghezza di una chiave esistente, usa ssh-keygen -e -f mykeyfile

  • Se puoi, restringi le chiavi nel file authorized_keys a uno specifico indirizzo IP o insieme di nomi host

    • from="192.168.1.2" ssh-rsa ABCDE...012 [email protected]

    • from="*.test.test,!BadPC.test.test" ssh-ed25519ABCDE...012 [email protected]

  • Se utilizzi OpenSSH 6.8 o versioni successive, puoi limitare le chiavi autorizzate anche a determinati tipi in sshd_config

    • PubkeyAcceptedKeyTypes ssh-ed25519*,ssh-rsa*

• Usa fail2ban per fare in modo che i tentativi di forza bruta richiedano uno sforzo maggiore (ad esempio, fai in modo che utilizzino una botnet invece di una sola macchina o fai in modo che impieghino molto tempo)

  • L'impostazione dei certificati (chiavi) è superiore se stai chiedendo quale fare prima

• Riduci il tempo di tolleranza per l'accesso

  • Se stai usando i certificati, hai la possibilità di abbassarlo MOLTO a meno che tu non usi connessioni molto, molto lente

    • AccediGraceTime 8

  • Altrimenti, quanto velocemente digiti?

    • AccediGraceTime 20

• Controlla le scelte della tua suite di cifratura con le informazioni di Mozilla.org Security/Guidelines/OpenSSH

  • Dal momento che è il tuo server e solo tu stai entrando, puoi selezionare un raggruppamento molto, molto stretto in modo tale che siano consentiti solo i client più moderni. Forse

  • HostKey /etc/ssh/ssh_host_rsa_key

    • sudo ssh-keygen -o -N '' -b 4096 -t rsa -f /etc/ssh/ssh_host_rsa_key

      • o

      • HostKey /etc/ssh/ssh_host_ed25519_key

      • sudo ssh-keygen -o -N '' -t ed25519 -f /etc/ssh/ssh_host_ed25519_key

    • ovviamente corrisponde esattamente ai nomi dei file HostKey!

      • o entrambi (il più preferito prima)

      • rimuovere completamente tutte le chiavi dsa; sono fissati a un patetico 1024 bit per SSH

  • Usa le direttive ssh -Q per determinare cosa supporta il tuo sistema per le opzioni della suite di cifratura

  • Esempio di [email protected]

  • Crittografia [email protected],[email protected],[email protected]

  • Esempio [email protected]

  • O qualunque scelta specifica ti faccia sentire più al sicuro

  • E tenere il passo con la letteratura; quando c'è un difetto in qualcosa che hai scelto, scegli qualcosa che non ha difetti noti in quel momento.

• Usa il tuo iptables (o firewall) con le blocklist da I-blocklist

• Usa il tuo iptables (o firewall) con elenchi IP geografici o basati su ISP; una di queste fonti di elenchi geografici è maxmind.com

• Passa a una porta nell'intervallo di porte dinamiche (temporanee) da 49152 a 65535 per RFC6335

  • E collega solo agli indirizzi IP richiesti

• Blocca tutte le altre porte su quel server tramite iptables; è probabile che tu venga colpito da MOLTI attacchi

  • In particolare, rafforza il tuo database MySQL, se presente:vedo MOLTI attacchi MySQL (e SQL Server) sul mio IDS e non ne ho mai eseguito nessuno o nessuna delle due porte è stata aperta. Impostali solo su IP locali, non instradabili, ecc., password lunghe, disabilitali, ecc.

  • In particolare, disabilita tutti i server web, impostali solo su IP locali, non instradabili, ecc.

• Usa il port knocking per il sito della guida di Ubuntu o un articolo di DigitalOcean

• Limite di frequenza di nuovi tentativi di connessione, in base a questa risposta alla domanda ServerFault "Centinaia di accessi ssh non riusciti"

iptables -A INPUT -p tcp --dport 22 -m recenti --update --seconds 60 --hitcount 5 --name SSH --rsource -j DROP

iptables -A INPUT -p tcp --dport 22 -m recenti --set --name SSH --rsource -j ACCEPT

• Prendi in considerazione l'utilizzo di chroot secondo la documentazione Debian"OpenSSH SFTP chroot() with ChrootDirectory"

• Assicurati che rhosts sia disabilitato con l'opzione sshd_config

  • IgnoreRhosts sì

  • Numero di autenticazione RhostsRSAA

  • Numero di autenticazione Rhosts

• Aggiungi ulteriori restrizioni al processo senza privilegi di pre-autenticazione

  • Utilizza sandboxPrivilegeSeparation

• Se non stai usando l'inoltro o il tunneling, disabilitalo in sshd_config

  • X11Inoltro no

  • AllowTcpForwarding no

  • GatewayPorts no

  • PermessoTunnel n

• Impedisci altre impostazioni non sicure nelle directory o nelle autorizzazioni

  • StrictModes sì

  • E poi passa attraverso le tue autorizzazioni e impostazioni fino a quando non funziona di nuovo :)

• Disabilita l'autenticazione basata su host

  • Autenticazione basata sull'host no

• Nota che per la risposta di This Serverfault a "Il demone OpenSSH ignora la direttiva ServerKeyBits", la vecchia direttiva ServerKeyBits sshd_config non è più applicabile, poiché in primo luogo non consenti SSH v1.

• Non consentire root in sshd_config

  • PermitRootLogin no

• Non permettere a diversi utenti - forse utenti di servizio su qualche pacchetto che installi - di avere altre opzioni

  • PermitUserEnvironment no

• Installa un firewall completo separato come pfSense o un Ubiquiti Edgerouter Lite tra quella macchina e il mondo esterno.

  • E poi usa la VPN integrata IN ADDITION TO il tuo accesso SSH rafforzato

  • Anche con accessi basati su certificato, non accessi basati su nome utente/password

  • Se usi OpenVPN

    • Assicurati di utilizzare anche una chiave precondivisa --tls-auth "ta.key"

    • E scegli cifrari migliori di quelli predefiniti

  • E usa anche le liste di blocco menzionate sopra a questo livello

Come menzionato da DeerHunter, la modifica di ssh e/o iptables e/o altre impostazioni del firewall senza nessun altro modo può comportare una mancanza di capacità di accesso tramite SSH.

Ecco qua:

• Genera chiavi SSH + proteggile con password
• Consenti solo a un utente specifico di accedere (AllowUsers)
• Consenti da IP specifico [email protected]
• Cambia porta predefinita
• Crea regole firewall
• e per ultima cosa installa fail2ban.