sshdの「UseDNS」オプションのポイントは何ですか？

79

私はそれが何をするのか知っていますが、その理由はわかりません。どのような攻撃を防ぎますか？

あらゆる種類の認証方法に関連していますか？（ホストベース、パスワード、公開鍵、キーボードインタラクティブ...）

— user368507
ソース

2

ここでもCoreOSに追加しました：github.com/coreos/bugs/issues/92

66

このUseDNSオプションはほとんど役に立ちません。クライアントマシンがインターネット上にある場合、リバースDNSがないか、リバースDNSが順方向に解決しないか、またはDNSが「これに属する」以外の情報を提供しない可能性が高くなります。 IPアドレスが既に通知しているISP」。

通常の構成では、DNSはロギングにのみ使用されます。認証に使用できますが、IgnoreRhosts noで指定されてsshd_configいる場合のみです。これは、あなたが「と呼ばれるユーザーと言うことができRSH、使われていた古いインストールとの互換性のためであるbobというマシン上では、darkstarとしてログインするalice（書き込むことにより、任意の資格情報を示すことなく、」darkstar bob中を~alice/.rhosts）。sshサーバーに接続している可能性のあるすべてのマシンを信頼する場合にのみ安全です。つまり、これが安全な方法で使用されることはほとんどありません。

DNSルックアップは、非常に特殊な状況を除いて有用な情報を提供しないため、オフにする必要があります。私が知る限り、デフォルトでオンになっている唯一の理由は、ごく一部の状況にしか当てはまらないとしても、技術的に安全であるということです（可用性ではなく認証が心配な場合）。

この機能をオフにする別の議論は、余分な機能はすべて不必要なセキュリティリスクであるということです。

— ジル
ソース

したがって、UseDNSはホストベースの認証にのみ関係しますか？ホストベースの認証を使用せず、ホスト名またはIPがログに表示されるかどうかを気にしない場合、UseDNSは違いを生じませんか？

— user368507

5

@ user368507はい、それだけです。キーベースのホスト認証を使用している場合は、ホスト名ベースのホスト認証を使用している場合（つまり、非常に弱い認証）でUseDNSさえも役に立ちません。

— ジル

3

もちろん、@ Gillesは、キーベースおよびホスト名ベースの認証を使用する場合、UseDNS非常に便利で重要です。MACアドレスに割り当てられたキーに基づいてユーザーを認証し、ホスト名に基づいてサーバーを認証します。

— カラデニズ

38

これについて、Ubuntuのバグレポート（古いが、現在も最新）に追加しました。

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

デフォルトを「いいえ」に変更し、新しいドキュメントを追加することを提案しました。

# 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.

— ロドニー
ソース

2

upvote ...これは、私が探していた情報が含まれているため、より便利です。

— 0xC0000022L

1

同様に、UseDNSがnoの場合、pam_accessルールでホスト名を一致させることができず、代わりにIPを使用する必要があります。

— ColinM

1

私は数年前にこの答えを支持しましたが、今日になってようやく、OpenSSH 6.8p1ではデフォルトが「UseDNS no」に変更されました。これはUbuntu 15.10以降です。

— アンソニー・ジョゲガン

RedHat（RHEL7）は最近、デフォルトを同様にNoに変更しました。これにより、ホスト名ベースのアクセス制御（イントラネット上のアドバイザリー制御として有用であり、明らかに唯一のアクセス制御メカニズムとしては役立ちません）。

— ダニーザウアー

8

のマンページから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”.

これを有効にすると、適切な（順方向および逆方向）DNSがない場所からのアクセスがログに警告を生成します。

そのため、警告をログに記録しないためには、クライアントの修飾されたリモートアドレスが必要になることを除いて、攻撃を防ぐことはできません。このような警告は、そのPTRレコードが意味をなす場合にのみ、攻撃者を追跡するのに役立ちます。

^{編集：Andrey Voitenkovのコメントに従って更新。}

— ガートダイク
ソース

DNSサーバーにあるものに基づいて、だれが接続を許可されるのかというフィルターです。

— user368507

2

なぜアクセスできなくなるのですか？DNS A / PTRレコードが一致しない場合、sshdは警告を生成します。問題を解決する場合、ログオンシーケンスは遅くなります。

— アンドレイヴォイテンコフ

これにより、攻撃者がfrom=問題の認証キー（使用されている場合）の前にフィールドの値をスプーフィングできない限り、認証キーが侵害された場合にアクセスが防止されます。

— アレッツ

7

authorized_keysファイルでFROMオプションを使用し、IPだけでなく名前でフィルタリングする場合に必要です。

authorized_keysファイルの行のFROMオプションを使用すると、特定のキーを使用できるホストを制限できます。
これにより、通常は意図せずにマシンのクローンがその起源になりすますことなく、相互にアクセスできる複数のサーバーを管理する能力が向上します（残されたcrontab、人為的エラー）。

— ディディ・コーエン
ソース

3

私はCentOSの7（1503年7月1日）、したがって、Red Hat Enterprise Linuxに7上のことを追加したいと思い、私がいたができないのデフォルト設定を使用してログインするyesためUseDNS。コメントを外してに設定した後no、ログインできました。したがって、DNSが正しく機能していない場合、実際にサービスを拒否される可能性があります。CentOSの6で、デフォルトは表示されますnoので、私ができるとsshいない機能のDNSで！

私の実験は、物理マシンではなく、LXCコンテナーで行われたということを付け加えたいと思います。

— アンソニーK
ソース