Una password con una maggiore complessità è ottima, ma se c'è un exploit contro il software server (OpenSSH o altro) che stai utilizzando, non sarà di aiuto. L'idea alla base di un oscuro numero di porte alte è che non verrà attaccato in primo luogo, ma ci sono alcune avvertenze da prendere in considerazione:
Le porte alte presentano un ulteriore rischio per la sicurezza. Se il server SSH non funziona, un utente locale può posizionare un nuovo server SSH sulla stessa porta. Solo le porte 1-1024 sono limitate all'utente root, quindi la porta alternativa deve trovarsi in tale intervallo. (Questo taglia in entrambi i modi: i port scanner esaminano solo queste porte, quindi sei meno nascosto.)
Questa è sicurezza attraverso l'oscurità e dovrebbe essere considerata "extra", ma dovrebbe < em> not essere considerati parte della sicurezza quando si calcolano entropia e rischio. Non è male essere oscuri, ma è male presumere che l'oscurità offra sicurezza sufficiente. Adattamento di un preventivo da @barbecue :
Obscurity is to security as camouflage is to armor.
One makes it harder to find you, the other protects you once you have been found.
Potresti ottenere meno attacchi sulla porta 2938, ma una password debole è una password debole.
Mi piace molto la tua idea di confrontare l'entropia della password di whatever con whatever2938 (* modificato da password e password2938 per i motivi indicati di seguito), che I calcola per essere 17 bit contro 30 bit, mostrando che la password più lunga è sicuramente più sicura, ma per modellarla correttamente dovresti ottenere delle statistiche su quanti aggressori port-22-bound potrebbero eventualmente infrangere quella password più lunga rispetto a quanti attacker troverebbero entrambi la porta non standard e rompere la password più breve, e anche quell'analisi dovrebbe assumere lo stesso tasso di persistenza anche se gli attacchi stanno aumentando sia in termini di frequenza che di sofisticazione.
Invece, consiglierei qualcosa come Fail2ban , che può riconoscere gli accessi falliti e vietare l'IP che li ha tentati (per impostazione predefinita, Fail2ban blocca un IP per dieci minuti dopo dieci accessi falliti entro dieci minuti, ma questo è tutto configurabile). Questo limita gli attacchi a provare una password al minuto, quindi whatever richiederebbe circa una settimana per interromperla e anche una password più tipica (ma ancora debole) come Da5id richiederebbe 12+ anni (2 < sup> 22.6 & div; 365 & div; 24 & div; 60 = 12) di controllo password non-stop, che è presumibilmente il tempo necessario per farti notare i tentativi nei log.
non pensa che ciò renda deboli le password come Da5idRox una buona idea. Fail2ban funziona solo sul server SSH; qualcuno con l'accesso alla shell potrebbe rompere questo in due settimane.
Naturalmente, non c'è nulla che ti impedisca di fare tutto. Aggiungi complessità alla tua password, usa una porta alternativa e blocca gli IP con troppi errori. Un'ulteriore tecnica di offuscamento che potresti provare è bussare alla porta , che può anche essere eseguita sicuro se il knock stesso è crittografato end-to-end o utilizza un password one -time .
* Una nota minore: ho modificato le password di esempio della domanda per utilizzare whatever anziché password perché password è un caso speciale. Le password comuni come password (e semplici variazioni) sono meglio assunte per un'entropia attorno a 0-5, quindi ad es. p455w0rDz ha un'entropia di circa 12, che è più debole di L% . Nella matematica di cui sopra, ho invece assunto che intendessi una parola di dizionario casuale, che ha un'entropia di 17 bit). Altro sulla complessità della password calcoli .