Ho un sacco di macchine Linux che desidero amministrare su Internet. Attualmente utilizzo le chiavi SSH, ma è consigliabile utilizzare l'autenticazione a 2 fattori. Le chiavi SSH sono qualcosa che conosci. Qual è l'indirizzo IP che hai? (Sì, l'IP può essere falsificato, ma lo sono anche i dati biometrici e quindi le schede atm).
Posso bloccare SSH per consentire solo le connessioni dal mio intervallo IP e sarebbe considerato 2-fattore in combinazione con le chiavi SSH?
Penso che un indirizzo IP sia "da qualche parte" piuttosto che uno dei tradizionali "qualcosa che conosci", "qualcosa che hai" e "qualcosa che sei" che fa parte dell'autenticazione a 3 fattori.
Sebbene gli indirizzi IP siano banali da falsificare, le connessioni TCP non lo sono e SSH è un protocollo costruito su TCP. L'indirizzo IP di una connessione TCP è un indicatore affidabile di chi sei connesso direttamente.
Diciamo che limito le connessioni SSH al solo indirizzo IP del mio ufficio, un utente malintenzionato deve fare una delle seguenti operazioni:
Il punto 3. consente all'attaccante di essere in qualsiasi parte del mondo ma aumenta la difficoltà di un attacco.
I punti 1. e 2. riducono significativamente il numero di persone che possono utilizzare con successo gli altri fattori (come la chiave SSH o la password) se riescono ad acquisirli e quindi lo vedo come essere utile.
La qualità dell'indirizzo IP è un fattore importante qui. Ho usato il mio ufficio come nell'esempio sopra, ma se hai un indirizzo IP dinamico, ti fidi dell'intero intervallo di proprietà del tuo ISP? In che modo ciò influisce sulla facilità con cui un utente malintenzionato ottiene uno di questi indirizzi IP? L'affidabilità di un indirizzo IP cambia quando sai che ci sono 10 macchine nascoste da NAT dietro di esso? Cosa succede se ci sono 2000 macchine e 100 punti di accesso wireless?
Non considererei un indirizzo IP un fattore da solo.
Se fatto correttamente, potrebbe essere un'aggiunta utile al tuo protocollo di sicurezza. Tuttavia, sarei molto riluttante a utilizzarlo per sostituire un fattore preesistente nella tua autenticazione, in quanto gli indirizzi IP non sono informazioni segrete (lo dai ad ogni sito web che visiti) e dipendono da come / dove prendi l'IP indirizzo da, potrebbe essere banale per parodia. Ma se si utilizza l'indirizzo IP da una connessione TCP insieme a dire un cookie protetto solo http memorizzato, è possibile aggiungere un po 'di sicurezza. In particolare, invaliderei il cookie ogni volta che l'indirizzo IP cambia (che potrebbe cambiare per ragioni benigne come l'ISP che riassegna il tuo IP) e per motivi dannosi (l'attaccante ha ottenuto il tuo cookie).
Poiché Ladadadada ha affermato, gli indirizzi IP nelle connessioni TCP non sono più facilmente falsificati. TCP richiede una procedura di handshaking per ottenere un numero di sequenza a 32 bit casuale dal server prima di poter scambiare le informazioni. Se si crea un indirizzo IP casuale completamente falso all'avvio della procedura di sincronizzazione, i pacchetti non verranno instradati sul computer tramite Internet, quindi non è possibile completare l'handshake. A meno che non si controllino i router intermedi dell'ISP o un computer su una delle stesse reti locali in grado di catturare i pacchetti indirizzati altrove, nel qual caso è possibile creare indirizzi IP casuali.
Tuttavia, se si progetta un'app Web e si registra l'indirizzo IP, è necessario prestare attenzione. Supponiamo che tu disponga di un'app Web con due server Web (ad esempio, uno per contenuto dinamico / uno per statico), dietro a un servizio di bilanciamento del carico o un altro proxy. È possibile vedere per tentativi ed errori che l'indirizzo IP del client è presente solo nell'intestazione HTTP X-Forwarded-For . Tuttavia, questo campo è facile da cambiare. Ad esempio, telnet www.whatismyip.org 80 e digita quanto segue con / senza X-Forwarded-For della riga (ricorda di premere Invio due volte dopo l'ultima riga per indicare la fine della richiesta HTTP).
GET / HTTP/1.1
Host: www.whatismyip.org
X-Forwarded-For: 1.2.3.4
e vedrai che questa web app pensa che il tuo indirizzo IP sia cambiato in 1.2.3.4 . Quindi assicurati di testare accuratamente. Nel complesso, ritengo che farlo da solo sia più importante del suo valore, soprattutto perché potrebbe frustrare gli utenti i cui indirizzi IP cambiano abbastanza frequentemente.
EDIT: mi sono reso conto dopo averlo scritto che mentre rispondevo alla domanda del titolo ("può IP address essere un componente di 2 factor auth?"), ma non la parte specifica che si riferisce alla gestione di ssh, direi ssh passphrase protected la chiave è essenzialmente un'autenticazione a due fattori: qualcosa che hai (la chiave ssh) e qualcosa che conosci (la chiave della passphrase).
Tecnicamente sì, ma aggiungere un secondo fattore che è banale da falsificare non aumenta la sicurezza di molto.
Supponendo che ti sia stato consigliato di utilizzare il fattore 2 perché una sorta di valutazione del rischio ti suggeriva di avere bisogno di un'autenticazione più strong, quindi dovresti esaminare controlli migliori.
(Fai anche la whitelist IP, non è molto strong ma ci vorranno solo un minuto o due, quindi perché no?)
La cosa fondamentale è ricordare che "2-factor" non è una frase magica che ti rende sicuro. Devi comprendere il rischio e implementare controlli adeguatamente efficaci.
Tipicamente l'autenticazione a 2 fattori si riferisce a qualcosa che "conosci" e qualcosa che "hai". Il "sapere" è una password e "avere" è chiavi ssh. Questi potrebbero essere usati nel modo in cui li stai usando ora o su una sorta di smart card o dongle (che sshd quindi accede usando GSSAPI; vedi man sshd_config ).
Penso che la persona che ti ha chiesto di usare l'autenticazione a 2 fattori vuole che tu usi le chiavi e le password (se qualcuno ruba la tua chiave non importa in quanto non conoscono neanche la password).
Un indirizzo IP non è proprio qualcosa che possiedi perché, come hai detto, può essere falsificato. Lo stesso con gli indirizzi MAC. Tuttavia, è possibile bloccare l'accesso sshd a determinati indirizzi / intervalli IP in modo da rendere più difficile la molestia del server ssh. Ad esempio, l'esecuzione di sshd sulla porta predefinita su Internet porterà molte persone a tentare di utilizzare password di forza bruta, ecc .; la limitazione agli indirizzi IP dovrebbe essere d'aiuto in quanto richiede maggiore persistenza e configurazione per falsificare l'IP. Metti una linea simile alla seguente in /etc/hosts.deny
sshd,sshdfwd-X11:ALL
e questo in /etc/hosts.allow
sshd,sshdfwd-X11: 192.168.0.0/255.255.255.240
sshd,sshdfwd-X11: 127.0.0.1
(l'indirizzo IP / subnet mask sopra definisce un intervallo di indirizzi, è solo un esempio).
Controlla sempre quando effettui questo tipo di modifiche in quanto non vuoi bloccarti per sbaglio dal tuo server. Lascia sempre una sessione connessa durante il test (poiché queste modifiche riguardano solo i nuovi accessi).
La semantica è pertinente qui? Il fatto che "ti sia stato consigliato di usare l'autenticazione a 2 fattori" suggerisce che qualcuno te lo aspetti, quindi non ha più senso scoprire dalla persona con l'aspettativa cosa sarebbe ritenuto accettabile?
No. Non dovresti fare affidamento sull'indirizzo IP per fornire molta sicurezza. Se qualcuno si connette su una rete wireless aperta (ad esempio, dal proprio smartphone o dal proprio laptop in un bar pubblico), è banale montare un attacco man-in-the-middle o falsificare il proprio indirizzo IP. Per quegli utenti, l'indirizzo IP non aggiunge alcuna sicurezza.
Pertanto, se si consiglia di utilizzare l'autenticazione a 2 fattori, non considerare l'indirizzo IP del client come un secondo fattore. Per alcuni dei tuoi utenti, questo sarà sostanzialmente inutile.
Direi che è bene filtrare le connessioni SSH per consentire solo quelle da un intervallo di indirizzi IP limitato. Questo potrebbe aumentare un po '. Tuttavia, non considerarlo come un secondo fattore! Se è necessaria l'autenticazione a due fattori, utilizzare due fattori reali. Non provare a "tirare uno veloce" con un falso secondo fattore.
Lascia che ti racconti una piccola storia su un altro segmento industriale che ne ha tratto uno veloce con l'autenticazione a 2 fattori. Diversi anni fa, i regolatori bancari statunitensi hanno approvato un regolamento che impone a tutte le banche degli Stati Uniti di utilizzare l'autenticazione a due fattori per il banking online. Un requisito plausibile, soprattutto se sei preoccupato per gli attacchi di phishing per rubare le password bancarie delle persone. Ma poi le banche sono andate e sono diventate "intelligenti" (e non lo dico in senso positivo) su come hanno implementato il requisito. Hanno deciso che la tua password di banking online sarebbe il primo fattore (fino ad ora) e un cookie persistente sulla tua macchina sarebbe il secondo fattore (beh, plausibile). Ma come hanno ottenuto il cookie persistente sulla tua macchina? Bene, se non hai il cookie, ti fanno la tua domanda di sfida, e se puoi fornire la risposta corretta, ti danno il cookie. Quindi alla fine i loro due fattori sono: (1) una password e (2) un'altra password (la risposta alla tua domanda di sfida). Ciò vanifica lo scopo dell'autenticazione a due fattori. Ad esempio, un phisher può semplicemente chiedere entrambe le password. In effetti, alcuni studi hanno rilevato che questa forma di autenticazione a due password non è più sicura contro il phishing rispetto all'autenticazione con una sola password. Quindi non essere come le banche. Non considerare l'autenticazione a 2 fattori come qualcosa che puoi giocare, perché in questo modo annullerai i suoi vantaggi in termini di sicurezza.
In un certo senso, sì. Ma è più una questione di semantica che di sicurezza.
In un certo senso, un indirizzo IP può essere considerato "qualcosa che sei" o "qualcosa che hai"; vale a dire, se l'accesso è limitato solo a un numero limitato di indirizzi IP, quindi un utente malintenzionato dovrebbe "essere" o "avere" uno di questi indirizzi IP al fine di perpetrare un attacco - come ciò potrebbe accadere dipende dallo scenario e tecnologia, ma certamente ridurrà drasticamente la superficie di attacco.
La semantica fa parte dell'argomento se questo conta come secondo fattore, o se si tratti solo di una buona sicurezza aggiuntiva. Tecnicamente non sei il tuo indirizzo IP né è tuo; qualcun altro può assumerne il controllo a seconda della struttura della rete. Ma lo stesso vale per qualsiasi altra tecnologia di autenticazione: è tutto a disposizione dell'implementazione.
L'unica volta che conta davvero se conta come secondo fattore è nel contesto di una sorta di audit di processo o di un quadro più ampio, nel qual caso devono essere elencati i fattori di qualificazione. Altrimenti, sono solo discussioni da nerd.
Direi che richiedere una password oltre a imporre una restrizione IP è una sicurezza molto ragionevole, a patto che vengano seguite rigorosamente le politiche appropriate. È certamente meglio della sola password.
Non si dovrebbe usare l'indirizzo IP come fattore di autenticazione. È facile falsificare un indirizzo IP invece di scomporre altri mezzi come il biometrico. Uno script kiddie può farlo facilmente.
Come puoi gestire involontariamente le modifiche agli indirizzi IP come usare la VPN? Esistono molte soluzioni per l'utilizzo dell'autenticazione a due fattori SSH. Puoi semplicemente cercarli su Google.
L'IP sarebbe semplicemente troppo facile da falsificare o persino ipotizzare in base a una sottorete. Solo così tante opzioni lì. Non lo considererei utile. Ci sono molti altri sistemi a 2 fattori che puoi usare che sono semplici e funzionano. Guarda LinotP e OpenOTP.
Un'altra opzione consiste nel limitare l'accesso solo alle macchine che utilizzano una smart card o hanno già attivato un'altra forma di fattore 2.
Qualche risposta pratica a cui potresti o non potresti credere
Una volta ho lavorato per una società che ha creato un sito secondario per MasterCard. Intendiamoci, non era niente di molto legato alla sicurezza, nessun numero CC, nessuna transazione. Una piccola gara con piccoli prezzi. Ma questo significa che il sito ha un meccanismo di accesso e alcune informazioni personali (login, email, forse anche indirizzo postale). Le procedure MC richiedevano una qualche forma di 2FA per la gestione dei server di produzione e il filtraggio basato su IP, limitato a 1 indirizzo IP (gateway dall'edificio) è stato considerato sufficiente. D'altra parte il sito era di un valore così basso che non si sono presi la briga di verificare effettivamente ciò che abbiamo detto, ci hanno preso in parola. Ma includendo il filtro IP come 2FA è stata la loro idea, l'hanno esplicitamente chiesta, non abbiamo davvero pensato che quindi includere sia come parte di 2FA.
Leggi altre domande sui tag authentication network ssh