DuoSecurityを使用したLinuxでの2faの実装経験

最近のZeronights会議で、 2要素認証と、その実装にどのような問題があるかについて話しました。 残念ながら、このトピックに完全に没頭するのに十分な時間はなかったので、個々の投稿でいくつかの詳細を開示しようとします。
そして、最も人気のあるトピック、つまりLinuxでの2要素認証から始めましょう-構成オプションとは何か、そして非常に優れたソリューションでさえファイルで完成させる必要がある理由です。

カスタマイズオプション

私が言ったように、Linuxの2faテーマは非常に人気があり、これを可能にする多くのソリューションがあります。

sshによる認証の2番目の要素を作成するには、主に2つの方法があります。 最初の方法は擬似秒の要素であり、sshd設定のForceCommandオプションを使用して、承認ステージの後に任意のバイナリを開始します。

www.openssh.com/txt/release-4.4

この方法の利点は何ですか？ openssh4.4でサポートが追加されたため、適切な設定をオンにできないサーバーを見つけることはほとんどありません。 これで、利点は本質的に終わります。 短所ははるかにあります：

• tcpportforwardを有効にしている場合、バイナリ内の既存のチェックをバイパスしてポートを転送できます。
• rcファイルに書き込まれたものはすべてForceCommandの前に実行されるため、そこにexec shの実行を登録し、毎回2番目の要因で入力を確認することはできません。
• ユーザーがsftpまたはscpを介してサーバーに接続すると、sshクライアントを使用した標準ログインの場合に印刷できる招待状は表示されません。 したがって、この場合のユーザーの利便性は事実上無効になります。

そのため、ほとんどの手順で提供されている2番目の方法を検討します。 もちろん、これはpamモジュールを使用した設定です。

PAMによる2番目の要因

古典的なスクリプトは/etc/pam.d/sshd configの修正であり、適切なモジュールが最初におよそ次の形式で配置されます。

auth required pam_google_authenticator.so 

ただし、これは、認証がPAMレベルで実行されない場合は問題を解決しませんが、キーによる認証など、sshdサーバー自体を使用して実行されます。 この場合の対処方法

認証方法

幸い、バージョン6.2以降のopensshでは、2番目の要素をネイティブでサポートしていました。 これで、 AuthenticationMethodsオプションを使用して、サーバーに入るために正常に渡される必要がある認証方法をリストできます。

lwn.net/Articles/544640

同様の構成の例：

 AuthenticationMethods publickey,password hostbased,publickey 

ここに何が書かれていますか？ 認証を成功させるには、次の組み合わせのいずれかを実行する必要があります。

• 公開鍵+パスワード
• またはホストベース+公開鍵

しかし、二要素認証のためにモジュールをどこに接続するのでしょうか？ キーボードインタラクティブ方式で接続されます。 つまり、同じgoogle authモジュールを介したpublickeyによる認証後に確認が必要な場合は、sshd構成で次を設定します。

 AuthenticationMethods publickey,keyboard-interactive 

また、 pam.d / sshdファイルで次を指定します。

 auth required pam_google_authenticator.so 

すべてが非常に簡単です。 ただし、1つの方法がsshd（publickeyまたはkerberos）のレベルで実行され、もう1つの方法がpam（同じパスワード）のレベルで実行される場合、さらにいくつかの認証方法を有効にする必要があります。 問題は、パスワードとキーボードインタラクティブの両方が同じpam-configで処理されることです。 このようなsshd構成の場合、認証の第1段階を第2段階から分離する方法を何らかの方法で学習する必要があります。

 AuthenticationMethods password,keyboard-interactive publickey,keyboard-interactive 

私はこの問題の解決策を長い間探していましたが、facebookがそれ自体で2番目の要因を作った方法の説明に出会いました。

www.slideshare.net/yandex/004-tim-tickelchadgreene2fac
www.youtube.com/watch?v=pY4FBGI7bHM

Facebookの警備員が自宅で2faを実装することについて話したとき、彼らはAuthentication Submethodsに言及しました 。 これにより、認証を特定のデバイスに制限できます。 その結果、同僚はデュオを介してキーボードインタラクティブの認証を指定することができました。

lwn.net/Articles/544640（dugsongからのコメント）

しかし、これらのコミットまたは希望するバージョンのopenssh-6.2p1を見つける試みは失敗しました。 したがって、問題をさらに調査することが決定されました。

パムセットアップ実験

ここでも、PAMスタックとは何か、モジュールを接続できるオプションは何かを思い出します。 authセクションの標準接続オプション（必須、必須、十分、オプション）を誰もが覚えています。

しかし、これらのオプションのみを使用してモジュールを組み合わせた実験では何も起こりませんでした。 キー認証の場合でもユーザーにパスワードを要求するか、パスワードを再入力することで2番目の要素をバイパスすることができます。

そして、PAMのチューニングをより細かく開始します。 結果のステータスごとに、スタックへの影響を示すことができます。 1つ以上のプラグインをスキップします。

たとえば、このように。

 auth [success=1 default=ignore] pam_radius_auth.so 

duosecurityを介して2要素を設定するとき、ユーザーとのインタラクティブな対話が不可能な場合に、モジュールがPAM_ABORTのみを返すことに気づいたため、まさにこのpam構成を作成しました。 つまり、認証は次のようになり始めます。

 AuthenticationMethods gssapi-with-mic,keyboard-interactive password,keyboard-interactive 

そして、config pam.d / sshdは次のようになります。

 auth [success=2 abort=ignore default=1] /lib64/security/pam_duo.so auth [success=1 default=ignore] pam_unix.so nullok_secure auth requisite pam_deny.so auth required pam_permit.so 

可能な認証の最初のバージョン-gssapi-with-mic、キーボードインタラクティブで何が起こるかを検討してください

ユーザーはKerberosチケットを使用してログインし、キーボードインタラクティブ認証を実行する必要があります。 pam_duoモジュールは正常に接続されます。成功した場合、 PAM_PERMITへの移行は、他のすべてのバリエーションでPAM_DENYに続きます。 すべてが非常に簡単です。

ログインがパスワードで保護されている場合はどうなりますか。 pam-modulesの同じスタックを満たしますが、pam_duoを初期化できず、 PAM_ABORTが返されます。 なぜなら abort = ignoreと書かれています。何の影響もありません。制御は次のpam_unixモジュールに渡されます。 すべてが順調であれば、第2段階への移行が行われます-キーボードインタラクティブで、上記のメカニズムが繰り返されます。

はい、すべてが大丈夫のようです。 しかし、ニュアンスがあります。

pam_duoを使用すると、追加の設定を指定できます（認証が必要なユーザーと認証が不要なユーザー）。

duo.com/docs/duounix#duo-configuration-options

そのような構成の例を次に示します。

 groups = users,!wheel,!*admin 

そして、テストの結果、何がわかりましたか？ 例によると、ユーザーがwheelグループに属している場合、モジュールはPAM_SUCCESSを返しますが、これはかなり論理的です。 しかし、これはモジュールの初期化を試みる前に、つまりパスワード段階でも戻ります。 したがって、そのようなユーザーのログインを知っている場合、2番目の要素をバイパスするだけでなく、ユーザーのパスワードさえ知らなくてもシステムにログインできます。 一般的に、完全な障害。

2番目の機能もあります。 pam.d / sshdではなく、通常は他のモジュールで接続されるグローバル設定であるpassword-authの設定を変更すると、ローカルコンソールを介したログインが発生し、モジュールがインタラクティブな相互作用で接続できるようになります。 つまり、検証の最初の段階がスキップされ、2番目の要素がすぐにチェックされます。ここでは、例外グループでアカウント名を知ることができます。 これも失敗です。

ファイルのファイナライズ

しかし、後戻りはできないため、ソースコードの読み取りを開始します。
すべてのチェックが行われるメインファイル：

github.com/duosecurity/duo_unix/blob/master/pam_duo/pam_duo.c

pam_sm_authenticate関数に興味があります 。 ソースを調べると、モジュールとモジュールを呼び出すアプリケーション（この場合はsshd）の間でやり取りする関数を呼び出すことができることがわかります。

man7.org/linux/man-pages/man3/pam_get_item.3.html
man7.org/linux/man-pages/man3/pam_conv.3.html

約5つのセグメンテーション違反（テスト中および固定モジュールの接続中）の後、パスワードとキーボードインタラクティブの場合にどのパラメーターが異なるかを確認します。 テストは、指定された機能を使用してギャップを引き出そうと試みました。 pam_conv構造体のrespへのポインターは、成功すると0になります。

その結果、2つの機能を実行する変更されたソースを取得します。モジュールがパスワードステージで接続されると、 PAM_AUTHINFO_UNAVAILが返されます。 また、サービス名がsshdと異なる場合は、 PAM_AUTHINFO_UNAVAILを返します（ローカルコンソールからログインする際の上記の状況を回避するため）。

gist.github.com/videns/5348e3cc04fbce3a8c26fe3c99a61b50/revisions

さて、すべてのサーバーへのインストールの利便性のために、たとえば同じfpmを使用してパッケージを収集します。

変更したモジュールをインストールした後、pam.d / sshdに最新の変更を加える必要があります。

 auth [success=2 authinfo_unavail=ignore default=1] /lib64/security/pam_duo.so auth [success=1 default=ignore] pam_unix.so nullok_secure auth requisite pam_deny.so auth required pam_permit.so 

その結果、モジュールがキーボードインタラクティブステージで接続されていない場合、応答PAM_AUTHINFO_UNAVAILが返され、スタックで処理されます。 他のすべてのオプションでは、成功するとpam_denyまたはpam_permitに移行します。

また、サービスで使用され、したがって一度に1つのファクターを入力する必要があるアカウントについては、sshd構成のMatchパラメーターを使用して個別の設定を行うことができます。

要約すると、非常に優れたソリューションであっても、ユーザーが次のようにならないように、ファイルを少し変更する必要がある場合が多いと言えます。



また、2要素認証に関する詳細情報を共有する準備ができました。たとえば、レーキは統合時に存在していたり​​、duosecurityプロバイダーの興味深い機能を説明したりします。