私はこれをここに投稿するのかセキュアSEに投稿するのか悩んでいましたが、これは実際には暗号化に関する質問ではなく、Linuxユーザー/権限に関するそれ以上の質問ではないので、Unix SEを使用することにしました。今日私のGoogleは弱いかもしれませんが、これまで私が遭遇した唯一のことは
- 具体的な例なしで、これが「悪い慣行」または「人気のない」ものに非常に一般的な答えを提供します。
- パスワードのないユーザーがrootアクセス権を持っていると仮定するか、可能な限りすべての保護を放棄するという回答があります。
明らかに、私はこれを擁護するのではなく、実際に妥当な理由を探しています。いいえそうするのに、単に「これは悪い」ではなく、具体的な理由を探したい。 :-)
それでは、実際にこの質問について考えた例を挙げてみましょう。
ホームシステムの設定を検討しており、アカウントに強力なパスワードがあるとしましょうroot。また、私はfredという非ルートアカウントそれはいいえ管理者グループwheel（またはsudoersDebian / Ubuntu）。このシステムには、/home起動中にロックが解除される別のLUKS暗号化パーティションもあります。つまり、パスワードはするそれでもGRUBとログインマネージャの間に入力されていますが、ログインマネージャは自動的にログインするように設定されています。これに加えて、（rootで）以下を設定するとしますpassword -f -u fred。強制ロック解除パスワードfred（fredパスワードは空白のままにしておくと効果的です）。
この状況ではどのようなセキュリティ問題が発生する可能性がありますか？あなたがこのことをしたくないと感じるには、もっともらしい理由が必要です。しかし、ただこれまで私が考えたことは次のとおりです。
- スクリーンセーバーロックを実行してもLUKSパーティションは閉じられません（少なくともCinnamonでははいトリガーとして設定）。したがって、誰かが自分の家に侵入して
fredすでにログインしている場合は、fredまずコンピュータを取り外し/再起動/削除しない限り、座ってモニターの電源を入れてアクセスできるすべての項目を見ることができます（したがってLUKSを再ロックします）。十分に努力している場合は、スクリーンセーバーが実行されたときにスクリプトを呼び出してから、そのスクリプトでLUKSをロックすると（またはkde / xfce / gnome / etcが既にどのような方法を持っている可能性があります）、この脆弱性を閉じる方法がわかります。 ）これを処理するには？ ）。
強力で強力なパスワードを使用してもfred管理者でなければソフトウェアをインストールできず、システム設定がめちゃくちゃになります。また、わかりませんが、ファイルへのブラウザ/ワインアクセスがどのように変更されないと思います。もしケースよりも危険なものはありますか？fred したパスワードがありますか？
編集：それは重要ではないと思いますが、ディストリビューションはFedora（SELinuxアクティベーション）ですが、他のディストリビューション（またはSELinuxアクティベーションなし）で応答する方が快適であると感じる場合は、それでも問題ありません。
編集＃2：関連ssh/ samba。私は通常Samba共有などを/media/sdb1/shared使用するのではなく、フォルダのようなものを設定します。$HOME私はこれが家のような小規模なユーザー環境で設定するのがとても簡単であることがわかりました。 （明らかに、作業環境やすべてのユーザーがお互いを信頼していない環境ではこれを行うわけではありません）smb.conf。強化するためのいくつかのガイドラインに従ってください。この設定で障害が見つかった場合は、ログインアカウントに空のパスワードを使用して仮想シナリオ/設定を攻撃するのに有効であると想定しますfred（Sambaアカウントのパスワードは、いいえ空ですが）。
の場合、ssh基本的に空のパスワードが拒否されることを確認したいと思います。みんなアカウント（と同様root）。そうでなければ、FelixJNの答えが有効だと思います。それ以外の場合は、おそらくsamba通常使用するのと同じ設定、つまり基本構成の拡張バージョンを使用します。これに関する多くの設定を変更した記憶がないので、一般的に修正した内容を正確に見つけてここに含めることができるかどうか調べてみましょう。わかりません。ポート番号を変更しても構いません。
拒否を確認したとき、LM19は（force）フラグをサポートしていないようですssh。 LM19ボックスからFedoraに切り替えようとすると拒否されます。passwd-fssh
$ ssh -p 2468 fred@fedora-testbox
fred@fedora-testbox's password:
Permission denied, please try again.
fred@fedora-testbox's password:
Permission denied, please try again.
ポートに加えて、許可されている最小パスワード/ MAC / KexAlgorithmsを増やして//を減らした後LoginGraceTime//を設定したようです。のための:MaxAuthTriesMaxSessionsPermitRootLogin noUsePAM yesChallengeResponseAuthentication noPermitEmptyPasswordsいいえがデフォルトのようです。しかし、私は明らかにしました。
ベストアンサー1
私が考える最大の実際的な理由は、一部のネットワークソフトウェアを使用すると、誰かがパスワードなしでリモートでコンピュータにログインできることです。リスクは、あなたが知っているソフトウェアにあるのではなく、あなたが考慮しないソフトウェアにあります。おそらくディストリビューションに付属のソフトウェアです。
パスワードを持たないユーザーの場合は、コンピュータのすべてのネットワーク接続サービスを確認して、パスワードなしでリモートログインを許可することを確認する必要があります。
一般的なセキュリティ原則は、誰もがロックし、誰もが入らないようにすることで「失敗」したいということです。パスワードのないユーザーがいる場合、間違いや単純な不注意により、どこかにバックドアがロック解除されやすくなります。
たとえば、電子メールサーバーが挙げられます。パブリックIPv4アドレスを持つマシンがある場合は、次のことが保証されます。〜する毎週または毎日SMTPにログインしてみてください。ハッカーは脆弱なシステムを見つけるためにすべてのIPv4アドレスをシャットダウンします（アドレスはわずか40億です）。
SSHでも同様です。 OpenSSHは、パスワードなしで（認証は不要）ログイン試行を拒否するように構成されているため、おそらく安全です。しかし、毎日ハッカーは、パスワードが空のユーザー名を見つけようとしています。彼らは、何千もの共通のユーザー名を循環しながら幸運を願っています。