Quando si esegue un server Web pubblico (ad es. con Apache), ho sentito che si consiglia di associare SSH a un secondo indirizzo IP, diverso da quello che sta ascoltando Apache.
Ma per me sembra che questa sia solo una questione di offuscamento - una volta che un attaccante conosce il secondo indirizzo IP, la situazione sarebbe la stessa di un singolo indirizzo IP.
Ho ragione? O ci sono altri vantaggi nell'usare un secondo indirizzo IP ad eccezione dell'offuscamento?
A meno che quell'indirizzo IP appartenga a una rete di gestione dedicata che implementa una sicurezza aggiuntiva, è uno spreco di risorse.
Entrambi gli IP, ovviamente, finiscono sullo stesso server. Ciò significa che, a meno che non entrino attraverso reti diverse (ovvero una rete di gestione che implementa una protezione aggiuntiva), non ci sarà alcuna differenza tra una connessione a SSH che si attiva su un IP o l'altra: è possibile firewall esattamente nello stesso modo (se lo desideri) e non lo rende più o meno evidente nei log.
L'unica cosa che stai "nascondendo" è la relazione tra il server SSH e il server web e, a meno che tu non abbia una procedura molto scarsa per il prelievo dei nomi di account, allora non dovrebbe avere importanza.
Se si utilizza una rete di gestione dedicata, tuttavia, è una questione diversa: una rete di questo tipo potrebbe richiedere tutte le connessioni per passare attraverso una fase di autenticazione sicura e imporre un limite aggiuntivo alla parte intercettazione (ad esempio, è possibile richiedere loro essere fisicamente connesso alla rete o passare attraverso una VPN che richiede 2FA e assicurandosi che il tuo cliente sia "pulito" ).
Sei sostanzialmente corretto. È offuscamento. L'offuscamento non è privo di valore, ma non devi fare affidamento su di esso.
La prima risposta è corretta, a proposito, che è buona norma ospitare servizi di gestione come SSH su una rete separata (ad esempio, non su Internet).
È un po 'come spostare SSH su una porta diversa. Devi solo nascondere qualcosa (male) e questo non dovrebbe essere qualcosa su cui basare la sicurezza di un sistema. Potrebbe buttare via gli attaccanti che davvero non sanno quello che stanno facendo (e non entreranno in ssh comunque se è configurato correttamente) ma è inutile altrimenti.
With fwknop deployed, anyone using nmap to look for SSHD can't even tell that it is listening - it makes no difference if they want to run a password cracker against SSHD or even if they have a 0-day exploit.
Ho alcune note qui per usare fwknop . Posso anche ssh in contenitori dietro NAT senza nessuna porta aperta esternamente.
Suppongo che una buona domanda sarebbe perché hai persino SSH aperto sulla WAN, comunque? ... Come altri hanno menzionato, l'amministrazione tramite una rete privata è il Santo Graal.
La migliore approssimazione (e il motivo per cui mi preoccupo di rispondere qui) per una connessione WAN è un involucro IP o un set di regole firewall che consente solo SSH da un particolare indirizzo IP. Una di queste strategie è un server SSH dedicato che utilizza solo l'autenticazione basata su chiave (se necessario, da qualsiasi indirizzo IP) e un server WWW che accetta solo SSH in entrata dall'indirizzo IP di detto server. Quando un utente malintenzionato deve indovinare, e quindi contraffare, un indirizzo IP per entrare, hai aggiunto un buon livello di protezione. Che potrebbe essere una sola applicazione per il tuo secondo indirizzo IP ...