Rischio di servizi in esecuzione sulle porte 1024

Se sul tuo Raspberry Pi c'è un processo anomalo, allora sei già stato compromesso, anche se l'autore dell'attacco o il processo malevolo automatico non è ancora riuscito a elevare alla radice.

The rogue process cannot access the host keys, so would present a different fingerprint to the user when connecting, alerting them to an issue.

Questo è vero. Tuttavia questo dipende dal fatto che i tuoi utenti possano notarlo o meno. Su un sistema medio, molti utenti fanno clic sugli avvertimenti, tuttavia con un sistema basato su Linux che utilizza SSH questa barra di solito è elevata abbastanza da consentire la connessione solo a utenti semi-esperti, aumentando la possibilità che realizzino qualcosa che non va. p>

If key based authentication is in use, little can be gained from intercepting communications.

D'accordo. Anche se la chiave pubblica potrebbe essere recuperata dal client SSH, non ci sarebbe alcun modo in cui il servizio non autorizzato intercetta la chiave privata in quanto non viene mai inviata.

Ci potrebbe essere un rischio se invece fosse usata l'autenticazione della password, sebbene, come notato, l'utente avrebbe dovuto ignorare qualsiasi messaggio di avviso della chiave host.

Pertanto, in sintesi, non vi è alcun rischio aggiuntivo introdotto utilizzando una porta non privilegiata per SSH quando è attiva l'autenticazione della chiave pubblica. L'unico attacco a cui potrei pensare è dove il demone SSH rogue permetterà a un utente di connettersi nella speranza che l'utente emetta immediatamente un sudo / su e quindi immetta una password che viene poi catturata. Se ciò non è stato fatto immediatamente perché il processo canaglia non avrà le stesse autorizzazioni dell'utente vero, l'utente probabilmente noterà che qualcosa non funziona.

Servizi in esecuzione su porte < 1024 (almeno sui server * nix) sono generalmente considerati più sicuri, poiché richiedono root (o un utente fidato con privilegi di root) per avviarli, mentre i servizi in esecuzione su ports > = 1024 potrebbero essere eseguiti da un server non affidabile (possibilmente canaglia) sul server.

Quindi, è plausibile che un attacco come quello descritto nel post reddit che hai copiato possa essere scaricato da un utente malintenzionato sul server, senza privilegi di root.

Per quanto riguarda "1.The rogue process cannot access the host keys, so would present a different fingerprint to the user when connecting, alerting them to an issue." : questo è vero - se un utente si è collegato al server in precedenza e il suo client SSH ha bloccato la chiave pubblica del server. In questo caso, il client SSH dell'utente dovrebbe (presumibilmente) avvertirlo che la chiave pubblica del server è cambiata e l'utente dovrebbe (presumibilmente) sapere che qualcosa sta succedendo. Tuttavia, l'utente verrebbe avvisato solo se si era collegato al server in precedenza e il suo client ha bloccato la chiave pubblica del server.

Riguardo a "2.If key based authentication is in use, little can be gained from intercepting communications." : sono scettico su questo. Il client SSH dell'utente invierà la sua chiave pubblica, come al solito durante l'avvio di una sessione SSH, quindi il server SSH canaglia potrebbe semplicemente autenticare il client (come avviene normalmente quando la chiave pubblica del client è presente nel file authorized_keys del server) e procedere con la sessione utilizzando la chiave pubblica inviata dal client.

Alcuni thread di SE stanno discutendo i pro e amp; contro questo da una prospettiva di sicurezza . Cambiare il numero di porta predefinito aumenta la sicurezza? e Devo cambiare la porta SSH in < 1024? .

Tuttavia, c'è anche un rischio coinvolto, che il processo canaglia che hai menzionato ti blocca effettivamente dal tuo server. Le probabilità che ciò accada potrebbero essere basse, ma cosa succede se? Sarai fortunato se riesci a riavviare il server senza accesso SSH. E spero che all'avvio il demone SSH stia reclamando la porta prima del processo illecito.