Qual è il punto dell'opzione sshd "UseDNS"?

79

So cosa fa, ma non so perché . Quale attacco / i previene?

È rilevante per tutti i tipi di metodi di autenticazione? (basato su host, password, chiave pubblica, tastiera interattiva ...)

— user368507
fonte

2

Ne ho aggiunto uno anche a CoreOS qui: github.com/coreos/bugs/issues/92

66

L' UseDNSopzione è per lo più inutile. Se i computer client sono disponibili su Internet, è molto probabile che non dispongano di DNS inverso, che il loro DNS inverso non si risolva in avanti o che il DNS non fornisca informazioni diverse da "appartiene a questo ISP "che l'indirizzo IP ti dice già.

Nelle configurazioni tipiche, il DNS viene utilizzato solo per la registrazione. Può essere utilizzato per l'autenticazione, ma solo se IgnoreRhosts nospecificato in sshd_config. Questo è per la compatibilità con i vecchi impianti che utilizzato rsh, dove si può dire “l'utente chiamato bobsulla macchina chiamata darkstarpuò accedere come alicesenza mostrare alcun credenziali” (scrivendo darkstar bobin ~alice/.rhosts). È sicuro solo se ti fidi di tutte le macchine che potrebbero essere connesse al server SSH. In altre parole, questo è molto molto raramente utilizzabile in modo sicuro.

Dato che la ricerca DNS non fornisce alcuna informazione utile se non in circostanze molto particolari, dovrebbe essere disattivata. Per quanto ne so, l'unica ragione per cui è attiva per impostazione predefinita è che è tecnicamente più sicura (se sei preoccupato per l'autenticazione, non per la disponibilità), anche se ciò si applica solo a una piccola serie di circostanze.

Un altro argomento per disattivare questa funzione è che ogni funzione superflua rappresenta un rischio per la sicurezza non necessario .

— Gilles
fonte

Quindi, UseDNS è rilevante solo per l'autenticazione basata su host? Se non utilizzo un'autorizzazione basata su host e non mi interessa se il nome host o l'IP vengono visualizzati nei registri, UseDNS non fa differenza?

— user368507,

5

@ user368507 Sì, è tutto. UseDNSnon è nemmeno utile se si utilizza l' autenticazione host basata su chiave , solo se si utilizza l'autenticazione host basata su nome host (ovvero autenticazione estremamente debole).

— Gilles,

3

@Gilles, naturalmente, se si utilizza basato su chiavi e l'autenticazione basata su host, UseDNSè molto utile, e critico. Si autentica un utente in base alla chiave e il server in base al nome host, assegnato a un indirizzo MAC.

— Kara Deniz,

38

Ho aggiunto a questo un bug report (vecchio ma ancora attuale) in Ubuntu.

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/424371

Ho proposto di modificare l'impostazione predefinita su No e di aggiungere la documentazione più recente su di essa:

# UseDNS - Determines whether IP Address to Hostname lookup and comparison is performed
# Default value is No which avoids login delays when the remote client's DNS cannot be resolved
# Value of No implies that the usage of "from=" in authorized_keys will not support DNS host names but only IP addresses.
# Value of Yes supports host names in "from=" for authorized_keys. Additionally if the remote client's IP address does not match the resolved DNS host name (or could not be reverse lookup resolved) then a warning is logged.

— Rodney
fonte

2

Su upvote ... questo è più utile, perché contiene un'informazione che stavo cercando.

— 0xC0000022L

1

Allo stesso modo, se UseDNS è no, non è possibile far corrispondere i nomi host nelle regole pam_access e si devono usare gli IP.

— ColinM,

1

Ho votato a favore di questa risposta un paio di anni fa, ma solo oggi ho notato che, l'impostazione predefinita è stata cambiata in "UseDNS no" in OpenSSH 6.8p1, che è in Ubuntu 15.10 e versioni successive .

— Anthony G - giustizia per Monica,

RedHat (in RHEL7) ha recentemente cambiato anche il valore predefinito in No, il che rompe i controlli di accesso basati sul nome host (che sono utili principalmente come controlli consultivi su una rete intranet, ovviamente non come l'unico meccanismo di controllo degli accessi).

— dannysauer,

8

Dalla manpage di sshd_config(5):

 UseDNS  Specifies whether sshd(8) should look up the remote host name and
         check that the resolved host name for the remote IP address maps
         back to the very same IP address.  The default is “yes”.

Abilitando ciò, l'accesso da una posizione senza DNS (avanti e indietro) corretto genera un avviso nei registri.

Quindi questo non impedisce alcun attacco, tranne che avrebbe bisogno di un indirizzo remoto qualificato del client per non registrare alcun avviso. Un simile avviso può aiutarti a rintracciare l'attaccante solo se quel record PTR ha un senso.

^{modifica: aggiornato secondo il commento di Andrey Voitenkov .}

— gertvdijk
fonte

Quindi è un filtro su chi è autorizzato a connettersi in base a qualsiasi cosa ci sia nel server DNS?

— user368507,

2

Perché renderebbe impossibile l'accesso? sshd genera semplicemente un avviso se i record DNS A / PTR non corrispondono. La sequenza di accesso sarà lenta in caso di risoluzione dei problemi.

— Andrey Voitenkov,

Ciò impedisce l'accesso se la chiave autorizzata è stata compromessa fintanto che l'attaccante non può falsificare i valori nel from=campo prima della chiave autorizzata in questione (se utilizzata).

— Alecz,

7

È necessario quando si utilizza l'opzione FROM in un file authorized_keys e si desidera filtrare in base ai nomi e non solo agli IP.

L'opzione FROM in una riga di un file authorized_keys consente di limitare gli host che possono utilizzare una chiave specifica.
Ciò aumenta la capacità di gestire più server che hanno accesso reciproco senza consentire ai cloni di una macchina di impersonare la sua origine, di solito involontariamente (crontab rimanenti, errore umano).

— Didi Kohen
fonte

3

Vorrei aggiungere che su CentOS 7 (7.1.1503) e quindi su Red Hat Enterprise Linux 7, non sono stato in grado di accedere con l'impostazione predefinita di yesper UseDNS. Dopo aver commentato e impostato su no, sono stato in grado di accedere. Quindi sembra che si possa davvero negare il servizio se il DNS non funziona correttamente! In CentOS 6, sembra che l'impostazione predefinita sia noe quindi posso farlo sshsenza DNS funzionante!

Vorrei aggiungere che la mia sperimentazione era su contenitori LXC e non su macchine fisiche, nel caso in cui ciò faccia la differenza!

— AnthonyK
fonte